All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: Pierre Ossman <drzeus-list@drzeus.cx>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Purpose of MMC_DATA_MULTI?
Date: Thu, 02 Feb 2006 10:49:51 +0100	[thread overview]
Message-ID: <43E1D5BF.5000807@drzeus.cx> (raw)
In-Reply-To: <20060202093656.GA5034@flint.arm.linux.org.uk>

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



  reply	other threads:[~2006-02-02  9:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01  6:40 Purpose of MMC_DATA_MULTI? Pierre Ossman
2006-02-01  9:29 ` Russell King
2006-02-01  9:37   ` Pierre Ossman
2006-02-02  9:36     ` Russell King
2006-02-02  9:49       ` Pierre Ossman [this message]
2006-02-02  9:59         ` Russell King
2006-02-02 15:00           ` Pierre Ossman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E1D5BF.5000807@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.