[lkml]   [2002]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFT][PATCH] generic device DMA implementation
    Adam J. Richter wrote:
    > Odd number of ">" = David Brownell
    > Even number of ">>" = Adam Richter

    Toggle that one more time ... ;)

    > On the other hand, it might be a convenient shorthand be able to
    > say dma_malloc(usb_device,....) instead of
    > dma_malloc(usb_device->controller, ...). It's just that the number of
    > callers is small enough so that I don't think that the resulting code
    > shrink would make up for the size of the extra wrapper routines. So,

    Since about 2.5.32 that API has been

    void *usb_buffer_alloc(usb_device *, size, mem_flags, dma_addr_t *)

    Sure -- when dma_alloc() is available, we should be able to make it
    inline completely. Done correctly it should be an object code shrink.

    > struct device {
    > ....
    > struct dma_device *dma_dev;
    > }
    > device.dma_dev would point back to the device in the case of PCI,
    > ISA and other memory mapped devices, and it would point to the host
    > controller for USB devices, the SCSI host adapter for SCSI devices, etc.

    With 'dma_device' being pretty much the 'whatsit' I mentioned: some state
    (from platforms that need it, like u64 dma_mask and maybe a list of pci
    pools to use with dma_malloc), plus methods basically like James' signatures
    from 'struct bus_dma_ops'.

    Yes, that'd be something that might be the platform implementation (often
    pci, if it doesn't vanish like on x86), something customized (choose dma
    paths on the fly) or just BUG() out.

    > BUG() is generally the optimal way to fail due to programmer
    > error, as opposed to program error. You want to catch the bug as
    > early as possible.

    I can agree to that in scenarios like relying on DMA ops with hardware
    known not to support them. If it ever happens, there's deep confusion.

    But not in the case of generic dma "map this buffer" operations failing
    because of issues like temporary resource starvation; or almost any
    other temporary allocation failure that appears after the system booted.

    >>Please look at the 2.5.53 tree with my "usbcore dma updates (and doc)"
    >>patch, which Greg has now merged and submitted to Linus.
    > This looks great. Notice that you're only doing DMA
    > operations on usb_device->controller, which is a memory-mapped device
    > (typically PCI).

    Actually it isn't necessarily ... some host controllers talk I/O space
    using FIFOs for commands and data, rather than memory mapping registers,
    shared memory request schedules, and DMAing to/from the kernel buffers.
    Linux would want a small tweak to support those controllers; maybe it'd
    be as simple as testing whethere there's a dma_whatsit object pointer.

    The usb_buffer_*map*() calls could now be inlined, but I thought I'd rather
    only leave one copy of all the "don't go through null pointer" checking.
    If we ever reduce such checking in USB, those routines would all be
    good candidates for turning into inlined calls to dma_*() calls.

    - Dave

    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-03-22 13:32    [W:0.024 / U:6.040 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site