The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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