Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements - FreeBSD

This is a discussion on Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements - FreeBSD ; On Sat, Sep 27, 2008 at 5:43 PM, Alexander Motin wrote: > Hi. > > I would like to present initial revision of my generic PCI SD Host > Controller driver (sdhci). It support PCI devices with class 8 and ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

  1. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    On Sat, Sep 27, 2008 at 5:43 PM, Alexander Motin wrote:

    > Hi.
    >
    > I would like to present initial revision of my generic PCI SD Host
    > Controller driver (sdhci). It support PCI devices with class 8 and subclass
    > 5 according to SD Host Controller Specification. With some limitations it
    > successfully works on my Acer TM6292 notebook with ENE CB714 card reader.
    >



    > Things that are not working yet:
    > - DMA modes (code is written, but as my controller looks like has broken
    > DMA I have no ability to debug it),
    > - card insert/remove detection (need more thinking), you should reload mmc
    > module to rescan cards,
    > - SDHC and MMC cards (have no such cards now to debug that code), only
    > standard capacity SD Memory cards up to 4GB size are supported now,
    > - high speed (double rate) bus mode (need more thinking and DMA support).



    Most 4G cards are SDHC that I've seen. The notes on this that I've read
    talk about the fact that you can have a 4G regular SD card but that many
    (most) devices don't support it because of the need for a larger FAT to
    support 4G.

    I have two laptops with these controllers, but I have only SDHC media (4 and
    8 gig cards).
    _______________________________________________
    freebsd-mobile@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-mobile
    To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"


  2. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    On Mon, 6 Oct 2008 01:26:19 -0400
    "Zaphod Beeblebrox" wrote:

    > Most 4G cards are SDHC that I've seen. The notes on this that I've read
    > talk about the fact that you can have a 4G regular SD card but that many
    > (most) devices don't support it because of the need for a larger FAT to
    > support 4G.
    >
    > I have two laptops with these controllers, but I have only SDHC media (4 and
    > 8 gig cards).


    I have 4G SD card (not SDHC), this driver works perfectly with it.
    Card is Transcend 4Gb 150x.

    Output from dmesg:
    sdhci0-slot0: Card inserted
    mmc0: on sdhci0
    mmcsd0: 3926MB at mmc0
    mmc0: setting transfer rate to 30.000MHz
    mmc0: setting bus width to 4 bits
    GEOM_LABEL: Label for provider mmcsd0 is msdosfs/WM_ILYA.

    I've been able to copy large file (diablo jdk 1.6) to and from this card, with no file corruption.

    I have another SD card, 2 Gb size, in my camera. It's from Kingston. It doesn't work:

    sdhci0-slot0: Card inserted
    mmc0: on sdhci0
    sdhci0-slot0: Command error 1 (opcode 2 arg 0 flags 103 dlen 0 dflags 0)
    mmc0: setting transfer rate to 50.000MHz

    .... and no new storage devices appear.
    --
    Ilya Bakulin

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkjsY40ACgkQo9vlj1oadwjNBACeNVxxNOVZ5u 3FUHqtX3PxV1GW
    ZJwAoJQUgXFZaONfuMJBY5+NhqJ7ZXHi
    =QZxx
    -----END PGP SIGNATURE-----


  3. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    M. Warner Losh wrote:
    > : Problem was solved by increasing the number of answer read attempts in mmc_send_app_op_cond(). With attached patch (against latest driver version) card is recognized properly on ~ 190th attempt (while in original driver there are only 100 attempts).
    > :
    > : Furthermore, non-mine SDHC card is now also recognized in this cardreader (it doesn't even under Windows). In this case, it takes about 400 attempts to read answer.
    >
    > I think I bumped the number of iterations to 100 when I found that 10
    > wasn't enough. 25 different cards worked just fine, but I got use of
    > a 16MB SD card at BSDcan that needed like 65. Bumping it from 100 to
    > 1000, however, makes the timeout go from 1s to 10s. That opens up
    > window for insertion races, but that's the only downside I see... Of
    > course, we want to fix those races, but this may expose them a little
    > more..
    >
    > I can't believe that you had a card that took 4s to become active!
    >
    > Can you confirm the elapsed time is really 4s for that card?
    > Otherwise, this may be pointing out a bug in another area of the
    > code...


    Completely fortunate I have noticed that number of iterations depends on
    my laptop power source. After small investigation I have found that it
    actually depends on dev.cpu.0.freq value. With default value 2400 I have
    only several iterations. But every double frequency decrease doubles
    iteration count. With minimum value 100MHz I have more then 100
    iterations. Same time it doesn't looks like this time is a real wall
    time. It looks like DELAY() used in a loop has some problems with time
    counting.

    --
    Alexander Motin
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  4. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    M. Warner Losh wrote:
    > : Problem was solved by increasing the number of answer read attempts in mmc_send_app_op_cond(). With attached patch (against latest driver version) card is recognized properly on ~ 190th attempt (while in original driver there are only 100 attempts).
    > :
    > : Furthermore, non-mine SDHC card is now also recognized in this cardreader (it doesn't even under Windows). In this case, it takes about 400 attempts to read answer.
    >
    > I think I bumped the number of iterations to 100 when I found that 10
    > wasn't enough. 25 different cards worked just fine, but I got use of
    > a 16MB SD card at BSDcan that needed like 65. Bumping it from 100 to
    > 1000, however, makes the timeout go from 1s to 10s. That opens up
    > window for insertion races, but that's the only downside I see... Of
    > course, we want to fix those races, but this may expose them a little
    > more..
    >
    > I can't believe that you had a card that took 4s to become active!
    >
    > Can you confirm the elapsed time is really 4s for that card?
    > Otherwise, this may be pointing out a bug in another area of the
    > code...


    Completely fortunate I have noticed that number of iterations depends on
    my laptop power source. After small investigation I have found that it
    actually depends on dev.cpu.0.freq value. With default value 2400 I have
    only several iterations. But every double frequency decrease doubles
    iteration count. With minimum value 100MHz I have more then 100
    iterations. Same time it doesn't looks like this time is a real wall
    time. It looks like DELAY() used in a loop has some problems with time
    counting.

    --
    Alexander Motin
    _______________________________________________
    freebsd-mobile@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...freebsd-mobile
    To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"


  5. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    On Wed, 15 Oct 2008 23:25:11 +0300
    Alexander Motin mentioned:
    >
    > Completely fortunate I have noticed that number of iterations depends on
    > my laptop power source. After small investigation I have found that it
    > actually depends on dev.cpu.0.freq value. With default value 2400 I have
    > only several iterations. But every double frequency decrease doubles
    > iteration count. With minimum value 100MHz I have more then 100
    > iterations. Same time it doesn't looks like this time is a real wall
    > time. It looks like DELAY() used in a loop has some problems with time
    > counting.
    >


    What do you mean? DELAY(9) on your laptop doesn't correspond to the
    real time? AFAIK, DELAY(9) relies on current timecounter for time
    accountiong, so there might be problems with it. Have you tried
    switching the kern.timecounter.hardware sysctl to see if it will
    affect results?

    --
    Stanislav Sedov
    ST4096-RIPE

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkj2VoEACgkQK/VZk+smlYHA5wCeIgg4IPiIQihQ3sVJ5IzawUaK
    nGgAnid2uyjyJbK0jty1Tp3zl+gXNRn7
    =WF8Y
    -----END PGP SIGNATURE-----


  6. Re: RFC: PCI SD host controller driver & mmc/mmcsd modulesimprovements

    On Wed, 15 Oct 2008 23:25:11 +0300
    Alexander Motin mentioned:
    >
    > Completely fortunate I have noticed that number of iterations depends on
    > my laptop power source. After small investigation I have found that it
    > actually depends on dev.cpu.0.freq value. With default value 2400 I have
    > only several iterations. But every double frequency decrease doubles
    > iteration count. With minimum value 100MHz I have more then 100
    > iterations. Same time it doesn't looks like this time is a real wall
    > time. It looks like DELAY() used in a loop has some problems with time
    > counting.
    >


    What do you mean? DELAY(9) on your laptop doesn't correspond to the
    real time? AFAIK, DELAY(9) relies on current timecounter for time
    accountiong, so there might be problems with it. Have you tried
    switching the kern.timecounter.hardware sysctl to see if it will
    affect results?

    --
    Stanislav Sedov
    ST4096-RIPE

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.9 (FreeBSD)

    iEYEARECAAYFAkj2VoEACgkQK/VZk+smlYHA5wCeIgg4IPiIQihQ3sVJ5IzawUaK
    nGgAnid2uyjyJbK0jty1Tp3zl+gXNRn7
    =WF8Y
    -----END PGP SIGNATURE-----


+ Reply to Thread