| Message ID | 1441362818-4323-1-git-send-email-kernel@martin.sperl.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
kernel@martin.sperl.org writes: > From: Martin Sperl <kernel@martin.sperl.org> > > This patch sets the clock speed to 250MHz to make the SD card > work at the correct clock speed without overclocking by 2.5. > > Signed-off-by: Martin Sperl <kernel@martin.sperl.org> > --- > arch/arm/boot/dts/bcm2835.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Analysis with a logic-analyzer found that the current setting > of the mmc clock at 100MHz is wrong and results in overclocking > the SD-card and eMMC on the Compute Module. > > Exact measurements show that when 25Mhz are selected by the sdhci > driver effectively 62.5MHz are used (so 2.5 times faster), which is > what is expected when the clock is configured to a fixed 100MHz > instead of the 250MHz that the clock is actually running at. Looks like this became the default in the firmware in November 2013 (you can, of course, still do lots of configuration that would change it higher or lower). I don't know what the downside would be of running MMC with too large of a divisor for devices running pre-November firmware. I suspect we should just wait until the new clock driver lands, to avoid any backwards-compatibility issues. Sorry for the trouble :(
On 09/08/2015 04:13 PM, Eric Anholt wrote: > kernel@martin.sperl.org writes: > >> From: Martin Sperl <kernel@martin.sperl.org> >> >> This patch sets the clock speed to 250MHz to make the SD card >> work at the correct clock speed without overclocking by 2.5. >> >> Signed-off-by: Martin Sperl <kernel@martin.sperl.org> --- >> arch/arm/boot/dts/bcm2835.dtsi | 2 +- 1 file changed, 1 >> insertion(+), 1 deletion(-) >> >> Analysis with a logic-analyzer found that the current setting of >> the mmc clock at 100MHz is wrong and results in overclocking the >> SD-card and eMMC on the Compute Module. >> >> Exact measurements show that when 25Mhz are selected by the >> sdhci driver effectively 62.5MHz are used (so 2.5 times faster), >> which is what is expected when the clock is configured to a fixed >> 100MHz instead of the 250MHz that the clock is actually running >> at. > > Looks like this became the default in the firmware in November 2013 > (you can, of course, still do lots of configuration that would > change it higher or lower). > > I don't know what the downside would be of running MMC with too > large of a divisor for devices running pre-November firmware. I > suspect we should just wait until the new clock driver lands, to > avoid any backwards-compatibility issues. Sorry for the trouble > :( I imagine we'd just end up with a slower-than-expected clock rate which should work just fine albeit at lower than expected/possible performance. Conversely, the effect of not fixing this is errors or corruption, which seems somewhat worse. Still, if the real clock driver is showing up very very imminently it just might be worth waiting for that (although we could set this patch Cc: stable which might help some people?)
> On 16.09.2015, at 06:04, Stephen Warren <swarren@wwwdotorg.org> wrote: > > On 09/08/2015 04:13 PM, Eric Anholt wrote: >> kernel@martin.sperl.org writes: >> >>> From: Martin Sperl <kernel@martin.sperl.org> >>> >>> This patch sets the clock speed to 250MHz to make the SD card >>> work at the correct clock speed without overclocking by 2.5. >>> >>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org> --- >>> arch/arm/boot/dts/bcm2835.dtsi | 2 +- 1 file changed, 1 >>> insertion(+), 1 deletion(-) >>> >>> Analysis with a logic-analyzer found that the current setting of >>> the mmc clock at 100MHz is wrong and results in overclocking the >>> SD-card and eMMC on the Compute Module. >>> >>> Exact measurements show that when 25Mhz are selected by the >>> sdhci driver effectively 62.5MHz are used (so 2.5 times faster), >>> which is what is expected when the clock is configured to a fixed >>> 100MHz instead of the 250MHz that the clock is actually running >>> at. >> >> Looks like this became the default in the firmware in November 2013 >> (you can, of course, still do lots of configuration that would >> change it higher or lower). >> >> I don't know what the downside would be of running MMC with too >> large of a divisor for devices running pre-November firmware. I >> suspect we should just wait until the new clock driver lands, to >> avoid any backwards-compatibility issues. Sorry for the trouble >> :( > > I imagine we'd just end up with a slower-than-expected clock rate > which should work just fine albeit at lower than expected/possible > performance. Conversely, the effect of not fixing this is errors or > corruption, which seems somewhat worse. Still, if the real clock > driver is showing up very very imminently it just might be worth > waiting for that (although we could set this patch Cc: stable which > might help some people?) > Solved by the patch of Eric with regards to clocks (normal and auxiliar) - since I have applied that patch the CM works fine.
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi index 301c73f..591f202 100644 --- a/arch/arm/boot/dts/bcm2835.dtsi +++ b/arch/arm/boot/dts/bcm2835.dtsi @@ -170,7 +170,7 @@ reg = <0>; #clock-cells = <0>; clock-output-names = "mmc"; - clock-frequency = <100000000>; + clock-frequency = <250000000>; }; clk_i2c: clock@1 {