Re: Proposal for new generic device API: dma_get_required_mask()

[Krzysztof Halasa <khc@pm.waw.pl>]

James Bottomley <James.Bottomley@steeleye.com> writes:

> If the driver decides to use the mask, it would do another
> dma_set_mask() to confirm it (this gives the platform the opportunity if
> it so chooses to return a mask that doesn't quite cover memory, but
> would be more optimal...say for platforms that have all memory under 4GB
> bar one small chunk at 64GB or something).

What I think drivers such as AIC7xxx should do is:

#define OUR_COST_32 = 4
#define OUR_COST_39 = 8
#define OUR_COST_64 = 10

int cost32 = check_dma_mask(32 bits);
int cost39 = check_dma_mask(39 bits);
int cost64 = check_dma_mask(64 bits);

if (!cost32  && !cost39 && !cost64)
	printk(KERN_ERR "64 bits aren't enough for RAM addressing?\n")
else
	use_mode_with_minimal_cost(cost32 * OUR_COST_32,
				   cost39 * OUR_COST_39,
				   cost64 * OUR_COST_64);

This check_dma_mask() should be renamed + extended to cover different
RAM access types:
- coherent vs non-coherent memory
- preallocated/initialized memory (such as skb->data passed to
  hard_start_xmit()) vs uninitialized memory (such as returned by
  kmalloc()).

The "cost" is needed for cases where both the host and the device can
support many addressing modes, such as with AIC7xxx, > 4GB of RAM
and (costly) IO MMU or bounce buffers.


Currently, set_dma_mask(less than 32 bits) can return success but then
the mapping functions can return addresses which don't fit in the
requested number of bits. In fact set_dma_mask() has any meaning
only to *alloc functions. The statement "pci_set_consistent_dma_mask()
will always be able to set the same or a smaller mask as
pci_set_dma_mask()" doesn't make IMHO sense.


If we fix the API we should IMHO also remove set_dma_mask() and add
the number of address bits to the arguments of actual mapping
functions. It would make it possible to use different masks for
different tasks, I'm told there is hardware which can benefit from it.
Done correctly it wouldn't have any runtime overhead.

I would also change the "u64 mask" into plain number of bits.
It would be easier for people, cpp, gcc and CPU.
-- 
Krzysztof Halasa, B*FH