From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers
Date: Wed, 16 Dec 2015 15:13:05 +0100 [thread overview]
Message-ID: <201512161513.05834.marex@denx.de> (raw)
In-Reply-To: <5670D05C.8000309@wwwdotorg.org>
On Wednesday, December 16, 2015 at 03:45:48 AM, Stephen Warren wrote:
> On 12/15/2015 05:42 PM, Marek Vasut wrote:
> > On Wednesday, December 16, 2015 at 12:35:23 AM, Stephen Warren wrote:
> >> On 11/13/2015 06:16 PM, Marek Vasut wrote:
> >>> On Friday, November 13, 2015 at 09:34:09 PM, Stephen Warren wrote:
> >>>> From: Stephen Warren <swarren@nvidia.com>
> >>>>
> >>>> When CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP is enabled, use a
> >>>> GET_REPORT control transfer to retrieve the initial state of the
> >>>> keyboard. This matches the technique used to poll the keyboard state.
> >>>> This is useful since it eliminates the remaining use of interrupt
> >>>> transfers from the USB keyboard driver, which allows it to work with
> >>>> USB HCD that don't support interrupt transfers.
> >>>>
> >>>> Cc: Hans de Goede <hdegoede@redhat.com>
> >>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >>>> ---
> >>>> Are there any disadvantages to using control transfers over interrupt
> >>>> transfers? I'm not aware of any, but I assume there must be a reason
> >>>> that U-Boot typically uses interrupt transfers.
> >>>
> >>> I initially implemented the control EP polling because I had a keyboard
> >>> which had issues with interrupt transfers.
> >>>
> >>> Reviewed-by: Marek Vasut <marex@denx.de>
> >>
> >> Did you intend someone else to apply this?
> >
> > Is the discussion concluded already? I was under the impression that
> > there was no general agreement.
> >
> > Otherwise I can pick this of course.
>
> The last comments in the thread were:
>
> Hans de Goede wrote:
> > Stephen Warren wrote:
> >> However, I think that fixing the existing "use control transfers"
> >> support so that it exclusively uses control transfers is still
> >> reasonable?
> >
> > Ack, as long as we have it, we should fix it. I do believe we should get
> > rid of it in the long run though.
Oki, in that case, it makes sense to apply this in the short term. Thanks
for the reminder, applied!
Best regards,
Marek Vasut
next prev parent reply other threads:[~2015-12-16 14:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-13 20:34 [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers Stephen Warren
2015-11-14 1:16 ` Marek Vasut
2015-12-15 23:35 ` Stephen Warren
2015-12-16 0:42 ` Marek Vasut
2015-12-16 2:45 ` Stephen Warren
2015-12-16 14:13 ` Marek Vasut [this message]
2015-11-15 19:40 ` Hans de Goede
2015-11-16 17:16 ` Stephen Warren
2015-11-16 17:20 ` Hans de Goede
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=201512161513.05834.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/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