Matthieu wrote:
On Sat, 23 Sep 2006 02:50:02 -0400, Mike Frysinger wrote:
>> It would be nice if you could use a generic way to pass this
>> partition data to the kernel from the mtd medium, instead of
hardcoding it here.
>
> i often wish for such things myself :)
>
> unfortunately, the boot loader we utilize (u-boot) isnt exactly
> friendly to the idea of managing flash partitions like redboot, and
> what we have here is the current standard method for defining flash
> partitions with mtd
>
humm you could use cmdlinepart [1] and pass the partition as a kernel
string with uboot.
That's what we are doing and it works perfectly.
Thanks for the pointer - we will have a look.
>> > +/* Clock and System Control (0xFFC0 0400-0xFFC0 07FF) */
>> > +#define bfin_read_PLL_CTL() bfin_read16(PLL_CTL)
>> > +#define bfin_write_PLL_CTL(val) bfin_write16(PLL_CTL,val)
>> > +#define bfin_read_PLL_STAT() bfin_read16(PLL_STAT)
>> (and 700 more of these)
>>
>> What's the point, are you getting paid by lines of code? Just use the
>> registers directly!
>
> in our last submission we were doing exactly that ... and we were told
> to switch to a function style method of reading/writing memory mapped
> registers
hum, IRRC in your last submission you used volatile to read/write register.
Some people told you that volatile are evil and you should use a function
to read them.
But there no need to these defines. Just use bfin_read16(register_name) in
your code.
But then all the driver developers need to remember if a register is 16 or
32 bits. Blackfin peripherals mix and match, depending on what the silicon
designer decided what good at the time. (which means if it fits in 16 bits,
it is a 16-bit register).
I guess we are all lazy, and don't want to have to go through the
complexity of looking up each register when we use it in a driver.
calling bfin_read_PLL_CTL() which is defined and typecast properly as short
bfin_read16(PLL_CTL), ensure we resolve issues like this at compile time,
without having to keep the manual in front of us.
-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
