From: Greg Ungerer <gerg@snapgear.com>
To: Philippe De Muyter <phdm@macqel.be>
Cc: Stany MARCEL <smarcel@pactenovation.fr>, linux-m68k@vger.kernel.org
Subject: Re: M54xx FEC and DMA
Date: Tue, 16 Oct 2012 15:44:12 +1000 [thread overview]
Message-ID: <507CF42C.2050201@snapgear.com> (raw)
In-Reply-To: <20121015144318.GA12485@frolo.macqel>
Hi Philippe,
On 16/10/12 00:43, Philippe De Muyter wrote:
> Hello Stany,
>
> [CCing linux-m68k@vger.kernel.org]
>
> On Mon, Oct 15, 2012 at 03:37:25PM +0200, Stany MARCEL wrote:
>> Hello,
>>
>>
>>
>> I have sent a patch on linuxm68k mailing list, a few minutes ago, that
>> permits to use your driver correctly with MMU without caching issues.
>>
>>
>>
>> The strategy is to map a memory zone used for dma allocation as non
>> cachable.
>
> Bright idea.
>
>>
>>
>>
>> It is a lot better than a complete flush at each network operation, and
>> correct my issue of lost UDP frames.
>>
>>
>>
>> With this and the read write operation replaced by __raw_* one Your FEC
>> and MCD DMA works very well for me.
>
> Thanks for the positive feedback.
>
> I was not aware of any difference between __raw_writel and writel on m68k.
>
> For the non-MMU case, I see:
> arch/m68k/include/asm/io_no.h:#define __raw_writel writel
>
> but now I have found for the MMU case:
> arch/m68k/include/asm/io_mm.h:#define writel(val,addr) out_le32((addr),(val))
> arch/m68k/include/asm/raw_io.h:#define __raw_writel(val,addr) out_be32((addr),(val))
>
> and I understand your problem (out_le32 vs out_be32), but I wonder:
> should we not:
>
> - try to understand/fix the difference between __raw_writel and writel in
> CONFIG_MMU case (Greg, Geert ?)
Yes, I figure they should be the same (on ColdFire at least).
Typically you should use writel in a driver. From the kernels documentation,
Documentation/DocBook/deviceiobook.tmpl:
<para>
The read and write functions are defined to be ordered. That is the
compiler is not permitted to reorder the I/O sequence. When the
ordering can be compiler optimised, you can use <function>
__readb</function> and friends to indicate the relaxed ordering. Use
this with care.
</para>
Whereas __raw_writel is really raw, no ordering, no barriers, no
bye-swapping, no nothing. Just direct write of the register.
Regards
Greg
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
prev parent reply other threads:[~2012-10-16 5:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1512C13C0C5EA947AE50B9B9AC314F470343F021@ATLAS.pactenovation.fr>
2012-10-15 14:43 ` M54xx FEC and DMA Philippe De Muyter
2012-10-16 5:44 ` Greg Ungerer [this message]
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=507CF42C.2050201@snapgear.com \
--to=gerg@snapgear.com \
--cc=linux-m68k@vger.kernel.org \
--cc=phdm@macqel.be \
--cc=smarcel@pactenovation.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.