From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Dimitrov Date: Wed, 15 Oct 2014 22:16:03 +0300 Subject: [U-Boot] [PATCH V7] ARM: mx6: Add support for Kosagi Novena In-Reply-To: <543E2691.5060903@kosagi.com> References: <1412990082-8628-1-git-send-email-marex@denx.de> <543A20B1.5000500@kosagi.com> <201410142338.35674.marex@denx.de> <543DFC6D.9050503@mail.bg> <543E2691.5060903@kosagi.com> Message-ID: <543EC7F3.4040403@mail.bg> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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