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;
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.
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 :
The implementation for the above can be seen mmc.c file snippet shown below
CODE SNIPPET : linux/driver/core/mmc.c
/*
* Since we're changing the OCR value, we seem to
* need to tell some cards to go back to the idle
* state. We wait 1ms to give cards time to
* respond.
* mmc_go_idle is needed for eMMC that are asleep
*/
mmc_go_idle(host);
/* The extra bit indicates that we support high capacity */
err = mmc_send_op_cond(host, ocr | (1 << 30), &rocr);
if (err)
goto err;
/*
* For SPI, enable CRC as appropriate.
*/
if (mmc_host_is_spi(host)) {
err = mmc_spi_set_crc(host, use_spi_crc);
if (err)
goto err;
}
/*
* Fetch CID from card.
*/
if (mmc_host_is_spi(host))
err = mmc_send_cid(host, cid);
else
err = mmc_all_send_cid(host, cid);
if (err)
goto err;
if (oldcard) {
if (memcmp(cid, oldcard->raw_cid, sizeof(cid)) != 0) {
err = -ENOENT;
goto err;
}
card = oldcard;
} else {
/*
* Allocate card structure.
*/
card = mmc_alloc_card(host, &mmc_type);
if (IS_ERR(card)) {
err = PTR_ERR(card);
goto err;
}
card->type = MMC_TYPE_MMC;
card->rca = 1;
memcpy(card->raw_cid, cid, sizeof(card->raw_cid));
}
/*
* For native busses: set card RCA and quit open drain mode.
*/
if (!mmc_host_is_spi(host)) {
err = mmc_set_relative_addr(card);
if (err)
goto free_card;
mmc_set_bus_mode(host, MMC_BUSMODE_PUSHPULL);
}
if (!oldcard) {
/*
* Fetch CSD from card.
*/
err = mmc_send_csd(card, card->raw_csd);
if (err)
goto free_card;
err = mmc_decode_csd(card);
if (err)
goto free_card;
err = mmc_decode_cid(card); //send CMD9
if (err)
goto free_card;
}
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.
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
On Thu, Nov 17, 2011 at 8:11 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Wednesday 16 November 2011, Shashidhar Hiremath wrote:
>> The patch provides An infrastructure to test commands other than Read/Write commands using the IOCTL interface.The Patch can be useful incase of validating the device to verify whether device support a given command or not. The result of the sent command will be written to the result element of the mmc_ioc_cmd structure passed through IOCTL interface.
>>
>> Signed-off-by: Shashidhar Hiremath <shashidharh@xxxxxxxxxxxxxxx>
>
> Hi Shashidhar,
>
> Unfortunately, I have to tell you that an implementation like this is
> inappropriate for a number of reasons. My feeling is that most
> importantly you should instead have the test logic entirely in user
> space and only call the existing ioctl in the kernel. This would
> make the entire patch obsolete, so I'm not commenting on the other
> problems.
>
> What has lead you to implementing the individual test cases in the
> kernel?
>
> 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
