Re: Purpose of MMC_DATA_MULTI?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux