All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 07/10] usb: dbc: handle endpoint stall
Date: Wed, 02 Mar 2016 14:58:59 +0200	[thread overview]
Message-ID: <87h9gp8298.fsf@ti.com> (raw)
In-Reply-To: <56D6E380.3060800@linux.intel.com>

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


Hi,

Mathias Nyman <mathias.nyman@linux.intel.com> writes:
> [ text/plain ]
> On 26.01.2016 14:58, Lu Baolu wrote:
>> In case of endpoint stall, software is able to detect the situation
>> by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
>> framework to handle endpoint stall. When software detects endpoint
>> stall situation, it should wait until endpoint is recovered before
>> read or write oprations.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>>   drivers/usb/early/xhci-dbc.c | 36 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index c81df40..344d93e 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -1163,6 +1163,37 @@ static int xdbc_wait_until_dbc_configured(void)
>>   	return -ETIMEDOUT;
>>   }
>>
>> +static int xdbc_wait_until_epstall_cleared(bool read)
>> +{
>> +	int timeout = 0;
>> +
>> +	if (read) {
>> +		do {
>> +			if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HIT)) {
>> +				xdbcp->in_ep_state = EP_RUNNING;
>> +
>> +				return 0;
>> +			}
>> +
>> +			xdbcp->in_ep_state = EP_HALTED;
>> +			xdbc_udelay(10);
>> +		} while (timeout++ < XDBC_LOOPS);
>> +	} else {
>> +		do {
>> +			if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HOT)) {
>> +				xdbcp->out_ep_state = EP_RUNNING;
>> +
>> +				return 0;
>> +			}
>> +
>> +			xdbcp->out_ep_state = EP_HALTED;
>> +			xdbc_udelay(10);
>> +		} while (timeout++ < XDBC_LOOPS);
>> +	}
>> +
>> +	return -ETIMEDOUT;
>> +}
>>
>
> how about something like:
>
> enum xdbc_ep_state *ep_state;
> u32 halt_bit;
>
> if (read) {
> 	ep_state = &xdbcp->in_ep_state
> 	halt_bit = CTRL_HIT
> } else {
>   	ep_state = &xdbcp->out_ep_state
> 	halt_bit = CTRL_HOT
> }
> do {
> 	if (!(readl(..) & halt_bit)) {
> 		*ep_state = EP_RUNNING;
> 		return 0;
> 	}
> 	*ep_state = EP_HALTED;
> 	delay()
> } while (..)

I'll agree, this looks better. Might also want to refactor the handshake
loop to its own function:

static int xdbg_ep_state_handshake(enum xdbc_ep_state *ep_state, u32 halt_bit)
{
        do {
		if (!(readl(...) & halt_bit)) {
                	...
                }
                *ep_state = EP_HALTED;
                delay(...);
        } while (...)

>> @@ -1182,6 +1213,11 @@ static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
>>   		return -EPERM;
>>   	}
>>
>> +	if (xdbc_wait_until_epstall_cleared(read)) {
>> +		xdbc_trace("%s: endpoint not ready\n", __func__);
>> +		return -EPERM;
>
> Is -EPERM appropriate here?
>
> Not sure about what error codes the device side is using, but usually
> HALT is set due to some Data buffer/transmission/TRB error.

EIO perhaps ?

> In this case the failure is that debug host failed to send a
> clearFeature(EP_HALT) request in time.

I haven't read the spec, but does it define a maximum time for this to
happen ?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-03-02 12:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 12:58 [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port Lu Baolu
2016-01-26 12:58 ` [PATCH v7 01/10] x86: fixmap: add permanent fixmap for xhci " Lu Baolu
2016-01-26 12:58 ` [PATCH v7 02/10] usb: dbc: probe and setup xhci debug capability Lu Baolu
2016-02-16 14:19   ` Mathias Nyman
2016-02-17  8:45     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 03/10] usb: dbc: add support for Intel xHCI dbc quirk Lu Baolu
2016-01-26 12:58 ` [PATCH v7 04/10] usb: dbc: add debug buffer Lu Baolu
2016-02-18 11:43   ` Mathias Nyman
2016-02-19  6:35     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 05/10] usb: dbc: add bulk out and bulk in interfaces Lu Baolu
2016-02-18 13:32   ` Mathias Nyman
2016-02-19  7:09     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 06/10] usb: dbc: handle dbc-configured exit Lu Baolu
2016-01-26 12:58 ` [PATCH v7 07/10] usb: dbc: handle endpoint stall Lu Baolu
2016-03-02 12:58   ` Mathias Nyman
2016-03-02 12:58     ` Felipe Balbi [this message]
2016-03-03  6:12       ` Lu Baolu
2016-03-03  6:00     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 08/10] x86: early_printk: add USB3 debug port earlyprintk support Lu Baolu
2016-01-26 12:58 ` [PATCH v7 09/10] usb: dbc: add handshake between debug target and host Lu Baolu
2016-01-26 12:58 ` [PATCH v7 10/10] usb: doc: add document for xHCI DbC driver Lu Baolu
2016-02-02 14:34 ` [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port Lu Baolu
2016-02-03 21:43   ` Greg Kroah-Hartman
2016-02-03 23:52     ` Lu Baolu

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=87h9gp8298.fsf@ti.com \
    --to=balbi@kernel.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.