Hi Sean, guys,
On 10/15/2014 10:47 AM, Sean Cross wrote:
On 15/10/2014 12:47, Nikolay Dimitrov wrote:
Hi Marek,
On 10/15/2014 12:38 AM, Marek Vasut wrote:
On Sunday, October 12, 2014 at 08:33:21 AM, Sean Cross wrote:
On 12/10/2014 05:04, Fabio Estevam wrote:
On Sat, Oct 11, 2014 at 11:21 AM, Sean Cross <x...@kosagi.com> wrote:
Ok, understood. Just curious: which Ethernet PHY is used on the
novena
board?
It's the same Micrel PHY used on the Sabrelite, the KSZ9021.
nitrogen/sabrelite holds Ethernet PHY reset low for 10ms, which is in
accordance with ksz9021 datasheet.
Shouldn't we wait 10ms here as well?
The reference manual for the PHY indicates that you should hold reset
low for 10ms after the supply voltage stabilizes. So long as it takes
at least 10msto get from the point at which the CPU starts executing
its
ROM code to the point at which the reset line is toggled, we will
be fine.
This definitelly is the case, so I presume we don't need the delay ?
Well, here's how I see the case.
After power on, the PHY unfortunately is out of reset (R20G is DNP,
imx6 pin pulled high internally after reset). At some unknown point in
time the CPU reaches novena_spl_setup_iomux_enet(). During all this
time the PHY is still out of reset. Neither this complies with the
recommended sequence, and even more doesn't comply if we remove the
delay.
If we leave the delay as it is currently implemented, the actual reset
sequence is just delayed (by the time it takes the CPU to reach the
PHY reset code). At this later point we enforce the proper reset
sequence: supply rail is obviously now stable, and we keep the PHY
reset low for the minimum specified time: 10ms.
My understanding is that this is simple and efficient way to guarantee
that for all different cases (different temperatures, different CPU
silicon revisions, differently configured drivers/subsystems), the PHY
reset timing is generated properly, and will be generated properly in
the future when the code evolves.
Please tell me if I'm missing something.
I generally think we'd be fine without the delay, putting it into reset
in the SPL and pulling it out of reset in U-Boot, but I can understand
the need for future-proofing and clarity. If someone were to copy the
code from Novena to a new board, they may find the PHY behaving unreliably
If 10ms is the difference between "we ought to be fine" and "we'll
definitely be fine and not surprise anyone", then we should leave the
delay in.
Oops, I think my position on this topic seems to be "too hard headed". I
just wanted to justify why I wrote the patch this way, and I didn't
wanted to look like an opposition.
Sean, you're in the position of the "oem", so I definitely appreciate
your opinion, together with Marek's and Fabio's imx6 expertise.
So guys, please advice - what should be the final value of this delay,
and I'll re-send the patch if needed.
Kind regards,
Nikolay
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
