Re: [PATCH 4/6] DMA: PL330: Add device tree support
Hi Rob, On 31 August 2011 21:34, Rob Herring robherri...@gmail.com wrote: Thomas, [...] As it says in Documentation/devicetree/bindings/arm/primecell.txt, you should have arm,primecell and a value for the specific peripheral. It should be in order of most specific to least specific. What Linux uses currently from the binding is a bit irrelevant. The binding is supposed to be future proof. An OS could choose to not use the primecell ID at all and only match with compatible string. Thanks for pointing this out. arm,pl330 has been added as another mandatory compatible string for the pl330 device node. Regards, Thomas. Rob [...] -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Hi Rob,
On 30 August 2011 18:49, Rob Herring robherri...@gmail.com wrote:
Thomas,
On 08/30/2011 07:18 AM, Thomas Abraham wrote:
Hi Rob,
On 26 August 2011 18:46, Rob Herring robherri...@gmail.com
mailto:robherri...@gmail.com wrote:
Thomas,
On 08/26/2011 03:40 AM, Thomas Abraham wrote:
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
mailto:thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 42
+
drivers/dma/pl330.c | 63
+++-
2 files changed, 103 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..46a8307
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,42 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory
contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should one or more of the following
+ - arm,pl330-pdma - For controllers that support mem-to-dev
and dev-to-mem
+ transfers.
+ - arm,pl330-mdma - For controllers that support mem-to-mem
transfers only.
And if they support both? I would think all controllers can support
mem-to-mem. If so, the distinction can be made with the number of
requests.
If a controller supports both types of transfer, the device node should
not claim compatibility for arm,pl330-pdma or arm,pl330-mdma.
Compatible should be arm,primecell.
No, every Primecell peripheral has arm,primecell, so it is not
specific enough for a driver to use.
Is there a case that a controller with peripheral requests cannot
support mem-to-mem transfers? I don't think there is. You could decide
you don't want to for other reasons like you don't have enough free
channels, but that's really a s/w decision, not a h/w description.
Ok. The driver has now been changed in a way that DMA_MEMCPY
capability is assigned by default to a pl330 dma controller. The
DMA_SLAVE and DMA_CYCLIC capability are assigned if the controller
supports peripheral request interface. For mem-to-mem transfer channel
requests, the filter function specified for the request should check
for the right match.
+ - arm,primecell - should be included for all pl330 dma
controller nodes.
+
+ - reg: physical base address of the controller and length of
memory mapped
+ region.
+
+ - interrupts: interrupt number to the cpu.
+
+ - arm,primecell-periphid: should be 0x00041330.
Should be optional. It's only needed when the h/w value is wrong. This
is already documented in primecell.txt.
Ok. This will be made optional.
+
+ - arm,pl330-peri-reqs: number of actual peripheral requests
connected to the
+ dma controller. Maximum value is 32.
Perhaps could be a bitmask for sparsely populated requests. May not
matter since phandles will define the connections.
Can be optional and not present means 00 requests (mem-to-mem only).
As suggested by Russell, this property will be removed and its value
will be read from the configuration register.
Good. Reading a value of 0 requests can still be used to determine the
controller is mem-to-mem only.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,pl330-pdma, arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ arm,primecell-periphid = 0x00041330;
+ arm,pl330-peri-reqs = 30;
+ };
+
+Client drivers (device nodes requiring dma transfers from
dev-to-mem or
+mem-to-dev) should specify the DMA channel
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Hi Rob,
On 31 August 2011 18:21, Rob Herring robherri...@gmail.com wrote:
Thomas,
[...]
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 29
drivers/dma/pl330.c | 35
+---
2 files changed, 59 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..89f4b9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,29 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should be arm,primecell.
Sorry, I guess I wasn't clear. This has to be arm,primecell plus
something else. In this case, arm,pl330. If the IP is modified from
standard ARM version (like ST likes to do), then something like
samsung,pl330 would be appropriate.
This is not actually used by the kernel at the moment, but could if
modified versions of pl330 show up.
of_platform_bus_create() checks for arm,primecell compatible value
to instantiate a amba device from device tree. The peripheral_id is
also noted in the amba device instance. The amba drivers register with
a with a peripheral_id and peripheral_id is used match amba device
with a driver.
In cases of modified version of the same IP, the peripheral_id would
be different. So, arm,primecell would just be enough for now. Any
other compatible value would anyway go unused. I did use
arm,primecell-pdma and arm-primecell-mdma to derive the dma_cap
value. But, as per your comments, I dropped it.
So, for now, I will just list arm,primecell as required compatible
value. Please let me know if arm,pl330 would be required here.
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+ - interrupts: interrupt number to the cpu.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma request id];
At least fix the -dma-channel part of the name. It not clear if that's
the case or just an example.
[name]-dma-channel = [phandle of the dma controller] [dma request id];
The name of the property that specifies the dma channel to use is
decided by the client device node. It is not enforced by the dma
device node. So, there will be no specific requirement stated in the
documentation for pl330 device node.
The rest looks good.
Thanks for your review and comments.
Regards,
Thomas.
Rob
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Thomas,
On 08/31/2011 10:46 AM, Thomas Abraham wrote:
Hi Rob,
On 31 August 2011 18:21, Rob Herring robherri...@gmail.com wrote:
Thomas,
[...]
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 29
drivers/dma/pl330.c| 35
+---
2 files changed, 59 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..89f4b9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,29 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should be arm,primecell.
Sorry, I guess I wasn't clear. This has to be arm,primecell plus
something else. In this case, arm,pl330. If the IP is modified from
standard ARM version (like ST likes to do), then something like
samsung,pl330 would be appropriate.
This is not actually used by the kernel at the moment, but could if
modified versions of pl330 show up.
of_platform_bus_create() checks for arm,primecell compatible value
to instantiate a amba device from device tree. The peripheral_id is
also noted in the amba device instance. The amba drivers register with
a with a peripheral_id and peripheral_id is used match amba device
with a driver.
In cases of modified version of the same IP, the peripheral_id would
be different. So, arm,primecell would just be enough for now. Any
other compatible value would anyway go unused. I did use
arm,primecell-pdma and arm-primecell-mdma to derive the dma_cap
value. But, as per your comments, I dropped it.
So, for now, I will just list arm,primecell as required compatible
value. Please let me know if arm,pl330 would be required here.
+ - reg: physical base address of the controller and length of memory
mapped
+region.
+ - interrupts: interrupt number to the cpu.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma request id];
At least fix the -dma-channel part of the name. It not clear if that's
the case or just an example.
[name]-dma-channel = [phandle of the dma controller] [dma request id];
The name of the property that specifies the dma channel to use is
decided by the client device node. It is not enforced by the dma
device node. So, there will be no specific requirement stated in the
documentation for pl330 device node.
As it says in Documentation/devicetree/bindings/arm/primecell.txt, you
should have arm,primecell and a value for the specific peripheral. It
should be in order of most specific to least specific.
What Linux uses currently from the binding is a bit irrelevant. The
binding is supposed to be future proof. An OS could choose to not use
the primecell ID at all and only match with compatible string.
Rob
The rest looks good.
Thanks for your review and comments.
Regards,
Thomas.
Rob
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Hi Russell, On 26 August 2011 19:53, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 26, 2011 at 08:16:11AM -0500, Rob Herring wrote: Thomas, On 08/26/2011 03:40 AM, Thomas Abraham wrote: + - arm,pl330-peri-reqs: number of actual peripheral requests connected to the + dma controller. Maximum value is 32. Perhaps could be a bitmask for sparsely populated requests. May not matter since phandles will define the connections. Can be optional and not present means 00 requests (mem-to-mem only). The number of peripheral requests is readable from configuration register zero, so this is discoverable. Why should we put this information into DT if its provided by the hardware? The number of DMA channels available is also configurable by the SoC designer, yet you don't specify that in DT. And there's a whole bunch of other configuration options available to the SoC designer, most of which are discoverable from the configuration registers. So, I don't think you should be specifying the number of requests. Ok. The property specifying the number of peripheral requests will be dropped. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Hi Rob,
On 26 August 2011 18:46, Rob Herring robherri...@gmail.com wrote:
Thomas,
On 08/26/2011 03:40 AM, Thomas Abraham wrote:
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 42 +
drivers/dma/pl330.c | 63
+++-
2 files changed, 103 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..46a8307
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,42 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should one or more of the following
+ - arm,pl330-pdma - For controllers that support mem-to-dev and
dev-to-mem
+ transfers.
+ - arm,pl330-mdma - For controllers that support mem-to-mem transfers
only.
And if they support both? I would think all controllers can support
mem-to-mem. If so, the distinction can be made with the number of requests.
If a controller supports both types of transfer, the device node
should not claim compatibility for arm,pl330-pdma or
arm,pl330-mdma. Compatible should be arm,primecell.
+ - arm,primecell - should be included for all pl330 dma controller nodes.
+
+ - reg: physical base address of the controller and length of memory mapped
+ region.
+
+ - interrupts: interrupt number to the cpu.
+
+ - arm,primecell-periphid: should be 0x00041330.
Should be optional. It's only needed when the h/w value is wrong. This
is already documented in primecell.txt.
Ok. This will be made optional.
+
+ - arm,pl330-peri-reqs: number of actual peripheral requests connected to
the
+ dma controller. Maximum value is 32.
Perhaps could be a bitmask for sparsely populated requests. May not
matter since phandles will define the connections.
Can be optional and not present means 00 requests (mem-to-mem only).
As suggested by Russell, this property will be removed and its value
will be read from the configuration register.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,pl330-pdma, arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ arm,primecell-periphid = 0x00041330;
+ arm,pl330-peri-reqs = 30;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma request id];
+
+ where 'dma request id' is the dma request number which is connected
+ to the client controller.
+
+ Example: tx-dma-channel = pdma0 12;
I like this approach. I looked at this some and some PPC platforms do a
node for each channel/request, but this is much more simple and similar
to clock binding approach.
You need to define the property name. Probably just dma-channel is
enough. For peripherals with more than 1, just list them out like when
you have more than 1 interrupt. The order should be defined as part of
that device's binding (i.e. 1st channel is tx and 2nd channel is rx).
I am little hesitant to do this the way you suggested. A controller
could have dma request lines connected to multiple dma controllers. So
the phandle could be different for each dma channel. Also, the client
drivers specify the property value for each dma channel requested (the
property value gets assigned to chan-private and then used by the
filter function to lookup the dma channel). So changing it the way you
have suggested would make things complex.
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 9732995..984dc18 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -19,6 +19,7 @@
#include linux/amba/pl330.h
#include linux/pm_runtime.h
#include
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Thomas,
On 08/30/2011 07:18 AM, Thomas Abraham wrote:
Hi Rob,
On 26 August 2011 18:46, Rob Herring robherri...@gmail.com
mailto:robherri...@gmail.com wrote:
Thomas,
On 08/26/2011 03:40 AM, Thomas Abraham wrote:
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
mailto:thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 42
+
drivers/dma/pl330.c| 63
+++-
2 files changed, 103 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..46a8307
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,42 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory
contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should one or more of the following
+- arm,pl330-pdma - For controllers that support mem-to-dev
and dev-to-mem
+ transfers.
+- arm,pl330-mdma - For controllers that support mem-to-mem
transfers only.
And if they support both? I would think all controllers can support
mem-to-mem. If so, the distinction can be made with the number of
requests.
If a controller supports both types of transfer, the device node should
not claim compatibility for arm,pl330-pdma or arm,pl330-mdma.
Compatible should be arm,primecell.
No, every Primecell peripheral has arm,primecell, so it is not
specific enough for a driver to use.
Is there a case that a controller with peripheral requests cannot
support mem-to-mem transfers? I don't think there is. You could decide
you don't want to for other reasons like you don't have enough free
channels, but that's really a s/w decision, not a h/w description.
+- arm,primecell - should be included for all pl330 dma
controller nodes.
+
+ - reg: physical base address of the controller and length of
memory mapped
+region.
+
+ - interrupts: interrupt number to the cpu.
+
+ - arm,primecell-periphid: should be 0x00041330.
Should be optional. It's only needed when the h/w value is wrong. This
is already documented in primecell.txt.
Ok. This will be made optional.
+
+ - arm,pl330-peri-reqs: number of actual peripheral requests
connected to the
+dma controller. Maximum value is 32.
Perhaps could be a bitmask for sparsely populated requests. May not
matter since phandles will define the connections.
Can be optional and not present means 00 requests (mem-to-mem only).
As suggested by Russell, this property will be removed and its value
will be read from the configuration register.
Good. Reading a value of 0 requests can still be used to determine the
controller is mem-to-mem only.
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,pl330-pdma, arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ arm,primecell-periphid = 0x00041330;
+ arm,pl330-peri-reqs = 30;
+ };
+
+Client drivers (device nodes requiring dma transfers from
dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a
two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma
request id];
+
+ where 'dma request id' is the dma request number which is
connected
+ to the client controller.
+
+ Example: tx-dma-channel = pdma0 12;
I like this approach. I looked at this some and some PPC platforms do a
Re: [PATCH 4/6] DMA: PL330: Add device tree support
Thomas,
On 08/26/2011 03:40 AM, Thomas Abraham wrote:
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The 'chan_id' of the each channel is used as the
dma request id.
Client driver requesting dma channels specify the phandle of the
dma controller and the request id. The pl330 filter function
converts the phandle to the device node pointer and matches that
with channel's private data. If a match is found, the request id
from the client node and the 'chan_id' of the channel is matched.
A channel is found if both the values match.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/dma/arm-pl330.txt | 42 +
drivers/dma/pl330.c| 63
+++-
2 files changed, 103 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/arm-pl330.txt
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
new file mode 100644
index 000..46a8307
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt
@@ -0,0 +1,42 @@
+* ARM PrimeCell PL330 DMA Controller
+
+The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
+between memory and peripherals or memory to memory.
+
+Required properties:
+ - compatible: should one or more of the following
+- arm,pl330-pdma - For controllers that support mem-to-dev and dev-to-mem
+ transfers.
+- arm,pl330-mdma - For controllers that support mem-to-mem transfers
only.
And if they support both? I would think all controllers can support
mem-to-mem. If so, the distinction can be made with the number of requests.
+- arm,primecell - should be included for all pl330 dma controller nodes.
+
+ - reg: physical base address of the controller and length of memory mapped
+region.
+
+ - interrupts: interrupt number to the cpu.
+
+ - arm,primecell-periphid: should be 0x00041330.
Should be optional. It's only needed when the h/w value is wrong. This
is already documented in primecell.txt.
+
+ - arm,pl330-peri-reqs: number of actual peripheral requests connected to
the
+dma controller. Maximum value is 32.
Perhaps could be a bitmask for sparsely populated requests. May not
matter since phandles will define the connections.
Can be optional and not present means 00 requests (mem-to-mem only).
+
+Example: (from Samsung's Exynos4 processor dtsi file)
+
+ pdma0: pdma@1268 {
+ compatible = arm,pl330-pdma, arm,primecell;
+ reg = 0x1268 0x1000;
+ interrupts = 99;
+ arm,primecell-periphid = 0x00041330;
+ arm,pl330-peri-reqs = 30;
+ };
+
+Client drivers (device nodes requiring dma transfers from dev-to-mem or
+mem-to-dev) should specify the DMA channel numbers using a two-value pair
+as shown below.
+
+ [property name] = [phandle of the dma controller] [dma request id];
+
+ where 'dma request id' is the dma request number which is connected
+ to the client controller.
+
+ Example: tx-dma-channel = pdma0 12;
I like this approach. I looked at this some and some PPC platforms do a
node for each channel/request, but this is much more simple and similar
to clock binding approach.
You need to define the property name. Probably just dma-channel is
enough. For peripherals with more than 1, just list them out like when
you have more than 1 interrupt. The order should be defined as part of
that device's binding (i.e. 1st channel is tx and 2nd channel is rx).
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 9732995..984dc18 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -19,6 +19,7 @@
#include linux/amba/pl330.h
#include linux/pm_runtime.h
#include linux/scatterlist.h
+#include linux/of.h
#define NR_DEFAULT_DESC 16
@@ -277,6 +278,20 @@ bool pl330_filter(struct dma_chan *chan, void *param)
if (chan-device-dev-driver != pl330_driver.drv)
return false;
+#ifdef CONFIG_OF
+ if (chan-device-dev-of_node) {
+ const __be32 *prop_value;
+ phandle phandle;
+ struct device_node *node;
+
+ prop_value = ((struct property *)param)-value;
+ phandle = be32_to_cpup(prop_value++);
+ node = of_find_node_by_phandle(phandle);
+ return ((chan-private == node)
+ (chan-chan_id == be32_to_cpup(prop_value)));
+ }
+#endif
+
peri_id = chan-private;
return *peri_id == (unsigned)param;
}
@@ -777,6 +792,40 @@ static irqreturn_t pl330_irq_handler(int irq, void *data)
Re: [PATCH 4/6] DMA: PL330: Add device tree support
On Fri, Aug 26, 2011 at 08:16:11AM -0500, Rob Herring wrote: Thomas, On 08/26/2011 03:40 AM, Thomas Abraham wrote: + - arm,pl330-peri-reqs: number of actual peripheral requests connected to the +dma controller. Maximum value is 32. Perhaps could be a bitmask for sparsely populated requests. May not matter since phandles will define the connections. Can be optional and not present means 00 requests (mem-to-mem only). The number of peripheral requests is readable from configuration register zero, so this is discoverable. Why should we put this information into DT if its provided by the hardware? The number of DMA channels available is also configurable by the SoC designer, yet you don't specify that in DT. And there's a whole bunch of other configuration options available to the SoC designer, most of which are discoverable from the configuration registers. So, I don't think you should be specifying the number of requests. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
