Hello,
I am looking into developing a driver for a custom, non-PCI SATA
controller. The target arch is Microblaze, an FPGA-based NOMMU target
on a 2.4.29-uc0 kernel.
It seems that Jeff Garzik's libata is the way to go for SATA, however
there seems to be some degree of coupling between libata and PCI support.
Some comments/observations, please correct me if I am wrong:
- include/linux/libata.h appears to recognise that CONFIG_PCI may not
be set, however libata-compat.h is entirely PCI-specific. Indeed, it
effectively maps generic bus/dma operations onto their pci-specific
equivalents. Also, libata.h unconditionally includes pci.h.
- All of the drivers/scsi/sata_XXX drivers target PCI devices only.
It seems I have a few choices here.
Option 1 is to just hack together stubbed PCI support for my arch,
making our on-chip bus pretend to be PCI for the purposes of libata (and
indeed many other bus subsystems, like USB). This is pretty unclean,
particularly since it is entirely likely that someone will build a
microblaze system with a true PCI bridge and bus, meaning that this
temporary hack would certainly come back to haunt me[1].
Option 2 is to try to decouple libata from PCI support. This may be as
simple as a conditional inclusion of libata-compat.h from libata.h,
however I am not yet familiar enough with libata to be sure.
For now this will be staying in the NOMMU 2.4 kernel (uClinux), but if I
choose option (2) I would like to work with libata, not against it. It
may well be that non-PCI SATA support is a Good Thing in a broader
sense, so perhaps this is a good discussion to have anyway.
All input, suggestions and comments welcome.
Thanks,
John
[1] There is a bigger picture here, that with FPGA-based CPUs like
Microblaze, we can build systems with arbitrary CPU/memory/IO bus
topologies. Indeed, we do so on a daily basis. In the back of my mind
I am envisioning some kind of generic bus abstraction API, of which PCI,
USB etc would be mere instances.
--
John Williams, Research Fellow,
Embedded Systems Group / Reconfigurable Computing
School of ITEE, The University of Queensland, Brisbane, Australia
Hi,
On Mar 21, 2005 1:20 AM, John Williams <[email protected]> wrote:
> Hello,
>
> I am looking into developing a driver for a custom, non-PCI SATA
> controller. The target arch is Microblaze, an FPGA-based NOMMU target
> on a 2.4.29-uc0 kernel.
>
> It seems that Jeff Garzik's libata is the way to go for SATA, however
> there seems to be some degree of coupling between libata and PCI support.
>
> Some comments/observations, please correct me if I am wrong:
>
> - include/linux/libata.h appears to recognise that CONFIG_PCI may not
> be set, however libata-compat.h is entirely PCI-specific. Indeed, it
This is because generic DMA API and generic driver model
are not present in 2.4.x kernels.
> effectively maps generic bus/dma operations onto their pci-specific
> equivalents. Also, libata.h unconditionally includes pci.h.
>
> - All of the drivers/scsi/sata_XXX drivers target PCI devices only.
>
> It seems I have a few choices here.
>
> Option 1 is to just hack together stubbed PCI support for my arch,
> making our on-chip bus pretend to be PCI for the purposes of libata (and
> indeed many other bus subsystems, like USB). This is pretty unclean,
> particularly since it is entirely likely that someone will build a
> microblaze system with a true PCI bridge and bus, meaning that this
> temporary hack would certainly come back to haunt me[1].
>
> Option 2 is to try to decouple libata from PCI support. This may be as
> simple as a conditional inclusion of libata-compat.h from libata.h,
> however I am not yet familiar enough with libata to be sure.
Option 2 is better then Option 1. You may need to add
#ifdefs for DMA support on your arch to libata-compat.h
(kind of hack which shouldn't be needed in 2.6.x).
> For now this will be staying in the NOMMU 2.4 kernel (uClinux), but if I
> choose option (2) I would like to work with libata, not against it. It
> may well be that non-PCI SATA support is a Good Thing in a broader
> sense, so perhaps this is a good discussion to have anyway.
>
> All input, suggestions and comments welcome.
>
> Thanks,
>
> John
>
> [1] There is a bigger picture here, that with FPGA-based CPUs like
> Microblaze, we can build systems with arbitrary CPU/memory/IO bus
> topologies. Indeed, we do so on a daily basis. In the back of my mind
> I am envisioning some kind of generic bus abstraction API, of which PCI,
> USB etc would be mere instances.
Use 2.6.x :)
Bartlomiej