From: David Brownell <david-b@pacbell.net>
To: "Kumar, Purushotam" <purushotam@ti.com>
Cc: davinci-linux-open-source@linux.davincidsp.com,
Pierre Ossman <drzeus-mmc@drzeus.cx>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] DaVinci: MMC: V4: MMC/SD controller driver for DaVinci family.
Date: Fri, 17 Apr 2009 12:38:14 -0700 [thread overview]
Message-ID: <200904171238.15077.david-b@pacbell.net> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301CCA0190F@dbde02.ent.ti.com>
On Friday 17 April 2009, Kumar, Purushotam wrote:
>
> > I'm still not following the requirements here. Why would the hardware
> > only need to have the FIFO primed for those two commands and not every
> > kind of write?
>
> This required by SD controller as suggested by IP designer. Please
> look at SD controller spec at http://www.ti.com/litv/pdf/sprue30d .
> Please check section 3.2/3.6 and point no 11/10 in the controller spec.
Those are in Chapter 3, "Procedures for Common Operations" ...
that is, examples. Examples, as a rule, are there just to
elaborate ("unpack") the more detailed text, not substitute
for clear specification. (And TI is generally pretty good
about providing sane documentation, thank you! Fewer problems
than with "some" vendors.)
In this case the spec says in a note in 2.7.2 that priming
the fifo is needed for "write transactions" ... since no
"fifo became empty" IRQ is generated. It does not limit it
to the WRITE_BLOCK and WRITE_MULTIPLE_BLOCK commands.
Those examples are for writing single and multiple blocks; there
are no SDIO write operations shown, for example, or password
passing operations. Those would also suffer from the lack of
a "fifo became empty" IRQ.
> It does not talk about priming by 32 bytes for any other command.
Said diffferently, *every* PIO write transaction shown primes
the fifo ... but there are no examples of non-block writes.
> This restriction is from SD controller.
Could you confirm that interpretation with the folk who have
provided that silicon block?
If your reading is correct, and it's really a restriction to
those two commands, the documentation should change to say
that "single and multiple block write commands" require FIFO
priming ... not all "write transactions" as now written.
- Dave
next prev parent reply other threads:[~2009-04-17 19:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 9:56 Purushotam Kumar
2009-04-10 19:41 ` Pierre Ossman
2009-04-17 11:04 ` Kumar, Purushotam
2009-04-17 19:38 ` David Brownell [this message]
2009-04-21 14:14 ` Kumar, Purushotam
2009-04-28 19:45 ` 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=200904171238.15077.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=drzeus-mmc@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=purushotam@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®