[PATCH V3 1/2] of: Add generic device tree DMA helpers

[zhangfei.gao@gmail.com (zhangfei gao)]

On Fri, Jul 20, 2012 at 12:00 PM, Vinod Koul <vinod.koul@linux.intel.com> wrote:
> On Tue, 2012-07-17 at 19:24 +0000, Arnd Bergmann wrote:
>> On Friday 13 July 2012, Vinod Koul wrote:
>> > > Do you mean there must be a global table, or are you ok with putting
>> > > the information about a channel into the device that uses the channel,
>> > > as we do for most other subsystems (IRQ, GPIO, pinctrl, ...).
>> > > If not, what is the problem with that approach?
>> >
>> > Today, we simple ask, "give me dma channel with DMA_SLAVE capability".
>> >
>> > If we change it to "give me dma channel which suits my need" and have
>> > additional information in dmaengine to handle this request effectively.
>> >
>> > What that would mean is
>> > a) DMA channel either knows which channel to provide, Or
>> > b) Additional arguments provided to dmaengine API to help it find out
>> > which channel to provide.
>> >
>> > It would be good to have client ask for a specific channel. But in order
>> > to build generic clients, we face a problem that clients may not know
>> > how they mapped to dmac by SoC designer. Or the mux maybe entirely
>> > flexible on which channel.
>> >
>> > If we add this as DT property (which I assume should be platform
>> > specific), then client will know which channel to request.
>> > It can have two levels, dmac and channel. In case mux is flexible enough
>> > then client gets a channel and program the mux for this mapping.
>> >
>> > I think this is the most simplistic solution I have for this, thoughts?
>>
>> I think we're basically on the same page. Let's see if I have covered
>> all the cases we discussed so far. I've tried to update the binding that
>> Jon sent out initially with everything we've discussed, so please review
>> this to see if I understood you correctly.
> I think this looks fine to me. Few comments below on client side
>>
>>       Arnd
>>
>>
>> * Generic DMA Controller and DMA request bindings
>>
>> Generic binding to provide a way for a driver using DMA Engine to retrieve the
>> DMA request or channel information that goes from a hardware device to a DMA
>> controller.
>>
>> * DMA controller
>>
>> Required property:
>>     - #dma-cells: Number elements to describe DMA channel information. Must be
>>                   at least 2, allowing a phandle and a flags cell, but usually
>>                 is larger so a client can also specify a request or channel
>>                   number and/or some configuration.
>>
>> Optional properties:
>>     - #dma-channels: Number of DMA channels supported by the controller.
>>     - #dma-requests: Number of DMA requests signals supported by the controller.
>>
>> Example:
>>
>>        sdma: dmaengine at 48000000 {
>>                compatible = "ti,omap4-sdma"
>>                reg = <0x48000000 0x1000>;
>>                interrupts = <4>;
>>                #dma-cells = <3>;
>>                #dma-channels = <32>;
>>                #dma-requests = <127>;
>>        };
>>
>>
>> * DMA client
>>
>> Client drivers should specify the DMA property using a phandle to the controller
>> followed by the number of DMA request/channel and the transfer type of the
>> channel (eg. device-to-memory, memory-to-device, memory-to-memory, etc).
>>
>> Required property:
>>     dmas: list of one or more dma specifiers, each consisting of
>>      - phandle pointing to dma controller node
>>      - flags word, a bit map that can hold these flags
>>        * 0x00000001 channel can be used for transfer from device
>>        * 0x00000002 channel can be user for transfer to device
> Is this for identifying which channel is for TX and RX? If not I am not
> sure I understood it well
>
>>      - zero or more cells in a format specific to the the dma controller
>>        node listed in the phandle. This typically contains a dma request
>>        line number or a channel number, but can contain any data that
>>        is used required for configuring a channel.

How about extend struct dma_slave_config, adding one member of
"request_line", if
"request line" is must config in most platform.

struct dma_slave_config {
~
u32 request_line;
}
The advantage is request_line can be get directly from
dmaengine_slave_config regardless of DT.

>>
>> Optional property:
>>     dma-names: when present, this shall contain one identifier string
>>     for each dma specifier in the dmas property. The specific strings
>>     that can be used are defined in the binding of the DMA client
>>     device. When multiple dma specifiers can be used as alternatives,
>>     the dma-names for those dma specifiers must be identical.
>>
>> Any dma specifiers that have identical flags and identical dma-names
>> (if present) shall refer to different dma controllers that can be
>> used as alternatives, e.g. when a request line is connected to
>> multiple dma controllers. If multiple dma specifiers are listed that
>> have the same flags but refer to different functional channels,
>> the dma-names property must be used to distinguish them.
>>
>> Examples:
>>
>> 1. One DMA write channel, one DMA read/write channel:
>>
>>        i2c1: i2c at 1 {
>>                ...
>>                dmas = <&sdma 2 1 &sdma 3 2>;
>>                ...
>>        };
>>
>> 2. A single read-write channel with two alternative dma controllers
>>    providing it:
>>
>>       dmas = <&dma0 3 5
>>               &dma1 3 7
>>               &dma2 3 2>;
>>
>> 3. A device with three channels, one of which has two alternatives:
>>
>>       dmas = <&dma0 1 4 /* data read */
>>               &dma0 2 6 /* data write */
>>               &dma1 1 0 /* error read */
>>               &dma2 1 0>; /* alternative error read */
>>       dma-names = "data", "data", "error", "error";
>>
>> 4. A dma controller requiring complex configuration:
>>
>>        dma: dmaengine at 48000000 {
>>                compatible = "foo,foo-sdma"
>>                reg = <0x48000000 0x1000>;
>>                interrupts = <4>;
>>                #dma-cells = <6>; /* phandle, flag, request, channel,
>>                                        input-width, output-width */
> Why would we want the widths to be here?
> Assuming a DMA from System memory to a peripheral, source width should
> be system memory width and destination the peripheral width. IMO these
> should not be in dma property even if we need these
>>                #dma-channels = <32>;
>>                #dma-requests = <127>;
>>        };
>>
>>        mmc at 49000000 {
>>               ...
>>               dmas = <&dma 1  /* read */
>>                       2       /* request line */
>>                       5       /* channel */
>>                       16      /* 16 bit bus width on read */
>>                       8>      /* 8 bit bus width on write */
>>                      <&dma 2  /* write */
>>                       3       /* request line */
>>                       6       /* channel */
>>                       8       /* 8 bit bus width on read */
>>                       16>     /* 16 bit bus width on write */
> >From this looks like flag is for TX/RX, so maybe i read correct :)
>
> --
> ~Vinod
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel