[PATCH 0/6] Results of my work on memorystick subsystem

[Maxim Levitsky]

Hi,

Here is a result of lot of work I did improving the memorystick
subsystem and its drivers.

patch #1 add common code to memorystick core that makes card drivers easier
to understand

patch #2 just add a driver for my card reader

patch #3 reworks the Jmicron driver.
I can write a novel about the problems I had to go through with this device
(mostly hardware bugs I belive).
So I refactored the driver and added a lot of debug output future users.
Currently both MS and MSPro work fine.

patch #4 adds support for lagacy memorysticks.
Everything just works, not a single corruption this far.

patch #5, is what I did recently.
I rewrote large chunks on mspro_blk.c to use the common code I added in patch #1.
I also added lot of debug code, comments.

patch #6 adds more cleanups.

Now register window changes are completely hidden and automatic.
Functions that state machines call are explictly marked as so,
and that assumption is tested.
the card->current_mrq isn't passed as a pointer to functions
as this just complicates the code.

Code is tested with 2 mspro cards and one MS card.

Thanks again to Alex for his work.

***Changes from V1 ***

* Fixed brown paper bug in memstick core.
memset had its 2 and 3 arguments swapped.

* Cleaned a lot the PIO code in my r592 driver.
Now it finally looks sane.
Also tested it throughfully.

* Endiannes fixes in Jmicron driver and r592

Best regards,
	Maxim Levitsky

***Appendix***

Jmicron hardware bugs (the novel):

#1: FIFO write ready bit in INT status register is stuck to 1.
   It is stuck forever as soon as fifo
   is used for writing even once.
   Therefore if interrupt is shared (and here it is), its easy
   to 'service' the device while it doesn't need any service


#2: Its not possible to stuff the FIFO before TPC transfer.
   One really have to wait for write ready interrupt, even though the write ready status is stuck.


#3: TPCs with non 4 aligned length woes:
   Facts:

   * non 4 aligned DMA write hangs the system hard, maybe on bus level.

   * PIO read succedes but controller truncates the data stored in the FIFO to closest 4 byte boundary.
   That is if you read 26 bytes, it will save 24 bytes in the FIFO

   * PIO non-aligned write work, expect that they sometimes hose the DMA.... (regardless of the alignment)

   * TPC_P0, TPC_P1 not aligned transfters work just fine despite a statement in the datasheet
   that they are undefined.... (only mention of this problem)


#4: As soon as write PIO is used, then later write DMA fails.
   Facts:

   * This is triggered only by PIO write of registers
   (only happens in ms_block.c when it writes param + oob. Thats why mspro_blk isn't affected)
   Doing short DMA writes is a nice workaround.

   * Doing PIO writes in h_msb_read_page don't cause the problem.
     Therefore the bug causing sequence should be similiar to h_msb_write_block:

       1. PIO write of param + extra (10 bytes) or even padded to 12 or 16 bytes
       2. inline write (TPC_P0) of MS_CMD_BLOCK_WRITE + wait for int
       3. read of INT register via STATUS
       3. DMA write of MS_TPC_WRITE_LONG_DATA
       4. DMA write of MS_TPC_WRITE_LONG_DATA
           ---------timeout-----------
 
   * In fact first DMA write succedes, but next one fails, and so do all following writes

   * The problem persits till reboot, and shows up even if PIO isn't used again.
   Other way to "fix" it, is to put device in D3 and back to D0

   * Serial/parallel mode don't affect anything.

   After bug reproduction:

    * DMA writes stop working completely, therefore mspro_blk looses writes as well

    * PIO still works just fine. Its possible just to load the driver without dma support, and it works correctly.

    * DMA reads work just fine.

#5: Auto_Get_INT feature just doesn't work.
   Datasheet says that intreg is placed to TPC_P0, but that doesn't happen....
   card status register is 0.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/