On Fri, Jul 20, 2012 at 12:00 PM, Vinod Koul <vinod.koul@xxxxxxxxxxxxxxx> 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@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@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@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@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@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
