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
next prev parent 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.