Re: Purpose of MMC_DATA_MULTI?

Russell King wrote:
On Wed, Feb 01, 2006 at 10:37:12AM +0100, Pierre Ossman wrote:
Russell King wrote:
On Wed, Feb 01, 2006 at 07:40:26AM +0100, Pierre Ossman wrote:
I noticed that a new transfer flag was recently added to the MMC layer
without any immediate users, the MMC_DATA_MULTI flag. I'm guessing the
purpose of the flag is to indicate the difference between
MMC_READ_SINGLE_BLOCK and MMC_READ_MULTIPLE_BLOCKS with just one block.
If so, then that should probably be mentioned in a comment somewhere.
There are hosts out there (Atmel AT91-based) which need to know if the
transfer is going to be multiple block. Rather than have them test
the op-code (which is what they're already doing), we provide a flag
instead.
As far as the hardware is concerned there are two "multi-block" transfers:

 * Multiple, back-to-back blocks.
 * One or more blocks that need to be terminated by some form of stop
command.

The first can be identified by checking the number of blocks in the
request, the latter is harder to identify since it's a protocol semantic
(it could be just one block, but still need a stop). Does MMC_DATA_MULTI
indicate the latter, former or both?

In short, it's defined to be whatever AT91_MCI_TRTYP_MULTIPLE means in
the AT91RM9200 MMC host driver, which appears to be set for any of the
multiple block commands.  They currently are doing:


That's a bit fuzzy and bound to give problems. Why not settle for the first case and change their code to check the block count in the request? Less flags should be a good thing. And if that proves to be insufficient we should do a more thorough investigation once we have an actual failure case.

and using that as a lookup table by command for the value to put into
the command register.  I want to eliminate that, and not passing the
MULTI flag prevents elimination of this table.


Seems to be a common theme in the more recent drivers. Don't they teach people proper layering in the schools anymore? :)

Rgds
Pierre


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Relevant Pages

  • [PATCH 01/05] mm fix __alloc_pages cpuset ALLOC_* flags
    ... request that will free up more memory than is asked for (exiting ... With this, cpuset confinement ... flag entirely. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: d_splice_alias() problem.
    ... After reading your comments below the semantics of the flag ... Suppose one thread creates a disconnected dentry, ... When it is half way up another request comes in for the same ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: God omitted from flag certificate
    ... Word was requested for certificate for flag flown over Capitol; ... Rep. Turner helps family fix omission. ... "God" from the request. ...
    (rec.scouting.issues)
  • Re: [RFC] [PATCH] Power S3 Resume Optimization Patch. Request for Comment
    ... Here is a simple patch for optimising the S3 resume. ... Given the fact that device initialisation ... request and to make sure all the io request are queued till the device ... if the flag is set, it doesnt put the request in the dispatch queue. ...
    (Linux-Kernel)
  • God omitted from flag certificate
    ... Word was requested for certificate for flag flown over Capitol; ... "God" from the request. ...
    (rec.scouting.issues)