Re: swi_vm() and busdma_swi()?

[Sepherosa Ziehau <sepherosa@xxxxxxxxx>]

On Wed, Dec 1, 2010 at 2:07 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :If the system is short of bounce pages and the buffer to be loaded
> :needs to be bounced (i.e. needs to be copied to the address that is
> :accessible to device.  This usually happens on the system w/ more than
> :4Gbytes memory, since most old devices can't access physical addresses
> :above 4Gbytes), then those drivers will not work under these
> :situation.
> :
> :Best Regards,
> :sephe
>
>    I'd like to rip out the entire bounce buffer mechanism and replace
>    it with a fixed pre-allocation of bounce memory for the entire kernel,

Err, the current busdma API supports pre-allocation bounce buffer
zones for address restrictions and alignment constraints, all of the
network device drivers use that features (I think I converted all of
the network drivers early 2009).

>    for both 24 and 31/32 bit address restrictions.
>
>    Then we can get rid of all the async bounce buffer junk across the
>    board and replace it with normal driver-friendly synchronous bounce

AFAIR, bus_dmamap_load() is the only one that still supports async
callback.  As I had pointed out, some drivers (most of them are for
storage related devices) were coded for async callback (the callback,
the TX logic and the RX logic), all of these drivers should be
reworked or dropped, if we are going to drop the async callback.

>    buffers and a simple API call a driver can call when it is holding
>    no locks to block in a friendly way when bounce buffers are short.

Yeah, agree.

Best Regards,
sephe

-- 
Tomorrow Will Never Die