Return of PENDING status to SCSI driver

Return of PENDING status to SCSI driver

[Ramya Desai]

Dear Experts,

I am writing my mass storage class driver for my custom USB device.
My device is capable of queuing the commands that are issued to it.
So, I wanted to send the second command from my driver even before the
completion of first command.
To do this I wanted to return the PENDING status to the SCSI layer
immediately after receiving the command.

Can I do as explained above? I studied the default MS class driver, in
which no PENDING status was available.

Thanks in advance,

Regards,
RD

Re: Return of PENDING status to SCSI driver

[Jeff Garzik]

Ramya Desai wrote:
> Dear Experts,
> 
> I am writing my mass storage class driver for my custom USB device.
> My device is capable of queuing the commands that are issued to it.
> So, I wanted to send the second command from my driver even before the
> completion of first command.
> To do this I wanted to return the PENDING status to the SCSI layer
> immediately after receiving the command.

Simply queue as many commands as possible to your hardware, and complete 
them when they are done.  Use can_queue or scsi_adjust_queue_depth() to 
set queueing limits.

	Jeff

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

On 6/12/09, Jeff Garzik <jeff@garzik.org> wrote:
> Ramya Desai wrote:
>
> > Dear Experts,
> >
> > I am writing my mass storage class driver for my custom USB device.
> > My device is capable of queuing the commands that are issued to it.
> > So, I wanted to send the second command from my driver even before the
> > completion of first command.
> > To do this I wanted to return the PENDING status to the SCSI layer
> > immediately after receiving the command.
> >
>
>  Simply queue as many commands as possible to your hardware, and complete
> them when they are done.  Use can_queue or scsi_adjust_queue_depth() to set
> queueing limits.
>
>         Jeff

I used can_queue  to change the queue depth to 5, but I am not getting
the next command until I finish (Done) the first command. I wanted the
second command to come to my driver, even before first command
finishes.

-RD

Re: Return of PENDING status to SCSI driver

[Stefan Richter]

Ramya Desai wrote:
> I used can_queue  to change the queue depth to 5, but I am not getting
> the next command until I finish (Done) the first command. I wanted the
> second command to come to my driver, even before first command
> finishes.

Did you also set cmd_per_lun?
-- 
Stefan Richter
-=====-==--= -==- -==--
http://arcgraph.de/sr/

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/12/2009 03:54 PM, Ramya Desai wrote:
> On 6/12/09, Jeff Garzik <jeff@garzik.org> wrote:
>> Ramya Desai wrote:
>>
>>> Dear Experts,
>>>
>>> I am writing my mass storage class driver for my custom USB device.
>>> My device is capable of queuing the commands that are issued to it.
>>> So, I wanted to send the second command from my driver even before the
>>> completion of first command.
>>> To do this I wanted to return the PENDING status to the SCSI layer
>>> immediately after receiving the command.
>>>
>>  Simply queue as many commands as possible to your hardware, and complete
>> them when they are done.  Use can_queue or scsi_adjust_queue_depth() to set
>> queueing limits.
>>
>>         Jeff
> 
> I used can_queue  to change the queue depth to 5, but I am not getting
> the next command until I finish (Done) the first command. I wanted the
> second command to come to my driver, even before first command
> finishes.
> 
> -RD

If you are using the existing USB mass storage infrastructure then
it will not work. This is because all commands are issued from a
thread per host, which does a synchronous execution of one command
at a time. In fact it does not even have a Q, but a global one cmnd
pointer per host. And therefor sets can_queue to 1.

Are you using the existing USB infrastructure?

Boaz

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

On 6/14/09, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 06/12/2009 03:54 PM, Ramya Desai wrote:
>  > On 6/12/09, Jeff Garzik <jeff@garzik.org> wrote:
>  >> Ramya Desai wrote:
>  >>
>  >>> Dear Experts,
>  >>>
>  >>> I am writing my mass storage class driver for my custom USB device.
>  >>> My device is capable of queuing the commands that are issued to it.
>  >>> So, I wanted to send the second command from my driver even before the
>  >>> completion of first command.
>  >>> To do this I wanted to return the PENDING status to the SCSI layer
>  >>> immediately after receiving the command.
>  >>>
>  >>  Simply queue as many commands as possible to your hardware, and complete
>  >> them when they are done.  Use can_queue or scsi_adjust_queue_depth() to set
>  >> queueing limits.
>  >>
>  >>         Jeff
>  >
>  > I used can_queue  to change the queue depth to 5, but I am not getting
>  > the next command until I finish (Done) the first command. I wanted the
>  > second command to come to my driver, even before first command
>  > finishes.
>  >
>  > -RD
>
>
> If you are using the existing USB mass storage infrastructure then
>  it will not work. This is because all commands are issued from a
>  thread per host, which does a synchronous execution of one command
>  at a time. In fact it does not even have a Q, but a global one cmnd
>  pointer per host. And therefor sets can_queue to 1.
>
>  Are you using the existing USB infrastructure?
>
>
>  Boaz
>
I am replacing the default USB mass storage driver with the one I am
developing. But I am using the default SCSI and USB stack provided by
Linux.

So is there any another way to make my driver asynchronous?

-RD

Re: Return of PENDING status to SCSI driver

[Matthew Wilcox]

On Mon, Jun 15, 2009 at 05:37:14PM +0530, Ramya Desai wrote:
> I am replacing the default USB mass storage driver with the one I am
> developing. But I am using the default SCSI and USB stack provided by
> Linux.

It would be easier to help you if you could post the driver in its
current state ...

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/15/2009 03:07 PM, Ramya Desai wrote:
> On 6/14/09, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> On 06/12/2009 03:54 PM, Ramya Desai wrote:
>>  > On 6/12/09, Jeff Garzik <jeff@garzik.org> wrote:
>>  >> Ramya Desai wrote:
>>  >>
>>  >>> Dear Experts,
>>  >>>
>>  >>> I am writing my mass storage class driver for my custom USB device.
>>  >>> My device is capable of queuing the commands that are issued to it.
>>  >>> So, I wanted to send the second command from my driver even before the
>>  >>> completion of first command.
>>  >>> To do this I wanted to return the PENDING status to the SCSI layer
>>  >>> immediately after receiving the command.
>>  >>>
>>  >>  Simply queue as many commands as possible to your hardware, and complete
>>  >> them when they are done.  Use can_queue or scsi_adjust_queue_depth() to set
>>  >> queueing limits.
>>  >>
>>  >>         Jeff
>>  >
>>  > I used can_queue  to change the queue depth to 5, but I am not getting
>>  > the next command until I finish (Done) the first command. I wanted the
>>  > second command to come to my driver, even before first command
>>  > finishes.
>>  >
>>  > -RD
>>
>>
>> If you are using the existing USB mass storage infrastructure then
>>  it will not work. This is because all commands are issued from a
>>  thread per host, which does a synchronous execution of one command
>>  at a time. In fact it does not even have a Q, but a global one cmnd
>>  pointer per host. And therefor sets can_queue to 1.
>>
>>  Are you using the existing USB infrastructure?
>>
>>
>>  Boaz
>>
> I am replacing the default USB mass storage driver with the one I am
> developing. But I am using the default SCSI and USB stack provided by
> Linux.
> 
> So is there any another way to make my driver asynchronous?
> 
> -RD

I was afraid so.

There is a lot of code you will need to change in current USB storage stack
SCSI is built with native support for queuing, but not so USB-storage-stack.

You will need to first remove from "struct us_data" (drivers/usb/storage/usb.h)
the:
	/* SCSI interfaces */
	struct scsi_cmnd	*srb;		 /* current srb		*/
	unsigned int		tag;		 /* current dCBWTag	*/

which is the assumption that there is only one scsi_cmnd per usb-host.
And fix everything that got broken, by properly associating the command
tag with the scsi_cmnd structure or what ever way your controller supports
individual command addressing. Probably lots of current APIs that only receive
an "struct us_data *" today will need an extra "struct scsi_cmnd *". And so on ...
Not an easy task if you are not familiar with USB and SCSI code.

That said, it is certainly doable. Perhaps other USB people need this too,
and can help you...

[CCing USB list <linux-usb@vger.kernel.org>]
 
Boaz

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Mon, 15 Jun 2009, Boaz Harrosh wrote:

> >> If you are using the existing USB mass storage infrastructure then
> >>  it will not work. This is because all commands are issued from a
> >>  thread per host, which does a synchronous execution of one command
> >>  at a time. In fact it does not even have a Q, but a global one cmnd
> >>  pointer per host. And therefor sets can_queue to 1.
> >>
> >>  Are you using the existing USB infrastructure?
> >>
> >>
> >>  Boaz
> >>
> > I am replacing the default USB mass storage driver with the one I am
> > developing. But I am using the default SCSI and USB stack provided by
> > Linux.
> > 
> > So is there any another way to make my driver asynchronous?
> > 
> > -RD
> 
> I was afraid so.
> 
> There is a lot of code you will need to change in current USB storage stack
> SCSI is built with native support for queuing, but not so USB-storage-stack.

Boaz:

It looks like you didn't read Ramya's reply to your last message.  
Ramya isn't keeping the USB storage "stack" -- it is being replaced by
a new driver -- so there's no point talking about making changes to it.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

On 6/15/09, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
>
>  > >> If you are using the existing USB mass storage infrastructure then
>  > >>  it will not work. This is because all commands are issued from a
>  > >>  thread per host, which does a synchronous execution of one command
>  > >>  at a time. In fact it does not even have a Q, but a global one cmnd
>  > >>  pointer per host. And therefor sets can_queue to 1.
>  > >>
>  > >>  Are you using the existing USB infrastructure?
>  > >>
>  > >>
>  > >>  Boaz
>  > >>
>  > > I am replacing the default USB mass storage driver with the one I am
>  > > developing. But I am using the default SCSI and USB stack provided by
>  > > Linux.
>  > >
>  > > So is there any another way to make my driver asynchronous?
>  > >
>  > > -RD
>  >
>  > I was afraid so.
>  >
>  > There is a lot of code you will need to change in current USB storage stack
>  > SCSI is built with native support for queuing, but not so USB-storage-stack.
>
>
> Boaz:
>
>  It looks like you didn't read Ramya's reply to your last message.
>  Ramya isn't keeping the USB storage "stack" -- it is being replaced by
>  a new driver -- so there's no point talking about making changes to it.
>
>
>  Alan Stern
>
>

I already have an array length of 10 for the bellow members.
       struct scsi_cmnd        *srb;            /* current srb         */
       unsigned int            tag;              /* current dCBWTag     */

I am maintaining an internal queue for the commands.
My main problem is , I am not getting the next command in my USB
storage driver ( My custom) , until the first command is done.
How can I get the next command, while processing the first command?

-Ramya

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/15/2009 05:07 PM, Ramya Desai wrote:
> On 6/15/09, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
>>
>>  > >> If you are using the existing USB mass storage infrastructure then
>>  > >>  it will not work. This is because all commands are issued from a
>>  > >>  thread per host, which does a synchronous execution of one command
>>  > >>  at a time. In fact it does not even have a Q, but a global one cmnd
>>  > >>  pointer per host. And therefor sets can_queue to 1.
>>  > >>
>>  > >>  Are you using the existing USB infrastructure?
>>  > >>
>>  > >>
>>  > >>  Boaz
>>  > >>
>>  > > I am replacing the default USB mass storage driver with the one I am
>>  > > developing. But I am using the default SCSI and USB stack provided by
>>  > > Linux.
>>  > >
>>  > > So is there any another way to make my driver asynchronous?
>>  > >
>>  > > -RD
>>  >
>>  > I was afraid so.
>>  >
>>  > There is a lot of code you will need to change in current USB storage stack
>>  > SCSI is built with native support for queuing, but not so USB-storage-stack.
>>
>>
>> Boaz:
>>
>>  It looks like you didn't read Ramya's reply to your last message.
>>  Ramya isn't keeping the USB storage "stack" -- it is being replaced by
>>  a new driver -- so there's no point talking about making changes to it.
>>
>>
>>  Alan Stern
>>
>>
> 
> I already have an array length of 10 for the bellow members.
>        struct scsi_cmnd        *srb;            /* current srb         */
>        unsigned int            tag;              /* current dCBWTag     */
> 

That's good

> I am maintaining an internal queue for the commands.
> My main problem is , I am not getting the next command in my USB
> storage driver ( My custom) , until the first command is done.
> How can I get the next command, while processing the first command?
> 
> -Ramya

Post the code you have missed something, I'll have a look
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

On 6/15/09, Boaz Harrosh <bharrosh@panasas.com> wrote:
> On 06/15/2009 05:07 PM, Ramya Desai wrote:
>  > On 6/15/09, Alan Stern <stern@rowland.harvard.edu> wrote:
>  >> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
>  >>
>  >>  > >> If you are using the existing USB mass storage infrastructure then
>  >>  > >>  it will not work. This is because all commands are issued from a
>  >>  > >>  thread per host, which does a synchronous execution of one command
>  >>  > >>  at a time. In fact it does not even have a Q, but a global one cmnd
>  >>  > >>  pointer per host. And therefor sets can_queue to 1.
>  >>  > >>
>  >>  > >>  Are you using the existing USB infrastructure?
>  >>  > >>
>  >>  > >>
>  >>  > >>  Boaz
>  >>  > >>
>  >>  > > I am replacing the default USB mass storage driver with the one I am
>  >>  > > developing. But I am using the default SCSI and USB stack provided by
>  >>  > > Linux.
>  >>  > >
>  >>  > > So is there any another way to make my driver asynchronous?
>  >>  > >
>  >>  > > -RD
>  >>  >
>  >>  > I was afraid so.
>  >>  >
>  >>  > There is a lot of code you will need to change in current USB storage stack
>  >>  > SCSI is built with native support for queuing, but not so USB-storage-stack.
>  >>
>  >>
>  >> Boaz:
>  >>
>  >>  It looks like you didn't read Ramya's reply to your last message.
>  >>  Ramya isn't keeping the USB storage "stack" -- it is being replaced by
>  >>  a new driver -- so there's no point talking about making changes to it.
>  >>
>  >>
>  >>  Alan Stern
>  >>
>  >>
>  >
>  > I already have an array length of 10 for the bellow members.
>  >        struct scsi_cmnd        *srb;            /* current srb         */
>  >        unsigned int            tag;              /* current dCBWTag     */
>  >
>
>
> That's good
>
>
>  > I am maintaining an internal queue for the commands.
>  > My main problem is , I am not getting the next command in my USB
>  > storage driver ( My custom) , until the first command is done.
>  > How can I get the next command, while processing the first command?
>  >
>  > -Ramya
>
>
> Post the code you have missed something, I'll have a look
>
> Boaz
>

I can not post the code in public because of some limitations I have.
But Still I am confused with return status (to SCSI layer) for the
command while it is in progress, to get the next command. Is it some
thing like PENDING?

-RD

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

On 6/15/09, Ramya Desai <ramya.desai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 6/15/09, Boaz Harrosh <bharrosh-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org> wrote:
>  > On 06/15/2009 05:07 PM, Ramya Desai wrote:
>  >  > On 6/15/09, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>  >  >> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
>  >  >>
>  >  >>  > >> If you are using the existing USB mass storage infrastructure then
>  >  >>  > >>  it will not work. This is because all commands are issued from a
>  >  >>  > >>  thread per host, which does a synchronous execution of one command
>  >  >>  > >>  at a time. In fact it does not even have a Q, but a global one cmnd
>  >  >>  > >>  pointer per host. And therefor sets can_queue to 1.
>  >  >>  > >>
>  >  >>  > >>  Are you using the existing USB infrastructure?
>  >  >>  > >>
>  >  >>  > >>
>  >  >>  > >>  Boaz
>  >  >>  > >>
>  >  >>  > > I am replacing the default USB mass storage driver with the one I am
>  >  >>  > > developing. But I am using the default SCSI and USB stack provided by
>  >  >>  > > Linux.
>  >  >>  > >
>  >  >>  > > So is there any another way to make my driver asynchronous?
>  >  >>  > >
>  >  >>  > > -RD
>  >  >>  >
>  >  >>  > I was afraid so.
>  >  >>  >
>  >  >>  > There is a lot of code you will need to change in current USB storage stack
>  >  >>  > SCSI is built with native support for queuing, but not so USB-storage-stack.
>  >  >>
>  >  >>
>  >  >> Boaz:
>  >  >>
>  >  >>  It looks like you didn't read Ramya's reply to your last message.
>  >  >>  Ramya isn't keeping the USB storage "stack" -- it is being replaced by
>  >  >>  a new driver -- so there's no point talking about making changes to it.
>  >  >>
>  >  >>
>  >  >>  Alan Stern
>  >  >>
>  >  >>
>  >  >
>  >  > I already have an array length of 10 for the bellow members.
>  >  >        struct scsi_cmnd        *srb;            /* current srb         */
>  >  >        unsigned int            tag;              /* current dCBWTag     */
>  >  >
>  >
>  >
>  > That's good
>  >
>  >
>  >  > I am maintaining an internal queue for the commands.
>  >  > My main problem is , I am not getting the next command in my USB
>  >  > storage driver ( My custom) , until the first command is done.
>  >  > How can I get the next command, while processing the first command?
>  >  >
>  >  > -Ramya
>  >
>  >
>  > Post the code you have missed something, I'll have a look
>  >
>  > Boaz
>  >
>
>
> I can not post the code in public because of some limitations I have.
>  But Still I am confused with return status (to SCSI layer) for the
>  command while it is in progress, to get the next command. Is it some
>  thing like PENDING?
>
>
>  -RD
>

I am sorry for missing some of your mails and posting the same question again.

First command what I mean is some thing like READ(10) in general.

I have taken only 10% the default mass storage driver to develop my
custom driver as my device is entirely a new one. My driver and device
both are capable of queuing the commands. But the problem is only with
SCSI layer, which is not issuing next command (Like READ(10)) until
the first one is done.

-RD
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Mon, Jun 15, 2009 at 08:20:10PM +0530, Ramya Desai wrote:
> > I can not post the code in public because of some limitations I have.
> >  But Still I am confused with return status (to SCSI layer) for the
> >  command while it is in progress, to get the next command. Is it some
> >  thing like PENDING?
> 
> First command what I mean is some thing like READ(10) in general.
> 
> I have taken only 10% the default mass storage driver to develop my
> custom driver as my device is entirely a new one. My driver and device
> both are capable of queuing the commands. But the problem is only with
> SCSI layer, which is not issuing next command (Like READ(10)) until
> the first one is done.

Did you change the maximum number of commands that the virtual HBA can
accept?  It's a field in the structure used when usb-storage registers
itself with the SCSI core...

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

It's monday.  It must be monday.
					-- Greg
User Friendly, 5/4/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Mon, 15 Jun 2009, Ramya Desai wrote:

> I can not post the code in public because of some limitations I have.
> But Still I am confused with return status (to SCSI layer) for the
> command while it is in progress, to get the next command. Is it some
> thing like PENDING?

If you're talking about the return value from queuecommand(), it should 
be 0.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/15/2009 05:42 PM, Ramya Desai wrote:
> On 6/15/09, Boaz Harrosh <bharrosh-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org> wrote:
>> On 06/15/2009 05:07 PM, Ramya Desai wrote:
>>  > On 6/15/09, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>  >> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
>>  >>
>>  >>  > >> If you are using the existing USB mass storage infrastructure then
>>  >>  > >>  it will not work. This is because all commands are issued from a
>>  >>  > >>  thread per host, which does a synchronous execution of one command
>>  >>  > >>  at a time. In fact it does not even have a Q, but a global one cmnd
>>  >>  > >>  pointer per host. And therefor sets can_queue to 1.
>>  >>  > >>
>>  >>  > >>  Are you using the existing USB infrastructure?
>>  >>  > >>
>>  >>  > >>
>>  >>  > >>  Boaz
>>  >>  > >>
>>  >>  > > I am replacing the default USB mass storage driver with the one I am
>>  >>  > > developing. But I am using the default SCSI and USB stack provided by
>>  >>  > > Linux.
>>  >>  > >
>>  >>  > > So is there any another way to make my driver asynchronous?
>>  >>  > >
>>  >>  > > -RD
>>  >>  >
>>  >>  > I was afraid so.
>>  >>  >
>>  >>  > There is a lot of code you will need to change in current USB storage stack
>>  >>  > SCSI is built with native support for queuing, but not so USB-storage-stack.
>>  >>
>>  >>
>>  >> Boaz:
>>  >>
>>  >>  It looks like you didn't read Ramya's reply to your last message.
>>  >>  Ramya isn't keeping the USB storage "stack" -- it is being replaced by
>>  >>  a new driver -- so there's no point talking about making changes to it.
>>  >>
>>  >>
>>  >>  Alan Stern
>>  >>
>>  >>
>>  >
>>  > I already have an array length of 10 for the bellow members.
>>  >        struct scsi_cmnd        *srb;            /* current srb         */
>>  >        unsigned int            tag;              /* current dCBWTag     */
>>  >
>>
>>
>> That's good
>>
>>
>>  > I am maintaining an internal queue for the commands.
>>  > My main problem is , I am not getting the next command in my USB
>>  > storage driver ( My custom) , until the first command is done.
>>  > How can I get the next command, while processing the first command?
>>  >
>>  > -Ramya
>>
>>
>> Post the code you have missed something, I'll have a look
>>
>> Boaz
>>
> 
> I can not post the code in public because of some limitations I have.

This is bulshit. Get your act together babe. You are hacking and deriving from
GPLed code. You are legally bind by that.

But you are welcome to remove any lowlevel rocket science from your driver
and just post the Linux relevant things. Infact why don't you start with a
demo driver that just emulates in SW IO transfers close to what your driver
will do. scsi_debug is a good place to look.

> But Still I am confused with return status (to SCSI layer) for the
> command while it is in progress, to get the next command. Is it some
> thing like PENDING?
> 

Look in scsi_debug enable some prints. It queues and completes cmnds
asynchronously. Look in Alan's other mail I think you are hit with the
usb queue_command posting the commands to a thread. This is unique to
usb.

> -RD

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

> This is bulshit. Get your act together babe. You are hacking and deriving from
>  GPLed code. You are legally bind by that.
>
>  But you are welcome to remove any lowlevel rocket science from your driver
>  and just post the Linux relevant things. Infact why don't you start with a
>  demo driver that just emulates in SW IO transfers close to what your driver
>  will do. scsi_debug is a good place to look.
>
>
>  > But Still I am confused with return status (to SCSI layer) for the
>  > command while it is in progress, to get the next command. Is it some
>  > thing like PENDING?
>  >
>
>
> Look in scsi_debug enable some prints. It queues and completes cmnds
>  asynchronously. Look in Alan's other mail I think you are hit with the
>  usb queue_command posting the commands to a thread. This is unique to
>  usb.
>
>  > -RD
>
>
>  Boaz
>

At this stage, I can not reveal the complete code without my client’s
permission. But the entire code will be made public (According to GPL)
once driver is completed.

But here I am pasting the template structure code that I am using in my driver.

struct scsi_host_template usb_stor_host_template = {
	/* basic userland interface stuff */
	.name =				"usb-storage",
	.proc_name =			"usb-storage",
	.proc_info =			proc_info,
	.info =				host_info,

	/* command interface -- queued only */
	.queuecommand =			queuecommand,

	/* error and abort handlers */
	.eh_abort_handler =		command_abort,
	.eh_device_reset_handler =	device_reset,
	.eh_bus_reset_handler =		bus_reset,

	/* queue commands only, only one command per LUN */
	.can_queue =			5,
	.cmd_per_lun =			5,

	/* unknown initiator id */
	.this_id =			-1,

	.slave_alloc =			slave_alloc,
	.slave_configure =		slave_configure,

	/* lots of sg segments can be handled */
	.sg_tablesize =			SG_ALL,

	/* limit the total size of a transfer to 120 KB */
	.max_sectors =                  240,

	/* merge commands... this seems to help performance, but
	 * periodically someone should test to see which setting is more
	 * optimal.
	 */
	.use_clustering =		1,

	/* emulated HBA */
	.emulated =			5,

	/* we do our own delay after a device or bus reset */
	.skip_settle_delay =		1,

	/* sysfs device attributes */
	.sdev_attrs =			sysfs_device_attr_list,

	/* module management */
	.module =			THIS_MODULE
};


Here I am giving some portion of the data structure us_data I am using

struct us_data {
	
	.......
	
	/* SCSI interfaces */
	struct scsi_cmnd	*srb[5];		 /* current srb		*/
	unsigned int		tag[5];		 /* current dCBWTag	*/

	...continued.

}

If I call void (*done)(struct scsi_cmnd *) call back immediately after
receiving a command, will I get another command ?


Regards,
RD
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Alan Cox]

> If I call void (*done)(struct scsi_cmnd *) call back immediately after
> receiving a command, will I get another command ?

The mid layer will throw commands at you until either you tell it to
stop, there is an error or the amount of pending queued commands for the
target, or the adapter is reached.

In the utterly simplistic case of a totally dumb PIO adapter with no
interrupt support the flow is essentially

	foo_queue_command(cmd)
		cmd->done(cmd)
	return 0

	foo_queue_command(cmd)
		cmd->done(cmd)
	return 0

If you want the scsi mid layer to shut up for a bit then return one of
the MLQUEUE_xxx_BUSY forms and the command will be requeued and fed to
you again later.

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/16/2009 04:35 PM, Ramya Desai wrote:
>> This is bulshit. Get your act together babe. You are hacking and deriving from
>>  GPLed code. You are legally bind by that.
>>
>>  But you are welcome to remove any lowlevel rocket science from your driver
>>  and just post the Linux relevant things. Infact why don't you start with a
>>  demo driver that just emulates in SW IO transfers close to what your driver
>>  will do. scsi_debug is a good place to look.
>>
>>
>>  > But Still I am confused with return status (to SCSI layer) for the
>>  > command while it is in progress, to get the next command. Is it some
>>  > thing like PENDING?
>>  >
>>
>>
>> Look in scsi_debug enable some prints. It queues and completes cmnds
>>  asynchronously. Look in Alan's other mail I think you are hit with the
>>  usb queue_command posting the commands to a thread. This is unique to
>>  usb.
>>
>>  > -RD
>>
>>
>>  Boaz
>>
> 
> At this stage, I can not reveal the complete code without my client’s
> permission. But the entire code will be made public (According to GPL)
> once driver is completed.
> 

This is counter productive and stupid. If they are going to release the code,
anyway, and there are no secrets, then the time to release it is now when
there are problems. When the driver is done and everything is working we don't
need the code do we? it's during development that the code is important. When there
is nothing to do there is nothing to do.

> But here I am pasting the template structure code that I am using in my driver.
> 
> struct scsi_host_template usb_stor_host_template = {
> 	/* basic userland interface stuff */
> 	.name =				"usb-storage",
> 	.proc_name =			"usb-storage",
> 	.proc_info =			proc_info,
> 	.info =				host_info,
> 
> 	/* command interface -- queued only */
> 	.queuecommand =			queuecommand,

If this is the unchanged queuecommand from usb-storage then
this will not work. As explained

> 
> 	/* error and abort handlers */
> 	.eh_abort_handler =		command_abort,
> 	.eh_device_reset_handler =	device_reset,
> 	.eh_bus_reset_handler =		bus_reset,

All these currently assume a single command how
did you change them?

> 
> 	/* queue commands only, only one command per LUN */
> 	.can_queue =			5,
> 	.cmd_per_lun =			5,
> 

Good

> 	/* unknown initiator id */
> 	.this_id =			-1,
> 
> 	.slave_alloc =			slave_alloc,
> 	.slave_configure =		slave_configure,
> 
> 	/* lots of sg segments can be handled */
> 	.sg_tablesize =			SG_ALL,
> 
> 	/* limit the total size of a transfer to 120 KB */
> 	.max_sectors =                  240,
> 
> 	/* merge commands... this seems to help performance, but
> 	 * periodically someone should test to see which setting is more
> 	 * optimal.
> 	 */
> 	.use_clustering =		1,
> 
> 	/* emulated HBA */
> 	.emulated =			5,
> 
> 	/* we do our own delay after a device or bus reset */
> 	.skip_settle_delay =		1,
> 
> 	/* sysfs device attributes */
> 	.sdev_attrs =			sysfs_device_attr_list,
> 
> 	/* module management */
> 	.module =			THIS_MODULE
> };
> 
> 
> Here I am giving some portion of the data structure us_data I am using
> 
> struct us_data {
> 	
> 	.......
> 	
> 	/* SCSI interfaces */
> 	struct scsi_cmnd	*srb[5];		 /* current srb		*/
> 	unsigned int		tag[5];		 /* current dCBWTag	*/
> 
> 	...continued.
> 
> }
> 
> If I call void (*done)(struct scsi_cmnd *) call back immediately after
> receiving a command, will I get another command ?
> 

I think you miss understood:

done() can/usually be called asynchronously when you have results, good/bad,
of the executed command, and all memory has been consumed, (can be freed).

scsi will call .queuecommand upto min(can_queue, .cmd_per_lun) times
without any call to done(). Then for each done() called it will call
.queuecommand again. (If more commands are pending)

So in short min(can_queue, .cmd_per_lun) is the maximum number of
commands queued at the target.

> 
> Regards,
> RD

Above is all good. Your are doing something bad else where, which
you don't show us. Knowing the current USB code, then that is certainly
the culprit. Lots of places assume one command and other places behave
synchronously (ie. wait for response).

Free Life
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[James Bottomley]

On Tue, 2009-06-16 at 17:27 +0300, Boaz Harrosh wrote:
> scsi will call .queuecommand upto min(can_queue, .cmd_per_lun) times
> without any call to done(). Then for each done() called it will call
> .queuecommand again. (If more commands are pending)

Actually, there's one extra piece to this:  you have to return 0 from
your .queuecommand() routine to get the next command.

The helpful documentation for all of this is

Documentation/scsi/scsi_mid_low_api.txt

James

Re: Return of PENDING status to SCSI driver

[Ramya Desai]

>  >       /* error and abort handlers */
>  >       .eh_abort_handler =             command_abort,
>  >       .eh_device_reset_handler =      device_reset,
>  >       .eh_bus_reset_handler =         bus_reset,

Currently I have not implemented these functions. I will register a
transport handler for the above functions and use strategy handler for
error handling at later point of time.

Here is my queuecommand implementation. Please let me know if any
other part of the code is required to find the problem.


static int queuecommand(struct scsi_cmnd *srb,
			void (*done)(struct scsi_cmnd *))
{
		int res = 0;
	struct uas_task *task;
	struct us_data *us = host_to_us(srb->device->host);
	
	US_DEBUG(usb_stor_show_command(srb));

	/* check for state-transition errors */
	if (us->srb != NULL) {
		printk(KERN_ERR USB_STORAGE "Error in %s: us->srb = %p\n",
			__func__, us->srb);
		return SCSI_MLQUEUE_HOST_BUSY;
	}

	/* fail the command if we are disconnecting */
	if (test_bit(US_FLIDX_DISCONNECTING, &us->dflags)) {
		US_DEBUGP("Fail command during disconnect\n");
		srb->result = DID_NO_CONNECT << 16;
		done(srb);
		return 0;
	}

		
	/* Create one task per SCSI command */
	task = uas_create_task(srb, us, GFP_ATOMIC);
	if (!task)
	     return -ENOMEM;
	
	

	/* enqueue the command and wake up the control thread */
	srb->scsi_done = done;

          //us->srb = srb; // eliminated, as a task has been created
per SCSI command


	
		/* Queue the above created task */
		res = uas_queue(task, us);

		/* Examine */
		if (res) {
			
	           //Checking the status of the queue
                    if (res == -UAS_QUEUE_FULL) {
        	srb->result = DID_SOFT_ERROR << 16; /* retry */
			res = 0;
			done(srb);
			}
			return res;
		}
	
	

	printk("MyTag: <%s> <%s> Exit!\n",__FILE__, __FUNCTION__);

	return 0;  //Returning 0 to get the next command
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Tue, 16 Jun 2009, Ramya Desai wrote:

> static int queuecommand(struct scsi_cmnd *srb,
> 			void (*done)(struct scsi_cmnd *))
> {
> 		int res = 0;
> 	struct uas_task *task;
> 	struct us_data *us = host_to_us(srb->device->host);
> 	
> 	US_DEBUG(usb_stor_show_command(srb));
> 
> 	/* check for state-transition errors */
> 	if (us->srb != NULL) {

This test is your problem.  It will succeed as soon as you have 
accepted one command.  You need to remove it.

Alan Stern

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/16/2009 06:09 PM, Ramya Desai wrote:
>>  >       /* error and abort handlers */
>>  >       .eh_abort_handler =             command_abort,
>>  >       .eh_device_reset_handler =      device_reset,
>>  >       .eh_bus_reset_handler =         bus_reset,
> 
> Currently I have not implemented these functions. I will register a
> transport handler for the above functions and use strategy handler for
> error handling at later point of time.
> 
> Here is my queuecommand implementation. Please let me know if any
> other part of the code is required to find the problem.
> 
> 
> static int queuecommand(struct scsi_cmnd *srb,
> 			void (*done)(struct scsi_cmnd *))
> {
> 		int res = 0;
> 	struct uas_task *task;
> 	struct us_data *us = host_to_us(srb->device->host);
> 	
> 	US_DEBUG(usb_stor_show_command(srb));
> 
> 	/* check for state-transition errors */
> 	if (us->srb != NULL) {
> 		printk(KERN_ERR USB_STORAGE "Error in %s: us->srb = %p\n",
> 			__func__, us->srb);
> 		return SCSI_MLQUEUE_HOST_BUSY;
> 	}
> 

Did you not change this to an array? always true now!

> 	/* fail the command if we are disconnecting */
> 	if (test_bit(US_FLIDX_DISCONNECTING, &us->dflags)) {
> 		US_DEBUGP("Fail command during disconnect\n");
> 		srb->result = DID_NO_CONNECT << 16;
> 		done(srb);
> 		return 0;
> 	}
> 
> 		
> 	/* Create one task per SCSI command */
> 	task = uas_create_task(srb, us, GFP_ATOMIC);
> 	if (!task)
> 	     return -ENOMEM;
> 	

What does that do ?

> 	
> 
> 	/* enqueue the command and wake up the control thread */
> 	srb->scsi_done = done;
> 
>           //us->srb = srb; // eliminated, as a task has been created
> per SCSI command
> 
> 
> 	
> 		/* Queue the above created task */
> 		res = uas_queue(task, us);
> 

Does that return immediately?

> 		/* Examine */
> 		if (res) {
> 			
> 	           //Checking the status of the queue
>                     if (res == -UAS_QUEUE_FULL) {
>         	srb->result = DID_SOFT_ERROR << 16; /* retry */
> 			res = 0;
> 			done(srb);
> 			}
> 			return res;
> 		}
> 	
> 	
> 
> 	printk("MyTag: <%s> <%s> Exit!\n",__FILE__, __FUNCTION__);
> 

So do you see this print?
You should see up to 5 prints before the first done is called
by the uas_queue(task.

what do you see?


> 	return 0;  //Returning 0 to get the next command
> }

Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Tue, 16 Jun 2009, Ramya Desai wrote:

> If I call void (*done)(struct scsi_cmnd *) call back immediately after
> receiving a command, will I get another command ?

You MUST NOT do that!  Never call (*done)() until the scsi_cmnd is 
actually complete.  That's what it's for -- to tell the SCSI midlayer 
that the command has been carried out.

Can you post your code for queuecommand()?  That's probably where the
real problem is.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Jeff Garzik]

Ramya Desai wrote:
> I can not post the code in public because of some limitations I have.
> But Still I am confused with return status (to SCSI layer) for the
> command while it is in progress, to get the next command. Is it some
> thing like PENDING?


To repeat:  any "return status" of a currently-executing command is 
largely irrelevant to you.

1) You are given a command, via ->queuecommand

2) You send that command to hardware

3) When hardware is done, call the completion callback

Your driver never returns a "pending" status to the SCSI layer.  The 
SCSI layer is __already__ fully aware that a command is pending, when it 
is passed to your driver.

	Jeff

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Mon, 15 Jun 2009, Ramya Desai wrote:

> I already have an array length of 10 for the bellow members.
>        struct scsi_cmnd        *srb;            /* current srb         */
>        unsigned int            tag;              /* current dCBWTag     */
> 
> I am maintaining an internal queue for the commands.
> My main problem is , I am not getting the next command in my USB
> storage driver ( My custom) , until the first command is done.

When you say "first command", do you mean the _very first_ command sent 
to the device (an INQUIRY command)?  Or are referring to READ(10) 
commands in general?

> How can I get the next command, while processing the first command?

You can't.  Linux never sends any other commands to a SCSI device until
the first INQUIRY is complete.

But you should be getting multiple READ(10) commands.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return of PENDING status to SCSI driver

[Boaz Harrosh]

On 06/15/2009 05:01 PM, Alan Stern wrote:
> On Mon, 15 Jun 2009, Boaz Harrosh wrote:
> 
>>>> If you are using the existing USB mass storage infrastructure then
>>>>  it will not work. This is because all commands are issued from a
>>>>  thread per host, which does a synchronous execution of one command
>>>>  at a time. In fact it does not even have a Q, but a global one cmnd
>>>>  pointer per host. And therefor sets can_queue to 1.
>>>>
>>>>  Are you using the existing USB infrastructure?
>>>>
>>>>
>>>>  Boaz
>>>>
>>> I am replacing the default USB mass storage driver with the one I am
>>> developing. But I am using the default SCSI and USB stack provided by
>>> Linux.
>>>
>>> So is there any another way to make my driver asynchronous?
>>>
>>> -RD
>> I was afraid so.
>>
>> There is a lot of code you will need to change in current USB storage stack
>> SCSI is built with native support for queuing, but not so USB-storage-stack.
> 
> Boaz:
> 
> It looks like you didn't read Ramya's reply to your last message.  
> Ramya isn't keeping the USB storage "stack" -- it is being replaced by
> a new driver -- so there's no point talking about making changes to it.
> 

You are right, this is not what I understood. I understood that he is hacking
on current USB driver to try and enhance it in such a way that it will support
command queuing at the target.

He is not currently concerned about any devices but his own HW. But he is certainly
not writing a driver from scratch. He is basing on the current code base.

Did I understand right?

> Alan Stern
> 

Do you think you have any tips for him. For example at the USB transport side,
what is needed for asynchronous command execution as opposed to what is done now?

Boaz

Re: Return of PENDING status to SCSI driver

[Alan Stern]

On Mon, 15 Jun 2009, Boaz Harrosh wrote:

> You are right, this is not what I understood. I understood that he is hacking
> on current USB driver to try and enhance it in such a way that it will support
> command queuing at the target.
> 
> He is not currently concerned about any devices but his own HW. But he is certainly
> not writing a driver from scratch. He is basing on the current code base.
> 
> Did I understand right?

It's hard to tell from what he wrote.  Ramya's description of his code
is not very complete or precise.

> Do you think you have any tips for him. For example at the USB transport side,
> what is needed for asynchronous command execution as opposed to what is done now?

Nothing extra is needed as far as the lower parts of the USB stack are
concerned; they already are fully asynchronous.  But the entire
transport mechanism of usb-storage would have to be rewritten, since it
runs in a single thread and always waits for one command to finish
before accepting a new command.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html