Hi Sascha,
How are things going with the driver? I was hoping we could get it into
the kernel for 2.6.27 at least.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Hi,
On Samstag, 5. Juli 2008, Pierre Ossman wrote:
> Hi Sascha,
>
> How are things going with the driver? I was hoping we could get it into
> the kernel for 2.6.27 at least.
>
Ok here we go again:
Based on the feedback from your last review I did the following changes:
- the driver should now be able to transfer data blocks with sizes smaller
than 512 mb
- the endian problems in the block/io function should be gone
- the YENTA dependency has been removed
- the cmd specific includes have been removed
- set_ios() has been fixed to set the bus width correctly
- the busy check has been removed as per your suggestion
Apart from that the following problems remain:
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:
sdricoh_cs 0.0: query_status: timeout waiting for 1000000
sdricoh_cs 0.0: sdricoh_request: cmd 8 block transfer failed
sdricoh_cs 0.0: query_status: timeout waiting for 4
sdricoh_cs 0.0: sdricoh_request: transfer end error
mmc0: unable to read EXT_CSD, performance might suffer.
The card works without problems after this message.
Regards
Sascha
On Sat, 5 Jul 2008 21:11:49 +0200
Sascha Sommer <[email protected]> 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 ;))
> mmc0: unable to read EXT_CSD, performance might suffer.
>
> The card works without problems after this message.
>
Yeah, it works for older MMC cards. The newer, larger ones will fail
when it can't read the EXT_CSD though.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Hi,
On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> On Sat, 5 Jul 2008 21:11:49 +0200
>
> Sascha Sommer <[email protected]> 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
On Sun, 6 Jul 2008 09:09:30 +0200
Sascha Sommer <[email protected]> wrote:
>
> 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 ;(.
>
Very odd. Anyway, send an updated patch with a proper entry in
MAINTAINERS and I'll queue it up.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Hi,
On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> On Sun, 6 Jul 2008 09:09:30 +0200
>
> Sascha Sommer <[email protected]> wrote:
> > 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 ;(.
>
> Very odd. Anyway, send an updated patch with a proper entry in
> MAINTAINERS and I'll queue it up.
>
See the attached patch.
Regards
Sascha
On Fri, 11 Jul 2008 20:45:49 +0200
Sascha Sommer <[email protected]> wrote:
> Hi,
>
> On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> >
> > Very odd. Anyway, send an updated patch with a proper entry in
> > MAINTAINERS and I'll queue it up.
> >
>
> See the attached patch.
>
I've queued it up and it should be with Linus within a day or two.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
Hi,
On Dienstag, 15. Juli 2008, Pierre Ossman wrote:
> On Fri, 11 Jul 2008 20:45:49 +0200
>
> Sascha Sommer <[email protected]> wrote:
> > Hi,
> >
> > On Sonntag, 6. Juli 2008, Pierre Ossman wrote:
> > > Very odd. Anyway, send an updated patch with a proper entry in
> > > MAINTAINERS and I'll queue it up.
> >
> > See the attached patch.
>
> I've queued it up and it should be with Linus within a day or two.
>
> Rgds
Thanks.
Regards
Sascha