[lkml]   [2005]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [SATA] non-PCI SATA devices and libata

    On Mar 21, 2005 1:20 AM, John Williams <> 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 :)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-06 13:31    [W:0.053 / U:6.596 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site