On Mon, Dec 02, 2013 at 04:52:51PM +0100, Sylvestre Gallon wrote:
> On Wed, Nov 20, 2013 at 10:25:52AM +0100, Stefan Sperling wrote:
> > On Thu, Nov 07, 2013 at 08:10:16PM +0100, Stefan Sperling wrote:
> > > On Thu, Nov 07, 2013 at 08:06:11PM +0100, Sylvestre Gallon wrote:
> > > > +int
> > > > +rtsx_bus_width(sdmmc_chipset_handle_t sch, int width)
> > > > +{
> > > > +       struct rtsx_softc *sc = sch;
> > > > +
> > > > +       return (rtsx_set_bus_width(sc, width));
> > > 
> > > rtsx_set_bus_width() currently never returns an error so you'll
> > > need to tweak it as well.
> > > 
> > > I will test your diff on rtsx and sdhc.
> > 
> > This diff works with sdhc and provides an increase in read performance.
> > 
> > Unfortunately, the diff breaks rtsx. The disk manages to attach after
> > a CRC error, but it cannot be read. We'll need to figure this out.
> > 
> 
> Hi,
> 
> Does this diff works better ? I have just renable these lines in 
> rtsx_bus_power() :
> 
> -       error = rtsx_set_bus_width(sc, 1);
> -       if (error)
> -               goto ret;

Unfortunately, this still doesn't work.

sdmmc0: SD_SEND_SCR send failed.
sdmmc0: mem init failed

Perhaps the problem is that the code doing SEND_SCR is trying to
peform a data transfer, i.e. cmd.c_data and cmd.c_datalen are being set.
Why is a data transfer needed? Doesn't the card include the 32bit SCR
value in its response (cmd.c_resp)?

The rtsx code is using data transfer for reading and writing blocks from
the card, i.e. after cmd 17, 18, etc. Perhaps we could try to make rtsx
use RTSX_TM_NORMAL_READ data transfer mode for commands like SEND_SCR,
instead of RTSX_TM_AUTO_READ3. But I don't really know if that would help.

Anyway, one possible path forward would be to not change existing
code paths for host adapters that don't set SMC_CAPS_4BIT_MODE.
Then we could leave this feature disabled for rtsx to avoid the
regression and enable 4bit mode once we get it working. Do you think
that is feasible? Just removing the line that sets SMC_CAPS_4BIT_MODE
for rtsx is not enough because your diff changes the behaviour of the
sdmmc stack anyway -- rtsx still fails in SEND_SCR. And perhaps we would
need another CAPS flag for SEND_SWITCH_FUNC support and just as carefully
tip-toe around host controller drivers that don't set it.

BTW, this part of your diff looks wrong:

+       if (ptr != NULL)
+               if (ISSET(sc->sc_caps, SMC_CAPS_DMA))
+                       free(ptr, M_DEVBUF);

I think neither of these if-statements is needed.
You always need to free the pointer, and it's OK to free NULL.
Nothing sets CAPS_DMA right now, AFAIK. rtsx uses DMA, but it doesn't
require support from the sdmmc stack for this. It seems NetBSD are
doing that differently and you copied this CAPS_DMA check from there.

> If it still not work with this diff can you add a printf in the
> bus_clock code to know which frequency is required by the stack ?

See below. I've added some debug output with rtsxdebug=3 and a few
more printfs.

Note that the first 'soft reset' is normal, a timeout is expected
at that stage of card discovery. The second one means that data
transfer from the card has timed out.

rtsx0: card inserted
rtsx0: voltage change ocr=0x403c0000
rtsx0: setting buswidth to 1
rtsx_bus_clock: freq=400
rtsx0: executing cmd 5
rtsx0: executing cmd 0
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: voltage change ocr=0xc0000
rtsx0: setting buswidth to 1
rtsx0: executing cmd 0
rtsx0: executing cmd 8
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 55
rtsx0: executing cmd 41
rtsx0: executing cmd 2
rtsx0: executing cmd 3
rtsx0: executing cmd 2
rtsx0: soft reset
rtsx0: executing cmd 9
rtsx0: executing cmd 7
rtsx0: executing cmd 16
rtsx0: executing cmd 55
rtsx0: executing cmd 51
rtsx0: read xfer: 8 bytes with block size 8
rtsx0: soft reset
rtsx0: xfer done, error=60
sdmmc0: SD_SEND_SCR send failed.
sdmmc0: mem init failed
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <SD/MMC, Drive #01, > SCSI2 0/direct fixed
sd1: 1882MB, 512 bytes/sector, 3854336 sectors
rtsx0: executing cmd 17
rtsx0: soft reset
rtsx0: executing cmd 18
rtsx0: read xfer: 2048 bytes with block size 512
rtsx0: soft reset
rtsx0: xfer done, error=60
rtsx0: executing cmd 18
rtsx0: soft reset

Reply via email to