On Tue, 2016-03-29 at 10:41:27 -0700, Eric Wong wrote:
> Thanks Soren,
>
> So the 2nd ethernet port wasn't originally working in Linux because,
> without those two lines, Linux wasn't able to initialize the clock
> frequency for the GEM driver correctly, but the HW itself was fine? And a
> bare-metal app should be fine as long as I am using the same FSBL for my
> bare-metal application as I was using for Linux? Will give it a go and
> see. Thanks!
In theory yes ;)
>
> However, while debugging this before discovering the fix, I was having the
> Linux kernel print out debug logs for any writes to Zynq clock control
> registers (e.g., APER_CLK_CTRL, GEM1_CLK_CTRL) and something was
> manipulating/changing them during Linux boot up. Do you know what in the
> Linux kernel would possibly be controlling them? Unfortunately, I can't
> say which exact bits were being changed now, so perhaps it was unrelated to
> GEM1 clocking.
There are essentially two things that could happen:
1. Drivers changing clock state:
Every driver is expected to handle its input clocks. At a bare
minimum that means to enable/disable them, which for HW clocks that
provide the option, would change the corresponding state of the
clock gate.
More complex drivers could do even more and request changes of the
frequency (GEM does that as it is required to adjust the link speed
if needed). That can result, depending on the underlying drivers, in
changes to muxes and dividers (on Zynq only dividers should change).
2. Kernel changing clock state
Linux expects that all clocks are modeled in the clock framework and
that every clock is controlled by some user. I.e. if there is a
user, it should have told the kernel so by enabling the clock. Under
that assumption, Linux disables all clocks that do not have an
active user during the boot process.
A common case where this happens is that the fclks are used to clock
PL components that do not have a corresponding Linux driver that
complies to these conventions/frameworks. As a result the clock may
be gated off, even though something is using it as Linux is not
aware of any usage. For those particular cases the 'fclk-enable'
property was introduced
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/zynq-7000.txt#n26)
Sören
>
> Eric
>
>
>
> On Tue, Mar 29, 2016 at 9:59 AM, Sören Brinkmann wrote:
>
> > The DT must describe the HW. And those two lines do just that, they
> > describe your board/bitstream-specific clocking for the Ethernet core.
> > As long as you don't use any SOC-external clocking resources, the
> > abstraction in Linux is essentially containing the whole model of Zynq's
> > clock tree in this 'clkc' object. Based on internal registers and the
> > one parameter in DT specifying the oscillator frequency, SW can then
> > detect how the clocks are muxed and what frequencies they are running on.
> >
> > If you use the EMIO option for clocking though, Linux will read the
> > clock mux for the Ethernet clock, but it has no knowledge about what
> > clock might feed into that EMIO input. Hence, in such cases, you have to
> > provide that information in DT. In this particular case, you tell Linux
> > that you have connected output 17 of the clkc (fclk2
> > (
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/zynq-7000.txt#n58
> > ))
> > to the EMIO input for gem1
> > (
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/zynq-7000.txt#n31
> > ).
> > That enables Linux to correctly complete the SW representation of the
> > clock tree and calculate the clock frequencies. With that the GEM
> > driver can enable all relevant clocks and read/generate the correct
> > frequencies.
> >
> > Bare-metal has nothing like that. Assuming that you have clock
> > frequencies, muxes etc. configured correctly in Vivado, the FSBL should
> > correctly set these things up and nothing more should be needed. Adding
> > that description to the DT does not change any HW state, it just ensures
> > that Linux can create its SW state that is consistent with reality,
> > which may be required for the GEM driver to work correctly (I suspect it
> > would not like an input frequency of 0).
> >
> > Sören
> >
--
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx
