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

[Sean Cross <xobs@kosagi.com>]

On 16/10/2014 03:16, Nikolay Dimitrov wrote:
> 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@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.

My opinion is that, following the principle of least surprise, we should
leave the delay in.  If, sometime in the future, someone were to
micro-optimize the boot sequence, they can strip it out then, but in
that case it'd make more sense to load Linux directly from SPL.

I say leave it in.


Sean