public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* Plea for MMC spec owners
@ 2006-06-05  8:52 Pierre Ossman
  0 siblings, 0 replies; 12+ messages in thread
From: Pierre Ossman @ 2006-06-05  8:52 UTC (permalink / raw)
  To: linux-omap-open-source

Sorry for being a bit off topic, but this was the venue suggested to me
to get in touch with the required people.

Myself and Russell King (the MMC layer maintainer) have been discussing
a way to resolve the issue with 2GB+ cards that more and more users are
reporting.

The issue that is causing us grief is whether or not it's safe to always
use a sector size of 512 bytes. The card specs we have give conflicting
information, so we'd like to find someone who has access to the official
protocol spec and can check the exact wording. I was told that some of
the Nokia folks, who have been helpful in checking the offical spec
before, hang around here.  :)

What is needed is the exact definition of READ_BL_PARTIAL and
WRITE_BL_PARTIAL.

Thanks
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Plea for MMC spec owners
@ 2006-06-05 14:36 Khasim, Syed
  2006-06-05 15:57 ` Pierre Ossman
  0 siblings, 1 reply; 12+ messages in thread
From: Khasim, Syed @ 2006-06-05 14:36 UTC (permalink / raw)
  To: Pierre Ossman, linux-omap-open-source

Hi Pierre,

A quick search to write_bl_partial and read_bl_partial in MMC spec gave
the following lines.

WRITE_BL_PARTIAL
----------------
Defines whether partial block sizes can be used in block write commands.

WRITE_BL_PARTIAL='0' means that only the WRITE_BL_LEN block size can be
used for block oriented data write.

WRITE_BL_PARTIAL='1' means that smaller blocks can be used as well. The
minimum block size is one byte.

READ_BL_PARTIAL
---------------
Defines whether partial block sizes can be used in block read commands

READ_BL_PARTIAL=0 means that only the READ_BL_LEN block size can be used
for block oriented data transfers.

READ_BL_PARTIAL=1 means that smaller blocks can be used as well. The
minimum block size will be equal to minimum addressable unit (one byte)

Regards,
Khasim

-----Original Message-----
From: linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com
[mailto:linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com]
On Behalf Of Pierre Ossman
Sent: Monday, June 05, 2006 3:52 AM
To: linux-omap-open-source@linux.omap.com
Subject: Plea for MMC spec owners

Sorry for being a bit off topic, but this was the venue suggested to me
to get in touch with the required people.

Myself and Russell King (the MMC layer maintainer) have been discussing
a way to resolve the issue with 2GB+ cards that more and more users are
reporting.

The issue that is causing us grief is whether or not it's safe to always
use a sector size of 512 bytes. The card specs we have give conflicting
information, so we'd like to find someone who has access to the official
protocol spec and can check the exact wording. I was told that some of
the Nokia folks, who have been helpful in checking the offical spec
before, hang around here.  :)

What is needed is the exact definition of READ_BL_PARTIAL and
WRITE_BL_PARTIAL.

Thanks
Pierre
_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Plea for MMC spec owners
@ 2006-06-05 15:34 Khasim, Syed
  0 siblings, 0 replies; 12+ messages in thread
From: Khasim, Syed @ 2006-06-05 15:34 UTC (permalink / raw)
  To: Pierre Ossman, linux-omap-open-source

Hi Pierre,

I think you already have this pointer to SD spec, might be helpful to
others.

http://www.sdcard.org/sd_memorycard/Simplified%20Physical%20Layer%20Spec
ification.PDF

Regards,
Khasim

-----Original Message-----
From: linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com
[mailto:linux-omap-open-source-bounces+x0khasim=ti.com@linux.omap.com]
On Behalf Of Pierre Ossman
Sent: Monday, June 05, 2006 3:52 AM
To: linux-omap-open-source@linux.omap.com
Subject: Plea for MMC spec owners

Sorry for being a bit off topic, but this was the venue suggested to me
to get in touch with the required people.

Myself and Russell King (the MMC layer maintainer) have been discussing
a way to resolve the issue with 2GB+ cards that more and more users are
reporting.

The issue that is causing us grief is whether or not it's safe to always
use a sector size of 512 bytes. The card specs we have give conflicting
information, so we'd like to find someone who has access to the official
protocol spec and can check the exact wording. I was told that some of
the Nokia folks, who have been helpful in checking the offical spec
before, hang around here.  :)

What is needed is the exact definition of READ_BL_PARTIAL and
WRITE_BL_PARTIAL.

Thanks
Pierre
_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-05 14:36 Plea for MMC spec owners Khasim, Syed
@ 2006-06-05 15:57 ` Pierre Ossman
  0 siblings, 0 replies; 12+ messages in thread
From: Pierre Ossman @ 2006-06-05 15:57 UTC (permalink / raw)
  To: Khasim, Syed; +Cc: linux-omap-open-source

Khasim, Syed wrote:
> Hi Pierre,
>
> A quick search to write_bl_partial and read_bl_partial in MMC spec gave
> the following lines.
>   

Thanks. Unfortunately, it wasn't the response I was hoping for as it
isn't consistent with what we've been seeing with other MMC and SD readers.

> I think you already have this pointer to SD spec, might be helpful to
> others.
>
> http://www.sdcard.org/sd_memorycard/Simplified%20Physical%20Layer%20Spec
> ification.PDF
>
>   

I have to admit, I hadn't looked that closely at that spec as it didn't
cover the protocol properly. But it actually said something about this
issue:

4.3.2 2GByte Card
To make 2GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN)
shall be set to
1024 bytes. But Block Length set by CMD16 shall be up to 512 bytes to
keep consistency with 512
bytes Maximum Block Length cards (Less than and equal 2GByte cards).

Could you have a second look in the MMC spec and see if there are
similar provisions?

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Plea for MMC spec owners
@ 2006-06-05 22:19 Khasim, Syed
  2006-06-05 22:40 ` Pierre Ossman
  0 siblings, 1 reply; 12+ messages in thread
From: Khasim, Syed @ 2006-06-05 22:19 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: linux-omap-open-source

Hi Pierre,

Regarding 2GB, the MMC specification doesn't state any thing clearly as
the SD spec does.

As per my understanding, MMC (of all sizes) by default should be set to
operate in 512B (mandatory). This is true for both read and write. With
this default setup, I feel MMC card (<=2GB) should work as is with BLEN
set to 512.

However, if the size of MMC is greater than 2GB then it switches to
sector access mode (<=2GB operates in byte access) and we are supposed
to read from EXT_CSD register for getting the density of card. I was
wondering if for some reason on some of the cards it's switching to this
mode and therefore it's not consistent across all the 2GB MMCs.

Regards,
Khasim

-----Original Message-----
From: Pierre Ossman [mailto:drzeus-list@drzeus.cx] 
Sent: Monday, June 05, 2006 10:57 AM
To: Khasim, Syed
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Plea for MMC spec owners

Khasim, Syed wrote:
> Hi Pierre,
>
> A quick search to write_bl_partial and read_bl_partial in MMC spec
gave
> the following lines.
>   

Thanks. Unfortunately, it wasn't the response I was hoping for as it
isn't consistent with what we've been seeing with other MMC and SD
readers.

> I think you already have this pointer to SD spec, might be helpful to
> others.
>
>
http://www.sdcard.org/sd_memorycard/Simplified%20Physical%20Layer%20Spec
> ification.PDF
>
>   

I have to admit, I hadn't looked that closely at that spec as it didn't
cover the protocol properly. But it actually said something about this
issue:

4.3.2 2GByte Card
To make 2GByte card, the Maximum Block Length (READ_BL_LEN=WRITE_BL_LEN)
shall be set to
1024 bytes. But Block Length set by CMD16 shall be up to 512 bytes to
keep consistency with 512
bytes Maximum Block Length cards (Less than and equal 2GByte cards).

Could you have a second look in the MMC spec and see if there are
similar provisions?

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-05 22:19 Khasim, Syed
@ 2006-06-05 22:40 ` Pierre Ossman
  0 siblings, 0 replies; 12+ messages in thread
From: Pierre Ossman @ 2006-06-05 22:40 UTC (permalink / raw)
  To: Khasim, Syed; +Cc: linux-omap-open-source

Khasim, Syed wrote:
> Hi Pierre,
>
> Regarding 2GB, the MMC specification doesn't state any thing clearly as
> the SD spec does.
>
>   

That's too bad as I was hoping we could avoid guesswork. :-/

> As per my understanding, MMC (of all sizes) by default should be set to
> operate in 512B (mandatory). This is true for both read and write. With
> this default setup, I feel MMC card (<=2GB) should work as is with BLEN
> set to 512.
>   

That is my feeling as well. But it would have been nice to back it up
with an official spec.

> However, if the size of MMC is greater than 2GB then it switches to
> sector access mode (<=2GB operates in byte access) and we are supposed
> to read from EXT_CSD register for getting the density of card. I was
> wondering if for some reason on some of the cards it's switching to this
> mode and therefore it's not consistent across all the 2GB MMCs.
>
>   

This voodoo you speak of is rather unknown to us since we lack a real
MMC4 spec. ;-)

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Plea for MMC spec owners
@ 2006-06-06 14:44 Khasim, Syed
  2006-06-06 21:39 ` Pierre Ossman
  0 siblings, 1 reply; 12+ messages in thread
From: Khasim, Syed @ 2006-06-06 14:44 UTC (permalink / raw)
  To: Pierre Ossman; +Cc: linux-omap-open-source

> As per my understanding, MMC (of all sizes) by default should be set
to
> operate in 512B (mandatory). This is true for both read and write.
With
> this default setup, I feel MMC card (<=2GB) should work as is with
BLEN
> set to 512.
>   

>>> That is my feeling as well. But it would have been nice to back it
up
>>> with an official spec.

Pierre, this is clearly defined in spec. It's mandatory for a MMC (of
any size) to start with a 512M block on a soft reset / power on. 

Regards,
Khasim

-----Original Message-----
From: Pierre Ossman [mailto:drzeus-list@drzeus.cx] 
Sent: Monday, June 05, 2006 5:40 PM
To: Khasim, Syed
Cc: linux-omap-open-source@linux.omap.com
Subject: Re: Plea for MMC spec owners

Khasim, Syed wrote:
> Hi Pierre,
>
> Regarding 2GB, the MMC specification doesn't state any thing clearly
as
> the SD spec does.
>
>   

That's too bad as I was hoping we could avoid guesswork. :-/

> As per my understanding, MMC (of all sizes) by default should be set
to
> operate in 512B (mandatory). This is true for both read and write.
With
> this default setup, I feel MMC card (<=2GB) should work as is with
BLEN
> set to 512.
>   

That is my feeling as well. But it would have been nice to back it up
with an official spec.

> However, if the size of MMC is greater than 2GB then it switches to
> sector access mode (<=2GB operates in byte access) and we are supposed
> to read from EXT_CSD register for getting the density of card. I was
> wondering if for some reason on some of the cards it's switching to
this
> mode and therefore it's not consistent across all the 2GB MMCs.
>
>   

This voodoo you speak of is rather unknown to us since we lack a real
MMC4 spec. ;-)

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-06 14:44 Khasim, Syed
@ 2006-06-06 21:39 ` Pierre Ossman
  2006-06-06 23:49   ` Kyungmin Park
  0 siblings, 1 reply; 12+ messages in thread
From: Pierre Ossman @ 2006-06-06 21:39 UTC (permalink / raw)
  To: Khasim, Syed; +Cc: linux-omap-open-source

Khasim, Syed wrote:
>
> Pierre, this is clearly defined in spec. It's mandatory for a MMC (of
> any size) to start with a 512M block on a soft reset / power on. 
>   

Then I guess the spec would be self-contradictory as the section you
quoted earlier clearly stated that only READ_BL_LEN/WRITE_BL_LEN was
valid if *_BL_PARTIAL wasn't set.

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: Plea for MMC spec owners
  2006-06-06 21:39 ` Pierre Ossman
@ 2006-06-06 23:49   ` Kyungmin Park
  2006-06-07  9:04     ` Pierre Ossman
  2006-06-07 10:10     ` Pierre Ossman
  0 siblings, 2 replies; 12+ messages in thread
From: Kyungmin Park @ 2006-06-06 23:49 UTC (permalink / raw)
  To: 'Pierre Ossman', 'Khasim, Syed'; +Cc: linux-omap-open-source

Hi

The following is written from MMC Spec. 4.2

* READ_BL_PARTIAL
Defines whether partial block sizes can be used in block read commands.
Up to 2GB of density (byte access mode):
READ_BL_PARTIAL=0 means that only the 512B and the READ_BL_LEN block size
can be used for
block oriented data transfers.
READ_BL_PARTIAL=1 means that smaller blocks can be used as well. The
minimum block size will be
equal to minimum addressable unit (one byte).
Higher than 2GB of density (sector access mode):
READ_BL_PARTIAL=0 means that only the 512B and the READ_BL_LEN block sizes
can be used for
block oriented data transfers.
READ_BL_PARTIAL=1 means that smaller blocks than indicated in READ_BL_LEN
can be used as
well. The minimum block size will be equal to minimum addressable unit, one
sector (512B).

* WRITE_BL_LEN
Block length for write operations. See READ_BL_LEN for field coding.
Note that the support for 512B write access is mandatory for all cards. And
that the cards has to be in 512B
block length mode by default after power-on, or software reset. The purpose
of this register is to indicate the
supported maximum write data block length.
Defines whether partial block sizes can be used in block write commands.
Up to 2GB of density (byte access mode):
WRITE_BL_PARTIAL=’0’ means that only the 512B and the WRITE_BL_LEN block
size can be used
for block oriented data write.
WRITE_BL_PARTIAL=’1’ means that smaller blocks can be used as well. The
minimum block size is one
byte.
Higher than 2GB of density (sector access mode):
WRITE_BL_PARTIAL=’0’ means that only the 512B and the WRITE_BL_LEN block
size can be used
for block oriented data write.
WRITE_BL_PARTIAL=’1’ means that smaller blocks can be used as well. The
minimum block size will
be equal to minimum addressable unit, one sector (512B).

4.2.3 Access Mode Validation (Higher than 2GB of Densities)
The SEND_OP_COND (CMD1) command and the OCR register are also including two
bits for the indication of the supported access mode of the memory. The
specifically set bits in the CMD1 command argument are indicating to a
memory that the host is capable of handling sector type of addressing. The
correspondingly set bits in the OCR register are indicating that the card
is requiring usage of sector type of addressing. These specific
bits of the OCR register are valid only in the last response from the card
for CMD1 (card entering Ready state). This kind of two way handshaking is
needed so that
* If there is no indication by a host to a memory that the host is capable
of handling sector type of addressing
the higher than 2GB of density of memory will change its state to Inactive
(similarly to a situation in which there is no common voltage range to work
with)
* From the indication of the sector type of addressing requirement in the
OCR register the host is able to separate
the card from the byte access mode cards and prepare itself
It needs to be taken into account that in a multi card system a byte access
mode card (<=2GB) is blocking the
OCR response in such way that a sector access mode card (>2GB) is not
necessarily recognized as a sector
access mode card during the initialization. Thus this needs to be
reconfirmed by reading the SEC_COUNT
information from the EXT_CSD register. 

Regards,
Kyungmin Park

> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com 
> [mailto:linux-omap-open-source-bounces@linux.omap.com] On 
> Behalf Of Pierre Ossman
> Sent: Wednesday, June 07, 2006 6:40 AM
> To: Khasim, Syed
> Cc: linux-omap-open-source@linux.omap.com
> Subject: Re: Plea for MMC spec owners
> 
> Khasim, Syed wrote:
> >
> > Pierre, this is clearly defined in spec. It's mandatory for 
> a MMC (of 
> > any size) to start with a 512M block on a soft reset / power on.
> >   
> 
> Then I guess the spec would be self-contradictory as the 
> section you quoted earlier clearly stated that only 
> READ_BL_LEN/WRITE_BL_LEN was valid if *_BL_PARTIAL wasn't set.
> 
> Rgds
> Pierre
> 
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
> 
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-06 23:49   ` Kyungmin Park
@ 2006-06-07  9:04     ` Pierre Ossman
  2006-06-07 10:10     ` Pierre Ossman
  1 sibling, 0 replies; 12+ messages in thread
From: Pierre Ossman @ 2006-06-07  9:04 UTC (permalink / raw)
  To: kyungmin.park; +Cc: linux-omap-open-source

Kyungmin Park wrote:
> Hi
>
> The following is written from MMC Spec. 4.2
>
>   

Very nice. This should be sufficient to go ahead with locking down the
sector size to 512 bytes. :)

Thanks for the help.

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-06 23:49   ` Kyungmin Park
  2006-06-07  9:04     ` Pierre Ossman
@ 2006-06-07 10:10     ` Pierre Ossman
  2006-06-16 11:04       ` Pierre Ossman
  1 sibling, 1 reply; 12+ messages in thread
From: Pierre Ossman @ 2006-06-07 10:10 UTC (permalink / raw)
  To: kyungmin.park; +Cc: linux-omap-open-source

First off, thanks a bundle for all the help.

Now I was hoping that you could check one final thing before I scurry
off. :)

SD cards have a command (ACMD22) that reports the number of successfully
written blocks. This allows us to do multi-block writes safely, even
with deep pipelines. The MMC specs I have do not mention anything
similar, so this currently seems to be a SD-only feature. Could you guys
have a look if something along these lines have shown up in the later
versions?

Rgds
Pierre

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Plea for MMC spec owners
  2006-06-07 10:10     ` Pierre Ossman
@ 2006-06-16 11:04       ` Pierre Ossman
  0 siblings, 0 replies; 12+ messages in thread
From: Pierre Ossman @ 2006-06-16 11:04 UTC (permalink / raw)
  Cc: linux-omap-open-source

Anyone?

Pierre Ossman wrote:
> First off, thanks a bundle for all the help.
> 
> Now I was hoping that you could check one final thing before I scurry
> off. :)
> 
> SD cards have a command (ACMD22) that reports the number of successfully
> written blocks. This allows us to do multi-block writes safely, even
> with deep pipelines. The MMC specs I have do not mention anything
> similar, so this currently seems to be a SD-only feature. Could you guys
> have a look if something along these lines have shown up in the later
> versions?
> 
> Rgds
> Pierre
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2006-06-16 11:04 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-05 14:36 Plea for MMC spec owners Khasim, Syed
2006-06-05 15:57 ` Pierre Ossman
  -- strict thread matches above, loose matches on Subject: below --
2006-06-06 14:44 Khasim, Syed
2006-06-06 21:39 ` Pierre Ossman
2006-06-06 23:49   ` Kyungmin Park
2006-06-07  9:04     ` Pierre Ossman
2006-06-07 10:10     ` Pierre Ossman
2006-06-16 11:04       ` Pierre Ossman
2006-06-05 22:19 Khasim, Syed
2006-06-05 22:40 ` Pierre Ossman
2006-06-05 15:34 Khasim, Syed
2006-06-05  8:52 Pierre Ossman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox