Bug 1426 - RFE: Add SDHC kernel support
: RFE: Add SDHC kernel support
Status: RESOLVED FIXED
Product: Core
Kernel
: unspecified
: All All
: Low enhancement (vote)
: ---
Assigned To: Maemo QA (deprecated)
:
: http://intr.overt.org/blog/?p=50
:
:
:
  Show dependency tree
 
Reported: 2007-05-14 09:28 UTC by Neil MacLeod
Modified: 2008-12-06 16:07 UTC (History)
1 user (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Neil MacLeod (reporter) maemo.org 2007-05-14 09:28:12 UTC
I've just realised there is no enhancement request for SDHC (SD 2.0) support.
This is probably because we have been so well served with patched community
kernels that it didn't seem necessary.

Please add official support for SDHC/SD 2.0.

4GB and 8GB SDHC cards are now common place and relatively cheap. SDHC support
in the Linux kernel has been available for several months and this support
should now become standard in Nokia firmware. 

The latest community patched kernel[1] not only adds SDHC support but also adds
high-speed and wide data bus modes of operation. These high speed/wide data bus
modes significantly improve read performance, so should be considered essential
in future updates particularly as they appear to be very stable.

Hopefully SDHC support is already targeted for the next firmware release as the
necessary SDHC patches should already be in the Linux mainline - if so, this is
an easy bug to fix! :)

1. http://intr.overt.org/blog/?p=50
Comment 1 Neil MacLeod (reporter) maemo.org 2007-07-06 18:16:48 UTC
Fixed in 4.2007.26-8 - thanks!
Comment 2 Neil MacLeod (reporter) maemo.org 2007-07-08 02:47:35 UTC
Is anyone able to explain why the official SDHC support produces performance
figures that are much reduced when compared to that of the community developed
(and official mainline Linux) SDHC patches[1] used available for the previous
firmware?

I've run the following test which reads 240MB from a Transcend 8GB Class 2 SDHC
card in the external slot:

time dd if=/dev/mmcblk0 of=/dev/null bs=8192 count=30000
(Speed in bytes => 8192*30000/time
 Speed in Mbytes => 8192*30000/time/1024/1024)

and these are the results:

3.2007.10-7 with community SDHC patch/kernel

Card                   Clock    Width   Time/s       Speed        Slot
8GB Transcend SDHC C2  48Mhz   4-bits    19.54   11.99MB/s    Internal

4.2007.26-8 with official SDHC support

Card                   Clock    Width   Time/s       Speed        Slot
8GB Transcend SDHC C2      ?        ?    41.80    5.60MB/s    Internal

The new SDHC support is only capable of half the performance that we know the
N800 is capable of. In the new firmware, either the clock speed for the card is
running at 24Mhz or the bus width is only 1 bit... probably the former, is this
intentional or unintentional? Note that the patches for 3.2007.10-7 output some
very useful information which can be viewed in dmesg - it would be nice if the
official SDHC support did the same!

Can anyone explain why this reduced SDHC (and probably SD/MMC) performance is
necessary - is it intended as the solution to corrupted FAT filesystems (bug
#1204)? I have to admit I never had any problems with corruption when using the
higher performing SDHC patches in 3.2007.10-7.

Thanks!

1. http://intr.overt.org/blog/?p=49
Comment 3 Eero Tamminen nokia 2007-08-17 18:11:52 UTC
(In reply to comment #2)
> Can anyone explain why this reduced SDHC (and probably SD/MMC) performance is
> necessary - is it intended as the solution to corrupted FAT filesystems (bug
> #1204)? I have to admit I never had any problems with corruption when using the higher performing SDHC patches in 3.2007.10-7.

Here's the information I got for this:

Some cards had timeouts with 48Mhz.  The community SDHC patch has been been now
reviewed and tested with these cards (it uses some extra sleeps in commands
that are not mentioned in the SDHC spec) and it would seem to work better with
them.
This should affect mainly just detecting the cards.

The "official SDHC support" was just a backport from upstream kernel.  The
"community SDHC support" was a separate backport with additional changes to the
generic mmc support which hadn't (and haven't) been pushed to upstream.

Official code should be more robust (no potential reboot when taking card out)
in handling the mmc ports (non-generic part) than the community SDHC patch.


The earlier upstream code (used in previous release) had also a couple of
voltage value issues for low-voltage cards which were fixed in the new upstream
version (i.e. fixed in both of these SDHC support backports).
Comment 4 Eero Tamminen nokia 2007-08-17 19:00:27 UTC
(In reply to comment #3)
> The earlier upstream code (used in previous release) had also a couple of
> voltage value issues for low-voltage cards which were fixed in the new 
> upstream version (i.e. fixed in both of these SDHC support backports).

= If card gave bogus info (bits) it got non-standard (too low) voltage.
Comment 5 Neil MacLeod (reporter) maemo.org 2007-08-17 19:11:08 UTC
(In reply to comment #3)
> Some cards had timeouts with 48Mhz.  The community SDHC patch has been been now
> reviewed and tested with these cards (it uses some extra sleeps in commands
> that are not mentioned in the SDHC spec) and it would seem to work better with
> them.
> This should affect mainly just detecting the cards.
> 

Many thanks for the explanation. Hopefully a future Nokia firmware update will
support highspeed (48Mhz) mode once the additional sleeps are implemented - my
Transcend cards operate just fine at 48Mhz with the community kernel.