Messages in this thread | | | Date | Tue, 5 Apr 2005 18:37:34 +0200 | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: [SATA] non-PCI SATA devices and libata |
| |
Hi,
On Mar 21, 2005 1:20 AM, John Williams <jwilliams@itee.uq.edu.au> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |