Skip to content
  1. Dec 22, 2015
  3. Dec 15, 2015
  5. Dec 11, 2015
    • Stefan Agner's avatar
      ARM: dts: vf610: use reset values for L2 cache latencies · 9c171905
      Stefan Agner authored 
      Linux on Vybrid used several different L2 latencies so far, none
of them seem to be the right ones. According to the application note
AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
on CPU clock and is inside the L2 cache controller, whereas the data
portion is stored in the external SRAM running on platform clock.
Hence it is likely that the correct value requires a higher data
latency then tag latency.

These are the values which have been used so far:
- The mainline values:
  arm,data-latency = <1 1 1>;
  arm,tag-latency = <2 2 2>;
  Those values have lead to problems on higher clocks. They look
  like a poor translation from the reset values (missing +1 offset
  and a mix up between tag/latency values).
- The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
  arm,data-latency = <4 2 3>
  arm,tag-latency = <4 2 3>
  The cache initialization function along with the value matches the
  i.MX6 code from the same kernel, so it seems that those values have
  just been copied.
- The Colibri values:
  arm,data-latency = <2 1 2>;
  arm,tag-latency = <3 2 3>;
  Those were a mix between the values of the Linux 3.0 based BSP and
  the mainline values above.
- The SoC Reset values (converted to DT notation):
  arm,data-latency = <3 3 3>;
  arm,tag-latency = <2 2 2>;

So far there is no official statement on what the correct values are.
See also the related Freescale community thread:
https://community.freescale.com/message/579785#579785



For now, the reset values seem to be the best bet. Remove all other
"bogus" values and use the reset value on vf610.dtsi level.

Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      9c171905
  7. Dec 02, 2015
    • Stefan Agner's avatar
      ARM: dts: vf610: fix clock definition for SAI2 · 531ee1f4
      Stefan Agner authored 
      So far, only the bus clock has been assigned, but in reality the
SAI IP has for clock inputs. The driver has been updated to
make use of the additional clock inputs by c3ecef21

 ("ASoC:
fsl_sai: add sai master mode support"). Due to a bug in the
clock tree, the audio clock has been enabled none the less by
the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
clock tree"), which made master mode even without the proper
clock assigned working.

This patch completes the clock definition for SAI2. On Vybrid,
only two MCLK out of the four options are available (the first
being the bus clock itself). See chapter 8.10.1.2.3 of the
Vybrid Reference manual ("SAI transmitter and receiver options
for MCLK selection"). Note: The audio clocks are only required
in master mode.

Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      531ee1f4
  9. Nov 24, 2015