From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.ebshome.net (gate.ebshome.net [64.81.67.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "gate.ebshome.net", Issuer "gate.ebshome.net" (not verified)) by ozlabs.org (Postfix) with ESMTP id 1AEB368A5B for ; Thu, 2 Feb 2006 05:36:10 +1100 (EST) Resent-Message-ID: <20060201183608.GC24138@gate.ebshome.net> Date: Wed, 1 Feb 2006 10:23:09 -0800 From: Eugene Surovegin To: David Hawkins Subject: Re: Yosemite/440EP why are readl()/ioread32() setup to readlittle-endian? Message-ID: <20060201182309.GB24138@gate.ebshome.net> References: <35786B99AB3FDC45A8215724617919736D9217@gbrwgceumf01.eu.xerox.net> <43E0E9A7.4040508@ovro.caltech.edu> <20060201104405.C16064@cox.net> <43E0F81F.4050005@ovro.caltech.edu> <20060201181106.GA24138@gate.ebshome.net> <43E0FBFA.10103@ovro.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <43E0FBFA.10103@ovro.caltech.edu> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Feb 01, 2006 at 10:20:42AM -0800, David Hawkins wrote: > Eugene Surovegin wrote: > >On Wed, Feb 01, 2006 at 10:04:15AM -0800, David Hawkins wrote: > > > >>Matt, > >> > >>In the same vein as the readl()/writel() question, what > >>are the assumptions regarding memcpy_toio and memcpy_fromio? > >> > >>If the memcpy_to/fromio operations are intended only > >>for access to PCI devices, then they should also inherently > >>perform little-endianness conversion. For the test driver > >>I was working on, I did *not* find this the case, eg. > >>I implemented the test driver read() and write() using the > >>memcpy_to/fromio calls, and the data transfers occur > >>in big-endian (well, 'native' mode, since I also test the > >>same test driver with the PCI adapter in an x86 system). > >> > >>If memcpy_to/fromio can be used in a more general context, > >>then I can see why they operate in native mode. > >> > >>Just looking for enlightenment. > > > > > >This commands IIRC are intended for copying chunk of _bytes_. There > >are no issues with endianess for bytes, e.g. they work just like > >ordinary memcpy. > > > > True, good point. > > I quite often implement a 'control' device to read/write/mmap PCI > device registers. In that case, the registers are usually 32-bit, so > if I wanted endian neutrality, I could either let the user-space > app determine the endianness and act accordingly, or force the > user-space app to always see little-endian registers by replacing > memcpy_to/fromio calls with a loop over read;/writel, You seem to assume that memcpy should do 32-bit reads/writes. Why not 16-bit ones? That's why memcpy cannot do any byte swapping, because it can "theoretically" do 2 different types of it (16-bit and 32-bit), which is obviously not specified in memcpy interface. -- Eugene