public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tomoya MORINAGA" <tomoya-linux@dsn.okisemi.com>
To: Kyungmin Park <kmpark@infradead.org>
Cc: kok.howg.ewe@intel.com,
	"Andrew\"" <andrew.chih.howe.khor@intel.com>,
	linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org
Subject: Re: A MMC card transfer issue
Date: Thu, 11 Nov 2010 11:59:22 +0900	[thread overview]
Message-ID: <001701cb814c$71926bf0$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: AANLkTimfnj8GcSwmALjaZUBsiq6ssaVuzVZZsZHRYmiX@mail.gmail.com

Hi Park,

Though I  tried to patch yours to "sdhci.c" of linux-2.6.36,
but it seems your patch has already patched in linux-2.6.36.

Using this linux, MMC card is not recognized.
Inserting the MMC card, I saw the following erro message.

[   11.035441] sdhci: Secure Digital Host Controller Interface driver
[   11.035450] sdhci: Copyright(c) Pierre Ossman
[   11.058295] sdhci-pci 0000:02:04.0: SDHCI controller found [8086:8809] (rev 1)
[   11.058342]   alloc irq_desc for 18 on node -1
[   11.058350]   alloc kstat_irqs on node -1
[   11.058373] sdhci-pci 0000:02:04.0: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   11.058385] sdhci-pci 0000:02:04.0: Invalid iomem size. You may experience problems.
[   11.058487] sdhci-pci 0000:02:04.0: setting latency timer to 64
[   11.058623] Registered led device: mmc0::
[   11.058736] mmc0: SDHCI controller on PCI [0000:02:04.0] using DMA
[   11.058774] sdhci-pci 0000:02:04.1: SDHCI controller found [8086:880a] (rev 1)
[   11.058816] sdhci-pci 0000:02:04.1: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[   11.058828] sdhci-pci 0000:02:04.1: Invalid iomem size. You may experience problems.
[   11.058904] sdhci-pci 0000:02:04.1: setting latency timer to 64
[   11.059047] Registered led device: mmc1::
[   11.059153] mmc1: SDHCI controller on PCI [0000:02:04.1] using DMA
[   11.547645] mmc1: new high speed SD card at address 0ec7
[   11.629400] mmcblk0: mmc1:0ec7 SV02G 1.87 GiB (ro)
[   11.630314]  mmcblk0: p1
[   12.076459] gzip used greatest stack depth: 6008 bytes left
[   12.321795] ip used greatest stack depth: 5724 bytes left
[   13.786510] EXT3-fs (dm-0): using internal journal
[   13.887463] EXT3-fs: barriers not enabled
[   13.887872] kjournald starting.  Commit interval 5 seconds
[   13.888154] EXT3-fs (sda1): using internal journal
[   13.888178] EXT3-fs (sda1): mounted filesystem with writeback data mode
[   23.183874] Adding 2064380k swap on /dev/mapper/VolGroup00-LogVol01.  Priority:-1 extents:1 across:2064380k
[   39.171225] gconfd-2 used greatest stack depth: 5692 bytes left
[   86.545435] metacity[2318]: segfault at 0 ip 080aa093 sp bfd899a0 error 4 in metacity[8048000+82000]
[  115.124784] hda-intel: Invalid position buffer, using LPIB read method instead.
[  115.124821] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
[  346.630117] mmc1: card 0ec7 removed
[  408.266730] mmc1: new MMC card at address 0001
[  408.268142] mmcblk0: mmc1:0001 MMC    1.87 GiB
[  408.275970] mmcblk0: retrying using single block read
[  408.278451] mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900
[  408.278464] end_request: I/O error, dev mmcblk0, sector 0
[  408.280966] mmcblk0: error -84 transferring data, sector 1, nr 7, card status 0x900
[  408.280978] end_request: I/O error, dev mmcblk0, sector 1


I have suspected mmc.c is buggy.
I tried to disable like the following in "mmc_init_card".
As a result, the MMC card to be recognized correctly.
What's do you think ?

 */
static int mmc_init_card(struct mmc_host *host, u32 ocr,
 struct mmc_card *oldcard)
{
......

 /*
  * Activate wide bus (if supported).
  */
#if 0 //101111
 if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
     (host->caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
  unsigned ext_csd_bit, bus_width;

  if (host->caps & MMC_CAP_8_BIT_DATA) {
   ext_csd_bit = EXT_CSD_BUS_WIDTH_8;
   bus_width = MMC_BUS_WIDTH_8;
  } else {
   ext_csd_bit = EXT_CSD_BUS_WIDTH_4;
   bus_width = MMC_BUS_WIDTH_4;
  }

  err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
     EXT_CSD_BUS_WIDTH, ext_csd_bit);

  if (err && err != -EBADMSG)
   goto free_card;

  if (err) {
   printk(KERN_WARNING "%s: switch to bus width %d "
          "failed\n", mmc_hostname(card->host),
          1 << bus_width);
   err = 0;
  } else {
   mmc_set_bus_width(card->host, bus_width);
  }
 }
#endif //101111




------
Thanks,

Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.


----- Original Message ----- 
From: "Kyungmin Park" <kmpark@infradead.org>
To: "Tomoya MORINAGA" <tomoya-linux@dsn.okisemi.com>
Cc: <linux-mmc@vger.kernel.org>; <linux-kernel@vger.kernel.org>; "Andrew"" <andrew.chih.howe.khor@intel.com>;
<kok.howg.ewe@intel.com>
Sent: Tuesday, November 09, 2010 2:53 PM
Subject: Re: A MMC card transfer issue


> 2010/11/9 Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>:
> > I am facing the issue about some MMC cards on Intel EG20T PCH (Platform Controller Hub).
> > The linux version is 2.6.36.
> > I can not transfer data the MMC cards (e.g. Transcned MMC card).
> > The card is 1 bit bus width. And the card is according to MMC specification V3.x.
> > And the EG20T has a 4 bit bus width capability
> > Linux MMC standard driver decides the card bus width as 4 bit,
> > if the MMC specification version is larger than or equal to V4.0 like below.
> >
> > linux/drivers/mmc/core/mmc.c
> >
> > 505 /*
> > 506 * Activate wide bus (if supported).
> > 507 */
> > 508 if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
> > 509 (host->caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
> > 510 unsigned ext_csd_bit, bus_width;
> > 511
> > 512 if (host->caps & MMC_CAP_8_BIT_DATA) {
> > 513 ext_csd_bit = EXT_CSD_BUS_WIDTH_8;
> > 514 bus_width = MMC_BUS_WIDTH_8;
> > 515 } else {
> > 516 ext_csd_bit = EXT_CSD_BUS_WIDTH_4;
> > 517 bus_width = MMC_BUS_WIDTH_4;
> > 518 }
> > 519
> > 520 err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> > 521 EXT_CSD_BUS_WIDTH, ext_csd_bit);
> > 522
> > 523 if (err && err != -EBADMSG)
> > 524 goto free_card;
> > 525
> > 526 if (err) {
> > 527 printk(KERN_WARNING "%s: switch to bus width %d "
> > 528 "failed\n", mmc_hostname(card->host),
> > 529 1 << bus_width);
> > 530 err = 0;
> > 531 } else {
> > 532 mmc_set_bus_width(card->host, bus_width);
> > 533 }
> > 534 }
> > 535
> >
> > However the MMC specification version id is the same as V3.x and V4.0.
> > Therefore the driver uses the 4 bit bus width for the MMC card
> > even if the card has only 1 bit bus width.
> > I modified the driver to use 1 bit bus width only tentatively and confirmed that
> > we can mount the card and R/W correctly.
> >
> > I think we can not support MMC_CAP_4_BIT_DATA or MMC_CAP_8_BIT_DATA in MMC V4.0.
> >
> > How do you think ?
>
> You can find a patch for 4-bit support. the problem is there's some
> bug related so it set the 4 & 8 bit support both.
> So line 512 is always true. you can just remove the one line like this.
>
> It's quirk-and-dirty patch. now we try to find a generic solution to
> solve this issue.
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1849,7 +1849,7 @@ int sdhci_add_host(struct sdhci_host *host)
>         mmc->caps |= MMC_CAP_SDIO_IRQ;
>
>         if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> -               mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA;
> +               mmc->caps |= MMC_CAP_4_BIT_DATA;
>
>         if (caps & SDHCI_CAN_DO_HISPD)
>                 mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
>
> Thank you,
> Kyungmin Park
> >
> > --
> > Thanks,
> > Tomoya MORINAGA(OKI SEMICONDUCTOR CO., LTD.)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


  parent reply	other threads:[~2010-11-11  2:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-09  5:39 A MMC card transfer issue Tomoya MORINAGA
2010-11-09  5:53 ` Kyungmin Park
2010-11-09  7:29   ` Tomoya MORINAGA
2010-11-11  2:59   ` Tomoya MORINAGA [this message]
2010-12-01  1:08     ` Tomoya MORINAGA
     [not found]       ` <2D50F985-2383-4406-8514-DFE462A5F546@marvell.com>
2010-12-01  3:15         ` Philip Rakity
     [not found]         ` <4D2E0464ABB54FFF9C10583336E27879@hacdom.okisemi.com>
2011-01-19  0:59           ` Philip Rakity
2011-01-19  1:29             ` Tomoya MORINAGA
2011-01-19  1:41               ` Chris Ball
2011-01-19  3:12                 ` Philip Rakity
2011-01-19  6:05           ` Philip Rakity
2011-01-19  6:30             ` Tomoya MORINAGA
2011-01-19 17:42             ` Chris Ball
2011-01-19 23:49               ` Tomoya MORINAGA
2011-01-26  8:28               ` Tomoya MORINAGA
2011-01-26 15:42                 ` Philip Rakity
2011-01-27  1:00                   ` Tomoya MORINAGA
2011-01-27  1:03                     ` Philip Rakity
2011-01-27  1:31                       ` Tomoya MORINAGA
2011-01-27  1:43                         ` Philip Rakity
2011-01-27  3:20                           ` Tomoya MORINAGA
     [not found]                             ` <0DBFCBB8-B4A3-46A6-A68D-14FAED451619@marvell.com>
     [not found]                               ` <9992F28C7C0C445E956D351E3774C821@hacdom.okisemi.com>
     [not found]                                 ` <82CB4E44-6543-4578-ACE4-37850FC4A49A@marvell.com>
     [not found]                                   ` <EE9384C765994E26857C78E3D3A19304@hacdom.okisemi.com >
     [not found]                                   ` <EE9384C765994E26857C78E3D3A19304@hacdom.okisemi.com    >
     [not found]                                   ` <EE9384C765994E26857C78E3D3A19304@hacdom.okisemi.com>
     [not found]                                   ` <EE9384C765994E26857C78E3D3A19304@hacdom.okisemi.com   >
     [not found]                                     ` <AF584C10-A796-43 5 B-8AB2-DA6D6C0E3FD7@marvell.com>
     [not found]                                       ` <DE7D3AAF538943459079D18D0CE6ED44@hacdom.okisemi.com>
     [not found]                                         ` <DDF13C55-A8A1-45C1-AE9A-A76754ED7008@marvell.com>
     [not found]                                           ` <4425BB0054B748C68A25DD1DFBBB52A7@hacdom.okisemi.com>
     [not found]                                             ` <5E1B7BBD-C96E-4CC0-B03B-ADCEB0120085@marvell.com>
     [not found]                                               ` <0C438F11-132E-4639-820D-0E42EEDCD6E7@marvell.com>
     [not found]                                                 ` <671E3EC021E946A383C65F07A0101B27@hacdom.okisemi.com>
     [not found]                                                   ` <16706427-F00E-46F3-B0B4-9B7F06AD0E71@marvell.com>
2011-01-31 16:40                                                     ` Philip Rakity
2011-01-31 17:18                                                       ` Nicolas Pitre
2011-03-23  0:31                                                       ` Tomoya MORINAGA
2011-03-24 14:19                                                         ` Philip Rakity
2011-03-25  1:22                                                           ` Tomoya MORINAGA

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001701cb814c$71926bf0$66f8800a@maildom.okisemi.com' \
    --to=tomoya-linux@dsn.okisemi.com \
    --cc=andrew.chih.howe.khor@intel.com \
    --cc=kmpark@infradead.org \
    --cc=kok.howg.ewe@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox