6 messages, 3 authors, 2012-07-20 · open the first message on its own page
From: andrew@lunn.ch (Andrew Lunn)
Date: 2012-07-20 14:41:33
Hi Ian
Good to hear you got SATA working. What was wrong?
I'm interested in Ethernet. I assume it uses
drivers/net/ethernet/marvell/mv643xx_eth.c?
If so, your work should be applicable for all Orion devices, and i'm
happy to test on kirkwood.
Andrew
From: Ian Molton <hidden>
Date: 2012-07-20 15:35:41
On 20/07/12 15:41, Andrew Lunn wrote:
Hi Ian
Hi! Good to hear you got SATA working. What was wrong? Window setup was wrong - mostly just the function setting it up simply not getting called. I suspect that this platform rather badly needs the clock stuff implementing. > I'm interested in Ethernet. I assume it uses drivers/net/ethernet/marvell/mv643xx_eth.c? AIUI, yes. I havent checked yet. > If so, your work should be applicable for all Orion devices, and i'm happy to test on kirkwood. Cheers! :) -Ian
From: Thomas Petazzoni <hidden>
Date: 2012-07-20 15:52:37
Le Fri, 20 Jul 2012 16:41:33 +0200, Andrew Lunn [off-list ref] a ?crit :
I'm interested in Ethernet. I assume it uses drivers/net/ethernet/marvell/mv643xx_eth.c?
No, the network IP in the A370 and AXP is totally different and Marvell engineers think it needs a new driver, and I have been making internal reviews of their driver, but it needs more work before being ready for submission. 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 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 -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
From: Ian Molton <hidden>
Date: 2012-07-20 16:05:26
On 20/07/12 16:52, Thomas Petazzoni wrote:
Le Fri, 20 Jul 2012 16:41:33 +0200, Andrew Lunn [off-list ref] a ?crit :quoted
I'm interested in Ethernet. I assume it uses drivers/net/ethernet/marvell/mv643xx_eth.c?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.
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? the window setup code looks horrid to me - we really should look for a way to pass this in nicely.
From: Thomas Petazzoni <hidden>
Date: 2012-07-20 16:12:58
Le Fri, 20 Jul 2012 17:05:26 +0100, Ian Molton [off-list ref] a ?crit :
quoted
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.
quoted
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, ThomasThe 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
From: Ian Molton <hidden>
Date: 2012-07-20 16:25:46
On 20/07/12 17:12, Thomas Petazzoni wrote:
Le Fri, 20 Jul 2012 17:05:26 +0100, Ian Molton
> [off-list ref] 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? Certainly. >> 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? For now, yes. Since it sounds like it'll be acceptable to use plat-orion, I will redo my patch to do that, and post it here.
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. Looks like a couple of base addresses differ. I'll let you know if this causes any trouble on monday.
Would you mind sharing the current state of your SATA work, even if
> not ready for prime time? Sure, I'll sort out posting it up first thing monday.
quoted
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. I'll take a look. Cheers, -Ian