From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philip Rakity Subject: Re: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host Date: Sun, 31 Oct 2010 18:52:37 -0700 Message-ID: <45311249-8F46-4B20-9525-E66F10C7B44F@marvell.com> References: <16C48D64-3B93-450C-8C92-EFE4D70BD5ED@marvell.com> <1288447317.4817.9.camel@maxim-laptop> <1288575866.25600.1.camel@maxim-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Return-path: Received: from na3sys009aog104.obsmtp.com ([74.125.149.73]:37866 "HELO na3sys009aog104.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753816Ab0KABwr convert rfc822-to-8bit (ORCPT ); Sun, 31 Oct 2010 21:52:47 -0400 In-Reply-To: <1288575866.25600.1.camel@maxim-laptop> Content-Language: en-US Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Maxim Levitsky Cc: "linux-mmc@vger.kernel.org" , Chris Ball On Oct 31, 2010, at 6:44 PM, Maxim Levitsky wrote: > On Sat, 2010-10-30 at 16:01 +0200, Maxim Levitsky wrote: >> On Sat, 2010-10-30 at 05:47 -0700, Philip Rakity wrote: >>> eMMC unlike SD does not have a field to inside the card data to say the bit width of the card. >>> In addition some mmc cards (from Transcend) only support 1 bit mode. The physical pins to support 4 bit data are not there as well as no card specific data saying the bus width of the card. >>> >>> The only solution is to probe the bus by sending a CMD19 and CMD14 (BUSTEST_W/BUSTEST_R). >>> This procedure is defined in the JEDEC Standard No. 84-A441 spec -- Annex A.8.3 and this has been working in our linux 2.6.28/2.6.29 for quite a while. I can submit a patch if this makes sense. >>> However, it may not work all the time; some controllers do not send out the CMD19 sequence. The (BUSTEST_W/BUSTEST_R) procedure is used in BSD. Also, in SD v3.0 CMD19 is defined for tuning and its definition is slightly different then in the JEDEC standard. >>> >>> One option for the problem you are seeing would be for my patch >>> http://permalink.gmane.org/gmane.linux.kernel.mmc/3966 >>> or something like it to be accepted. As well as adding the bustest procedure. >>> >>> At least the board specific data can then say 8 bit data lines are supported on the physical slot. The controller can say 8 bit works but normally does not have knowledge of the lower level board design. >> >> I see two solutions to this problem which you proposed above: >> >> 1. Allow the controller to tell host that it doesn't support 8-bit. >> However, what about generic sdhci controllers? These that don't have >> quirks in sdhci.c. Are there any desktop sdhci controllers that support >> 8-bit. Note that SDHCI controllers are primary for SD/SDHCI cards not >> MMC. I don't know if extra pins have same locations on SD and MMC cards. The quirk I defined ENABLES 8 bit mode. 8 bit mode requires 4 additional data lines be brought out and the chips are normally mounted on the board. I am not aware of any 8 bit SD/MMC cards that plug into a slot. >> >> 2. Test the card for being readable. >> >> In memstick subsystem I recently had a lot of expirence with >> (unfortunately its maintainer isn't easy to work with - probably >> underestimation...) >> >> It should be possible to set bus width and then just test the card for >> being readable. While I don't yet know MMC spec and meaning of the >> commands, I thing sending an ordinary command like reading card ID, >> or something like that would suffiece to see if it accepts the bus >> width. If such command fails, 4-bit bus width should be used. In my testing setting the bus width to 4 bits when the physical card only supports 1 bit works. Need to test the bus width. >> >> I now assume that above commit broke all MMC cards in sdhci readers. >> This has to be fixed somehow. > Ping. >> >> > >