[U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena

[Nikolay Dimitrov]

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 <xobs at 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