From: awallis@codeaurora.org (Adam Wallis)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
Date: Tue, 21 Nov 2017 14:49:35 -0500 [thread overview]
Message-ID: <f200ce55-ac67-02f9-4dbf-7a3ba5b52b39@codeaurora.org> (raw)
In-Reply-To: <20171121191103.5oczqvrlo4gtwjqc@rob-hp-laptop>
On 11/21/2017 2:11 PM, Rob Herring wrote:
> On Tue, Nov 21, 2017 at 12:18:09PM -0500, Adam Wallis wrote:
>> Certain systems may run with CPUs at a very slow frequency. This
>> patch adds a quirk bit that can be used to relax certain timings, etc.
>>
>> This quirk might be needed for other fields in the future, but
>> initially, it will be used only on the IRQ control register to allow
>> firmare to control the value of the register. This can prevent an
>
> s/firmare/firmware/
>
Thanks, good catch.
> By firmware control, you mean the register is initialized on boot and
> then not touched by the kernel? What if the XHCI block is reset? Not
> sure if that's possible.
>
>> "interrupt storm" effect on certain systems.
>
> So now we have 2 ways to deal with this? The existing MediaTek quirk and
> now this one.
I do agree that 2 different ways to deal with it is not ideal. I also think that
having one hard-coded value (and one alternate for MTK) is also not ideal.
>
> I think you should change the existing quirk to a value and set the
> value based on compatible strings.
I like where you are going with this. Are you saying that I could read for a
device property read from firmware (for DTB or ACPI) like DWC3 does for
"snps,hird-threshold"? If you mean this, where do you recommend I store the
desired IRQ_CONTROL value - in struct xhci_hcd ?
Or by "compatible" strings, did you mean storing hard-coded values in the
of_device_id usb_xhci_of_match[] array? This would still be hard-coding (which I
would like to avoid) and also would not work for the ACPI case.
>
>> Signed-off-by: Adam Wallis <awallis@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
>> drivers/usb/host/xhci.c | 25 +++++++++++++++-------
>> drivers/usb/host/xhci.h | 1 +
>> 3 files changed, 19 insertions(+), 8 deletions(-)
Thanks for the feedback Rob.
Adam
--
Adam Wallis
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2017-11-21 19:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-21 17:18 [PATCH 0/2] usb: xhci: addition of timing quirk Adam Wallis
2017-11-21 17:18 ` [PATCH 1/2] usb: xhci: add relaxed timing quirk bit Adam Wallis
2017-11-21 19:11 ` Rob Herring
2017-11-21 19:49 ` Adam Wallis [this message]
2017-11-21 20:06 ` Rob Herring
2017-11-22 0:07 ` Adam Wallis
2017-11-22 15:24 ` Mathias Nyman
2017-11-22 19:56 ` Adam Wallis
2017-11-22 23:32 ` Adam Wallis
2017-11-23 10:59 ` Mathias Nyman
2017-11-23 14:35 ` Adam Wallis
2017-11-21 17:18 ` [PATCH 2/2] usb: host: xhci-plat: check " Adam Wallis
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=f200ce55-ac67-02f9-4dbf-7a3ba5b52b39@codeaurora.org \
--to=awallis@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).