quoted

quoted

quoted

Some people wanted the possibility to set the DMA mask as this
USB2 CI driver does not do specific Berlin operation and can be

reused later.

quoted

quoted

quoted

I don't particularly need to call dma_coerce_mask_and_coherent()
in my case, as far as I know.

Ok, just remove the call then and rely on the default mask.

quoted

They can maybe give the restrictions they might want to put on the
DMA mask.

If the restriction is from the bus, it should get handled
automatically by the device probe as long as the correct dma-ranges
property is there (though we have a small bug there at the moment).
If there is a variation of ci13xxx that can't do 32-bit DMA, that
should use a different compatible string and pass a fixed mask into
dma_set_mask_and_coherent() based on the device.

Correct me if my below understanding is wrong please.

For three chipidea users:
user_a: don't need dma mask
user_b: dma mask value is dma_mask_b
user_c: dma mask value is dma_mask_c

We don't need to call dma_coerce_mask_and_coherent() at generic
chipidea glue driver, and set dma-ranges as dma_mask_b at user_b's
dts, and set dma-ranges as dma_mask_c at user_c's dts.

The dma-ranges property doesn't just encode a dma-mask for a device, but
rather how the children of a bus see the memory address space of the
parent.

For traditional reasons we default to assuming that a 32-bit dma_mask is
correct, but there may be multiple reasons why this is not true:

- you have a device connected to a bus that is smaller than 32-bit wide
  (and that would have a dma-ranges property describing that)
- you have a device that has fewer than 32 address lines but is connected
  to a 32-bit upstream bus (hence the dma-ranges describe all 32 bit,
  but the driver must set a smaller mask)
- you have a 64-bit capable device connected to a 32-bit bus: the driver
  will ask for a 64-bit mask, but the dma_set_mask() call refuses this
  because of the bus capabilities.
- you have a 64-bit capable device on a 64-bit capable bus, and the
  dma_set_mask call should succeed.

The mask is definitely never "user" specific, but is a combination of the
device you have and the bus it is connected to.

Thanks, arnd.

For chipidea generic glue layer case, if there are three devices who use this
driver, and all devices have 32-bit bus, some devices have less 32 address lines.
For example:

- the device_a doesn't need to use dma_mask
- the device_b needs dma_mask as 0xfffffffff
- the device_c needs dma_mask as 0xfffffff0, assume it has only 28 address lines

My questions are:
- Can we not set dma_mask at driver, and only set dma-ranges at dts for device_b
and device_c as a solution to cover this different dma mask use case?

- If we can't use this solution, would you suggest one?

- If we can use this solution, for device_b and device_c, how can we write dma-ranges?
I can't find any arm platforms use it, only some powerpc platform use it.
According to the definition from Power_ePAPR_APPROVED_v1.1.pdf, it is
dma-ranges = <child-bus-address, parent-bus-address, length>
but I find the powerpc has different way for using dma-ranges. 

Peter