SATA working on 370/XP, Ethernet next...
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Fri Jul 20 12:12:58 EDT 2012
Le Fri, 20 Jul 2012 17:05:26 +0100,
Ian Molton <ian.molton at codethink.co.uk> a écrit :
> > A while ago, we had a discussion with Ben Dooks (from CodeThink) on
> > whether a new driver was needed or not. Ben will correct me if I'm
> > wrong, but he was suggesting that a new driver was not needed, but both
> > Marvell engineers and my comparison of the datasheets between A370/AXP
> > and older Marvell EBU SoCs clearly show that this IP has changed
> > dramatically, and is even not the same IP as before.
> > If needed, I can post the network driver code in a RFC state, but it
> > is clearly not yet ready for inclusion.
>
> I would certainly like to see that if possible, it'd definitley help my
> analysis of the problem.
Ok. I am not sure I wanted to submit this publicly on the netdev
mailing list right now, because the first feeling with a given patch
set is an important one. Would a private submission be possible?
I have been busy the last two days reviewing the code, making many
cleanups on it and collecting comments for the Marvell engineer who
wrote the code initially.
> > I would of course be happy to test SATA patches for the Armada XP.
> > Ian, did you reuse the plat-orion/addr-map.c code to do the window
> > setup? Best regards, Thomas
>
> The code is very similar, and could probably be merged with that. is
> plat-orion meant to now be common to orion, kirkwood, and armada?
Ok, so you duplicated the addr-map.c code?
Initially, I didn't want to use the plat-orion/ code, because I wanted
to replace that with proper drivers (i.e pinctrl driver instead of MPP,
gpio driver in drivers/gpio, proper platform driver for PCI, etc.). But
many drivers (SATA, SDIO, etc.) need the headers file from plat-orion/.
So reusing those drivers without using plat-orion/ is not that simple.
Would you mind sharing the current state of your SATA work, even if not
ready for prime time?
> the window setup code looks horrid to me - we really should look for a
> way to pass this in nicely.
I had started a discussion with Andrew on the mailing list earlier this
week, and we agreed for the moment to re-use the existing code, and see
later what could be done to expose this in the device tree.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the linux-arm-kernel
mailing list