On Wed, 2012-08-01 at 15:43 -0500, Jon Hunter wrote:
> Hi Vinod,
>
> On 07/31/2012 06:12 AM, Vinod Koul wrote:
> > On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
> So yes I can see that a channel itself could be configured to
> >> support a
> given direction, but when we ask for a
Hi Vinod,
On 07/31/2012 06:12 AM, Vinod Koul wrote:
> On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
So yes I can see that a channel itself could be configured to
>> support a
given direction, but when we ask for a channel via
>> dma_request_channel()
we are going to get a cha
On Thu, 2012-07-26 at 12:43 -0500, Jon Hunter wrote:
> >> So yes I can see that a channel itself could be configured to
> support a
> >> given direction, but when we ask for a channel via
> dma_request_channel()
> >> we are going to get a channel that matches the criteria we pass
> using
> >> the f
On Thu, 2012-07-26 at 10:53 -0500, Jon Hunter wrote:
> On 07/26/2012 06:28 AM, Vinod Koul wrote:
> > On Thu, 2012-07-26 at 07:14 +, Arnd Bergmann wrote:
> >> On Thursday 26 July 2012, Vinod Koul wrote:
> > But from a client POV it makes sense as with the given direction you
> > would ne
On 07/26/2012 01:42 AM, Vinod Koul wrote:
> On Tue, 2012-07-24 at 14:07 -0500, Jon Hunter wrote:
>> Hi Vinod,
>> Required property:
>> dmas: list of one or more dma specifiers, each consisting of
>> - phandle pointing to dma controller node
>> - flags word, a bit map
On 07/26/2012 06:28 AM, Vinod Koul wrote:
> On Thu, 2012-07-26 at 07:14 +, Arnd Bergmann wrote:
>> On Thursday 26 July 2012, Vinod Koul wrote:
> But from a client POV it makes sense as with the given direction you
> would need a specific request line for a channel. So this is right.
>>
On Thu, 2012-07-26 at 07:14 +, Arnd Bergmann wrote:
> On Thursday 26 July 2012, Vinod Koul wrote:
> > > > But from a client POV it makes sense as with the given direction you
> > > > would need a specific request line for a channel. So this is right.
> > > > But direction is something I don't e
On Thursday 26 July 2012, Vinod Koul wrote:
> > > But from a client POV it makes sense as with the given direction you
> > > would need a specific request line for a channel. So this is right.
> > > But direction is something I don't expect to be used for "give me a
> > > channel"
> >
> > Ok. The
On Tue, 2012-07-24 at 14:07 -0500, Jon Hunter wrote:
> Hi Vinod,
> 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
> * 0x00
On Fri, Jul 20, 2012 at 12:00 PM, Vinod Koul wrote:
> On Tue, 2012-07-17 at 19:24 +, 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 th
On Tuesday 24 July 2012, Jon Hunter wrote:
> Ok. The thought was that the user would have the following means of
> requesting a channel ...
>
> 1. By name
> 2. By a filter parameter (flags)
> 3. By name and a filter parameter
>
> So we would have the following APIs ...
>
> struct dma_chan
> *of_
On Tuesday 24 July 2012, Stephen Warren wrote:
> It seems that given there are two values for dma-names, there really are
> two channels; it's just that one channel is bi-directional, and the
> second has two alternatives.
>
> Still, I guess you could also view this as three separate channels
> in
Hi Vinod,
On 07/20/2012 04:37 AM, Vinod Koul wrote:
> On Fri, 2012-07-20 at 08:39 +, Arnd Bergmann wrote:
>> On Friday 20 July 2012, Vinod Koul wrote:
Required property:
dmas: list of one or more dma specifiers, each consisting of
- phandle pointing to dma controller no
On 07/24/2012 01:19 AM, Arnd Bergmann wrote:
> On Monday 23 July 2012, Stephen Warren wrote:
>>> 3. A device with three channels, one of which has two alternatives:
>>
>> s/three/four/ s/one of which/both of which/
>>
>> This binding doc seems reasonable to me.
>
> I asked a linguist about it wh
Hello.
On 24-07-2012 1:29, Stephen Warren wrote:
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 yo
On Monday 23 July 2012, Stephen Warren wrote:
> > 3. A device with three channels, one of which has two alternatives:
>
> s/three/four/ s/one of which/both of which/
>
> This binding doc seems reasonable to me.
I asked a linguist about it who said that you can't have "both" together
with "four
On 07/17/2012 01:24 PM, Arnd Bergmann wrote:
...
> 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 understoo
On Fri, 2012-07-20 at 11:08 +0200, Robert Jarzmik wrote:
> Vinod Koul writes:
>
> >> 4. A dma controller requiring complex configuration:
> >>
> >>dma: dmaengine@4800 {
> >>compatible = "foo,foo-sdma"
> >>reg = <0x4800 0x1000>;
> >>
On Fri, 2012-07-20 at 08:39 +, Arnd Bergmann wrote:
> On Friday 20 July 2012, Vinod Koul wrote:
> > > 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 t
Vinod Koul writes:
>> 4. A dma controller requiring complex configuration:
>>
>>dma: dmaengine@4800 {
>>compatible = "foo,foo-sdma"
>>reg = <0x4800 0x1000>;
>>interrupts = <4>;
>>#dma-cells = <6>; /* phandle, flag, r
On Friday 20 July 2012, Vinod Koul wrote:
> > 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
> >* 0x0001 channel can be used for transfe
On Tue, 2012-07-17 at 19:24 +, 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,
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 a
Hi Vinod
On Fri, 13 Jul 2012, Vinod Koul wrote:
> On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote:
[snip]
> > 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 subsys
On Fri, 2012-07-06 at 13:36 +0200, Guennadi Liakhovetski wrote:
> On Mon, 25 Jun 2012, Arnd Bergmann wrote:
>
> [snip]
>
> > The channel data in the device tree is still in a format
> > that is specific to that dmaengine driver and interpreted
> > by it. Using the regular dma_filter_fn prototype
On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote:
Back from vacation... so restart the pending discussion
>
> Sorry, I believe I was just using the wrong terminology, and what I named
> the slave here would just be the client.
>
> This may have contributed to a lot of confusion before, so
On Fri, 6 Jul 2012, Russell King - ARM Linux wrote:
> On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
> > I like this idea, but why don't we extend it to also cover the non-DT
> > case? I.e., why don't we add the above callback (call it "match" or
> > "filter" or anything
On Fri, Jul 06, 2012 at 05:43:38PM +0200, Guennadi Liakhovetski wrote:
> Hi Arnd
>
> On Fri, 6 Jul 2012, Arnd Bergmann wrote:
> > How would the individual driver know the size of the filter_arg?
>
> In exactly the same way as most dmaengine drivers do it today: they don't
> touch filter_arg unti
On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
> I like this idea, but why don't we extend it to also cover the non-DT
> case? I.e., why don't we add the above callback (call it "match" or
> "filter" or anything else) to dmaengine operations and inside (the
> extended) dm
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> > >
> > > for_each_channel() {
> > > ret = chan->device->device_alloc_chan_resources(chan,
> > > filter_arg);
> > > if (!ret)
> > > return chan;
> > > else if (ret != -ENODEV)
> > >
Hi Arnd
On Fri, 6 Jul 2012, Arnd Bergmann wrote:
> On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> > On Mon, 25 Jun 2012, Arnd Bergmann wrote:
> >
> > [snip]
> >
> > > The channel data in the device tree is still in a format
> > > that is specific to that dmaengine driver and interpreted
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
> On Mon, 25 Jun 2012, Arnd Bergmann wrote:
>
> [snip]
>
> > The channel data in the device tree is still in a format
> > that is specific to that dmaengine driver and interpreted
> > by it. Using the regular dma_filter_fn prototype is not
> >
On Mon, 25 Jun 2012, Arnd Bergmann wrote:
[snip]
> The channel data in the device tree is still in a format
> that is specific to that dmaengine driver and interpreted
> by it. Using the regular dma_filter_fn prototype is not
> necessary, but it would be convenient because the dmaengine
> code al
On Wednesday 27 June 2012, Vinod Koul wrote:
> On Tue, 2012-06-26 at 20:27 +, Arnd Bergmann wrote:
> > On Tuesday 26 June 2012, Vinod Koul wrote:
> > > On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> > If we instead modify the dmaengine code itself to know about DT
> > rather than wra
On Tue, 2012-06-26 at 20:27 +, Arnd Bergmann wrote:
> On Tuesday 26 June 2012, Vinod Koul wrote:
> > On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> > > On Tuesday 26 June 2012, Vinod Koul wrote:
> > > > Today, we just ask for a channel with specific mask. Further filtering
> > > > is
On Tuesday 26 June 2012, Vinod Koul wrote:
> On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> > On Tuesday 26 June 2012, Vinod Koul wrote:
> > > Today, we just ask for a channel with specific mask. Further filtering
> > > is done in filter function as we request a channel, not a specific o
On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> On Tuesday 26 June 2012, Vinod Koul wrote:
> > Today, we just ask for a channel with specific mask. Further filtering
> > is done in filter function as we request a channel, not a specific one.
> > In most slave cases, we need a specific cha
On Tuesday 26 June 2012, Vinod Koul wrote:
> Today, we just ask for a channel with specific mask. Further filtering
> is done in filter function as we request a channel, not a specific one.
> In most slave cases, we need a specific channel from a specific
> controller, and that is where DT can play
On Mon, 2012-06-25 at 20:30 +, Arnd Bergmann wrote:
> dma_request_channel is called with some information about the channel
> provided in its arguments, and the driver might get that from a number
> of places.
Today, we just ask for a channel with specific mask. Further filtering
is done in fil
On Monday 25 June 2012, Vinod Koul wrote:
> On Mon, 2012-06-25 at 11:51 -0500, Jon Hunter wrote:
> > Hi Russell,
> > Dan, Vinod, in this thread we have been discussing the addition of a
> > generic device-tree binding for DMA controllers. In the below, we were
> > discussing the addition of a devi
On Mon, 2012-06-25 at 11:51 -0500, Jon Hunter wrote:
> Hi Russell,
>
> On 06/22/2012 06:12 PM, Russell King - ARM Linux wrote:
> > Before this goes much further... one fairly obvious and important point
> > must be made.
> >
> > You're designing an API here. You're designing it *WITHOUT* involvi
Hi Russell,
On 06/22/2012 06:12 PM, Russell King - ARM Linux wrote:
> Before this goes much further... one fairly obvious and important point
> must be made.
>
> You're designing an API here. You're designing it *WITHOUT* involving
> the two most important people in its design that there are. T
Before this goes much further... one fairly obvious and important point
must be made.
You're designing an API here. You're designing it *WITHOUT* involving
the two most important people in its design that there are. The
DMA engine maintainers. Is this how we go about designing APIs - behind
mai
Hi Arnd,
On 06/14/2012 06:48 AM, Arnd Bergmann wrote:
[snip]
> This would let us handle the following cases very easily:
>
> 1. one read-write channel
>
> dmas = <&dmac 0x3 match>;
>
> 2. a choice of two read-write channels:
>
> dmas = <&dmacA 0x3 matchA>, <&dmacB 0x3 matchB>;
>
On Thursday 21 June 2012, Guennadi Liakhovetski wrote:
> Indeed, this solution should be good enough, thanks! I'm not sure, whether
> making this multiplexing available requires any additional code to the
> generic DMA DT binding implementation. If it does - please, let's make
> this a part of t
Hi Arnd
Sorry for a delayed reply, we had to discuss this your idea internally
first before replying.
On Fri, 15 Jun 2012, Arnd Bergmann wrote:
> On Friday 15 June 2012, Guennadi Liakhovetski wrote:
> > > In the common case, you could have one device connected to the third
> > > slave ID of the
On Friday 15 June 2012, Mitch Bradley wrote:
> > #address-cells =<1>;
> > #size-cells =<1>;
> > ranges;
>
> In light of the reg entries below, perhaps #size-cells=0 ?
> >
> >
> > dmae@0xfe008020{
> > compatible = "renesa
On 6/15/2012 1:27 AM, Arnd Bergmann wrote:
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
con
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
> > In the common case, you could have one device connected to the third
> > slave ID of the first controller but the fifth slave ID of the
> > second controller. In this case, you really have to specify each
> > controller with its slave ID sepa
Hi Arnd
On Fri, 15 Jun 2012, Arnd Bergmann wrote:
> On Thursday 14 June 2012, Jon Hunter wrote:
>
> > > Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot.
> > >
> > > Generic DMACs can serve any slave (peripheral) request line on any their
> > > physical channel, USB DMACs only
On Thursday 14 June 2012, Jon Hunter wrote:
> > Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot.
> >
> > Generic DMACs can serve any slave (peripheral) request line on any their
> > physical channel, USB DMACs only serve fixed USB controller instances. To
> > configure (connect
On Thursday 14 June 2012, Jon Hunter wrote:
>
> On 06/14/2012 06:48 AM, Arnd Bergmann wrote:
> > On Wednesday 13 June 2012, Jon Hunter wrote:
> >> So in that case, I don't see why the first cell after the phandle could
> >> not be an index which could be either a direction or request-id and then
>
On Thu, 14 Jun 2012, Jon Hunter wrote:
>
> On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote:
> > Hi all
> >
> > Sorry for jumping in so late in the game. But I think, the model, to which
> > this discussion is slowly converging, is not very well suitable for the
> > shdma DMACs, present on
On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote:
> Hi all
>
> Sorry for jumping in so late in the game. But I think, the model, to which
> this discussion is slowly converging, is not very well suitable for the
> shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and
> the
On 06/14/2012 06:48 AM, Arnd Bergmann wrote:
> On Wednesday 13 June 2012, Jon Hunter wrote:
>
>>> As I said previously, I think just encoding the direction but not
>>> the client specific ID (meaning we would have to disambiguate
>>> the more complex cases that Stephen mentioned using a dma-names
Hi all
Sorry for jumping in so late in the game. But I think, the model, to which
this discussion is slowly converging, is not very well suitable for the
shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and
the model is indeed suitable, in which case I'd be grateful, if someo
On Wednesday 13 June 2012, Jon Hunter wrote:
> > As I said previously, I think just encoding the direction but not
> > the client specific ID (meaning we would have to disambiguate
> > the more complex cases that Stephen mentioned using a dma-names
> > property) would be the best because it keeps
On 14 June 2012 04:02, Jon Hunter wrote:
> On 06/08/2012 07:04 PM, Arnd Bergmann wrote:
>
>> As I said previously, I think just encoding the direction but not
>> the client specific ID (meaning we would have to disambiguate
>> the more complex cases that Stephen mentioned using a dma-names
>> prop
Hi Arnd,
On 06/08/2012 07:04 PM, Arnd Bergmann wrote:
> On Friday 08 June 2012, Jon Hunter wrote:
>> On 05/21/2012 03:32 PM, Stephen Warren wrote:
>>> On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
On Monday 21 May 2012, Stephen Warren wrote:
>
> If so, that seems a little odd; you have
On Friday 08 June 2012, Jon Hunter wrote:
> On 05/21/2012 03:32 PM, Stephen Warren wrote:
> > On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
> >> On Monday 21 May 2012, Stephen Warren wrote:
> >>>
> >>> If so, that seems a little odd; you have to request a DMA channel for
> >>> "TX", but then end up
Hi Stephen, Arnd,
Been a while ;-)
On 05/21/2012 03:32 PM, Stephen Warren wrote:
> On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
>> On Monday 21 May 2012, Stephen Warren wrote:
The point with the direction was that it covers most cases and makes
them rather simple, while for the rar
On 05/21/2012 12:18 PM, Arnd Bergmann wrote:
> On Monday 21 May 2012, Stephen Warren wrote:
>>>
>>> The point with the direction was that it covers most cases and makes
>>> them rather simple, while for the rare case where you need more than
>>> two channels, you just use the otherwise optional nam
On Monday 21 May 2012, Stephen Warren wrote:
> >
> > The point with the direction was that it covers most cases and makes
> > them rather simple, while for the rare case where you need more than
> > two channels, you just use the otherwise optional named interface
> > rather than the numbered one.
On 05/19/2012 02:44 AM, Arnd Bergmann wrote:
> On Friday 18 May 2012, Stephen Warren wrote:
>> On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
>
>>> So if we do that, we might want to make the dma-names property mandatory
>>> for every device, and document what the names are.
>>
>> We could do that,
On Friday 18 May 2012, Stephen Warren wrote:
> On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
> > So if we do that, we might want to make the dma-names property mandatory
> > for every device, and document what the names are.
>
> We could do that, but one more proposal: Add the client's ID/index in
On 05/18/2012 03:43 PM, Arnd Bergmann wrote:
> On Friday 18 May 2012, Stephen Warren wrote:
>>> The driver can still request the dma line by name "tx" and the subsystem
>>> would pick one out of those with the same name.
>>>
>>> For the majority of cases, we would only need a single dma request lin
On Friday 18 May 2012, Stephen Warren wrote:
> > The driver can still request the dma line by name "tx" and the subsystem
> > would pick one out of those with the same name.
> >
> > For the majority of cases, we would only need a single dma request line
>
> Hmm. Many devices have multiple differe
On 05/18/2012 02:49 PM, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Stephen Warren wrote:
>> Simple case:
>>
>> /* e.g. FIFO TX DMA req - 2 DMACs possible */
>> dma-req-0 = <&dmac1 DMAC1_DMA_REQ_6>;
>> /* e.g. FIFO RX DMA req 1 DMAC possible */
>> dma-req-1 = <&dmac1 DMAC1_DMA_REQ_8>;
>>
>> Mu
On Wednesday 16 May 2012, Jassi Brar wrote:
> On 17 May 2012 01:12, Arnd Bergmann wrote:
>
> > I'm still anything but convinced by this model. Basically it's the
> > exact opposite of what we do for every other subsystem (irq, pinctrl,
> > regulator, gpio, ...), where the device using some infras
On Wednesday 16 May 2012, Stephen Warren wrote:
> Simple case:
>
> /* e.g. FIFO TX DMA req - 2 DMACs possible */
> dma-req-0 = <&dmac1 DMAC1_DMA_REQ_6>;
> /* e.g. FIFO RX DMA req 1 DMAC possible */
> dma-req-1 = <&dmac1 DMAC1_DMA_REQ_8>;
>
> Multiple DMAC case:
>
> /* e.g. FIFO TX DMA req - 2 DM
On 18 May 2012 01:02, Stephen Warren wrote:
>
> Now, the DMA node for an on-SoC DMAC would be in soc.dtsi. Typically,
> the DMAC is connected to many on-SoC devices, and hence soc.dtsi would
> need to specify the routing information for all those devices to avoid
> duplicating it in every board.dt
On 05/16/2012 03:16 PM, Jassi Brar wrote:
> On 17 May 2012 01:12, Arnd Bergmann wrote:
...
>> More importantly, you make it very hard to add devices in a board file
>> to a dma controller that already has descriptions for some channels,
>> because you cannot easily extend the chan-map unless you r
On Thu, May 17, 2012 at 02:52:36PM +0100, Mark Brown wrote:
> On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
>
> > DMA on the other hand seems to have cases where you can make a choice
> > between two or more providers of the service. The impression that I'm
> > getting
On Thu, May 17, 2012 at 02:22:23PM +0100, Russell King - ARM Linux wrote:
> DMA on the other hand seems to have cases where you can make a choice
> between two or more providers of the service. The impression that I'm
> getting from this thread is that it's difficult to describe that kind
> of re
On Wed, May 16, 2012 at 07:42:20PM +, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Jassi Brar wrote:
> > The assumed model of the DMAC, in this binding, has P peripheral
> > interfaces (P request signals) that could request a data transfer
> > and C physical channels that actually do the d
On Thu, May 10, 2012 at 11:00:53AM -0600, Stephen Warren wrote:
> To solve Russell's HW, we need some way of representing the mux directly
> in DT irrespective of how the DMA controller or DMA client specify what
> they're connected to. Anything else isn't representing the HW in DT.
Note that it's
On 17 May 2012 05:29, Stephen Warren wrote:
>>>
>>> Generic binding to provide a way to provide the client-channel map and
>>> other dmac specific parameters to the dma controller driver
>>>
>>> DMA Model:-
>>> Only the most common characteristics of a dma setup are assumed
>>> in this binding.
On 05/16/2012 01:42 PM, Arnd Bergmann wrote:
> On Wednesday 16 May 2012, Jassi Brar wrote:
>> On 16 May 2012 21:45, Stephen Warren wrote:
>
>>
>> Generic binding to provide a way to provide the client-channel map and
>> other dmac specific parameters to the dma controller driver
>>
>> DMA Model:-
On 17 May 2012 01:12, Arnd Bergmann wrote:
>>
>> Generic binding to provide a way to provide the client-channel map and
>> other dmac specific parameters to the dma controller driver
>>
>> DMA Model:-
>> Only the most common characteristics of a dma setup are assumed
>> in this binding.
>> Clien
On Wednesday 16 May 2012, Jassi Brar wrote:
> On 16 May 2012 21:45, Stephen Warren wrote:
>
> Generic binding to provide a way to provide the client-channel map and
> other dmac specific parameters to the dma controller driver
>
> DMA Model:-
> Only the most common characteristics of a dma se
On 05/16/2012 12:46 PM, Stephen Warren wrote:
> On 05/16/2012 11:37 AM, Jon Hunter wrote:
>>
>>
>> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>>> On 16 May 2012 22:42, Jon Hunter wrote:
>>>
>> What is still unclear to me, is if you use this token approach how
>> readable is the device-tree
On 05/16/2012 11:37 AM, Jon Hunter wrote:
>
>
> On 05/16/2012 12:24 PM, Jassi Brar wrote:
>> On 16 May 2012 22:42, Jon Hunter wrote:
>>
> What is still unclear to me, is if you use this token approach how
> readable is the device-tree? For example, if you have a client that can
> use
On 05/16/2012 12:24 PM, Jassi Brar wrote:
> On 16 May 2012 22:42, Jon Hunter wrote:
>
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For example, if you have a client that can
use one of two dmac and for each dmac the request/chann
On 16 May 2012 22:42, Jon Hunter wrote:
>>> What is still unclear to me, is if you use this token approach how
>>> readable is the device-tree? For example, if you have a client that can
>>> use one of two dmac and for each dmac the request/channel number is
>>> different, then by using a global
On 05/16/2012 11:16 AM, Jassi Brar wrote:
> On 16 May 2012 21:31, Jon Hunter wrote:
>> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>>> Hi Jassi,
>>>
>>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter wrote:
> On 05/04/2012 02:01 PM, Jassi Brar
On 05/16/2012 11:22 AM, Jassi Brar wrote:
[...]
> OK, my guts feel people might be interested in what's cooking on
> my side. I started with the binding text first and then would write
> code based upon that approach.
>
> The following might be tweaked as I look deeper into client and DMAC
> dr
On 16 May 2012 21:45, Stephen Warren wrote:
> On 05/16/2012 10:01 AM, Jon Hunter wrote:
> ...
>> By the way, I do see your point. You wish to describe the all the
>> mappings available to all dma controllers and then set a mapping in the
>> device tree. Where as I am simply setting a mapping and d
On 16 May 2012 21:31, Jon Hunter wrote:
> On 05/16/2012 08:15 AM, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>> Hi Jon,
>>>
>>> On 16 May 2012 06:41, Jon Hunter wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
>
> + i2c1: i2c@1 {
> +
On 05/16/2012 10:01 AM, Jon Hunter wrote:
...
> By the way, I do see your point. You wish to describe the all the
> mappings available to all dma controllers and then set a mapping in the
> device tree. Where as I am simply setting a mapping and do not list all
> other possibilities (assuming that
On 05/16/2012 10:44 AM, Stephen Warren wrote:
> On 05/16/2012 07:15 AM, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>>> Hi Jon,
>>>
>>> On 16 May 2012 06:41, Jon Hunter wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
>
> + i2c1: i2c@1 {
>
On 05/16/2012 08:15 AM, Jon Hunter wrote:
> Hi Jassi,
>
> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>> Hi Jon,
>>
>> On 16 May 2012 06:41, Jon Hunter wrote:
>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = <&sdma 2
On 05/16/2012 07:15 AM, Jon Hunter wrote:
> Hi Jassi,
>
> On 05/16/2012 07:37 AM, Jassi Brar wrote:
>> Hi Jon,
>>
>> On 16 May 2012 06:41, Jon Hunter wrote:
>>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = <&sdma 2 1
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
> Hi Jon,
>
> On 16 May 2012 06:41, Jon Hunter wrote:
>> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>>
>>> + i2c1: i2c@1 {
>>> + ...
>>> + dma = <&sdma 2 1 &sdma 3 2>;
>>> + ...
>>> + };
>>>
Hi Jon,
On 16 May 2012 06:41, Jon Hunter wrote:
> On 05/04/2012 02:01 PM, Jassi Brar wrote:
>>
>> + i2c1: i2c@1 {
>> + ...
>> + dma = <&sdma 2 1 &sdma 3 2>;
>> + ...
>> + };
>>>
>> I see this requires a client driver to specify a particular re
Hi Jassi,
On 05/04/2012 02:01 PM, Jassi Brar wrote:
> On 4 May 2012 20:47, Jon Hunter wrote:
>> Hi Jassi,
>>
>> On 05/04/2012 01:56 AM, Jassi Brar wrote:
>>> On 1 May 2012 02:47, Jon Hunter wrote:
From: Jon Hunter
This is based upon the work by Benoit Cousson [1] and Nicolas Ferr
Hi Jassi,
On 05/12/2012 08:40 AM, Jassi Brar wrote:
> On 12 May 2012 05:21, Stephen Warren wrote:
>> On 05/11/2012 03:06 PM, Jassi Brar wrote:
>>> On 12 May 2012 00:58, Stephen Warren wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
>> ...
>> client0: i2s {
>> /* has 2 DMA request
On 12 May 2012 05:21, Stephen Warren wrote:
> On 05/11/2012 03:06 PM, Jassi Brar wrote:
>> On 12 May 2012 00:58, Stephen Warren wrote:
>>> On 05/10/2012 01:59 PM, Jassi Brar wrote:
> ...
> client0: i2s {
> /* has 2 DMA request output signals: 0, 1 */
> };
>
> client1: spdif
On 05/11/2012 03:06 PM, Jassi Brar wrote:
> On 12 May 2012 00:58, Stephen Warren wrote:
>> On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
client1: spdif {
/* has 2 DMA request signals: 0, 1 */
};
>
On 12 May 2012 00:58, Stephen Warren wrote:
> On 05/10/2012 01:59 PM, Jassi Brar wrote:
>
>> I think arbitrary numerical tokens are a reasonable price to pay for the
>> robustness and simplicity they bring.
>
> I have to disagree here.
>
> Using phandle+ID is almost as simple, and much more flexib
On 05/10/2012 01:59 PM, Jassi Brar wrote:
> On 10 May 2012 22:30, Stephen Warren wrote:
>> On 05/09/2012 03:38 PM, Jassi Brar wrote:
>
>>> One point is about 'qos' here something like bandwidth allocation.
>>> If the dmac driver knew up-front the max possible clients that could be
>>> active
1 - 100 of 129 matches
Mail list logo
