[PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
Jason Cooper
jason at lakedaemon.net
Wed May 29 04:02:27 EST 2013
Jason,
Sorry, I meant to get back to this earlier and it slipped off of my
plate. :(
On Fri, May 24, 2013 at 11:33:06AM -0600, Jason Gunthorpe wrote:
> On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote:
>
> > > Why are you not keen on this? It seems like normal device driver
> > > practice, that is what the data field of of_device_id is typically
> > > used for..
> >
> > I'm not keen on it because we don't have a document saying "All kirkwood
> > SoCs need PSC1 set to X after reset." We know it, but have we tested
> > the 6282?
>
> I disagree. The manul is very clear how PSC1 must be set for proper
> operation. Clk125BypassEn bit is used only for loopback testing, it
> should never set for driver operation. Similarly PortReset must be
> cleared for driver operation.
>
> It is always safe for the driver to clear these bits, if it knows they
> are available. In fact, I would argue the driver should always clear
> these bits so that the bootloader isn't relied on to do it. It doesn't
> matter if the SOC errantly sets the bit or not, it can *always* be
> safely cleared.
Great!
> Further, I compared my 88F6282/88F6283 manual against the public
> 88F6180/88F619x/88F6281 spec and confirmed that the PSC1 layout is the
> same.
Even better.
> So all of these SOC's can share a driver compatible string.
Ok, "marvell,kirkwood-eth" works for me then. I think Sebastian already
has patches for that.
> AFAICT the only reason the driver doesn't touch PSC1 today is because
> the PSC1 was introduced in a later IP revision and its presence isn't
> auto-detectable.
Makes sense.
> The last bit of the puzzle to get bootloader independence on kirkwood
> is to encode the phy interface type (GMII/RGMII/BASE-X) in the DT so
> the entire PSC1 can be set by the driver..
Hmm, let's work on that separately, and later. I've snowballed this
attempt enough ;-)
Thanks for digging into this for us,
Jason.
More information about the Linuxppc-dev
mailing list