[EMAIL PROTECTED] wrote:
> Yea, that works! I hit the probe function. Thanks very much Timur. I
> would never have found that.
I'm glad to help.
> Experimentally, I've found that I don't need the "simple-bus"
> compatibility in the of_device_id array in the Elo DMA driver. Any idea
> why?
Timur Tabi <[EMAIL PROTECTED]> wrote on 11/11/2008 11:22:06 AM:
> [EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <2>;
> device_type = "soc";
> +
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
+compatible = "simple-bus";
And then add
{ .compatible = "simple
>
> I believe this because the kernel never scanned the DMA entries in the
device
> tree. This is why I said you need of_platform_bus_probe() with the
compatible
> field of the parent of the DMA controller node. Send me your device
tree.
>
///
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote on 11/09/2008
> 04:09:51 PM:
>
>>> The Elo device driver is an async DMA back-end driver. That is, you
>>> don't communicate with that driver directly, you communicate with the
>>> async library (which is new - so you won't find it in LDD3).
>>>
On Tue, 11 Nov 2008 14:39:38 +0530
"Rajasekaran Kaliyaperumal, Chennai" <[EMAIL PROTECTED]> wrote:
>
>
> HI,
>
Hi Rajasekaran,
Firstly - please don't hijack an existing thread when asking a new, completely
unrelated question. Start a new thread with a relevant title.
> I would like to port
K.Rajasekaran.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Monday, November 10, 2008 11:29 PM
To: Timur Tabi
Cc: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org
Subject: Re: Using DMA
Timur Tabi <[EMAIL PROTECTED]> wrote on
[EMAIL PROTECTED] wrote on 11/09/2008
04:09:51 PM:
> >
> > The Elo device driver is an async DMA back-end driver. That is, you
> > don't communicate with that driver directly, you communicate with the
> > async library (which is new - so you won't find it in LDD3).
> >
>
> Okay, has anyone ac
Timur Tabi <[EMAIL PROTECTED]> wrote on 11/10/2008 06:35:21 AM:
> [EMAIL PROTECTED] wrote:
>
> > Is there something else I need to do? Or is there something wrong
with my
> > device tree (always a possibility :) ). Any help is appreciated.
>
> You might need to add something like this:
>
>
[EMAIL PROTECTED] wrote:
Is there something else I need to do? Or is there something wrong with my
device tree (always a possibility :) ). Any help is appreciated.
You might need to add something like this:
static struct of_device_id __initdata mpc8610_ids[] = {
{ .compatible = "fs
>
> The Elo device driver is an async DMA back-end driver. That is, you
> don't communicate with that driver directly, you communicate with the
> async library (which is new - so you won't find it in LDD3).
>
Okay, has anyone actually _used_ the Elo driver? I can't get the probe
function to r
Timur Tabi wrote:
> [EMAIL PROTECTED] wrote:
>
>> So it sounds like the async dma is the way to go, since I want to off load
>> as much as possible from the core. As you say, though, it's new and not
>> in LDD3. Is .../drivers/dma/dmaengine.c what everyone is refering to as
>> async dma?
>
>
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote on 11/07/2008 01:46:42 PM:
>
>> Whether or not using async dma is worth the effort can only be
>> determined by profiling the code. Either it's better, or it's not.
>> There's no real way to tell in advance.
>>
>
> Pretty much the answer I expec
>
> There's some network stuff that uses it for optimization. If
> CONFIG_NET_DMA is
> enabled, that will turn on some kind of TCP/IP offloading. I don't
> really know
> much about that. There's also a dmatest.c testing driver.
>
> It would definitely be nice to see a third client driver.
>
[EMAIL PROTECTED] wrote:
> So it sounds like the async dma is the way to go, since I want to off load
> as much as possible from the core. As you say, though, it's new and not
> in LDD3. Is .../drivers/dma/dmaengine.c what everyone is refering to as
> async dma?
Yes.
> If not, what is? An
[EMAIL PROTECTED] wrote on 11/07/2008 01:46:42 PM:
>
> Whether or not using async dma is worth the effort can only be
> determined by profiling the code. Either it's better, or it's not.
> There's no real way to tell in advance.
>
Pretty much the answer I expected :), I was just hoping that "w
On Fri, Nov 7, 2008 at 3:31 PM, <[EMAIL PROTECTED]> wrote:
> I'm not sure if I need something as complicated as sound/soc/fsl/fsl_dma.c
> or not. Maybe you can offer an opinion. The NAND flash in our product is
> our backing storage, i.e., our hard drive. We know that we're going to be
> stori
Hi Timur,
Thanks for the reply, very informative.
>
> The Elo device driver is an async DMA back-end driver. That is, you
> don't communicate with that driver directly, you communicate with the
> async library (which is new - so you won't find it in LDD3).
>
> Please note that the async DMA st
and DMA-mapping.txt
> everyone talks about how to allocate buffers using
> dma/pci_alloc_coherent(), but no one talks about how to actually use it.
That's because allocating a DMA buffer is a task common to all DMA
operations. Everything else about DMA is device- and/or
architecture-s
[EMAIL PROTECTED] wrote:
> Bill Gatliff <[EMAIL PROTECTED]> wrote on 11/06/2008 10:36:58 AM:
>
>> Scott Wood wrote:
>>> [EMAIL PROTECTED] wrote:
>>>> In the Cafe driver, Linux Device Drivers 3rd Edition, and
>>>> DMA-mapping.txt everyone
Bill Gatliff <[EMAIL PROTECTED]> wrote on 11/06/2008 10:36:58 AM:
> Scott Wood wrote:
> > [EMAIL PROTECTED] wrote:
> >> In the Cafe driver, Linux Device Drivers 3rd Edition, and
> >> DMA-mapping.txt everyone talks about how to allocate buffers using
> >>
Scott Wood wrote:
> [EMAIL PROTECTED] wrote:
>> In the Cafe driver, Linux Device Drivers 3rd Edition, and
>> DMA-mapping.txt everyone talks about how to allocate buffers using
>> dma/pci_alloc_coherent(), but no one talks about how to actually use
>> it. I'm pretty
[EMAIL PROTECTED] wrote:
In the Cafe driver, Linux Device Drivers 3rd Edition, and DMA-mapping.txt
everyone talks about how to allocate buffers using
dma/pci_alloc_coherent(), but no one talks about how to actually use it.
I'm pretty sure (even in my ignorance) that just allocating
no one here has ever had to set up DMA from scratch before, it's always
been done by an existing driver or the kernel, so I'm in uncharted
teritory.
In the Cafe driver, Linux Device Drivers 3rd Edition, and DMA-mapping.txt
everyone talks about how to allocate buffers using
dma/pci
Hi. I'm using linuxppc_2_4_devel from Denx CVS on a Lite5200 board.
When doing "put" of a large file to a ftp server, ftp eats all the CPU
available (90%+). I suspect it's not using DMA for the ethernet. Is this right?
Thanks in advance.
I?igo
k Chambers
wvcomputronics.com
- Original Message -
From: "I?igo Lopez Barranco" <[EMAIL PROTECTED]>
To:
Sent: Thursday, November 18, 2004 11:55 AM
Subject: Ethernet on 5200 is using DMA?
Hi. I'm using linuxppc_2_4_devel from Denx CVS on a Lite5200 board.
When doing "put"
26 matches
Mail list logo
