MMCv4 support (8-bit support missing)

MMCv4 support (8-bit support missing)

[Madhusudhan c]

Hi Pierre/philip,

This is regarding the MMCv4 support that came in as part of the MMC
core of 2.6.20 linux kernel version.

The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit
support seems to be missing from the MMCv4 support implemented by
Philip Langdale .
To support 8-bit transfers the core needs to implement "bus testing
procedure". This requires support for CMD19 and CMD14.

Why is the support for bus testing procedure msiing from the MMCv4 support?

Regards,
Madhu

Re: MMCv4 support (8-bit support missing)

[Philip Langdale]

Madhusudhan c wrote:
> Hi Pierre/philip,
> 
> This is regarding the MMCv4 support that came in as part of the MMC
> core of 2.6.20 linux kernel version.
> 
> The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit
> support seems to be missing from the MMCv4 support implemented by
> Philip Langdale .
> To support 8-bit transfers the core needs to implement "bus testing
> procedure". This requires support for CMD19 and CMD14.
> 
> Why is the support for bus testing procedure msiing from the MMCv4 support?

Because we have not seen any 8-bit hardware - let alone any 8-bit hardware
which we know how to drive. It is unclear how necessary the bus testing sequence
is, but the main reason why it's not there is that I could never get it to work
on the sdhci controller I use for testing. Due to how the CRC is handled for these
commands, the controller gets confused, reports failure, and doesn't provide the
returned data - making the test impossible.

If you have found an 8-bit controller that we can support, we'd love to know about
it!

--phil

Re: MMCv4 support (8-bit support missing)

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

Madhusudhan c wrote:
> Hi Pierre/philip,
> 

Hi Madhusudhan,

Feel free to add me as cc in the future if you want me to notice your mail ;)

> This is regarding the MMCv4 support that came in as part of the MMC
> core of 2.6.20 linux kernel version.
> 
> The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit
> support seems to be missing from the MMCv4 support implemented by
> Philip Langdale .

As soon as hardware with specs is available we'll start hacking. :)

> To support 8-bit transfers the core needs to implement "bus testing
> procedure". This requires support for CMD19 and CMD14.
> 
> Why is the support for bus testing procedure msiing from the MMCv4 support?
> 

We haven't determined it as necessary, and as Philip commented, most (if not
all) controllers cannot properly support the test.

Rgds
Pierre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: MMCv4 support (8-bit support missing)

[Madhusudhan c]

Hi Perre/Philip,

> Feel free to add me as cc in the future if you want me to notice your mail ;)
Sure. In fact I looked around to find your email id and did not find
it. In future I will include you in cc.

> We haven't determined it as necessary, and as Philip commented, most (if not
> all) controllers cannot properly support the test.
The MMCA spec 4.1 has the below two lines of explaination in the Bus
testing procedure section.

1. "The data pattern sent by the host may optionally include a CRC16
checksum, which is ignored by the card."
2. "The reverse data pattern sent by the card may optionally include a
CRC16 checksum, which is ignored by the host."

I faced a simillar problem as philip mentioned on our hardware. I used
to see failures on CMD19. I used to get a "Data timeout" interrupt.
After speaking to our hardware folks, we got it working. The hardware
folks suggested me to do a soft reset of the data lines upon receiving
the DTO for CMD19.Our controller has a bit in the MMC registers to
soft reset the data lines. It solved the problem. So I expect their
may be simillar stuff on other controllers as well.

Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support
long back, which had the bus testing procedure implemented and it
works fine. I am able to write and read the data pattern back
successfuly with his patch. I am not sure why his patch was not
integrated into the main line kernel.

Why should we be bothered about how controllers respond at the MMC
core level. We need to just implement what specification says and
leave the controller handling part to the controller driver. Am I
correct?

Regards,
Madhusudhan


On 4/18/07, Pierre Ossman <drzeus@drzeus.cx> wrote:
> Madhusudhan c wrote:
> > Hi Pierre/philip,
> >
>
> Hi Madhusudhan,
>
> Feel free to add me as cc in the future if you want me to notice your mail ;)
>
> > This is regarding the MMCv4 support that came in as part of the MMC
> > core of 2.6.20 linux kernel version.
> >
> > The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit
> > support seems to be missing from the MMCv4 support implemented by
> > Philip Langdale .
>
> As soon as hardware with specs is available we'll start hacking. :)
>
> > To support 8-bit transfers the core needs to implement "bus testing
> > procedure". This requires support for CMD19 and CMD14.
> >
> > Why is the support for bus testing procedure msiing from the MMCv4 support?
> >
>
> We haven't determined it as necessary, and as Philip commented, most (if not
> all) controllers cannot properly support the test.
>
> Rgds
> Pierre
>
>
>

Re: MMCv4 support (8-bit support missing)

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Madhusudhan c wrote:
> 
> Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support
> long back, which had the bus testing procedure implemented and it
> works fine. I am able to write and read the data pattern back
> successfuly with his patch. I am not sure why his patch was not
> integrated into the main line kernel.
> 

I don't think I've seen that patch. And now we have the work by Philip and
myself which adds support for both MMC 4.0 and 4.2. The only missing piece is
8-bit data and I'm not that interested in adding it until we have a driver that
can use it.

> Why should we be bothered about how controllers respond at the MMC
> core level. We need to just implement what specification says and
> leave the controller handling part to the controller driver. Am I
> correct?

Kindof. The controller drivers should indeed just handle the controller and
leave the protocol stuff to the mmc core. The problem is that this bus testing
stuff breaks the previous standards. Sending invalid CRC was not previously a
supported operation, so many controllers just toss the data when that happens.
And since the bus testing is specified as a test, not a required part of the
wide bus song and dance, we've decided to leave it out.

Rgds
Pierre



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: MMCv4 support (8-bit support missing)

[Madhusudhan c]

Hi Perre,

>I don't think I've seen that patch. And now we have the work by Philip and
> myself which adds support for both MMC 4.0 and 4.2. The only missing piece is
> 8-bit data and I'm not that interested in adding it until we have a driver that
> can use it.
Here is a link to that patch.

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3489/1

The bus test procedure from this patch can be adopted to the MMCv4
support in the MMC core with small changes to do bus testing procedure
only if the host sets the capability to support 8-bit. That way we
dont break the legacy code. What do you think?

On 4/18/07, Pierre Ossman <drzeus@drzeus.cx> wrote:
> Madhusudhan c wrote:
> >
> > Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support
> > long back, which had the bus testing procedure implemented and it
> > works fine. I am able to write and read the data pattern back
> > successfuly with his patch. I am not sure why his patch was not
> > integrated into the main line kernel.
> >
>
> I don't think I've seen that patch. And now we have the work by Philip and
> myself which adds support for both MMC 4.0 and 4.2. The only missing piece is
> 8-bit data and I'm not that interested in adding it until we have a driver that
> can use it.
>
> > Why should we be bothered about how controllers respond at the MMC
> > core level. We need to just implement what specification says and
> > leave the controller handling part to the controller driver. Am I
> > correct?
>
> Kindof. The controller drivers should indeed just handle the controller and
> leave the protocol stuff to the mmc core. The problem is that this bus testing
> stuff breaks the previous standards. Sending invalid CRC was not previously a
> supported operation, so many controllers just toss the data when that happens.
> And since the bus testing is specified as a test, not a required part of the
> wide bus song and dance, we've decided to leave it out.
>
> Rgds
> Pierre
>
>
>
>

Re: MMCv4 support (8-bit support missing)

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Madhusudhan c wrote:
> 
> The bus test procedure from this patch can be adopted to the MMCv4
> support in the MMC core with small changes to do bus testing procedure
> only if the host sets the capability to support 8-bit. That way we
> dont break the legacy code. What do you think?
> 

Until 8-bit SD shows up, at which point things go to hell again.

You need to present a valid case for why we need this bus testing stuff. The
spec never requires it, and neither does any cards. So this is just crud that we
know causes problems and doesn't give us anything back.

Rgds
Pierre



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: MMCv4 support (8-bit support missing)

[Madhusudhan c]

Hi Perre,

> Until 8-bit SD shows up, at which point things go to hell again.
>
> You need to present a valid case for why we need this bus testing stuff. The
> spec never requires it, and neither does any cards. So this is just crud that we
> know causes problems and doesn't give us anything back.
Okay. Let me try to explain a scenario where it is required.

Suppose a host controller is capable of suporting 8-bit and it tells
the core that it can support 8-bit. Now the card that is plugged in
might or might not support 8-bit based on the type of the card. There
is no field in the ext_csd which will tell you what bus width the card
can support.

So you need first try to setup 8-bit and send a patteren on the data
lines and read it back. If you get back the expected data then you are
good to go in 8-bit. Else, shift to 4-bit and try again with the data
patteren to see if four bit works. This is how the patch is
implemented. Also the spec says that you need to perform bus test
procedure before sending the switch command to set the bus width.

By doing this you can figure out whether the card supports 8-bit or
not. And this is the only way to support 8-bit cards, which are widely
available in the market today.

Also if the host controler says it can only support 4-bit then no need
of bus testing procedure.Ignoring the bus test procedure does not
affect you to functionally support 4-bit but there is no way you can
support 8-bit cards without it correctly.

Regards,
Madhu

On 4/19/07, Pierre Ossman <drzeus@drzeus.cx> wrote:
> Madhusudhan c wrote:
> >
> > The bus test procedure from this patch can be adopted to the MMCv4
> > support in the MMC core with small changes to do bus testing procedure
> > only if the host sets the capability to support 8-bit. That way we
> > dont break the legacy code. What do you think?
> >
>
> Until 8-bit SD shows up, at which point things go to hell again.
>
> You need to present a valid case for why we need this bus testing stuff. The
> spec never requires it, and neither does any cards. So this is just crud that we
> know causes problems and doesn't give us anything back.
>
> Rgds
> Pierre
>
>
>
>

Re: MMCv4 support (8-bit support missing)

[Philip Langdale]

Madhusudhan c wrote:
> 
> Suppose a host controller is capable of suporting 8-bit and it tells
> the core that it can support 8-bit. Now the card that is plugged in
> might or might not support 8-bit based on the type of the card. There
> is no field in the ext_csd which will tell you what bus width the card
> can support.

My understanding is that 8-bit support on the card is not optional. ie:
the card is not mmc 4 compliant if it doesn't support 8-bit and this
is why there's no ext_csd field. The only case I could think of where
bus testing would be needed would be if a controller was placed into
a configuration where some pins were deliberately left unconnected
(perhaps because space constraints prevented the extra 4 pins from being
placed on a pcb) and there was no way to change the capabilities reported
by the controller.

But in any case - this is all hypothetical right now - one can't find
a controller in the wild for love or money (well - Arasan will sell you
a validation controller for $5000 but still...). As neither Pierre or
myself is in a position to do any sort of tests on an 8-bit controller,
we can't investigate or verify any of this.

It certainly seems that you have access to an 8-bit controller. If you
can help one or both of us get access to one, I'm sure we could work out
the right thing to do.

--phil

Re: MMCv4 support (8-bit support missing)

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Madhusudhan c wrote:
> 
> Suppose a host controller is capable of suporting 8-bit and it tells
> the core that it can support 8-bit. Now the card that is plugged in
> might or might not support 8-bit based on the type of the card. There
> is no field in the ext_csd which will tell you what bus width the card
> can support.
> 

I've looked through the MMC 4.2 spec and I see nothing in it that even hints
that 8-bit support might be optional. So as it stands, the bus testing is still out.

Rgds
Pierre



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: MMCv4 support (8-bit support missing)

[Madhusudhan c]

Hi Pierre/Philip,

> I've looked through the MMC 4.2 spec and I see nothing in it that even hints
> that 8-bit support might be optional. So as it stands, the bus testing is still out.
Okay. Its possible that my understanding was wrong in the sense that I
thought bus testing procedure is mandatory to support 8-bit cards. If
8-bit is mandatory for MMC4 cards, then the changes required in the
MMC core to support 8-bit might be  simple. Based on host controller
cap this can be handled.

Philip asked me about the access to the 8-bit controller. We might not
be able to provide you direct access to the hardware platform as it
requires involvement of business managers and so on. But can I be of
help by testing your code on our platform and leting you know the
results?

Regards,
Madhu



On 4/24/07, Pierre Ossman <drzeus@drzeus.cx> wrote:
> Madhusudhan c wrote:
> >
> > Suppose a host controller is capable of suporting 8-bit and it tells
> > the core that it can support 8-bit. Now the card that is plugged in
> > might or might not support 8-bit based on the type of the card. There
> > is no field in the ext_csd which will tell you what bus width the card
> > can support.
> >
>
> I've looked through the MMC 4.2 spec and I see nothing in it that even hints
> that 8-bit support might be optional. So as it stands, the bus testing is still out.
>
> Rgds
> Pierre
>
>
>
>

Re: MMCv4 support (8-bit support missing)

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Madhusudhan c wrote:
> 
> Philip asked me about the access to the 8-bit controller. We might not
> be able to provide you direct access to the hardware platform as it
> requires involvement of business managers and so on. But can I be of
> help by testing your code on our platform and leting you know the
> results?
> 

Sure. Or you'll construct a patch for that yourselves. It should be fairly
trivial to extend the current stuff.

Will this driver be submitted upstream? I'm not too fond of merging features in
the mmc layer that no in-kernel driver uses.

Rgds
Pierre



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]