Re: sata AHCI controller over non-PCI bus

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@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

[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

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?