Hi Pierre, Thanks for explaining.
I guess then I have a crappy SDIO card that needs the "voodoo" bit set for correct operation. There are other registers close to the START ADDRESS so it is a FIFO, but the Incrementing Address flag is needed to read from and write to the FIFO correctly. Regards, Dean. On Wed, 2007-11-21 at 14:08 +0100, Pierre Ossman wrote: > On Wed, 21 Nov 2007 11:57:01 +0000 > Dean Jenkins <[EMAIL PROTECTED]> wrote: > > > Hi Pierre, > > > > I've looked at the SD Card Association's SDIO Part E1 V2.00 > > specification concerning the Incrementing Address OP Code field for > > CMD53. > > > > The specification indicates that the START ADDRESS is inserted into the > > Register Address register field. When the OP Code field has a value of 1 > > then the during the transfer the IO address is internally incremented > > for each byte transferred. This applies to a single CMD53 command. > > > > Looking at the implementation of sdio_io_rw_ext_helper() in sdio_io.c. > > This function can send multiple CMD53 commands. My concern is that with > > incrementing address mode selected the START ADDRESS is erroneously > > changed for subsequent CMD53 commands in the while loop. > > > > Since the caller is not supposed to care about the internal operation of > sdio_io_rw_ext_helper(), the address increase is a must to maintain a > consistent behaviour regardless of what transactions it decides to use. > > I.e. if I write 2048 bytes with start address 0x1000, I expect it to do a > single write to register 0x1000 through 0x17FF, not and unknown number of > writes to some unknown interval. > > Now what I suspect you're championing is to support some broken card that > treats the address increase bit in CMD53 as "Magic voodoo bit #5" instead of > the definition in the SDIO spec. I.e. the only address it cares about is the > start address and hence needs it to be the same for each transaction. This > kind of blatant disregard for the SDIO register design is of course not what > sdio_io_rw_ext_helper() was designed for, and probably never will be. > > > What I am trying to say is I don't believe the START ADDRESS should be > > changed by the core driver when incrementing address mode is used. I > > think incrementing address mode only applies internally to a single > > CMD53 command. The SDIO card must physically have a suitable register > > present at the START ADDRESS so changing this address to something > > dependent on the data size is going to fail I think. > > > > The SDIO card must physically have a suitable register present at the entire > relevant range, not just the start address. If it doesn't then it isn't > following the register interface design of SDIO (having the "increase > address" bit would just be silly if the arguments were arbitrary tokens and > not part of a consistent address space). > > > Do you have any evidence that any card drivers will use > > sdio_io_rw_ext_helper() in a manner that needs the START ADDRESS to be > > changed by the core driver ? > > > > There are no drivers using "increase address" yet. The ones so far have all > used a single byte FIFO port. > > Rgds -- Dean Jenkins Embedded Software Engineer MontaVista Software (UK) Professional Services Division - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
