[U-Boot] Access IO register with writel/readl?
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?
for example:
struct base_gpt { unsigned int control; unsigned int prescaler; };
#define GPT1_BASE_ADDR GPTCR_SWR volatile struct base_gpt *cur_gpt = (struct base_gpt *)GPT1_BASE_ADDR;
A) acess with writel __raw_writel(GPTCR_SWR, &cur_gpt->control);
B) direct access cur_gpt->control = GPTCR_SWR;
(Note I define the structure with volatile )
Dennis
Hi,
On Wed, Oct 17, 2012 at 6:47 PM, Dennis Lan (dlan) dennis.yxun@gmail.com 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.)
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.
I have seen various comments about this topic on the list, but I'm not sure if there is a definitive document anywhere - you could write one with U-Boot in mind if you like.
for example:
struct base_gpt { unsigned int control; unsigned int prescaler; };
#define GPT1_BASE_ADDR GPTCR_SWR volatile struct base_gpt *cur_gpt = (struct base_gpt *)GPT1_BASE_ADDR;
A) acess with writel __raw_writel(GPTCR_SWR, &cur_gpt->control);
B) direct access cur_gpt->control = GPTCR_SWR;
(Note I define the structure with volatile )
Dennis
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 10/18/2012 07:09:19 AM, Simon Glass wrote:
Hi,
On Wed, Oct 17, 2012 at 6:47 PM, Dennis Lan (dlan) dennis.yxun@gmail.com 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
participants (3)
-
Dennis Lan (dlan) -
Scott Wood -
Simon Glass