Hi Arnd, thanks for the reply. On Tue, Nov 22, 2011 at 9:34 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Friday 18 November 2011, Shashidhar Hiremath wrote: >> Hi Arnd, >> Please forgive me for a lengthy mail. >> >> firstly, the Patch has not added testcases in kernel, but has added >> support infrastructure for handling different commands. Function >> names are misnomers and “.test_CMD0” should have instead been >> “send_CMD0”. >> >> I have tried to express my views in 2 questions: >> >> Q1 : What all Commands can be sent using MMC block layer IOCTL ? >> >> Currently it be used for sending only read/write commands. >> Should it also not support non-data (read/write) commands ? >> If Yes, then the “block.c” must be modified with few changes to >> handle non-data commands by making the read/write code conditional. >> >> Ex: Code snippet below has to be made conditional i.e. execute only >> for read/write commands >> >> data.sg = &sg; >> data.sg_len = 1; >> data.blksz = idata->ic.blksz; >> data.blocks = idata->ic.blocks; >> >> sg_init_one(data.sg, idata->buf, idata->buf_bytes); >> >> if (idata->ic.write_flag) >> data.flags = MMC_DATA_WRITE; >> else >> data.flags = MMC_DATA_READ; > > This is all fine, I don't object at all to changing the code so it > supports non-data commands. It should be easy enough to make the above > code get executed only if idata->buf_bytes is positive. > >> Q2 : Can I send CMD 9 (or any non-data command) via the mmc blk layer >> IOCTL ? If not what are the issues ? >> >> As of now non-data commands are not supported. So in order to send CMD >> 9, the card has to be brought to a certain known state by sending the >> pre CMD 9 sequence. > > The command interface we have is for very low-level commands, and the > kernel should not try to intercept these. > >> As per the Specification, before sending CMD 9, the following commands >> have to be sent >> Pre-CMD 9 Sequence >> CMD0 : Reset >> CMD8 : Get ocr >> CMD55 : App command >> CMD41 : >> CMD2 : >> CMD3 : >> >> ... >> >> From user space, in order to send CMD9, the above code snippet should >> be available as a single stand alone function. As of now the mmc core >> state machine has a single flow which is card enumeration. But if we >> want to send stand alone commands from user space, the enumeration >> flow has to be broken into single standalone functions specific to the >> commands that is they have to send the pre command sequence and get >> the card to the proper state to send the user specified command. > > I think it is reasonable to require user space to know that it needs to > send all the other commands before it can send CMD9. However, if you > need the mmc_block driver to perform any other operations besides > sending commands to the card, you can add new ioctl commands for > this, e.g. you can have one ioctl to tell the block driver to > get out of the way and not accept any requests from the block layer > while you are sending low-level commands, and another ioctl to > tell the block layer to rescan the card in order to get it into > a known working state again after you are done with the tests. Would > that work for you? Yes, extra ioctl's can help me bringing the card to defined state. I will try implementing with this approach. > >> The command sent should also work in following scenarios:- >> CASE 1 : Card enumerated, and ready for transfer >> CASE 2 : Card is reset >> CASE 3 : CMD 9 has been sent, now can I send CMD 8 > > Why is that a requirement? I would argue that the user application > already does things that are outside of the scope of normal > operation, so it should know what it is doing and cannot expect > the kernel to perform extra magic behind its back. I Agree, Kernel need not worry about these scenarios.. > > Arnd > -- regards, Shashidhar Hiremath -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
