On Tuesday 18 September 2012, Mitch Bradley wrote:
There is a delicious irony here with respect to Shark. Shark has real
Open Firmware. It's the platform that I used for the first OFW port to
ARM. We (the Shark design team) had a version of NetBSD that would run
on Shark without any native
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
...
Typo nits in the binding examples below...
Documentation/devicetree/bindings/dma/dma.txt | 81 +
drivers/of/Makefile |2 +-
drivers/of/dma.c | 219
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..a4f59a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,81
On 09/14/2012 05:41 PM, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
[snip]
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Nicolas
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
+ controller.
Shouldn't these two optional
On 09/19/2012 09:24 AM, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
+
On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote:
On 09/19/2012 09:24 AM, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA
On 9/19/2012 7:09 PM, Arnd Bergmann wrote:
On Tuesday 18 September 2012, Mitch Bradley wrote:
There is a delicious irony here with respect to Shark. Shark has real
Open Firmware. It's the platform that I used for the first OFW port to
ARM. We (the Shark design team) had a version of NetBSD
On Wednesday 19 September 2012, Matt Porter wrote:
On Wed, Sep 19, 2012 at 09:36:36AM -0500, Rob Herring wrote:
On 09/19/2012 09:24 AM, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported
On 9/19/2012 10:24 PM, Arnd Bergmann wrote:
On Wednesday 19 September 2012, Matt Porter wrote:
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller.
+- #dma-requests: Number of DMA requests signals supported by the
+
On Monday 17 September 2012, David Brown wrote:
There is also a lot of similarity between the mmci hardware and the
msm_sdcc hardware. Enough so, that it is probably better for us to
make the mmci driver work with our hardware, rather than trying to
keep msm_sdcc going.
There is also an
On 9/18/2012 4:42 AM, Arnd Bergmann wrote:
On Saturday 15 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to
On Wed, Sep 19, 2012 at 06:19:06AM +0800, Mitch Bradley wrote:
Is there ever a point when old architectures leave the Linux tree, or
will people have to see grep hits from them until the end of time?
That depends on use and the burden of keeping them in the tree. I'm
not aware of much activity
On Saturday 15 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to
easily
support them with regard to
On Mon, Sep 17, 2012 at 08:42:11PM +, Arnd Bergmann wrote:
On Saturday 15 September 2012, Russell King - ARM Linux wrote:
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
Aim of DMA helpers
- The purpose of device-tree is to describe the capabilites of the hardware.
Thinking about DMA
On 09/14/2012 04:41 PM, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
The binding looks good to me now, so,
Reviewed-by: Stephen Warren
On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote:
3. Supporting legacy devices not using DMA Engine
These devices present a problem, as there may not be a uniform way to
easily
support them with regard to device tree. Ideally, these should be migrated
to DMA engine.
18 matches
Mail list logo
