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: Maxim Levitsky on 10 Aug 2010 06:00 On Tue, 2010-08-10 at 00:53 -0700, Alex Dubov wrote: > > About INT bits, I still don't > > understand them exactly. > > > > First of all we have 4 meaningful bits. > > In parallel mode these are exposed on data lines, in serial > > mode only > > MEMSTICK_INT_CED is. > > And I can always send MS_TPC_GET_INT or just read the > > registers. > > > > #define MEMSTICK_INT_CMDNAK 0x01 > > This bit means command was not acknowledged by the media (media not ready). > > > #define MEMSTICK_INT_BREQ 0x20 > > This bit means media is ready for long data transfer (either in or out). > > > #define MEMSTICK_INT_ERR 0x40 > > This bit means that some error had occurred during command execution. > > > #define MEMSTICK_INT_CED 0x80 > > This bit marks a completion of the command, but it may switch value in > between, so it is not that reliable by itself. > > > > > > > Now, I send a command to device, say MS_CMD_BLOCK_READ. > > What bits I need to poll until I can be sure that command > > is completed? > > All of them. > > > > > Also the MEMSTICK_INT_BREQ tells that input is available in > > firmware > > buffer (to read using TPC_READ_LONG_DATA)? > > > > Not exactly. BREQ signal indicated that media's state machine is in the > mode to pump data in or out. You wait for it, than you do the data > transfer (it works the same with READ and WRITE). > > > > > > > Is that true that MEMSTICK_INT_BREQ is a summary of fifo > > full/empty bits > > in status0? > > This can not be relied upon. Sony states, that only BREQ bit must be used > in block transfer operations. BE/BF bits are probably of more use in > memstick IO cards (there exists such a beast). Even better. > > > > > And same about MEMSTICK_INT_ERR and status1. > > status1 errors apply only to data errors (bit flips). > There are errors in command execution that do not result in bit flips, > rather data can not be delivered at all or command/parameters are invalid. Understood. However if I get MEMSTICK_INT_ERR, I should also look at status1, because there might be correctable error. 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: Alex Dubov on 11 Aug 2010 04:10 > I know everything you have just said. > I just want to point out that code in many places assumes > that register > window is the same as set on device initialization. It's not. Can you please point at a particular place? > > But, if you're using the auto incrementing write, you > will have to write > > extra register for every page transferred. > But what if I fill extra register with 0xFF? > And besides on reads, the fact that I *write* the extra > register before > I execute read command shouldn't matter at all regardless > of what I > write there. > On writes however I *do* need to write extra register > anyway with proper > values. > > Therefore I see no reason why I can't set write window to > cover both > param and extra register, and leave it always like that. Because when you do autoincrementing write you _can not_ write into param register. You will break the command execution. On the other thought, it may be unnecessary to write unique extra data to every page, so one full register write at the beginning of the command may do. Considering, that legacy memstick is not going to evolve, this may be reasonable assumption. -- 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 11 Aug 2010 04:20 > result in bit flips, > > rather data can not be delivered at all or > command/parameters are invalid. > Understood. > However if I get MEMSTICK_INT_ERR, I should also look at > status1, > because there might be correctable error. > > I don't remember the details, but it may be, that status1 errors do not raise INT_ERR (or do not always raise?). The idea is, first you check INT_ERR. If command completed successfully and you received the data, you may still need to check status1 for possible bit flips. Some experimentation may be required, especially for the case of correctable errors. After all, they should not prevent the command from successful completion, yet action should be taken on them (at the very least - log warning, just like with normal disks). -- 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 11 Aug 2010 04:40 On Wed, 2010-08-11 at 01:08 -0700, Alex Dubov wrote: > > I know everything you have just said. > > I just want to point out that code in many places assumes > > that register > > window is the same as set on device initialization. > > It's not. > Can you please point at a particular place? > > > > But, if you're using the auto incrementing write, you > > will have to write > > > extra register for every page transferred. > > But what if I fill extra register with 0xFF? > > And besides on reads, the fact that I *write* the extra > > register before > > I execute read command shouldn't matter at all regardless > > of what I > > write there. > > On writes however I *do* need to write extra register > > anyway with proper > > values. > > > > Therefore I see no reason why I can't set write window to > > cover both > > param and extra register, and leave it always like that. > > Because when you do autoincrementing write you _can not_ write into param register. You will break the command execution. Thanks, I finally understand you, so you are objection to write of _param_ register, not the _extra_. I agree with you. > > On the other thought, it may be unnecessary to write unique extra data to every page, so one full register write at the beginning of the command may do. Considering, that legacy memstick is not going to evolve, this may be reasonable assumption. Indeed that what I do now. Maximum I might need to clear page status bits, but I can do that later after I write the block. This won't be any performance impact because amount of bad pages shouldn't be normally greater that zero. (Otherwise there will be data loss...) One interesting thing that I just want your opinion on is what to do with correctable errors. Common sense suggests to relocate the sector + and mark it bad. But I don't know how common such sectors are, and thus I could do more harm that good by marking too many sectors as bad. Of course all such problems are reason why today flash devices contain the FTL inside, and can improve/define it in the way they want. No more questions for now, thank you very much for help. I hope I create ms_block.c soon, and put that old problem to the rest. As time permits I will also port your driver for xD portion of jMicron device (which I have). 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 12 Aug 2010 03:30
> Maximum I might need to clear page status bits, but I can > do that later > after I write the block. > This won't be any performance impact because amount of bad > pages > shouldn't be normally greater that zero. > (Otherwise there will be data loss...) These things do degrade. I think, memsticks do write-verify, so bad blocks will appear during write and can be marked as such without any data loss. > > One interesting thing that I just want your opinion on is > what to do > with correctable errors. > Common sense suggests to relocate the sector + and mark it > bad. > But I don't know how common such sectors are, and thus I > could do more > harm that good by marking too many sectors as bad. I agree that number of writes to the media should be kept minimal. So bad (in either way) blocks encountered should be logged, but not touched, unless the error appears during an actual write/modify operation. > > I hope I create ms_block.c soon, and put that old problem > to the rest. If you have time and desire, try to put a low level format option in - some function to erase all blocks, except the system ones. > > As time permits I will also port your driver for xD portion > of jMicron > device (which I have). By the way, I've got some errata for the newer JMicron chipsets. If they have not contacted you yet, I'll forward it to you. -- 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/ |