* RE: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host
@ 2010-10-30 12:47 Philip Rakity
2010-10-30 14:01 ` Maxim Levitsky
0 siblings, 1 reply; 7+ messages in thread
From: Philip Rakity @ 2010-10-30 12:47 UTC (permalink / raw)
To: Maxim Levitsky, linux-mmc; +Cc: Chris Ball
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.
>Hi,
>
>I just bisected and reverted this commit.
>With it I am unable to read MMC cards via Ricoh MMC function,
>support for which I added recently.
>
>07:00.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev
>12)
>
>The logs show lot of errors like this:
>
>[ 219.590748] mmc1: new MMC card at address 0001
>[ 219.639449] mmcblk0: mmc1:0001 MMC 483 MiB
>[ 219.647008] mmcblk0: retrying using single block read
>[ 219.649262] mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900
>[ 219.649271] end_request: I/O error, dev mmcblk0, sector 0
>[ 219.651964] mmcblk0: error -84 transferring data, sector 1, nr 7, card status 0x900
>[ 219.651969] end_request: I/O error, dev mmcblk0, sector 1
>[ 219.654202] mmcblk0: error -84 transferring data, sector 2, nr 6, card status 0x900
>[ 219.654206] end_request: I/O error, dev mmcblk0, sector 2
>[ 219.657049] mmcblk0: error -84 transferring data, sector 3, nr 5, card status 0x900
>[ 219.657054] end_request: I/O error, dev mmcblk0, sector 3
>[ 219.661094] mmcblk0: error -84 transferring data, sector 4, nr 4, card status 0x900
>[ 219.661100] end_request: I/O error, dev mmcblk0, sector 4
>[ 219.663347] mmcblk0: error -84 transferring data, sector 5, nr 3, card status 0x900
>[ 219.663352] end_request: I/O error, dev mmcblk0, sector 5
>[ 219.665593] mmcblk0: error -84 transferring data, sector 6, nr 2, card status 0x900
>[ 219.665598] end_request: I/O error, dev mmcblk0, sector 6
>[ 219.667905] mmcblk0: error -84 transferring data, sector 7, nr 1, card status 0x900
>[ 219.667910] end_request: I/O error, dev mmcblk0, sector 7
>[ 219.667915] Buffer I/O error on device mmcblk0, logical block 0
>[ 219.672258] mmcblk0: retrying using single block read
>....
>
>
>Now that reader in not standard (it doesn't claim SDHCI, but work very similiar),
>so it might be device specific bug or not.
>
>One thing for sure, it doesn't physicaly support 8-bit (although the MMC Plus card I tested
>probably does via extra connectors).
>Best regards,
> Maxim Levitsky
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host
2010-10-30 12:47 commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host Philip Rakity
@ 2010-10-30 14:01 ` Maxim Levitsky
2010-11-01 1:44 ` Maxim Levitsky
0 siblings, 1 reply; 7+ messages in thread
From: Maxim Levitsky @ 2010-10-30 14:01 UTC (permalink / raw)
To: Philip Rakity; +Cc: linux-mmc, Chris Ball
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.
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.
I now assume that above commit broke all MMC cards in sdhci readers.
This has to be fixed somehow.
Best regards,
Maxim Levitsky
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host
2010-10-30 14:01 ` Maxim Levitsky
@ 2010-11-01 1:44 ` Maxim Levitsky
2010-11-01 1:52 ` Philip Rakity
0 siblings, 1 reply; 7+ messages in thread
From: Maxim Levitsky @ 2010-11-01 1:44 UTC (permalink / raw)
To: Philip Rakity; +Cc: linux-mmc, Chris Ball
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.
>
> 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.
>
> I now assume that above commit broke all MMC cards in sdhci readers.
> This has to be fixed somehow.
Ping.
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host
2010-11-01 1:44 ` Maxim Levitsky
@ 2010-11-01 1:52 ` Philip Rakity
2010-11-02 11:25 ` Peppe CAVALLARO
0 siblings, 1 reply; 7+ messages in thread
From: Philip Rakity @ 2010-11-01 1:52 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-mmc, 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.
>>
>>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host
2010-11-01 1:52 ` Philip Rakity
@ 2010-11-02 11:25 ` Peppe CAVALLARO
[not found] ` <3A6B0239-ACA2-4476-B3FC-F9593971594E@marvell.com>
0 siblings, 1 reply; 7+ messages in thread
From: Peppe CAVALLARO @ 2010-11-02 11:25 UTC (permalink / raw)
To: Philip Rakity; +Cc: Maxim Levitsky, linux-mmc, Chris Ball
On 11/1/2010 2:52 AM, Philip Rakity wrote:
>
> 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.
>
Hello.
In my testing, setting the bus width to 8, I had seen a performance
improvements on ST STB.
I think it's worth having a new quirk for that as Maxim suggested.
I can also prepare and test the patch if you like.
Let me know
Regards
Peppe
>
> >>
> >> I now assume that above commit broke all MMC cards in sdhci readers.
> >> This has to be fixed somehow.
> > Ping.
> >>
> >>
> >
> >
>
> --
> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-11-02 12:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-30 12:47 commit mmc: sdhci: add MMC_CAP_8_BIT_DATA in the host Philip Rakity
2010-10-30 14:01 ` Maxim Levitsky
2010-11-01 1:44 ` Maxim Levitsky
2010-11-01 1:52 ` Philip Rakity
2010-11-02 11:25 ` Peppe CAVALLARO
[not found] ` <3A6B0239-ACA2-4476-B3FC-F9593971594E@marvell.com>
2010-11-02 11:40 ` Fwd: " Philip Rakity
2010-11-02 11:57 ` Peppe CAVALLARO
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.