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 channel via
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 channel that
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 need a specific
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 filter
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
* 0x0001 channel can be
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 thought was that
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 expect to be
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.
But direction
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 that can hold these flags
On Fri, Jul 20, 2012 at 12:00 PM, Vinod Koul vinod.k...@linux.intel.com 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
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. She
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
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 who said that
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 node
-
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
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
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 understood
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 transfer from
Vinod Koul vinod.k...@linux.intel.com writes:
4. A dma controller requiring complex configuration:
dma: dmaengine@4800 {
compatible = foo,foo-sdma
reg = 0x4800 0x1000;
interrupts = 4;
#dma-cells = 6; /* phandle,
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 these flags
On Fri, 2012-07-20 at 11:08 +0200, Robert Jarzmik wrote:
Vinod Koul vinod.k...@linux.intel.com writes:
4. A dma controller requiring complex configuration:
dma: dmaengine@4800 {
compatible = foo,foo-sdma
reg = 0x4800 0x1000;
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, GPIO,
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
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, 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 is not
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 subsystems
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
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
necessary,
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
by it.
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
dmaengine_core
for_each_channel() {
ret = chan-device-device_alloc_chan_resources(chan,
filter_arg);
if (!ret)
return chan;
else if (ret != -ENODEV)
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)
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 until
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 else) to
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 done in
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 wrapping
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
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 a
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 channel
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 one.
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. The
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* involving
the
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 device-tree
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;
3. one
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
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 first
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 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 = renesas,sh-dma;
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 SH and ARM
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
the next
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) a
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 serve fixed
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 separately,
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
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 the
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
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
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
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 to request a DMA
On 14 June 2012 04:02, Jon Hunter jon-hun...@ti.com 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
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 rare case where
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 having the common
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, but one more
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. My
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 named interface
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 into
On 18 May 2012 01:02, Stephen Warren swar...@wwwdotorg.org 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
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 DMACs possible */
On Wednesday 16 May 2012, Jassi Brar wrote:
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de 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
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;
Multiple DMAC case:
/*
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 different FIFOs,
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 line
Hmm. Many
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 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 data
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
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 from
On 05/16/2012 03:16 PM, Jassi Brar wrote:
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de 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
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com 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
Hi Jassi,
On 05/16/2012 07:37 AM, Jassi Brar wrote:
Hi Jon,
On 16 May 2012 06:41, Jon Hunter jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
+ ...
+ };
I see this
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 jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
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 jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+ ...
+ dma = sdma 2 1 sdma 3 2;
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 jon-hun...@ti.com 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 16 May 2012 21:31, Jon Hunter jon-hun...@ti.com 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 jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM, Jassi Brar wrote:
+ i2c1: i2c@1 {
+
On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org 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
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
drivers
On 05/16/2012 11:16 AM, Jassi Brar wrote:
On 16 May 2012 21:31, Jon Hunter jon-hun...@ti.com 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 jon-hun...@ti.com wrote:
On 05/04/2012 02:01 PM,
On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com 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
On 05/16/2012 12:24 PM, Jassi Brar wrote:
On 16 May 2012 22:42, Jon Hunter jon-hun...@ti.com 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
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 jon-hun...@ti.com 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
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 jon-hun...@ti.com wrote:
What is still unclear to me, is if you use this token approach how
readable is the device-tree? For
On Wednesday 16 May 2012, Jassi Brar wrote:
On 16 May 2012 21:45, Stephen Warren swar...@wwwdotorg.org 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
On 17 May 2012 01:12, Arnd Bergmann a...@arndb.de 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.
Client:
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 swar...@wwwdotorg.org wrote:
Generic binding to provide a way to provide the client-channel map and
other dmac specific parameters to the dma controller driver
DMA
On 17 May 2012 05:29, Stephen Warren swar...@wwwdotorg.org 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.
Hi Jassi,
On 05/12/2012 08:40 AM, Jassi Brar wrote:
On 12 May 2012 05:21, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
Hi Jassi,
On 05/04/2012 02:01 PM, Jassi Brar wrote:
On 4 May 2012 20:47, Jon Hunter jon-hun...@ti.com wrote:
Hi Jassi,
On 05/04/2012 01:56 AM, Jassi Brar wrote:
On 1 May 2012 02:47, Jon Hunter jon-hun...@ti.com wrote:
From: Jon Hunter jon-hun...@ti.com
This is based upon the work by
On 12 May 2012 05:21, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/10/2012 01:59 PM, Jassi Brar wrote:
...
client0: i2s {
/* has 2 DMA request output signals: 0, 1 */
};
On 05/10/2012 01:59 PM, Jassi Brar wrote:
On 10 May 2012 22:30, Stephen Warren swar...@wwwdotorg.org 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
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org 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
On 05/11/2012 03:06 PM, Jassi Brar wrote:
On 12 May 2012 00:58, Stephen Warren swar...@wwwdotorg.org 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 */
};
Do we
1 - 100 of 127 matches
Mail list logo
