From: Sascha Sommer <saschasommer@freenet.de>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: sdricohcs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: Status of Ricoh Bay1Controller driver?
Date: Sun, 6 Jul 2008 09:09:30 +0200 [thread overview]
Message-ID: <200807060909.30563.saschasommer@freenet.de> (raw)
In-Reply-To: <20080706012435.016358d6@mjolnir.drzeus.cx>
Hi,
On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> On Sat, 5 Jul 2008 21:11:49 +0200
>
> Sascha Sommer <saschasommer@freenet.de> wrote:
> > There is still some hack for ACMDs. I know you won't like that but I did
> > not get the SD_APP_SEND_SCR command to work without it.
> >
> > MMC_SEND_EXT_CSD does not work (also not with that ACMD hack) and prints
> > out something like:
>
> The SCR and EXT_CSD are both the only data transfers that are done in
> 1-bit mode in the respective init paths. Are you sure that hack you
> have for ACMDs is really for ACMDs and not for 1-bit transfers?
>
> (And you're right about me not liking that hack, but I can let that one
> slide as long as you agree it is important to get rid off ;))
>
Well I do not like the hacks either ;) However I'm out of ideas when it comes
to these two commands. As far as I know the windows driver also does the |=64
for the SD_APP_OP_COND and SD_APP_SET_BUS_WIDTH what are the only ACMDs.
These aren't data read commands.
When I do not do the |= 64 the SD_APP_SEND_SCR command fails just like the
MMC_SEND_EXT_CSD command.
#define MMC_SEND_EXT_CSD 8 /* adtc R1 */
#define MMC_SEND_CSD 9 /* ac [31:16] RCA R2 */
#define SD_APP_SEND_SCR 51 /* adtc R1 */
After the SD_APP_SEND_SCR command worked I tryed to fix the MMC_SEND_EXT_CSD
command.
As you can see they look quite similar from the command description.
I tryed:
- different bit combination for what seem to be the command flags
- or the opcode with |= 64, if this flag is for data transfers in one 1-bit
mode this should have worked, shouldn't it?
- set the bus width to 4 bit before the read
Nothing worked ;( == The status register simply does not indicate that there
is data available that can be read. It doesn't even change. Reading the data
register nevertheless returns only zeros.
So to summarize this I agree that it is important to get rid off these
hacks ;) but I don't have a better solution available at the moment ;(.
Regards
Sascha
next prev parent reply other threads:[~2008-07-06 7:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-05 9:50 Status of Ricoh Bay1Controller driver? Pierre Ossman
2008-07-05 19:11 ` Sascha Sommer
2008-07-05 23:24 ` Pierre Ossman
2008-07-06 7:09 ` Sascha Sommer [this message]
2008-07-06 17:49 ` Pierre Ossman
2008-07-11 18:45 ` Sascha Sommer
2008-07-15 12:18 ` Pierre Ossman
2008-07-15 12:28 ` Sascha Sommer
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=200807060909.30563.saschasommer@freenet.de \
--to=saschasommer@freenet.de \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=sdricohcs-devel@lists.sourceforge.net \
/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