lkml.org 
[lkml]   [2014]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH v3 07/12] usb: chipidea: add a usb2 driver for ci13xxx
    Date
    > > > >
    > > > > 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.
    > > > > 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.
    > > >
    > > > > 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




    \
     
     \ /
      Last update: 2014-07-17 04:01    [W:4.134 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site