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? > 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. Arnd -- 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
