public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dolev Raviv" <draviv@codeaurora.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Santosh Y <santoshsy@gmail.com>,
	linux-scsi@vger.kernel.org, vinholikatti@gmail.com,
	Dolev Raviv <draviv@codeaurora.org>
Subject: Re: [PATCH 3/3] scsi: ufs: add support for query requests
Date: Sun, 5 May 2013 03:32:23 -0700	[thread overview]
Message-ID: <81efb1ec20c4c2ddf523f1cc34d8962b.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <1367605900.5981.47.camel@dabdike>

Hi James,
I've noticed you haven't merged this patch.
To avoid further problems I resent a V5 to this patch removing the Kconfig
change.

Dolev

> On Thu, 2013-05-02 at 17:25 +0530, Santosh Y wrote:
>> From: Dolev Raviv <draviv@codeaurora.org>
>>
>> Add support for sending UFS query requests through tagged command
>> queuing. This design allows queuing query requests in any open slot
>> along with other SCSI commands. In this way there is no need to
>> save a slot in the requests queue and decrease its size.
>>
>> A query request is posing to a SCSI command to use native flow. But
>> unlike normal SCSI command flow, the data and response fields are
>> filled in UFS host data structure instead of passing as arguments
>> while queuing into SCSI mlqueue (mid-layer SCSI queue, the requests
>> from this queue are submitted to the device queue). As per specification
>> only one query request is allowed to be processed by device. Hence a
>> mutex lock for protecting data and response fields (hba->query.request
>> and
>> hba->query.response) needs to be held while query request is in
>> progress.
>>
>> The API for submitting a query request is ufs_query_request() in
>> ufshcd.c. This function is responsible for:
>> 1. Obtaining the SCSI device from the host
>> 2. Keeping the query mutex to prevent multiple queries
>> 3. Storing the required data for sending a query request in ufs_hba
>> 4. Queuing a SCSI vendor specific command to trigger a query request
>>    in the UFS driver.
>>
>> The callers of ufs_query_request() are expected to fill the query
>> command data fields and are to provide an allocated response field
>> for the driver to fill response fields after request completion.
>>
>> The request and response upiu is extended in a union to enable using the
>> same data structure, both for command upiu and query request upiu.
>>
>> The query request flow is separated from the scsi command flow in:
>> 1. Preparing the request
>> 2. Validating response (error) codes
>> 3. Copying data (only used for descriptor read/write query requests)
>> 4. Copying response/sense
>>
>> Data error can't be handled in the scsi command native flow. Hence,
>> we pass the code as without a change back to the submitting layer.
>>
>> UPIU (UFS Protocol Information Unit) size is increased to 512 bytes
>> from 128. The UPIU header and the transaction specific fields (SCSI
>> command or Query Request OSF - Op-code Specific Fields) are 32 bytes
>> together, the rest is used to transfer extra request data (such as
>> descriptor in query requests). In order to accommodate the largest
>> descriptor in the UFS spec (256 bytes) we need to increase the UPIU
>> size.
>>
>> Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
>> Signed-off-by: Santosh Y <santoshsy@gmail.com>
>>
>> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
>> index 35faf24..82417d6 100644
>> --- a/drivers/scsi/ufs/Kconfig
>> +++ b/drivers/scsi/ufs/Kconfig
>> @@ -35,6 +35,7 @@
>>  config SCSI_UFSHCD
>>  	tristate "Universal Flash Storage Controller Driver Core"
>>  	depends on SCSI
>> +	default y
>>  	---help---
>>  	This selects the support for UFS devices in Linux, say Y and make
>>  	  sure that you know the name of your UFS host adapter (the card
>
> I don't think you want to force this on in every configuration since
> it's only appropriate to non server/desktop.  I stripped this hunk.
>
> James
>
>
> --
> 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
>


-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



  reply	other threads:[~2013-05-05 10:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-02 11:55 [PATCH 0/3] scsi: ufs: Platform and Query updates Santosh Y
2013-05-02 11:55 ` [PATCH 1/3] ufs: Add Platform glue driver for ufshcd Santosh Y
2013-05-02 11:55 ` [PATCH 2/3] ufs: Correct the expected data transfersize Santosh Y
2013-05-02 11:55 ` [PATCH 3/3] scsi: ufs: add support for query requests Santosh Y
2013-05-03 18:31   ` James Bottomley
2013-05-05 10:32     ` Dolev Raviv [this message]
2013-05-06  4:26     ` Santosh Y
2013-05-06 10:41       ` merez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81efb1ec20c4c2ddf523f1cc34d8962b.squirrel@www.codeaurora.org \
    --to=draviv@codeaurora.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=santoshsy@gmail.com \
    --cc=vinholikatti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox