MEMSTICK: Add driver for Ricoh R5C592 Card reader.
in [Kernel]
|
Prev: MEMSTICK: fix hangs on unexpected device removal in mspro_blk
Next: media: Add a cached version of the contiguous video buffers
From: Alex Dubov on 7 Aug 2010 09:20 > > > > > > > > > > > > > > That's how its called in the > spec. > > > > > > > Sectors can be larger than > 512b on > > > Pro-HG sticks, and > > > > > > there's additional > > > > > > > TPC_READ/WRITE_QUAD_DATA > which operates > > > on larger > > > > > > quantities. > > > > > > But not on ordinary PRO, right? > > > > > > > > > > Pro sectors are normally 512 bytes. > > > > > > > > > > > > > > > > > Small question, can I use Pro-HG > stick in my > > > reader that is > > > > > > designed for > > > > > > Standard/PRO only? Does your > subsystem > > > support it? > > > > > > > > > > It should work. It works for me on TI, > which has > > > no 8b mode either. > > > > In that case, is there an upper limit on > sector size? > > > Also, you don't use the MS_TPC_READ_QUAD_DATA at > all. > > > So mspro_blk.c won't work with >512 > bytes/sector disk? > > > Or there is some compatibility? > > > > > > > The code can work with arbitrarily sized pages, 512b > > value is not hard coded. All that is needed is to > slightly alter > > h_mspro_block_transfer_data function, given, of > course, that adapters > > support longer transfer > > No, I mean if I go and buy memstick PRO HG, that has > > 512 bytes/sector, > will it work with current code? > > Btw, there is currently no way of telling core about > maximum transfer > length. > Here absolute maximum is 1024 (number of bit that _might_ > hold TPC > length), and FIFO size is 512 bytes (maybe its possible to > use fifo > twice) > On TI adapters, FIFO can be reused and DMA restarted. Jmicron adapters are funny beasts, but their team is keen to support MSpro-HG, so at some point it will be fully possible, though, probably, not with every version of the chipset. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 7 Aug 2010 12:00 On Sat, 2010-08-07 at 06:15 -0700, Alex Dubov wrote: > > > > > > > > > > > > > > > > That's how its called in the > > spec. > > > > > > > > Sectors can be larger than > > 512b on > > > > Pro-HG sticks, and > > > > > > > there's additional > > > > > > > > TPC_READ/WRITE_QUAD_DATA > > which operates > > > > on larger > > > > > > > quantities. > > > > > > > But not on ordinary PRO, right? > > > > > > > > > > > > Pro sectors are normally 512 bytes. > > > > > > > > > > > > > > > > > > > > Small question, can I use Pro-HG > > stick in my > > > > reader that is > > > > > > > designed for > > > > > > > Standard/PRO only? Does your > > subsystem > > > > support it? > > > > > > > > > > > > It should work. It works for me on TI, > > which has > > > > no 8b mode either. > > > > > In that case, is there an upper limit on > > sector size? > > > > Also, you don't use the MS_TPC_READ_QUAD_DATA at > > all. > > > > So mspro_blk.c won't work with >512 > > bytes/sector disk? > > > > Or there is some compatibility? > > > > > > > > > > The code can work with arbitrarily sized pages, 512b > > > value is not hard coded. All that is needed is to > > slightly alter > > > h_mspro_block_transfer_data function, given, of > > course, that adapters > > > support longer transfer > > > > No, I mean if I go and buy memstick PRO HG, that has > > > 512 bytes/sector, > > will it work with current code? > > > > Btw, there is currently no way of telling core about > > maximum transfer > > length. > > Here absolute maximum is 1024 (number of bit that _might_ > > hold TPC > > length), and FIFO size is 512 bytes (maybe its possible to > > use fifo > > twice) > > > > On TI adapters, FIFO can be reused and DMA restarted. Jmicron adapters are > funny beasts, but their team is keen to support MSpro-HG, so at some > point it will be fully possible, though, probably, not with every version > of the chipset. > I still need an answer for whether HG sticks need MS_TPC_READ_QUAD_DATA to be used. But anyway, I buy a HG stick and see how it works. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 7 Aug 2010 12:10 On Sat, 2010-08-07 at 06:12 -0700, Alex Dubov wrote: > > > > > > > > Btw, I want to add a callback from driver to card > > driver to > > > > be able to > > > > reset card in case of error (windows driver does > > that in > > > > case of any > > > > error) > > > > > > > > I would use most of the mspro_block_resume for > > the > > > > implementation for > > > > mspro. > > > > > > > > Any objections, suggestions? > > > > > > > > > > Just toggle a power on it. Power off/power on will do > > the full reset of > > > the controller and the media. You don't have to > > reinitialize it, as you > > > are sure that it's the same stick. > > > > Yea, but after such reboot, the device will be in serial > > mode. So, I > > will need to send switch TPC to device. My driver doesn't > > know how to do > > that...., so it would be nice to have callback to the > > core. > > > > Lets ask a different question: why do you think this > particular functionality is needed at all? Have you encountered any > problems which require it (I haven't, btw)? I would image using this to verify that stick is still in place on I/O error. If I just power down/up it, it will loose state, for example IO mode, reg range, etc... But anyway, this isn't very important. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Maxim Levitsky on 7 Aug 2010 16:30 Hi, I have few more questions about memsticks. First of all, I need an explanation of overwrite flag. You already explained it to me once, but I still not sure about few things. #define MEMSTICK_OVERWRITE_UDST 0x10 This one I understand, thinking about xD again, I think it is very handy. My idea (from xD of course) is that copyonwrite is done this way: 1. read old sector 2. allocate new sector 2. write what was just read to new sector. 3. erase old sector. Could you explain when I need to set and reset the MEMSTICK_OVERWRITE_UDST? #define MEMSTICK_OVERWRITE_PGST1 0x20 #define MEMSTICK_OVERWRITE_PGST0 0x40 I suppose these indicate that page(sector) contains incorrect data, just like in xD there is page status? Again, better explanation is welcome. Also, should I touch that flag when I update sector? #define MEMSTICK_OVERWRITE_BKST 0x80 This marks bad blocks? Another question is about write of oob data. When I write it, overwrite flag is updated, or I need to use MEMSTICK_CP_OVERWRITE to update it? I think former is true. When I write a sector, I just write 0 to management flag, right? And last question, If I use MEMSTICK_CP_BLOCK, can I start reading a block from non-zero page offset? And surely last question, what is 'MS_CMD_BLOCK_END' Thanks again for all help so far, Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alex Dubov on 8 Aug 2010 09:40
--- On Sat, 7/8/10, Maxim Levitsky <maximlevitsky(a)gmail.com> wrote: > From: Maxim Levitsky <maximlevitsky(a)gmail.com> > Subject: Re: [PATCH 2/2] MEMSTICK: Add driver for Ricoh R5C592 Card reader. > To: "Alex Dubov" <oakad(a)yahoo.com> > Cc: "LKML" <linux-kernel(a)vger.kernel.org> > Received: Saturday, 7 August, 2010, 8:58 AM > On Sat, 2010-08-07 at 06:15 -0700, > Alex Dubov wrote: > > > > > > > > > > > > > > > > > > That's how its > called in the > > > spec. > > > > > > > > > Sectors can be > larger than > > > 512b on > > > > > Pro-HG sticks, and > > > > > > > > there's additional > > > > > > > > > > TPC_READ/WRITE_QUAD_DATA > > > which operates > > > > > on larger > > > > > > > > quantities. > > > > > > > > But not on ordinary PRO, > right? > > > > > > > > > > > > > > Pro sectors are normally 512 > bytes. > > > > > > > > > > > > > > > > > > > > > > > Small question, can I > use Pro-HG > > > stick in my > > > > > reader that is > > > > > > > > designed for > > > > > > > > Standard/PRO only? Does > your > > > subsystem > > > > > support it? > > > > > > > > > > > > > > It should work. It works for > me on TI, > > > which has > > > > > no 8b mode either. > > > > > > In that case, is there an upper > limit on > > > sector size? > > > > > Also, you don't use the > MS_TPC_READ_QUAD_DATA at > > > all. > > > > > So mspro_blk.c won't work with >512 > > > bytes/sector disk? > > > > > Or there is some compatibility? > > > > > > > > > > > > > The code can work with arbitrarily sized > pages, 512b > > > > value is not hard coded. All that is needed > is to > > > slightly alter > > > > h_mspro_block_transfer_data function, given, > of > > > course, that adapters > > > > support longer transfer > > > > > > No, I mean if I go and buy memstick PRO HG, that > has > > > > 512 bytes/sector, > > > will it work with current code? > > > > > > Btw, there is currently no way of telling core > about > > > maximum transfer > > > length. > > > Here absolute maximum is 1024 (number of bit that > _might_ > > > hold TPC > > > length), and FIFO size is 512 bytes (maybe its > possible to > > > use fifo > > > twice) > > > > > > > On TI adapters, FIFO can be reused and DMA restarted. > Jmicron adapters are > > funny beasts, but their team is keen to support > MSpro-HG, so at some > > point it will be fully possible, though, probably, not > with every version > > of the chipset. > > > > I still need an answer for whether HG sticks need > MS_TPC_READ_QUAD_DATA > to be used. No, they work fine with LONG_DATA, at least the ones I tried. > > But anyway, I buy a HG stick and see how it works. This is always a right thing to do. > > Best regards, > Maxim Levitsky > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |