linux-mips
[Top] [All Lists]

Re: [PATCH] I/O helpers rework

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH] I/O helpers rework
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 17 Feb 2005 01:34:06 +0000
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, macro@mips.com, Richard Sandiford <rsandifo@redhat.com>, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.61L.0501211739410.16576@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.61.0501131824350.21179@perivale.mips.com> <87k6qh2e6j.fsf@redhat.com> <Pine.LNX.4.61.0501141956520.21179@perivale.mips.com> <20050122.015040.108744446.anemo@mba.ocn.ne.jp> <Pine.LNX.4.61L.0501211739410.16576@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Sat, Jan 22, 2005 at 02:51:47AM +0000, Maciej W. Rozycki wrote:

> > 1. How about using 'const void *' for outs*()/reads*() ?  This will
> >    remove some compiler warnings too.  Also, it seems 'volatile' for
> >    memory buffer are unneeded.
> > 
> > 2. In *in*()/*out*(), it would be better to call __swizzle_addr*()
> >    AFTER adding mips_io_port_base.  This unifies the meaning of the
> >    argument of __swizzle_addr*() (always virtual address).  Then,
> >    mach-specific __swizzle_addr*() can to every evil thing based on
> >    the argument.
> > 
> > 3. How about Moving generic ioswab*() to mangle-port.h ?  Also how
> >    about passing virtual address to *ioswab*() ?  Then we can provide
> >    mach-specific ioswab*() and can do every evil thing based on its
> >    argument.  It is usefull on machines which have regions with
> >    different endian conversion scheme.
> 
>  Thanks for your insight -- your comments are not lost and I am working on 
> taking them into account.  But meanwhile a confusion around the semantics 
> of these operations arose (there is no documentation on them and some 
> drivers expect some of these functions to swap, while others expect them 
> not to) and changes were made to the tree that invalidated some of the 
> fixes.  That needs to be addressed first and I expect another update to 
> the file.  Here's a patch I'm going to start with.  Functions it adds have 
> been named dma_* to indicate they are meant to preserve memory byte 
> ordering.

Looks good but I don't really like the dma_* name prefix as these functions
really have nothing to do with DMA - in fact they're the opposite.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>