From: David Miller <davem@davemloft.net>
To: khc@pm.waw.pl
Cc: netdev@vger.kernel.org
Subject: Re: Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver.
Date: Tue, 14 Jul 2009 12:38:48 -0700 (PDT) [thread overview]
Message-ID: <20090714.123848.189674670.davem@davemloft.net> (raw)
In-Reply-To: <m3d483m53q.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Tue, 14 Jul 2009 21:34:01 +0200
> Well, e100 driver uses streaming mapping for it's RX/TX buffers as well
> as for the descriptors. Now it gets tricky - RX ring descriptors can be
> written by the device at any time (when completing RX) and at the same
> time the CPU has to be able to check the descriptor's status. It seems
> it can't be formally done with the streaming DMA API, since it doesn't
> provide invalidate and flush operations, it's rather about transfering
> control.
>
> I guess the coherent/consistent allocations should be used for this
> purpose (= uncached RAM pages on IXP4xx if I understand it correctly).
>
> Now that I know the inner working of DMA API the attached patch "fixes"
> the e100 problems, but it still doesn't seem to be a valid use of the
> API.
E100's use of streaming mappings for RX descriptors is a bug, it
should be using consistent mappings for sure.
And it's especially buggy if it isn't doing DMA API sync calls before
looking at descriptor fields, as your patch seems to cure.
next prev parent reply other threads:[~2009-07-14 19:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m31vokbi6p.fsf@intrepid.localdomain>
[not found] ` <20090713181237.GD31979@n2100.arm.linux.org.uk>
2009-07-14 19:34 ` Debounce code vs. dma_sync_single_range_for_cpu() and e100 driver Krzysztof Halasa
2009-07-14 19:38 ` David Miller [this message]
2009-07-14 21:01 ` Krzysztof Halasa
2009-07-14 21:05 ` David Miller
2009-07-16 22:27 ` Jeff Kirsher
2009-07-17 1:09 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090714.123848.189674670.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=khc@pm.waw.pl \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox