From: Jung Daehwan <dh10.jung@samsung.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"open list:USB XHCI DRIVER" <linux-usb@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Subject: Re: [RFC] usb: host: xhci-mem: Write high first on erst base of secondary interrupter
Date: Mon, 27 May 2024 11:49:50 +0900 [thread overview]
Message-ID: <20240527024950.GA146722@ubuntu> (raw)
In-Reply-To: <b936df07-47cc-9921-0550-469fbbb6b49f@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3395 bytes --]
On Thu, May 23, 2024 at 04:38:48PM +0300, Mathias Nyman wrote:
> On 23.5.2024 7.43, Jung Daehwan wrote:
> >On Wed, May 22, 2024 at 04:40:56PM +0300, Mathias Nyman wrote:
> >>On 22.5.2024 4.03, Daehwan Jung wrote:
> >>>ERSTBA_HI should be written first on secondary interrupter.
> >>>That's why secondary interrupter could be set while Host Controller
> >>>is already running.
> >>>
> >>>[Synopsys]- The host controller was design to support ERST setting
> >>>during the RUN state. But since there is a limitation in controller
> >>>in supporting separate ERSTBA_HI and ERSTBA_LO programming,
> >>>It is supported when the ERSTBA is programmed in 64bit,
> >>>or in 32 bit mode ERSTBA_HI before ERSTBA_LO
> >>
> >>xHCI specification 5.1 "Register Conventions "states that 64 bit
> >>registers should be written in low-high order
> >>
> >>>
> >>>[Synopsys]- The internal initialization of event ring fetches
> >>>the "Event Ring Segment Table Entry" based on the indication of
> >>>ERSTBA_LO written.
> >>>
> >>
> >>Any idea if this is a common issue with this host?
> >>Should other 64 bit registers also be written in reverse order.
> >>
> >>>Signed-off-by: Daehwan Jung <dh10.jung@samsung.com>
> >>>---
> >>> drivers/usb/host/xhci-mem.c | 5 ++++-
> >>> drivers/usb/host/xhci.h | 6 ++++++
> >>> 2 files changed, 10 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> >>>index 3100219..36ee704 100644
> >>>--- a/drivers/usb/host/xhci-mem.c
> >>>+++ b/drivers/usb/host/xhci-mem.c
> >>>@@ -2325,7 +2325,10 @@ xhci_add_interrupter(struct xhci_hcd *xhci, struct xhci_interrupter *ir,
> >>> erst_base = xhci_read_64(xhci, &ir->ir_set->erst_base);
> >>> erst_base &= ERST_BASE_RSVDP;
> >>> erst_base |= ir->erst.erst_dma_addr & ~ERST_BASE_RSVDP;
> >>>- xhci_write_64(xhci, erst_base, &ir->ir_set->erst_base);
> >>>+ if (intr_num == 0)
> >>>+ xhci_write_64(xhci, erst_base, &ir->ir_set->erst_base);
> >>>+ else
> >>>+ xhci_write_64_r(xhci, erst_base, &ir->ir_set->erst_base);
> >>
> >>This may cause issues with other hosts expecting low-high order as stated
> >>in the specification.
> >>
> >>If all 64 bit registers should be written in high-low order for this host then
> >>maybe set a quirk flag and change xhci_write_64()instead.
> >>
> >>xhci_write_64(...)
> >>{
> >> if (xhci->quirks & XHCI_WRITE_64_HI_LO)
> >> hi_lo_writeq(val, regs);
> >> else
> >> lo_hi_writeq(val, regs);
> >>}
> >>
> >
> >Mathias, Thanks for the comment.
> >
> >I've seen this issue only writing the base address of ERST.
> >It's better to use a quirk flag as you said.
> >How about using the quirk only in xhci_add_interrupter?
> >
> >@@ -2325,7 +2325,10 @@ xhci_add_interrupter(struct xhci_hcd *xhci, struct xhci_interrupter *ir,
> > erst_base = xhci_read_64(xhci, &ir->ir_set->erst_base);
> > erst_base &= ERST_BASE_RSVDP;
> > erst_base |= ir->erst.erst_dma_addr & ~ERST_BASE_RSVDP;
> > xhci_write_64(xhci, erst_base, &ir->ir_set->erst_base);
> > if (xhci->quirks & XHCI_WRITE_64_HI_LO)
> > xhci_write_64_r(xhci, erst_base, &ir->ir_set->erst_base);
> > else
> > xhci_write_64(xhci, erst_base, &ir->ir_set->erst_base);
> >
>
> This works.
> Maybe even skip the xhci_write_64_r() helper and just use hi_lo_writeq() directly.
>
> Thanks
> Mathias
>
>
Thanks. I will send the quirk patch soon.
Best Regards,
Jung Daehwan
>
>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
prev parent reply other threads:[~2024-05-27 2:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240522010409epcas2p457b2fcb4f423f2500305053f44ae3199@epcas2p4.samsung.com>
2024-05-22 1:03 ` [RFC] usb: host: xhci-mem: Write high first on erst base of secondary interrupter Daehwan Jung
2024-05-22 13:40 ` Mathias Nyman
2024-05-23 4:43 ` Jung Daehwan
2024-05-23 13:38 ` Mathias Nyman
2024-05-27 2:49 ` Jung Daehwan [this message]
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=20240527024950.GA146722@ubuntu \
--to=dh10.jung@samsung.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--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.