sata AHCI controller over non-PCI bus

sata AHCI controller over non-PCI bus

[Subbrathnam, Swaminathan]

Hi,

            I would like to post support for OMAPL138 SATA controller that is AHCI 1.1 compliant.  OMAPL138 is an ARM926 based platform.

Current "ahci.c" assumes that AHCI is getting supported over PCI by default, whereas the SATA AHCI controller on OMAPL138 is connected to a non-PCI bus.  Since I am in the process of posting the support I would like to get the  opinion from the community on how to proceed on this front.  I see the following 2 options today

1.       #ifdef the PCI specific code in ahci.c and implement the platform_device based implementation to support non-PCI AHCI controllers.

2.       Re-organize the ahci.c to abstract the AHCI functionalities from PCI, non-PCI bus dependencies.

Currently we have implemented Option 1 in our internal tree to support SATA on OMAPL138 platform and it works well.  Ideally I would want to proceed with Option 2 but would like get feedback from the community before proceeding in this direction.

 

Regards

swami

Re: sata AHCI controller over non-PCI bus

[Sergei Shtylyov]

Hello.

Subbrathnam, Swaminathan wrote:
> Hi,
>
>             I would like to post support for OMAPL138 SATA controller that is AHCI 1.1 compliant.  OMAPL138 is an ARM926 based platform.
>
> Current "ahci.c" assumes that AHCI is getting supported over PCI by default, whereas the SATA AHCI controller on OMAPL138 is connected to a non-PCI bus.  Since I am in the process of posting the support I would like to get the  opinion from the community on how to proceed on this front.

   Well, you're not the first with this problem, Marvell already had it.

>   I see the following 2 options today
>
> 1.       #ifdef the PCI specific code in ahci.c and implement the platform_device based implementation to support non-PCI AHCI controllers.
>   

   I don't think this is a community-acceptable option at all.

> 2.       Re-organize the ahci.c to abstract the AHCI functionalities from PCI, non-PCI bus dependencies.
>
> Currently we have implemented Option 1 in our internal tree to support SATA on OMAPL138 platform and it works well.  Ideally I would want to proceed with Option 2 but would like get feedback from the community before proceeding in this direction.

   See 
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=shortlog;h=libahci 
for Jeff Garzik's work on separating AHCI support from PCI.

MBR, Sergei

Re: sata AHCI controller over non-PCI bus

[Sergei Shtylyov]

Hello, I wrote:

>>             I would like to post support for OMAPL138 SATA controller 
>> that is AHCI 1.1 compliant.  OMAPL138 is an ARM926 based platform.
>>
>> Current "ahci.c" assumes that AHCI is getting supported over PCI by 
>> default, whereas the SATA AHCI controller on OMAPL138 is connected to 
>> a non-PCI bus.  Since I am in the process of posting the support I 
>> would like to get the  opinion from the community on how to proceed 
>> on this front.
>
>   Well, you're not the first with this problem, Marvell already had it.

   Er, not Marvell... Synopsis. :-<

>> 2.       Re-organize the ahci.c to abstract the AHCI functionalities 
>> from PCI, non-PCI bus dependencies.
>>
>> Currently we have implemented Option 1 in our internal tree to 
>> support SATA on OMAPL138 platform and it works well.  Ideally I would 
>> want to proceed with Option 2 but would like get feedback from the 
>> community before proceeding in this direction.
>
>   See 
> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=shortlog;h=libahci 
> for Jeff Garzik's work on separating AHCI support from PCI.

   Well, no, it doesn't separate PCI code yet (and the task for this 
patchset was different). Yet it was a step in that direction... I 
suggest that you somehow coordinate with Sagar Borikar, see his initial 
patch here:

http://marc.info/?l=linux-ide&m=123807608819226

MBR, Sergei

RE: sata AHCI controller over non-PCI bus

[Subbrathnam, Swaminathan]

Jeff,
	From the below link (from Sergei) it seems that you have already re-factored the AHCI implementation dependency on PCI.  I would like to add support for the OMAPL138 SATA on top of your changes.  That would be the ideal way forward for me.

	Have the ahci re-factoring changes queued for mainline merge already?  I just joined the list and hence do not know the status.

Sergei,
	Appreciate the response.

Regards
swami

-----Original Message-----
From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] 
Sent: Monday, August 10, 2009 2:33 PM
To: Subbrathnam, Swaminathan
Cc: linux-ide@vger.kernel.org
Subject: Re: sata AHCI controller over non-PCI bus

Hello.

Subbrathnam, Swaminathan wrote:
> Hi,
>
>             I would like to post support for OMAPL138 SATA controller that is AHCI 1.1 compliant.  OMAPL138 is an ARM926 based platform.
>
> Current "ahci.c" assumes that AHCI is getting supported over PCI by default, whereas the SATA AHCI controller on OMAPL138 is connected to a non-PCI bus.  Since I am in the process of posting the support I would like to get the  opinion from the community on how to proceed on this front.

   Well, you're not the first with this problem, Marvell already had it.

>   I see the following 2 options today
>
> 1.       #ifdef the PCI specific code in ahci.c and implement the platform_device based implementation to support non-PCI AHCI controllers.
>   

   I don't think this is a community-acceptable option at all.

> 2.       Re-organize the ahci.c to abstract the AHCI functionalities from PCI, non-PCI bus dependencies.
>
> Currently we have implemented Option 1 in our internal tree to support SATA on OMAPL138 platform and it works well.  Ideally I would want to proceed with Option 2 but would like get feedback from the community before proceeding in this direction.

   See 
http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=shortlog;h=libahci 
for Jeff Garzik's work on separating AHCI support from PCI.

MBR, Sergei

Re: sata AHCI controller over non-PCI bus

[Jeff Garzik]

Subbrathnam, Swaminathan wrote:
> Jeff,
> 	From the below link (from Sergei) it seems that you have already re-factored the AHCI implementation dependency on PCI.  I would like to add support for the OMAPL138 SATA on top of your changes.  That would be the ideal way forward for me.
> 
> 	Have the ahci re-factoring changes queued for mainline merge already?  I just joined the list and hence do not know the status.
> 
> Sergei,
> 	Appreciate the response.

I store the refactoring in git, on the "libahci" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

Unfortunately, I am having second thoughts about an element of the 
current design.  With current Linux distributions, they do not appear to 
deal well with the multi-module dependency libata -> libahci -> ahci. 
If I had to guess, I would say that mkinitrd creation tools only look at 
one tree level's worth of kernel module dependencies.

Thus, ahci would wind up -not- in initrd, in a libahci solution.

I am thinking that I will just add Marvell and ATP support to ahci.c, 
and let someone else deal with libahci separation -- which is still needed.

At this point, I would rather get Marvell/ATP support into users' hands, 
rather than wait for distros to catch up to modern technology.

	Jeff

RE: sata AHCI controller over non-PCI bus

[Subbrathnam, Swaminathan]

Jeff,

I can work on the seperation aspects as I need to get the OMAPL138 SATA solution working.  I will try to provide a basic implementation by end of this week.  Pl. provide your feedback on the same if we need to further refine it to address broad use cases.

Thanks for your response.

regards
swami

________________________________________
From: Jeff Garzik [jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org]
Sent: Sunday, August 16, 2009 6:23 PM
To: Subbrathnam, Swaminathan
Cc: Sergei Shtylyov; linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; LKML
Subject: Re: sata AHCI controller over non-PCI bus

Subbrathnam, Swaminathan wrote:
> Jeff,
>       From the below link (from Sergei) it seems that you have already re-factored the AHCI implementation dependency on PCI.  I would like to add support for the OMAPL138 SATA on top of your changes.  That would be the ideal way forward for me.
>
>       Have the ahci re-factoring changes queued for mainline merge already?  I just joined the list and hence do not know the status.
>
> Sergei,
>       Appreciate the response.

I store the refactoring in git, on the "libahci" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

Unfortunately, I am having second thoughts about an element of the
current design.  With current Linux distributions, they do not appear to
deal well with the multi-module dependency libata -> libahci -> ahci.
If I had to guess, I would say that mkinitrd creation tools only look at
one tree level's worth of kernel module dependencies.

Thus, ahci would wind up -not- in initrd, in a libahci solution.

I am thinking that I will just add Marvell and ATP support to ahci.c,
and let someone else deal with libahci separation -- which is still needed.

At this point, I would rather get Marvell/ATP support into users' hands,
rather than wait for distros to catch up to modern technology.

        Jeff

RE: sata AHCI controller over non-PCI bus

[Subbrathnam, Swaminathan]

Jeff,

I can work on the seperation aspects as I need to get the OMAPL138 SATA solution working.  I will try to provide a basic implementation by end of this week.  Pl. provide your feedback on the same if we need to further refine it to address broad use cases.

Thanks for your response.

regards
swami

________________________________________
From: Jeff Garzik [jeff@garzik.org]
Sent: Sunday, August 16, 2009 6:23 PM
To: Subbrathnam, Swaminathan
Cc: Sergei Shtylyov; linux-ide@vger.kernel.org; LKML
Subject: Re: sata AHCI controller over non-PCI bus

Subbrathnam, Swaminathan wrote:
> Jeff,
>       From the below link (from Sergei) it seems that you have already re-factored the AHCI implementation dependency on PCI.  I would like to add support for the OMAPL138 SATA on top of your changes.  That would be the ideal way forward for me.
>
>       Have the ahci re-factoring changes queued for mainline merge already?  I just joined the list and hence do not know the status.
>
> Sergei,
>       Appreciate the response.

I store the refactoring in git, on the "libahci" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

Unfortunately, I am having second thoughts about an element of the
current design.  With current Linux distributions, they do not appear to
deal well with the multi-module dependency libata -> libahci -> ahci.
If I had to guess, I would say that mkinitrd creation tools only look at
one tree level's worth of kernel module dependencies.

Thus, ahci would wind up -not- in initrd, in a libahci solution.

I am thinking that I will just add Marvell and ATP support to ahci.c,
and let someone else deal with libahci separation -- which is still needed.

At this point, I would rather get Marvell/ATP support into users' hands,
rather than wait for distros to catch up to modern technology.

        Jeff

Re: sata AHCI controller over non-PCI bus

[James Bottomley]

On Sun, 2009-08-16 at 08:53 -0400, Jeff Garzik wrote:
> Subbrathnam, Swaminathan wrote:
> > Jeff,
> > 	From the below link (from Sergei) it seems that you have already re-factored the AHCI implementation dependency on PCI.  I would like to add support for the OMAPL138 SATA on top of your changes.  That would be the ideal way forward for me.
> > 
> > 	Have the ahci re-factoring changes queued for mainline merge already?  I just joined the list and hence do not know the status.
> > 
> > Sergei,
> > 	Appreciate the response.
> 
> I store the refactoring in git, on the "libahci" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> 
> Unfortunately, I am having second thoughts about an element of the 
> current design.  With current Linux distributions, they do not appear to 
> deal well with the multi-module dependency libata -> libahci -> ahci. 
> If I had to guess, I would say that mkinitrd creation tools only look at 
> one tree level's worth of kernel module dependencies.
> 
> Thus, ahci would wind up -not- in initrd, in a libahci solution.
> 
> I am thinking that I will just add Marvell and ATP support to ahci.c, 
> and let someone else deal with libahci separation -- which is still needed.
> 
> At this point, I would rather get Marvell/ATP support into users' hands, 
> rather than wait for distros to catch up to modern technology.

Can't you get the best of both worlds?  Do the separation but
artificially glue them together again as a module at link time.  This
solves the current distro problem and you can remove the linker hack as
soon as the distros get their act together.

James

---

diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 9f7b500..10101d7 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -1,8 +1,10 @@
 
 obj-$(CONFIG_ATA)		+= libata.o
 
-obj-$(CONFIG_SATA_AHCI)		+= libahci.o ahci.o
-obj-$(CONFIG_SATA_ACARD_AHCI)	+= libahci.o acard-ahci.o
+obj-$(CONFIG_SATA_AHCI)		+= ahci_mod.o
+obj-ahci_mod-y			+= libahci.o ahci.o
+obj-ahci_mod-$(CONFIG_SATA_ACARD_AHCI)	+= acard-ahci.o
+obj-ahci_mod-$(CONFIG_SATA_MV_AHCI)	+= mv-ahci.o
 obj-$(CONFIG_SATA_SVW)		+= sata_svw.o
 obj-$(CONFIG_ATA_PIIX)		+= ata_piix.o
 obj-$(CONFIG_SATA_PROMISE)	+= sata_promise.o
@@ -15,7 +17,6 @@ obj-$(CONFIG_SATA_SIS)		+= sata_sis.o
 obj-$(CONFIG_SATA_SX4)		+= sata_sx4.o
 obj-$(CONFIG_SATA_NV)		+= sata_nv.o
 obj-$(CONFIG_SATA_ULI)		+= sata_uli.o
-obj-$(CONFIG_SATA_MV_AHCI)	+= libahci.o mv-ahci.o
 obj-$(CONFIG_SATA_MV)		+= sata_mv.o
 obj-$(CONFIG_SATA_INIC162X)	+= sata_inic162x.o
 obj-$(CONFIG_PDC_ADMA)		+= pdc_adma.o

Re: sata AHCI controller over non-PCI bus

[Robert Hancock]

On 08/16/2009 06:53 AM, Jeff Garzik wrote:
> Subbrathnam, Swaminathan wrote:
>> Jeff,
>> From the below link (from Sergei) it seems that you have already
>> re-factored the AHCI implementation dependency on PCI. I would like to
>> add support for the OMAPL138 SATA on top of your changes. That would
>> be the ideal way forward for me.
>>
>> Have the ahci re-factoring changes queued for mainline merge already?
>> I just joined the list and hence do not know the status.
>>
>> Sergei,
>> Appreciate the response.
>
> I store the refactoring in git, on the "libahci" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
> Unfortunately, I am having second thoughts about an element of the
> current design. With current Linux distributions, they do not appear to
> deal well with the multi-module dependency libata -> libahci -> ahci. If
> I had to guess, I would say that mkinitrd creation tools only look at
> one tree level's worth of kernel module dependencies.
>
> Thus, ahci would wind up -not- in initrd, in a libahci solution.
>
> I am thinking that I will just add Marvell and ATP support to ahci.c,
> and let someone else deal with libahci separation -- which is still needed.
>
> At this point, I would rather get Marvell/ATP support into users' hands,
> rather than wait for distros to catch up to modern technology.

If that's the case it seems clearly a mkinitrd bug. What distribution 
were you seeing this behavior on?

Re: sata AHCI controller over non-PCI bus

[Jeff Garzik]

On 08/16/2009 11:34 AM, James Bottomley wrote:
> Can't you get the best of both worlds?  Do the separation but
> artificially glue them together again as a module at link time.  This
> solves the current distro problem and you can remove the linker hack as
> soon as the distros get their act together.
>
> James
>
> ---
>
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 9f7b500..10101d7 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -1,8 +1,10 @@
>
>   obj-$(CONFIG_ATA)		+= libata.o
>
> -obj-$(CONFIG_SATA_AHCI)		+= libahci.o ahci.o
> -obj-$(CONFIG_SATA_ACARD_AHCI)	+= libahci.o acard-ahci.o
> +obj-$(CONFIG_SATA_AHCI)		+= ahci_mod.o
> +obj-ahci_mod-y			+= libahci.o ahci.o
> +obj-ahci_mod-$(CONFIG_SATA_ACARD_AHCI)	+= acard-ahci.o
> +obj-ahci_mod-$(CONFIG_SATA_MV_AHCI)	+= mv-ahci.o


Yeah, that could definitely be an option...

	Jeff