All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Amit Blay" <ablay@codeaurora.org>
To: balbi@ti.com
Cc: Amit Blay <ablay@codeaurora.org>,
	greg@kroah.com, linux-usb@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, tlinder@codeaurora.org
Subject: Re: [RFC/PATCH 2/3] usb:gadget: Add SuperSpeed function power management
Date: Thu, 28 Jul 2011 09:15:59 -0700 (PDT)	[thread overview]
Message-ID: <4a64e01e1d3dc87bf2873cc42af4e15c.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <20110727143432.GQ5134@legolas.emea.dhcp.ti.com>

Hi Felipe,

>> Interface: GET_STATUS & SET_FEATURE(FUNC_SUSPEND).
>
> if it's targeted to an interface, why don't you just let the gadget
> driver handle it ? composite.c tracks all functions already and we
> should just call function->setup() to let the correct function handle
> this.

Your question is regarding why we added the function->func_suspend &
function->get_status callbacks in the first place? (I'm asking because
this is not covered by this patch...)
If we let both requests to be handled by function->setup(), then to
support SuperSpeed, we'll have to change each and every function's setup()
to respond back with a correct default value.
The advantage of adding function->func_suspend & function->get_status is
that if the function doesn't supply those functions, the default can be
handled by the composite setup() function.

>> 2. Add func_wakeup api to usb_gadget_ops.
>> Super-Speed device must provide interface number to the UDC when
>> it triggers remote wakeup (function wake).
>> The func_wakeup api is used instead of the wakeup api, when the
>> gadget is connected in Super-Speed. The wakeup api is left as is,
>> and it is used when the gadget is connected in High-Speed. Therefore,
>> no change is required in non Super-Speed UDCs.

> first of all, this needs to be splitted. You shouldn't do more than one
> thing in a patch ;-)

OK, I will split the patch.

>> +++ b/drivers/usb/gadget/zero.c
>> @@ -239,7 +239,11 @@ static void zero_autoresume(unsigned long _c)
>>  	 * because of some direct user request.
>>  	 */
>>  	if (g->speed != USB_SPEED_UNKNOWN) {
>> -		int status = usb_gadget_wakeup(g);
>> +		/*
>> +		 * The single interface of the current configuration
>> +		 * triggers the wakeup.
>> +		 */
>> +		int status = usb_gadget_wakeup(g, 1);
>
> no no, I think this should be handled by the function itself (f_*.c).

Yes you are right, the function should handle this. The next patch
(usb:gadget: SuperSpeed function power management testing support) adds
this exact capability to f_sourcesink. The function invokes the UDC's
func_wake callback.

But in this change above, I tried (with minimal changes) to keep the
current functionality of gadget zero's autoresume, which uses
usb_gadget_wakeup(). Since there is no device remote wakeup in SuperSpeed,
only function wake, calling usb_gadget_wakeup() has no real meaning in
non-SuperSpeed speeds.

The complete solution will be to move the autoresume feature from gadget
zero into the functions, f_sourcesink & f_loopback. This is the way wakeup
should be done in SuperSpeed, as I understand it. That means that both
functions will arm a timer on device suspend. When the timer expires, in
SuperSpeed it should call the UDC's func_wake callback. For lower speeds,
it should call usb_gadget_wakeup() to trigger device remote wakeup.
What do you think?

>> -static inline int usb_gadget_wakeup(struct usb_gadget *gadget)
>> +static inline int usb_gadget_wakeup(struct usb_gadget *gadget, int
>> interface_id)
>>  {
>> -	if (!gadget->ops->wakeup)
>> -		return -EOPNOTSUPP;
>> -	return gadget->ops->wakeup(gadget);
>> +	if (gadget->speed == USB_SPEED_SUPER) {
>> +		if (!gadget->ops->func_wakeup)
>> +			return -EOPNOTSUPP;
>> +
>> +		return gadget->ops->func_wakeup(gadget, interface_id);
>
> I really don't like this... You're just abusing this interface. Either
> add a separate one (which I still don't think it's the right approach)
> or just let the gadget driver handle it, meaning that composite.c would
> call into f_*.c and the drivers which don't use composite.c will handle
> it their own way.

This change is meant to keep usb_gadget_wakeup() API backwards compatible,
meaning that this API will still work in SuperSpeed.
Of course, if a new USB class will utilize function wake, the new function
will call gadget->ops->func_wakeup().
The solution I suggested above will address this comment as well, but the
downside is that it is not backward compatible, meaning, it requires to
change each gadget that is using usb_gadget_wakeup().

Thanks,
Amit.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  parent reply	other threads:[~2011-07-28 16:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03 14:29 [PATCH 0/3] usb:gadget: Add SuperSpeed Function Power Management Amit Blay
     [not found] ` <1309703373-22476-1-git-send-email-ablay-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2011-07-03 14:29   ` [RFC/PATCH 1/3] usb: Add SuperSpeed support to g_zero gadget Amit Blay
     [not found]     ` <1309703373-22476-2-git-send-email-ablay-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2011-07-08 10:58       ` Felipe Balbi
2011-07-03 14:29 ` [RFC/PATCH 2/3] usb:gadget: Add SuperSpeed function power management Amit Blay
     [not found]   ` <1309703373-22476-3-git-send-email-ablay-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2011-07-27 14:34     ` Felipe Balbi
2011-07-28 16:15       ` Amit Blay
2011-07-29  4:51         ` Felipe Balbi
     [not found]           ` <20110729045136.GA9069-UiBtZHVXSwEVvW8u9ZQWYwjfymiNCTlR@public.gmane.org>
2011-07-29  7:41             ` Amit Blay
2011-07-28 16:15       ` Amit Blay [this message]
2011-07-03 14:29 ` [RFC/PATCH 3/3] usb:gadget: SuperSpeed function power management testing support Amit Blay
     [not found]   ` <1309703373-22476-4-git-send-email-ablay-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2011-07-27 14:37     ` Felipe Balbi

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=4a64e01e1d3dc87bf2873cc42af4e15c.squirrel@www.codeaurora.org \
    --to=ablay@codeaurora.org \
    --cc=balbi@ti.com \
    --cc=greg@kroah.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=tlinder@codeaurora.org \
    /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.