Re: [PATCH] My work on MemoryStick system

[Alex Dubov <oakad@yahoo.com>]

> > > 
> > > I just tested this series with Jmicron, and
> unfortunelly
> > > there are bugs.
> > > 
> > > * driver refuses to handle 26 byte TPC I use to
> read regs
> > > (sizeof(ms_registers). If I bump it to 32, it
> works.
> > 
> > It will work with any multiply of 4 (24 and 28 work as
> well). It's a known
> > "feature".
> Then I bump the size of ms_registers to 32 and leave this
> as is.
> OK?

I'd rather minimize the transfer size, than increase it.


> And I add a warning about this feature of some hardwares
> someplace.
> 
> 
> But what about MS_TPC_GET_INT. This asks for single byte.
> Hardware has to support it.

They've got a custom register for its value. GET_INT is implemented by
different hardware than READ/WRITE_REG

> 
> 
> 
> > 
> > > 
> > > * With this fix first few reads still fail.
> > > That means that card isn't detected always
> because boot
> > > blocks might not
> > > be read.
> > > Later card works fine.
> > > 
> > > * Also I found out that msproblk.c allocates
> memory for
> > > attributes IO
> > > using stock kmalloc, and hangs that to driver.
> > > However if driver doesn't support such address,
> it will
> > > fail.
> > 
> > Why would hardware do anything at all with attribute
> memory space?
> Read it?
> 
> You allocate the memory with kmalloc, create a sg with
> sg_init_one and
> pass that to driver.
> So therefore it can be from arbitrary address.

Yes, indeed.

> 
> I found further problems in jmicron driver:
> 
> 
> 1. Serial mode doesn't work well.
> I first read the boot block, and then enable parallel
> mode.
> I do so because boot block has a flag that tells if
> parallel mode is
> supported.
> It turns out that sector reads often don't finish,
> especially first and
> often second one which contain boot blocks.
> If I enable parallel mode right away problem goes away.

They have really weird dependency between clock setup and operation mode.
Try to use the clock setup values from the errata I've sent you.
The order of register initialization and reset timing seems to affect
the operation as well.

To summarize my opinion about it: if I had to design a card reader, I
won't even look at anything, but TI chips. :-)


> 
> 
> 2. the MS_TPC_WRITE_LONG_DATA fail, therefore I can't write
> anything to
> the stick.
> 
> As soon as my driver starts to write a block,  first
> MS_TPC_WRITE_LONG_DATA succeeds, but second one timeouts.
> (there is no MS_TPC_GET_INT in between, because of parallel
> mode).
> 
> Maybe I do something wrong in my ms_block.c, but I checked
> it many
> times, and it appears to be correct, and it works fine with
> r592.c
> 
> 
> Best regards,
> Maxim Levitsky
> 
> 
> 
>