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 8 Aug 2010 10: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. Overwrite register can be accessed either as part of extra data access or separately (CP_OVERWRITE access mode). > > #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. This is correct. > > Could you explain when I need to set and reset the > MEMSTICK_OVERWRITE_UDST? UDST flag should be set when you're marking the block for reallocation during the read/modify/write cycle. You read the existing physical block, mark it with UDST flag (setting it to zero), then write different physical block on behalf of the same logical one, then erase the original block. The UDST flag is supposed to guard against a situation, whereupon power fails during the write cycle and you're left with two physical blocks mapped to the same logical one (so the one marked with zero UDST value is supposedly "known good"). > > > #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? BKST set to zero indicates that the whole block is bad and shouldn't be used. PGST1:0 has several values: 11: default, r/w page 10: reserved value, shouldn't be used 01: page is read-only (soft write-protect) 00: page is accessible, but the value is not guaranteed (faulty page that sort-of works) That's what the spec says. > > > > 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. As I mentioned above, it can be accessed either as part of extra data or separately. > > When I write a sector, I just write 0 to management flag, > right? You shouldn't touch management_flag at all, as far as I can tell. It's only used to indicate special purpose blocks, such as factory written boot blocks, volatile look-up table blocks (for systems with tight RAM requirements) and DRM marked blocks which I has no info about. > > > And last question, > If I use MEMSTICK_CP_BLOCK, can I start reading a block > from non-zero > page offset? Yes, it starts from the user specified page address and auto increments it until the current block end is hit. > > > And surely last question, what is 'MS_CMD_BLOCK_END' This command is used to terminate the currently ongoing block operation. If you are using one of the auto-increment modes (with CP_BLOCK set) but do not want to access all the pages until the block end, you must issue this command after the desired number of pages is transferred to return the media's state machine to the initial state. This command never hurts, as you can guess. > > > Thanks again for all help so far, > You're welcome. -- 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 8 Aug 2010 11:10 On Sun, 2010-08-08 at 07:26 -0700, Alex Dubov wrote: > > 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. > > Overwrite register can be accessed either as part of extra data access > or separately (CP_OVERWRITE access mode). > > > > > #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. > > This is correct. > > > > > Could you explain when I need to set and reset the > > MEMSTICK_OVERWRITE_UDST? > > UDST flag should be set when you're marking the block for > reallocation during the read/modify/write cycle. You read the existing > physical block, mark it with UDST flag (setting it to zero), then write > different physical block on behalf of the same logical one, then erase the > original block. The UDST flag is supposed to guard against a situation, > whereupon power fails during the write cycle and you're left with two > physical blocks mapped to the same logical one (so the one marked with > zero UDST value is supposedly "known good"). > > > > > > > > #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? > > BKST set to zero indicates that the whole block is bad and shouldn't be > used. > > PGST1:0 has several values: > 11: default, r/w page > 10: reserved value, shouldn't be used > 01: page is read-only (soft write-protect) > 00: page is accessible, but the value is not guaranteed (faulty page that > sort-of works) > > That's what the spec says. Thank you very much. > > > > > > > > > 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. > > As I mentioned above, it can be accessed either as part of extra data > or separately. > > > > > When I write a sector, I just write 0 to management flag, > > right? > > You shouldn't touch management_flag at all, as far as I can tell. > It's only used to indicate special purpose blocks, such as factory > written boot blocks, volatile look-up table blocks (for systems with > tight RAM requirements) and DRM marked blocks which I has no info about. > > > > > > > And last question, > > If I use MEMSTICK_CP_BLOCK, can I start reading a block > > from non-zero > > page offset? > > Yes, it starts from the user specified page address and auto increments it > until the current block end is hit. > > > > > > > And surely last question, what is 'MS_CMD_BLOCK_END' > > This command is used to terminate the currently ongoing block operation. > If you are using one of the auto-increment modes (with CP_BLOCK set) but > do not want to access all the pages until the block end, you must issue > this command after the desired number of pages is transferred to return > the media's state machine to the initial state. This command never hurts, > as you can guess. That what I expected, thanks! > > > > > > > Thanks again for all help so far, > > > > You're welcome. Thank you very much! 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 8 Aug 2010 16:10 On Sun, 2010-08-08 at 18:07 +0300, Maxim Levitsky wrote: > On Sun, 2010-08-08 at 07:26 -0700, Alex Dubov wrote: > > > 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. > > > > Overwrite register can be accessed either as part of extra data access > > or separately (CP_OVERWRITE access mode). > > Few more questions I gathered today. I currently assume that if I set req->need_card_int, the driver will wait till device raises MEMSTICK_INT_CED regardless of serial/parallel mode. This bit is always available on serial line. Is that OK to assume? Another thing that I want to ask is about writes to overwrite/managment flag. Common sense tells me that I can write the flash many times, but write can only clear bits. Therefore if I write 0xFF, this just means do nothing. Probably same applies to data content, but that isn't much of the use. Thats why I see that default (good) value of bits in overwrite flag is 1. This is correct I assume? Another interesting thing I observed was that MEMSTICK_INT_ERR can mean a correctable error, therefore it shouldn't alone reject read/write of a sector. (I think that it means that one of MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set) Same question about this. 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 9 Aug 2010 02:40 > > I currently assume that if I set req->need_card_int, the > driver will > wait till device raises MEMSTICK_INT_CED regardless of > serial/parallel > mode. This bit is always available on serial line. > Is that OK to assume? I'm not quite sure about this question. Normally, when you wait for the media interrupt, you want to see the whole value of the INT register (CED by itself doesn't indicate successful command completion; in fact it's value is undefined in presence of other INT flags, like BREQ or CMDNK). In parallel mode, host is required to fetch all meaningful INT bits from the media bus, while in serial mode this is only possible, if host supports automatic INT retrieval (the host will issue GET_INT tpc behind the scenes before alerting the software). > > Another thing that I want to ask is about writes to > overwrite/managment > flag. > Common sense tells me that I can write the flash many > times, but write > can only clear bits. Therefore if I write 0xFF, this just > means do > nothing. > Probably same applies to data content, but that isn't much > of the use. Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever. > Thats why I see that default (good) value of bits in > overwrite flag is > 1. > This is correct I assume? Yes, a direct consequence of the above. > > > Another interesting thing I observed was that > MEMSTICK_INT_ERR can mean > a correctable error,� therefore it shouldn't > alone� reject read/write of > a sector. (I think that it means that one of > MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set) > Same question about this. > There are three groups of error flags. While overwrite_flag register is accessible as part of extra data, being the indicator of block goodness it earned its own error flag: DTER (UCDT) - error (uncorrectable) in data area EXER (UCEX) - error (uncorrectable) in extra data area FGER (UCFG) - error (uncorrectable) in overwrite_flag register Uncorrectable error means that you've got some bit errors in the data you've obtained from the media. If uncorrectable flag is not set, it means that media's ECC circuit managed to correct the bit flip. The desired way of action is, of course, to reallocate the block before it develops an uncorrectable failure. -- 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 9 Aug 2010 03:00
On Sun, 2010-08-08 at 23:31 -0700, Alex Dubov wrote: > > > > I currently assume that if I set req->need_card_int, the > > driver will > > wait till device raises MEMSTICK_INT_CED regardless of > > serial/parallel > > mode. This bit is always available on serial line. > > Is that OK to assume? > > I'm not quite sure about this question. > Normally, when you wait for the media interrupt, you want to see the whole > value of the INT register (CED by itself doesn't indicate successful > command completion; in fact it's value is undefined in presence of other > INT flags, like BREQ or CMDNK). In parallel mode, host is required to > fetch all meaningful INT bits from the media bus, while in serial mode > this is only possible, if host supports automatic INT retrieval (the host > will issue GET_INT tpc behind the scenes before alerting the software). Ok, maybe I didn't explain myself correctly. Device is in serial mode. I set need_card_int I send a command. <here I assume that driver waits for CED bit, which is exposed on data line, if CED won't be set, driver/hardware will timeout> I send GET_INT _once_, look at flags. If I see CED, no NACK, then ok, otherwise I send error result. > > > > > Another thing that I want to ask is about writes to > > overwrite/managment > > flag. > > Common sense tells me that I can write the flash many > > times, but write > > can only clear bits. Therefore if I write 0xFF, this just > > means do > > nothing. > > Probably same applies to data content, but that isn't much > > of the use. > > Yes, all memsticks are NAND flash, so writing 1s has no effect whatsoever. > > > Thats why I see that default (good) value of bits in > > overwrite flag is > > 1. > > This is correct I assume? > > Yes, a direct consequence of the above. I suspect that managment flag also has default value of 0xFF, and these 'special' features (drm, boot block, temporary table) clear bits out of it. > > > > > > > Another interesting thing I observed was that > > MEMSTICK_INT_ERR can mean > > a correctable error, therefore it shouldn't > > alone reject read/write of > > a sector. (I think that it means that one of > > MEMSTICK_STATUS1_UCFG..MEMSTICK_STATUS1_DTER is set) > > Same question about this. > > > > There are three groups of error flags. While overwrite_flag register is > accessible as part of extra data, being the indicator of block goodness > it earned its own error flag: > > DTER (UCDT) - error (uncorrectable) in data area > EXER (UCEX) - error (uncorrectable) in extra data area > FGER (UCFG) - error (uncorrectable) in overwrite_flag register > > Uncorrectable error means that you've got some bit errors in the data > you've obtained from the media. If uncorrectable flag is not set, it > means that media's ECC circuit managed to correct the bit flip. The > desired way of action is, of course, to reallocate the block before it > develops an uncorrectable failure. That I understand clearly. I ask what the meaning of MEMSTICK_INT_ERR is. I expect it to be set if any of (un) correctable errors are found. Therefore if MEMSTICK_INT_ERR, I can't report error instantly, but I need to look at status1 to see if error is correctable or not. This is correct? 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/ |