Hi Chuang,
I am a newbie and I have not realized all the rules, so I have some questions.
On Tue Mar 31 12:24:03 CEST 2009, you wrote:
+static unsigned int rtc = CONFIG_SYS_RTC_BASE;
Please use a proper C structure to describe the RTC; do not use base address plus offsets.
Do you mean U-Boot prefers to use structure to describe registers?
Yes, we prefer to have this, as we then also let the compiler do for example type checking.
What if there were large gaps between registers?
Use dummy variables.
For example, in our ethernet IP FTMAC100, there is nothing in 0x34 - 0x84, 0xa0 - 0xc0. Should I use structure to describe it?
Yes please, use for example u32 dummy1[20] for the first gap and u32 dummy2[8] for the second.
I thought that placing a lot of paddings in a structure is ulgy. How do you think? Is there a guideline about this?
We are our own guideline ;)
No, seriously, we try to use structures wherever possible as a means to get more information to the compiler. It also helps preventing stupid errors like having one incorrect offset in a list of 40 defines which are *very* hard to catch.
Also in drivers/rtc/pl031.c, the RTC_WRITE_REG and RTC_READ_REG use base + offset.
outl() is not portable across architectures? inl() is not portable across architectures?
Sorry I don't understand.
There are outl() and inl() in most architectures except blackfin, i386 and sparc. And the outl() and the inl() I use are arm ones.
Which macros should I use?
We should really use macros specifying the expected-byteorder, i.e. in_be32, or out_le32, and so on. Using these macros, we can write drivers even being agnostic on the cpu byte ordering if the device stays the same. (Ok, ok, outl also infers a byte-ordering, but we like more expliciteness).
- debug("rtc_get(): record register: %x\n", inl(rtc + FTRTC_OFFSET_RECORD));
Line too long.
Sorry, this is my fault. I will fix them.
Thanks! Detlev