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.
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox