[RFC 3/5] dt: bcm2835: add mmc node

[Stephen Warren]

On 10/28/2014 08:04 PM, Stephen Warren wrote:
> On 10/28/2014 06:04 PM, Piotr Król wrote:
>> Add MMC node, increase clk_mmc frequency and use bcm2835-mmc instead of
>> bcm2835-sdhci.
> 
> Per comments on the previous patches, this isn't the right way to go.
> 
>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
> 
>> -&sdhci {
>> +&mmc {
> 
> Is there a real need to rename the label this points at?
> 
>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
> 
>> +		mmc: mmc at 7e300000 {
>> +			compatible = "brcm,bcm2835-mmc";
> 
> If you did do this, the other node should have been removed...
> 
>> @@ -160,7 +171,7 @@
>>  			reg = <0>;
>>  			#clock-cells = <0>;
>>  			clock-output-names = "mmc";
>> -	-		clock-frequency = <100000000>;
>> +			clock-frequency = <250000000>;
> 
> Better would be to add a real clock provider which communicates with the
> VC firmware so it can dynamically get the actual rate.
> 
> I chose 100000000 as the clock frequency to match the default frequency
> for this clock as set by the VC firmware. Changing the DT in no way
> affects how the clock is actually programmed in HW.
> 
> Perhaps this default rate has changed since I wrote the DT? That'd be
> annoying since it would mean changes to SW-visible behavior of the firmware.

On vaguely current firmware, executing property mailbox request
0x00030002 (get clock rate) for the eMMC clock returns 250MHz as you say.

However, the clock rate used to be 100MHz (and before that sometimes
50MHz and sometimes 80MHz) as evidenced by running "git log" on the RPi
firmware repository, and searching case-insensitive for clock|emmc.
There's some discussion re: why the clock rate changed at:
https://github.com/raspberrypi/linux/issues/415#issuecomment-27763584

I suppose this means we should indeed have 250MHz in the DT, so that any
divisor calculation is safe (generates a card frequency that is no more
than what's desired, but could be less on older firmware).

Well, even better would be a real clock provider that queries the actual
rate from the VideoCore firmware:-)