From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 22 Oct 2012 14:33:29 -0500 Subject: [U-Boot] Access IO register with writel/readl? In-Reply-To: (from sjg@chromium.org on Thu Oct 18 07:09:19 2012) Message-ID: <1350934409.30970.4@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 10/18/2012 07:09:19 AM, Simon Glass wrote: > Hi, > > On Wed, Oct 17, 2012 at 6:47 PM, Dennis Lan (dlan) > wrote: > > HI ALL: > > Is it just conventional to access IO register with wriltel, > readl? > > or is there any specific reason here. > > what's the difference with direct access? writel has few arch > releated > > operation to guarantee hardware access? > > Yes it is a convention. For CPUs which need to introduce > compiler/memory barriers or other operations, this is supposed to be > done automatically in the access functions rather than in the code. > > Volatile tells the compiler that the value can change, and not to > optimise accesses to it, but this is just the compiler and does not > necessarily do everything required for I/O access on the platform. > Linux has a README on this topic (search for > Documentation/volatile-considered-harmful.txt) but I'm not sure that > the locking / multi-threading discussion has much relevance to U-Boot. > > (Oddly, I did notice at one point that on ARM some of the access > functions don't actually have any barriers. It might have been > clrsetbits.) It looks like ARM is missing barriers on out_le32 etc. At one point ARM was missing barriers on all accessors, and commit 3c0659b535b075be124c3d2a0714e55e65c46737 only bothered with the writel/readb/etc. accessors. > People tend to use writel() rather than __raw_writel(). In U-Boot with > a flat address mapping I'm not sure there is much difference in > practice, but it is nice to keep code consistent. writel() is a little endian access with memory barriers if needed by the architecture. __raw_writel() is native-endian and does not provide barriers. Unfortunately there doesn't seem to be an accessor that is native-endian with barriers or specified-endian without barriers. At least, that's what happens on powerpc, and I don't see anything obviously contradicting that from scanning some other arches. -Scott