Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18

From: Robin Getz
Date: Sat Sep 23 2006 - 13:57:51 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/