A question on IOCTL interface for MMC

A question on IOCTL interface for MMC

[Shashidhar Hiremath]

Hi ,
  I am planning to use the existing IOCTL interface for SD/MMC present
in the kernel.
  Since, the IOCTL interface expects a read/write flag , and the MMC
IOCTL is actually an interface to block layer I feel without modifying
the block layer for the support of non-read write commands ,I may not
be able to test the non-read/write commands through the IOCTL
interface .
Is there a way of doing this without modifying block layer ?
--
regards,
Shashidhar Hiremath

Re: A question on IOCTL interface for MMC

[Arnd Bergmann]

On Thursday 20 October 2011 10:39:00 Shashidhar Hiremath wrote:
>   I am planning to use the existing IOCTL interface for SD/MMC present
> in the kernel.
>   Since, the IOCTL interface expects a read/write flag , and the MMC
> IOCTL is actually an interface to block layer I feel without modifying
> the block layer for the support of non-read write commands ,I may not
> be able to test the non-read/write commands through the IOCTL
> interface .
> Is there a way of doing this without modifying block layer ?

Hi Shashidhar,

I think there is actually no problem here at all. The block layer simply
passes the ioctl command number and argument to the driver, which can
do anything with it.

What functionality are you actually looking for?

	Arnd

Re: A question on IOCTL interface for MMC

[Shashidhar Hiremath]

Hi Arnd,
  As explained in previous mail, the IOCTL is actually an inteface to
block layer and it is only expecting read/write commands to be sent
through the interface.The prrof of it can be seen in write_flag
present in the IOCTL structure which indicates the either the command
can be read or a write command.

So, can I submit a linux module to the kernel which uses the same
mmc_ioc_cmd structure and do all the required processing in my module.

To be clear on my requirement:
it is  To test ALL SD/MMC Commands and NOT just the  Read/Write Commands.
or should I extend the mmc_test module present in kernel to support
testing of individual commands as well ?
Can I get some suggestions on what approach to take ?


On Thu, Oct 20, 2011 at 12:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thursday 20 October 2011 10:39:00 Shashidhar Hiremath wrote:
> >   I am planning to use the existing IOCTL interface for SD/MMC present
> > in the kernel.
> >   Since, the IOCTL interface expects a read/write flag , and the MMC
> > IOCTL is actually an interface to block layer I feel without modifying
> > the block layer for the support of non-read write commands ,I may not
> > be able to test the non-read/write commands through the IOCTL
> > interface .
> > Is there a way of doing this without modifying block layer ?
>
> Hi Shashidhar,
>
> I think there is actually no problem here at all. The block layer simply
> passes the ioctl command number and argument to the driver, which can
> do anything with it.
>
> What functionality are you actually looking for?
>
>        Arnd



--
regards,
Shashidhar Hiremath

Re: A question on IOCTL interface for MMC

[Chris Ball]

Hi,

On Mon, Oct 24 2011, Shashidhar Hiremath wrote:
> As explained in previous mail, the IOCTL is actually an inteface to
> block layer and it is only expecting read/write commands to be sent
> through the interface.The prrof of it can be seen in write_flag
> present in the IOCTL structure which indicates the either the command
> can be read or a write command.

Please just try it, using an arbitrary write_flag.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: A question on IOCTL interface for MMC

[J Freyensee]

On 10/24/2011 05:32 AM, Shashidhar Hiremath wrote:
> Hi Arnd,
>    As explained in previous mail, the IOCTL is actually an inteface to
> block layer and it is only expecting read/write commands to be sent
> through the interface.The prrof of it can be seen in write_flag
> present in the IOCTL structure which indicates the either the command
> can be read or a write command.
>
> So, can I submit a linux module to the kernel which uses the same
> mmc_ioc_cmd structure and do all the required processing in my module.
>
> To be clear on my requirement:
> it is  To test ALL SD/MMC Commands and NOT just the  Read/Write Commands.
> or should I extend the mmc_test module present in kernel to support
> testing of individual commands as well ?

I would think the mmc_test module would be a good vehicle to extend to 
have it test individual commands.

Of course if there is no documentation or HOWTO use mmc_test module to 
test an individual MMC command then the work is kind-of for naught.

> Can I get some suggestions on what approach to take ?
>
>
> On Thu, Oct 20, 2011 at 12:48 PM, Arnd Bergmann<arnd@arndb.de>  wrote:
>>
>> On Thursday 20 October 2011 10:39:00 Shashidhar Hiremath wrote:
>>>    I am planning to use the existing IOCTL interface for SD/MMC present
>>> in the kernel.
>>>    Since, the IOCTL interface expects a read/write flag , and the MMC
>>> IOCTL is actually an interface to block layer I feel without modifying
>>> the block layer for the support of non-read write commands ,I may not
>>> be able to test the non-read/write commands through the IOCTL
>>> interface .
>>> Is there a way of doing this without modifying block layer ?
>>
>> Hi Shashidhar,
>>
>> I think there is actually no problem here at all. The block layer simply
>> passes the ioctl command number and argument to the driver, which can
>> do anything with it.
>>
>> What functionality are you actually looking for?
>>
>>         Arnd
>
>
>
> --
> regards,
> Shashidhar Hiremath
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
J (James/Jay) Freyensee
Storage Technology Group
Intel Corporation

Re: A question on IOCTL interface for MMC

[Arnd Bergmann]

On Monday 24 October 2011, J Freyensee wrote:
> On 10/24/2011 05:32 AM, Shashidhar Hiremath wrote:
> > Hi Arnd,
> >    As explained in previous mail, the IOCTL is actually an inteface to
> > block layer and it is only expecting read/write commands to be sent
> > through the interface.The prrof of it can be seen in write_flag
> > present in the IOCTL structure which indicates the either the command
> > can be read or a write command.
> >
> > So, can I submit a linux module to the kernel which uses the same
> > mmc_ioc_cmd structure and do all the required processing in my module.
> >
> > To be clear on my requirement:
> > it is  To test ALL SD/MMC Commands and NOT just the  Read/Write Commands.
> > or should I extend the mmc_test module present in kernel to support
> > testing of individual commands as well ?
> 
> I would think the mmc_test module would be a good vehicle to extend to 
> have it test individual commands.
> 
> Of course if there is no documentation or HOWTO use mmc_test module to 
> test an individual MMC command then the work is kind-of for naught.

I'm still catching up on my email after travelling. I'm sorry I did not
catch this earlier, because this seems to be the source of the confusion
that lead to the suboptimal implementation of test code in the kernel
driver.

I believe the correct answer to the original question would have been
that any command that does not take an argument should just pass
a length of zero on the ioctl interface. If I read the code correctly,
this needs at least a change to mmc_blk_ioctl_copy_from_user to 
handle zero-length arguments, and there are possibly some other
issues, but I think that should let you do everything you need.

	Arnd

Re: A question on IOCTL interface for MMC

[Andrei Warkentin]

Hi,

----- Original Message -----
> From: "Shashidhar Hiremath" <shashidharh@vayavyalabs.com>
> To: "Chris Ball" <cjb@laptop.org>, "J Freyensee" <james_p_freyensee@linux.intel.com>, "John Calixto"
> <john.calixto@modsystems.com>, linux-mmc@vger.kernel.org
> Sent: Thursday, October 20, 2011 1:09:00 AM
> Subject: A question on IOCTL interface for MMC
> 
> Hi ,
>   I am planning to use the existing IOCTL interface for SD/MMC
>   present
> in the kernel.
>   Since, the IOCTL interface expects a read/write flag and the MMC
> IOCTL is actually an interface to block layer I feel without
> modifying
> the block layer for the support of non-read write commands ,I may not
> be able to test the non-read/write commands through the IOCTL
> interface .

Unsure what you mean. Certainly it's up to you how to handle the data
you pass to the ioctl(). The "in" and "out" just says whether you
are passing data to the kernel or expecting something back, no more - 
no less.

What are you actually trying to do? What are you trying to expose or control
through an ioctl?

A

Re: A question on IOCTL interface for MMC

[Shashidhar Hiremath]

thanks for the reply Andrei,
  through the IOCTL, I am actually trying to send a command to the
device and validate the response.So, when I send the command using the
IOCTL, I actually get a Input/Output Error. The reason I feel is that
the command is sent to the block layer and since block layer only
supports the read/write commands,even when I send command zero ,it
treats it like a read/write command.

On Thu, Oct 20, 2011 at 8:25 PM, Andrei Warkentin <awarkentin@vmware.com> wrote:
> Hi,
>
> ----- Original Message -----
>> From: "Shashidhar Hiremath" <shashidharh@vayavyalabs.com>
>> To: "Chris Ball" <cjb@laptop.org>, "J Freyensee" <james_p_freyensee@linux.intel.com>, "John Calixto"
>> <john.calixto@modsystems.com>, linux-mmc@vger.kernel.org
>> Sent: Thursday, October 20, 2011 1:09:00 AM
>> Subject: A question on IOCTL interface for MMC
>>
>> Hi ,
>>   I am planning to use the existing IOCTL interface for SD/MMC
>>   present
>> in the kernel.
>>   Since, the IOCTL interface expects a read/write flag and the MMC
>> IOCTL is actually an interface to block layer I feel without
>> modifying
>> the block layer for the support of non-read write commands ,I may not
>> be able to test the non-read/write commands through the IOCTL
>> interface .
>
> Unsure what you mean. Certainly it's up to you how to handle the data
> you pass to the ioctl(). The "in" and "out" just says whether you
> are passing data to the kernel or expecting something back, no more -
> no less.
>
> What are you actually trying to do? What are you trying to expose or control
> through an ioctl?
>
> A
>



-- 
regards,
Shashidhar Hiremath

Re: A question on IOCTL interface for MMC

[Shashidhar Hiremath]

Hi All,
Let me explain things in detail :-

My INTENT / REQUIREMENT is to test "ALL"  the SD/MMC Commands and NOT
just the Read/Write(data transfer) Commands.

How can this be helpful
  1. It can be used to validate the SD/MMC Core flows(Command specific
code paths)
  2. The Card Enumeration can be done from user space or for that
matter any sequence of commands can be sent from the user space.
  3. Individual commands can be tested with this interface, which is
good for the Buggy IP/Hardware testing. This provides fine control
over testing.

To do this I had two options
  1. Use the Block layer IOCTL.
  2. Write my own kernel module and hack MMC Core to call command
specific functions. This would be similar to "mmc_test.c" module.

APPROACH 1 : Using the Block Layer IOCTL

  Block Layer IOCTL expects only the READ/WRITE commands and hence its
  limited in functionality. I cannot send commands other than
Read/Write, say CMD 2 or
  CMD 0.
  Also you said that the Block Layer cannot be modified to add support for the
  non read/write commands. How should I go about this ?

   OR

  Can we have an IOCTL in MMC Core like the one at Block layer.

    Or

  Can we have a kernel module which can directly call the driver by bypassing
  mmc_core.

APPROACH 2 :

  I have already tested a Kernel Module that uses the sysfs interface to
  send commands. MMC Core will have to be binded to this kernel module.
  This is similar to mmc_test.c module usage.

  Commands will be sent via the sys file and response can be got from the card.
  As of now, the response is not sent to the user space but just to
/var/log/messages.

  MMC Core has to be hacked to export certain functions which will be called
  from the module.

  Is this ok and  can I submit this code.

Cheers,
Shashi


On Fri, Oct 21, 2011 at 10:04 AM, Shashidhar Hiremath
<shashidharh@vayavyalabs.com> wrote:
> thanks for the reply Andrei,
>  through the IOCTL, I am actually trying to send a command to the
> device and validate the response.So, when I send the command using the
> IOCTL, I actually get a Input/Output Error. The reason I feel is that
> the command is sent to the block layer and since block layer only
> supports the read/write commands,even when I send command zero ,it
> treats it like a read/write command.
>
> On Thu, Oct 20, 2011 at 8:25 PM, Andrei Warkentin <awarkentin@vmware.com> wrote:
>> Hi,
>>
>> ----- Original Message -----
>>> From: "Shashidhar Hiremath" <shashidharh@vayavyalabs.com>
>>> To: "Chris Ball" <cjb@laptop.org>, "J Freyensee" <james_p_freyensee@linux.intel.com>, "John Calixto"
>>> <john.calixto@modsystems.com>, linux-mmc@vger.kernel.org
>>> Sent: Thursday, October 20, 2011 1:09:00 AM
>>> Subject: A question on IOCTL interface for MMC
>>>
>>> Hi ,
>>>   I am planning to use the existing IOCTL interface for SD/MMC
>>>   present
>>> in the kernel.
>>>   Since, the IOCTL interface expects a read/write flag and the MMC
>>> IOCTL is actually an interface to block layer I feel without
>>> modifying
>>> the block layer for the support of non-read write commands ,I may not
>>> be able to test the non-read/write commands through the IOCTL
>>> interface .
>>
>> Unsure what you mean. Certainly it's up to you how to handle the data
>> you pass to the ioctl(). The "in" and "out" just says whether you
>> are passing data to the kernel or expecting something back, no more -
>> no less.
>>
>> What are you actually trying to do? What are you trying to expose or control
>> through an ioctl?
>>
>> A
>>
>
>
>
> --
> regards,
> Shashidhar Hiremath
>

OMAP HSMMC data timeout calculation

[Hebbar, Gururaja]

Hi all,


I am trying to understand data timeout value (dto) calculation done in omap hsmmc driver (omap_hsmmc.c)

I summed my understanding & my doubts in below code [GH].

Can someone help me in understanding the code


Thanks in advance.

Regards
Gururaja

static void set_data_timeout(struct omap_hsmmc_host *host,
			     unsigned int timeout_ns,
			     unsigned int timeout_clks)
{
	unsigned int timeout, cycle_ns;
	uint32_t reg, clkd, dto = 0;

	reg = OMAP_HSMMC_READ(host->base, SYSCTL);
	clkd = (reg & CLKD_MASK) >> CLKD_SHIFT;
	if (clkd == 0)
		clkd = 1;

	cycle_ns = 1000000000 / (clk_get_rate(host->fclk) / clkd);
	timeout = timeout_ns / cycle_ns;
	timeout += timeout_clks;

[GH] till here, data time out calculation for the card is calclated in terms of host controller clock rate


	if (timeout) {
		while ((timeout & 0x80000000) == 0) {
			dto += 1;
			timeout <<= 1;
		}
		dto = 31 - dto;

[GH] what is achieved here?


		timeout <<= 1;
		if (timeout && dto)
			dto += 1;

[GH] what is achieved here?


		if (dto >= 13)
			dto -= 13;
		else
			dto = 0;

[GH] why is 13 subtracted when the value is >13 & if <13, why is it made 0


		if (dto > 14)
			dto = 14;

[GH] This is done to limit the max value.

	}


	reg &= ~DTO_MASK;
	reg |= dto << DTO_SHIFT;
	OMAP_HSMMC_WRITE(host->base, SYSCTL, reg);
}


Regards
Gururaja