Following this will be two patches, refreshing the minimalist SPI stack
I've sent before. Notable changes are:
- Various updates to support real hardware, including reporting the
IRQ associated with an SPI slave chip, providing void* handles for
various flavors of board and controller state, dma_addr_t for I/O
buffers, some control over protocol delays, and more.
- New spi_alloc_master(). The driver model is happier if drivers
don't allocate the class devices; this helps "rmmod" and friends,
kind of handy for debugging drivers. It allocates controller
specific memory not unlike alloc_netdev().
- Various cleanup, notably removing Kconfig for all those drivers
that don't yet exist. That was added purely to illustrate the
potential scope of an SPI framework, when more folk were asking
just why a Serial Peripheral Interface (*) was useful.
- More kerneldoc. No Documentation/DocBook/spi.html though.
- Now there's a real ADS7864 touchscreen/sensor driver; lightly
tested, but it emits the right sort of input events and gives
syfs access to the temperature, battery, and voltage sensors.
This version seems real enough to integrate with.
One goal is promote reuse of driver code -- for SPI controllers and
slave chips connected using SPI -- while fitting them better into the
driver model framework. Today, SPI devices only seem to get drivers
that are board-specific; there's a fair amount of reinvent-the-wheel,
and drivers that are unsuitable for upstream merging.
I can now report this seems to be working with real controllers and
real slave chips ... two of each to start with, but as yet there's no
mix'n'match (with e.g. that touchscreen driver being used with a PXA
SSP controller, not just OMAP MicroWire). That should just take a
little bit of time and debugging.
- Dave
(*) And distinguish it from Singapore Paranormal Investigators. ;)
Hi,
can you please describe the data flow in case of DMA transfer? Thanks!
Vitaly
David Brownell wrote:
>Following this will be two patches, refreshing the minimalist SPI stack
>I've sent before. Notable changes are:
>
> - Various updates to support real hardware, including reporting the
> IRQ associated with an SPI slave chip, providing void* handles for
> various flavors of board and controller state, dma_addr_t for I/O
> buffers, some control over protocol delays, and more.
>
> - New spi_alloc_master(). The driver model is happier if drivers
> don't allocate the class devices; this helps "rmmod" and friends,
> kind of handy for debugging drivers. It allocates controller
> specific memory not unlike alloc_netdev().
>
> - Various cleanup, notably removing Kconfig for all those drivers
> that don't yet exist. That was added purely to illustrate the
> potential scope of an SPI framework, when more folk were asking
> just why a Serial Peripheral Interface (*) was useful.
>
> - More kerneldoc. No Documentation/DocBook/spi.html though.
>
> - Now there's a real ADS7864 touchscreen/sensor driver; lightly
> tested, but it emits the right sort of input events and gives
> syfs access to the temperature, battery, and voltage sensors.
>
>This version seems real enough to integrate with.
>
>One goal is promote reuse of driver code -- for SPI controllers and
>slave chips connected using SPI -- while fitting them better into the
>driver model framework. Today, SPI devices only seem to get drivers
>that are board-specific; there's a fair amount of reinvent-the-wheel,
>and drivers that are unsuitable for upstream merging.
>
>I can now report this seems to be working with real controllers and
>real slave chips ... two of each to start with, but as yet there's no
>mix'n'match (with e.g. that touchscreen driver being used with a PXA
>SSP controller, not just OMAP MicroWire). That should just take a
>little bit of time and debugging.
>
>- Dave
>
>(*) And distinguish it from Singapore Paranormal Investigators. ;)
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Hi Vitaly,
> can you please describe the data flow in case of DMA transfer? Thanks!
In the current model, the controller driver handles it (assuming
that it uses DMA not PIO):
- Use dma_map_single() at some point between the master->transfer()
call and the time the DMA address is handed to DMA hardware.
- Probably store those addresses in the spi_transfer struct, using
rx_dma and/or tx_dma as appropriate.
- After the DMA transfer completes, call dma_unmap_single() before
calling spi_message.complete(spi_message.context).
There are two fancier approaches to consider for sometime later, both
of which have been used for several years now by host-side USB.
* SPI controller drivers could require the mappings to already
have been done, and stored in {rx,tx}_dma fields. When those
drivers are using DMA, they'd only use those DMA addresses.
The way host-side USB does that is by having usbcore do work
on all the submit and giveback paths. Currently this SPI
framework doesn't do "core" work on those paths; spi_async()
just calls directly to the controller driver (no overhead!)
and the completion reports likewise go right from controller
driver back to the submitter (also, no overhead).
* Drivers for SPI slave chips might sometimes want to provide their
own rx_dma and/or tx_dma values ... either because they mapped the
buffers themselves -- great for dma_map_sg()! -- or because the
memory came from dma_alloc_coherent().
This implies that the controller drivers are ready to accept
those DMA addresses, and that there are per-buffer flags saying
whether its DMA address is also valid (vs just its CPU address).
Note that the slave-side USB support only supports the latter, which
means the USB peripheral controller drivers with DMA support decide
on a per-request basis whether to do the DMA mappings. I'd lean
towards doing that with SPI; it's a bunch simpler.
Right now DMA isn't on my priority list, but I'd be glad to see
someone else take further steps there. Anyone doing bulk I/O to an
SPI flash chip at 50 MHz is surely going to want DMA for it!
- Dave
p.s. Please be sure to CC me on replies, so I'm sure to see them...
BTW, haven't seen any place where message->complete() is called... Can
you please point out one?
Vitaly
David Brownell wrote:
>Following this will be two patches, refreshing the minimalist SPI stack
>I've sent before. Notable changes are:
>
> - Various updates to support real hardware, including reporting the
> IRQ associated with an SPI slave chip, providing void* handles for
> various flavors of board and controller state, dma_addr_t for I/O
> buffers, some control over protocol delays, and more.
>
> - New spi_alloc_master(). The driver model is happier if drivers
> don't allocate the class devices; this helps "rmmod" and friends,
> kind of handy for debugging drivers. It allocates controller
> specific memory not unlike alloc_netdev().
>
> - Various cleanup, notably removing Kconfig for all those drivers
> that don't yet exist. That was added purely to illustrate the
> potential scope of an SPI framework, when more folk were asking
> just why a Serial Peripheral Interface (*) was useful.
>
> - More kerneldoc. No Documentation/DocBook/spi.html though.
>
> - Now there's a real ADS7864 touchscreen/sensor driver; lightly
> tested, but it emits the right sort of input events and gives
> syfs access to the temperature, battery, and voltage sensors.
>
>This version seems real enough to integrate with.
>
>One goal is promote reuse of driver code -- for SPI controllers and
>slave chips connected using SPI -- while fitting them better into the
>driver model framework. Today, SPI devices only seem to get drivers
>that are board-specific; there's a fair amount of reinvent-the-wheel,
>and drivers that are unsuitable for upstream merging.
>
>I can now report this seems to be working with real controllers and
>real slave chips ... two of each to start with, but as yet there's no
>mix'n'match (with e.g. that touchscreen driver being used with a PXA
>SSP controller, not just OMAP MicroWire). That should just take a
>little bit of time and debugging.
>
>- Dave
>
>(*) And distinguish it from Singapore Paranormal Investigators. ;)
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Hi David,
David Brownell wrote:
>Hi Vitaly,
>
>
>
>>can you please describe the data flow in case of DMA transfer? Thanks!
>>
>>
>
>In the current model, the controller driver handles it (assuming
>that it uses DMA not PIO):
>
> - Use dma_map_single() at some point between the master->transfer()
> call and the time the DMA address is handed to DMA hardware.
>
>
So that implies calling dma_map_single() for the memory allocated in stack?
I'm afraid I know at least one target which won't work with this
approach (Philips ARM926-driven board with ARM PrimeCell DMA controller).
> - Probably store those addresses in the spi_transfer struct, using
> rx_dma and/or tx_dma as appropriate.
>
> - After the DMA transfer completes, call dma_unmap_single() before
> calling spi_message.complete(spi_message.context).
>
>There are two fancier approaches to consider for sometime later, both
>of which have been used for several years now by host-side USB.
>
> * SPI controller drivers could require the mappings to already
> have been done, and stored in {rx,tx}_dma fields. When those
> drivers are using DMA, they'd only use those DMA addresses.
>
> The way host-side USB does that is by having usbcore do work
> on all the submit and giveback paths. Currently this SPI
> framework doesn't do "core" work on those paths; spi_async()
> just calls directly to the controller driver (no overhead!)
> and the completion reports likewise go right from controller
> driver back to the submitter (also, no overhead).
>
> * Drivers for SPI slave chips might sometimes want to provide their
> own rx_dma and/or tx_dma values ... either because they mapped the
> buffers themselves -- great for dma_map_sg()! -- or because the
> memory came from dma_alloc_coherent().
>
>
Of course we want to use scatter-gather lists. The DMA controller
mentioned above can handle only 0xFFF transfer units at a transfer so we
have to split the large transfers into SG lists.
> This implies that the controller drivers are ready to accept
> those DMA addresses, and that there are per-buffer flags saying
> whether its DMA address is also valid (vs just its CPU address).
>
>Note that the slave-side USB support only supports the latter, which
>means the USB peripheral controller drivers with DMA support decide
>on a per-request basis whether to do the DMA mappings. I'd lean
>towards doing that with SPI; it's a bunch simpler.
>
>
Doesn't look straightforward to me.
Moreover, that looks like it may imply redundant data copying.
Can you please elaborate what you meant by 'readiness to accept DMA
addresses' for the controller drivers?
As far as I see it now, the whole thing looks wrong. The thing that we
suggest (i. e. abstract handles for memory allocation set to kmalloc by
default) is looking far better IMHO and doesn't require any flags which
usage increases uncertainty in the core.
>Right now DMA isn't on my priority list, but I'd be glad to see
>someone else take further steps there. Anyone doing bulk I/O to an
>SPI flash chip at 50 MHz is surely going to want DMA for it!
>
>
Yep, as well as for SPI SD/MMC controllers, SPI WiFi modules, SPI
Bluetooth modules, etc. etc.
Best regards,
Vitaly
> BTW, haven't seen any place where message->complete() is called... Can
> you please point out one?
There are calls to that from the pxa2xx_spi_ssp.c controller driver
which Stephen Street posted.
http://marc.theaimsgroup.com/?l=linux-kernel&m=112846505323865&w=2
Unfortunately he's struggling with mailers that are mangling
his patches (tabs-to-spaces, quoted-printable, base64, etc)
so you'll have to cope for a while with wrong-formatting.
I didn't post the OMAP MicroWire driver since I've not yet split
it out from the previous non-drivermodel support, so the patch
would be useless to anyone not working with the Linux-OMAP tree.
- Dave
> > > can you please describe the data flow in case of DMA transfer? Thanks!
> >
> > In the current model, the controller driver handles it (assuming
> > that it uses DMA not PIO):
> >
> > - Use dma_map_single() at some point between the master->transfer()
> > call and the time the DMA address is handed to DMA hardware.
> So that implies calling dma_map_single() for the memory allocated in stack?
Calling that for whatever is passed, certainly.
But the <linux/spi.h> header does have a comment right next to the
declarations of spi_transfer.tx_buf and rx_buf, saying that "buffers
must work with dma_*map_single() calls.
In general all APIs that use DMA will follow the rules listed under
"What memory is DMA'able?" in:
linux/Documentation/DMA-mapping.txt
The rest of that file is a bit PCI-centric, but that section remains
the primary description of what can be DMA'd. I had assumed that went
without saying; permaps wrongly.
- Dave
> Of course we want to use scatter-gather lists.
The only way "of course" applies is if you're accepting requests
from the block layer, which talks in terms of "struct scatterlist".
In my investigations of SPI, I don't happen to have come across any
SPI slave device that would naturally be handled as a block device.
There's lots of flash (and dataflash); that's MTD, not block.
> The DMA controller
> mentioned above can handle only 0xFFF transfer units at a transfer so we
> have to split the large transfers into SG lists.
Odd, I've seen plenty other drivers that just segment large buffers
into multiple DMA transfers ... without wanting "struct scatterlist".
- Sometimes they turn them into lists of DMA descriptors handled
by their DMA controller. Even the silicon designers who talk
to Linux developers wouldn't choose "struct scatterlist" to
hold those descriptors
- More often they just break big buffers into lots of little
transfers. Just like PIO, but faster. (And in fact, they may
need to prime the pump with some PIO to align the buffer.)
- Sometimes they just reject segments that are too large to
handle cleanly at a low level, and require higher level code
to provide more byte-sized blocks of I/O.
If "now" _were_ the point we need to handle scatterlists, I've shown
a nice efficient way to handle them, already well proven in the context
of another serial bus protocol (USB).
> Moreover, that looks like it may imply redundant data copying.
Absolutely not. Everything was aimed at zero-copy I/O; why do
you think I carefully described "DMA mapping" everywhere, rather
than "memcpy"?
> Can you please elaborate what you meant by 'readiness to accept DMA
> addresses' for the controller drivers?
Go look at the parts of the USB stack I mentioned. That's what I mean.
- In the one case, DMA-aware controller drivers look at each buffer
to determine whether they have to manage the mappings themselves.
If the caller provided the DMA address, they won't set up mappings.
- In the other case, they always expect their caller to have set
up the DMA mappings. (Where "caller" is infrastructure code,
not the actual driver issuing the I/O request.)
The guts of such drivers would only talk in terms of DMA; the way those
cases differ is how the driver entry/exit points ensure that can be done.
> As far as I see it now, the whole thing looks wrong. The thing that we
> suggest (i. e. abstract handles for memory allocation set to kmalloc by
> default) is looking far better IMHO and doesn't require any flags which
> usage increases uncertainty in the core.
You are conflating memory allocation with DMA mapping. Those notions
are quite distinct, except for dma_alloc_coherent() where one operation
does both.
The normal goal for drivers is to accept buffers allocated from anywhere
that Documentation/DMA-mapping.txt describes as being DMA-safe ... and
less often, message passing frameworks will do what USB does and accept
DMA addresses rather than CPU addresses.
- Dave
On Wed, Oct 05, 2005 at 09:21:17AM -0700, David Brownell wrote:
> In my investigations of SPI, I don't happen to have come across any
> SPI slave device that would naturally be handled as a block device.
> There's lots of flash (and dataflash); that's MTD, not block.
In two words, MMC cards.
They can be used in MMC mode or SPI mode. There have been some queries
about using them in SPI mode, but I don't think anyone's written such
a driver (yet).
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
> Date: Wed, 5 Oct 2005 17:24:53 +0100
> From: Russell King <[email protected]>
>
> On Wed, Oct 05, 2005 at 09:21:17AM -0700, David Brownell wrote:
> > In my investigations of SPI, I don't happen to have come across any
> > SPI slave device that would naturally be handled as a block device.
> > There's lots of flash (and dataflash); that's MTD, not block.
>
> In two words, MMC cards.
With the interesting subcase of DataFlash cards, which are MMC format
but which only talk SPI protocol. Dataflash would go through MTD.
(Seems to me that DataFlash cards are now "old tech" not being put
into many new systems. Certainly they're not price-competitive with
MMC/SD ... DigiKey charges $US 28 for an 8 MB card, quantity one,
and that's the local price of a single 256 MB MMC or SD card. The
story with discrete DataFlash chips seems to be different.)
> They can be used in MMC mode or SPI mode.
Yes, but ... any system with an MMC controller would use them in
MMC mode; then they'd be "MMC devices". (Except DataFlash...)
The reason to use them in SPI mode is that that the system might
not _have_ an MMC controller, yet it might want inexpensive
removable storage.
(And there's another funky case too. Most MMC controllers will
handle SPI protocol directly; I'm not sure how full the support
is, maybe it's just enough to talk to MMC cards. But systems
that want SPI -- say, for sensors -- might do that using their
MMC controllers on one of the chipselects that's not used for
an external card slot.)
> There have been some queries
> about using them in SPI mode, but I don't think anyone's written such
> a driver (yet).
Nor does the MMC stack yet understand that notion... it'd likely
help a bit if there were an SPI framework to build on!
Teaching that stack how to work in SPI mode, or even represent
controllers which only support SPI protocol, would be a lot more
work than just letting SPI drivers optionally provide DMA addresses
as well as the CPU addresses for their buffers. :)
- Dave
David Brownell wrote:
>>Of course we want to use scatter-gather lists.
>>
>>
>
>The only way "of course" applies is if you're accepting requests
>from the block layer, which talks in terms of "struct scatterlist".
>
>In my investigations of SPI, I don't happen to have come across any
>SPI slave device that would naturally be handled as a block device.
>There's lots of flash (and dataflash); that's MTD, not block.
>
>
What about SD controllers on SPI bus? I did work with 2. ;-)
>
>
>
>> The DMA controller
>>mentioned above can handle only 0xFFF transfer units at a transfer so we
>>have to split the large transfers into SG lists.
>>
>>
>
>Odd, I've seen plenty other drivers that just segment large buffers
>into multiple DMA transfers ... without wanting "struct scatterlist".
>
>
I didn't claim that scatterlist is to be used. We use 'hardware-driven'
structures for sg lists.
> - More often they just break big buffers into lots of little
> transfers. Just like PIO, but faster. (And in fact, they may
> need to prime the pump with some PIO to align the buffer.)
>
>
That won't work in some cases, as SPI might generate additional clock
cycles after each transfer which won't happen un case of real sg transfer.
> - Sometimes they just reject segments that are too large to
> handle cleanly at a low level, and require higher level code
> to provide more byte-sized blocks of I/O.
>
>
It's possible in some cases but won't work in other. See above.
>If "now" _were_ the point we need to handle scatterlists, I've shown
>a nice efficient way to handle them, already well proven in the context
>of another serial bus protocol (USB).
>
>
>
>
>>Moreover, that looks like it may imply redundant data copying.
>>
>>
>
>Absolutely not. Everything was aimed at zero-copy I/O; why do
>you think I carefully described "DMA mapping" everywhere, rather
>than "memcpy"?
>
>
>
I'm afraid that copying may be implicit.
>
>
>>Can you please elaborate what you meant by 'readiness to accept DMA
>>addresses' for the controller drivers?
>>
>>
>
>Go look at the parts of the USB stack I mentioned. That's what I mean.
>
> - In the one case, DMA-aware controller drivers look at each buffer
> to determine whether they have to manage the mappings themselves.
> If the caller provided the DMA address, they won't set up mappings.
>
> - In the other case, they always expect their caller to have set
> up the DMA mappings. (Where "caller" is infrastructure code,
> not the actual driver issuing the I/O request.)
>
>The guts of such drivers would only talk in terms of DMA; the way those
>cases differ is how the driver entry/exit points ensure that can be done.
>
>
>
>
>>As far as I see it now, the whole thing looks wrong. The thing that we
>>suggest (i. e. abstract handles for memory allocation set to kmalloc by
>>default) is looking far better IMHO and doesn't require any flags which
>>usage increases uncertainty in the core.
>>
>>
>
>You are conflating memory allocation with DMA mapping. Those notions
>are quite distinct, except for dma_alloc_coherent() where one operation
>does both.
>
>The normal goal for drivers is to accept buffers allocated from anywhere
>that Documentation/DMA-mapping.txt describes as being DMA-safe ... and
>less often, message passing frameworks will do what USB does and accept
>DMA addresses rather than CPU addresses.
>
>
As for our core implementation it's totally agnostic about what kind of
addresses is used and what way it should be handled in; it's all left
for controller driver to decide. I still think it's far better approach
than lotsa pointers and flags.
Vitaly
--- David Brownell <[email protected]> wrote:
> > Of course we want to use scatter-gather lists.
>
> The only way "of course" applies is if you're accepting requests
> from the block layer, which talks in terms of "struct scatterlist".
If you look at the mmci driver (drivers/mcc/mmci.c) then you will see the way that driver
transfers data is do to one sg element at a time. I have added DMA support to this driver which
also does one element at a time (which uses the ARM PL080 DMAC). sg lists should not be for the
SPI layer to worry about. The fact that the PL080 DMAC controller can only transfer (4096-1)K
objects (the size of the object being the source size) should be of no concern to the driver that
uses DMA (either directly for through the SPI subsystem). It is the job of the PL080 driver to
split the requested transfer into several transfers that it can handle.
>
> In my investigations of SPI, I don't happen to have come across any
> SPI slave device that would naturally be handled as a block device.
> There's lots of flash (and dataflash); that's MTD, not block.
>
>
> > The DMA controller
> > mentioned above can handle only 0xFFF transfer units at a transfer so we
> > have to split the large transfers into SG lists.
>
> Odd, I've seen plenty other drivers that just segment large buffers
> into multiple DMA transfers ... without wanting "struct scatterlist".
>
> - Sometimes they turn them into lists of DMA descriptors handled
> by their DMA controller. Even the silicon designers who talk
> to Linux developers wouldn't choose "struct scatterlist" to
> hold those descriptors
>
> - More often they just break big buffers into lots of little
> transfers. Just like PIO, but faster. (And in fact, they may
> need to prime the pump with some PIO to align the buffer.)
>
> - Sometimes they just reject segments that are too large to
> handle cleanly at a low level, and require higher level code
> to provide more byte-sized blocks of I/O.
>
> If "now" _were_ the point we need to handle scatterlists, I've shown
> a nice efficient way to handle them, already well proven in the context
> of another serial bus protocol (USB).
>
>
> > Moreover, that looks like it may imply redundant data copying.
>
> Absolutely not. Everything was aimed at zero-copy I/O; why do
> you think I carefully described "DMA mapping" everywhere, rather
> than "memcpy"?
>
>
> > Can you please elaborate what you meant by 'readiness to accept DMA
> > addresses' for the controller drivers?
>
> Go look at the parts of the USB stack I mentioned. That's what I mean.
>
> - In the one case, DMA-aware controller drivers look at each buffer
> to determine whether they have to manage the mappings themselves.
> If the caller provided the DMA address, they won't set up mappings.
>
> - In the other case, they always expect their caller to have set
> up the DMA mappings. (Where "caller" is infrastructure code,
> not the actual driver issuing the I/O request.)
>
> The guts of such drivers would only talk in terms of DMA; the way those
> cases differ is how the driver entry/exit points ensure that can be done.
>
>
> > As far as I see it now, the whole thing looks wrong. The thing that we
> > suggest (i. e. abstract handles for memory allocation set to kmalloc by
> > default) is looking far better IMHO and doesn't require any flags which
> > usage increases uncertainty in the core.
>
> You are conflating memory allocation with DMA mapping. Those notions
> are quite distinct, except for dma_alloc_coherent() where one operation
> does both.
>
> The normal goal for drivers is to accept buffers allocated from anywhere
> that Documentation/DMA-mapping.txt describes as being DMA-safe ... and
> less often, message passing frameworks will do what USB does and accept
> DMA addresses rather than CPU addresses.
>
> - Dave
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Mark Underwood wrote:
>--- David Brownell <[email protected]> wrote:
>
>
>
>>>Of course we want to use scatter-gather lists.
>>>
>>>
>>The only way "of course" applies is if you're accepting requests
>>from the block layer, which talks in terms of "struct scatterlist".
>>
>>
>
>If you look at the mmci driver (drivers/mcc/mmci.c) then you will see the way that driver
>transfers data is do to one sg element at a time. I have added DMA support to this driver which
>also does one element at a time (which uses the ARM PL080 DMAC). sg lists should not be for the
>SPI layer to worry about. The fact that the PL080 DMAC controller can only transfer (4096-1)K
>objects (the size of the object being the source size) should be of no concern to the driver that
>uses DMA (either directly for through the SPI subsystem). It is the job of the PL080 driver to
>split the requested transfer into several transfers that it can handle.
>
>
mmci.c is not the only one existing MMC driver ;-)
>
>
>>In my investigations of SPI, I don't happen to have come across any
>>SPI slave device that would naturally be handled as a block device.
>>There's lots of flash (and dataflash); that's MTD, not block.
>>
>>
>>
>>
>>>The DMA controller
>>>mentioned above can handle only 0xFFF transfer units at a transfer so we
>>>have to split the large transfers into SG lists.
>>>
>>>
>>Odd, I've seen plenty other drivers that just segment large buffers
>>into multiple DMA transfers ... without wanting "struct scatterlist".
>>
>> - Sometimes they turn them into lists of DMA descriptors handled
>> by their DMA controller. Even the silicon designers who talk
>> to Linux developers wouldn't choose "struct scatterlist" to
>> hold those descriptors
>>
>> - More often they just break big buffers into lots of little
>> transfers. Just like PIO, but faster. (And in fact, they may
>> need to prime the pump with some PIO to align the buffer.)
>>
>> - Sometimes they just reject segments that are too large to
>> handle cleanly at a low level, and require higher level code
>> to provide more byte-sized blocks of I/O.
>>
>>If "now" _were_ the point we need to handle scatterlists, I've shown
>>a nice efficient way to handle them, already well proven in the context
>>of another serial bus protocol (USB).
>>
>>
>>
>>
>>>Moreover, that looks like it may imply redundant data copying.
>>>
>>>
>>Absolutely not. Everything was aimed at zero-copy I/O; why do
>>you think I carefully described "DMA mapping" everywhere, rather
>>than "memcpy"?
>>
>>
>>
>>
>>>Can you please elaborate what you meant by 'readiness to accept DMA
>>>addresses' for the controller drivers?
>>>
>>>
>>Go look at the parts of the USB stack I mentioned. That's what I mean.
>>
>> - In the one case, DMA-aware controller drivers look at each buffer
>> to determine whether they have to manage the mappings themselves.
>> If the caller provided the DMA address, they won't set up mappings.
>>
>> - In the other case, they always expect their caller to have set
>> up the DMA mappings. (Where "caller" is infrastructure code,
>> not the actual driver issuing the I/O request.)
>>
>>The guts of such drivers would only talk in terms of DMA; the way those
>>cases differ is how the driver entry/exit points ensure that can be done.
>>
>>
>>
>>
>>>As far as I see it now, the whole thing looks wrong. The thing that we
>>>suggest (i. e. abstract handles for memory allocation set to kmalloc by
>>>default) is looking far better IMHO and doesn't require any flags which
>>>usage increases uncertainty in the core.
>>>
>>>
>>You are conflating memory allocation with DMA mapping. Those notions
>>are quite distinct, except for dma_alloc_coherent() where one operation
>>does both.
>>
>>The normal goal for drivers is to accept buffers allocated from anywhere
>>that Documentation/DMA-mapping.txt describes as being DMA-safe ... and
>>less often, message passing frameworks will do what USB does and accept
>>DMA addresses rather than CPU addresses.
>>
>>- Dave
>>
>>-
>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>the body of a message to [email protected]
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>>
>
>
>
>
>___________________________________________________________
>How much free photo storage do you get? Store your holiday
>snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
>
>
>
>
On Wed, 2005-10-05 at 08:10 -0700, David Brownell wrote:
> Unfortunately he's struggling with mailers that are mangling
> his patches (tabs-to-spaces, quoted-printable, base64, etc)
> so you'll have to cope for a while with wrong-formatting.
Christ, why does this keep coming up again and again?!? People ARE
reporting these as a bug to the author of these mailers, right?
Lee