From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Andy Gross <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Felipe Balbi <balbi@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Pavan Kondeti <quic_pkondeti@quicinc.com>,
Pratham Pratap <quic_ppratap@quicinc.com>,
Harsh Agarwal <quic_harshq@quicinc.com>,
Jack Pham <quic_jackp@quicinc.com>,
Wesley Cheng <quic_wcheng@quicinc.com>,
"quic_shazhuss@quicinc.com" <quic_shazhuss@quicinc.com>
Subject: Re: [RFC v4 2/5] usb: dwc3: core: Refactor PHY logic to support Multiport Controller
Date: Wed, 25 Jan 2023 19:08:10 +0000 [thread overview]
Message-ID: <20230125190805.l7yo5lls7gfhoo4b@synopsys.com> (raw)
In-Reply-To: <0d9eab77-ad5f-be23-8ed6-d78c0d3ccef1@quicinc.com>
On Wed, Jan 25, 2023, Krishna Kurapati PSSNV wrote:
>
>
> On 1/21/2023 4:14 AM, Thinh Nguyen wrote:
> >
> > This becomes rather more complicated because the user can skip certain
> > port in the DT. We have access to the host registers. Can we just
> > temporarily map and access HCSPARAMS1 to get the MAXPORTS and each port
> > capability before handing control over to the xHCI driver. We would be
> > able to get the num_ports and num_ss_ports then.
> >
> > Similarly, the xhci driver doesn't care whether the user skips certain
> > port in the DT, it only checks and operates based on the capability
> > registers.
> >
> > If we have the exact num_ports and num_ss_ports, we can be sure the
> > setting to GUSB3PIPECTLn and GUSB2PHYCFGn are valid.
> >
>
> Hi Thinh,
>
> Thanks for the suggestion. Is the following diff / implementation good
> enough ? I Wanted to get it clarified from upstream as I am using
> *ioremap/iounmap* directly instead of *devm_* API's
>
> I tested it and it works fine on SA8295P. Will do some further testing on
> other devices as well.
>
>
> +static int dwc3_read_port_info(struct dwc3 *dwc, struct resource *res)
> +{
> + void __iomem *regs;
> + struct resource dwc_res;
> + unsigned int hw_mode;
> + u32 offset;
> + u32 temp;
> + u8 major_revision;
> + u8 minor_revision;
> +
> + /*
> + * Request memory region including xHCI regs,
> + * since it is needed to get port info
> + */
> + dwc_res = *res;
> + dwc_res.start += 0;
> +
> + regs = ioremap(dwc_res.start, resource_size(&dwc_res));
> + if (IS_ERR(regs)) {
> + return PTR_ERR(regs);
> + }
We don't need to ioremap the whole region. Just do it for
the xhci_resources[0]
> +
> + /*
> + * If the controller is not host-only, then it must be a
> + * single port controller.
> + */
> + temp = readl(regs + DWC3_GHWPARAMS0);
> + hw_mode = DWC3_GHWPARAMS0_MODE(temp);
> + if (hw_mode != DWC3_GHWPARAMS0_MODE_HOST) {
> + dwc->num_ports = 1;
> + dwc->num_ss_ports = 1;
> + return 0;
> + }
This check should be done before we get into this function.
> +
> + offset = xhci_find_next_ext_cap(regs, 0,
> + XHCI_EXT_CAPS_PROTOCOL);
> + while (offset) {
> + temp = readl(regs + offset);
> + major_revision = XHCI_EXT_PORT_MAJOR(temp);;
> + minor_revision = XHCI_EXT_PORT_MINOR(temp);
We probably don't need minor revision.
> +
> + temp = readl(regs + offset + 0x08);
> + if (major_revision == 0x03) {
> + dwc->num_ss_ports += XHCI_EXT_PORT_COUNT(temp);
> + } else if (major_revision <= 0x02) {
> + dwc->num_ports += XHCI_EXT_PORT_COUNT(temp);
> + } else {
> + dev_err(dwc->dev, "revision gone wrong\n");
> + return -EINVAL;
> + }
> +
> + offset = xhci_find_next_ext_cap(regs, offset,
> + XHCI_EXT_CAPS_PROTOCOL);
> + }
> +
> + temp = readl(regs + DWC3_XHCI_HCSPARAMS1_OFFSET);
> + if (HCS_MAX_PORTS(temp) != (dwc->num_ss_ports + dwc->num_ports)) {
> + dev_err(dwc->dev, "inconsistency in port info\n");
> + return -EINVAL;
> + }
> +
> + dev_info(dwc->dev, "num_ports: %d, num_ss_ports: %d\n",
> dwc->num_ports, dwc->num_ss_ports);
> + iounmap(regs);
Make sure to iounmap on all the early return/error cases.
> + return 0;
> +}
> +
> static int dwc3_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -1912,6 +1964,10 @@ static int dwc3_probe(struct platform_device *pdev)
> dwc->xhci_resources[0].flags = res->flags;
> dwc->xhci_resources[0].name = res->name;
>
> + ret = dwc3_read_port_info(dwc, res);
This should be called after some initializations to make sure some
clocks are enabled. Otherwise some devices may not able to access the
registers. Preferably after dwc3_cache_hwparams() but before
dwc3_core_init().
> + if (ret)
> + return ret;
> +
> /*
> * Request memory region but exclude xHCI regs,
> * since it will be requested by the xhci-plat driver.
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 2f82eda9d44f..8535425b81d4 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -38,6 +38,9 @@
> /* Numer of ports supported by a multiport controller */
> #define MAX_PORTS_SUPPORTED 4
>
> +/* XHCI Reg constants */
> +#define DWC3_XHCI_HCSPARAMS1_OFFSET 0x04
Change to DWC3_XHCI_HCSPARAMS1
> +
> /* Global constants */
> #define DWC3_PULL_UP_TIMEOUT 500 /* ms */
> #define DWC3_BOUNCE_SIZE 1024 /* size of a superspeed bulk */
>
>
>
> Please let me know if this would be acceptable.
>
It looks fine to me. Please review the comments and remmove debug
prints and any other cleanup for a proper patch.
Thanks,
Thinh
next prev parent reply other threads:[~2023-01-25 19:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 11:41 [RFC v4 0/5] Add multiport support for DWC3 controllers Krishna Kurapati
2023-01-15 11:41 ` [RFC v4 1/5] dt-bindings: usb: Add bindings to support multiport properties Krishna Kurapati
2023-01-15 15:11 ` Rob Herring
2023-01-16 16:34 ` Rob Herring
2023-01-17 9:01 ` Krishna Kurapati PSSNV
2023-01-17 11:02 ` Krzysztof Kozlowski
2023-01-17 14:01 ` Krishna Kurapati PSSNV
2023-01-18 18:20 ` Bjorn Andersson
2023-01-15 11:41 ` [RFC v4 2/5] usb: dwc3: core: Refactor PHY logic to support Multiport Controller Krishna Kurapati
2023-01-19 0:36 ` Thinh Nguyen
2023-01-19 3:01 ` Krishna Kurapati PSSNV
2023-01-20 1:02 ` Thinh Nguyen
2023-01-20 1:46 ` Krishna Kurapati PSSNV
2023-01-20 22:44 ` Thinh Nguyen
2023-01-21 2:09 ` Krishna Kurapati PSSNV
2023-01-25 10:07 ` Krishna Kurapati PSSNV
2023-01-25 19:08 ` Thinh Nguyen [this message]
2023-01-25 20:49 ` Jack Pham
2023-01-25 22:27 ` Thinh Nguyen
2023-01-20 22:57 ` Thinh Nguyen
2023-01-21 2:06 ` Krishna Kurapati PSSNV
2023-01-21 2:19 ` Thinh Nguyen
2023-01-21 2:24 ` Krishna Kurapati PSSNV
2023-01-21 2:55 ` Thinh Nguyen
2023-01-19 22:09 ` Andrew Halaney
2023-01-20 1:55 ` Krishna Kurapati PSSNV
2023-01-20 14:37 ` Andrew Halaney
2023-01-20 15:13 ` Krishna Kurapati PSSNV
2023-01-20 15:18 ` Krishna Kurapati PSSNV
2023-01-24 8:21 ` Shazad Hussain
2023-01-15 11:41 ` [RFC v4 3/5] usb: dwc3: core: Do not setup event buffers for host only controllers Krishna Kurapati
2023-01-19 0:38 ` Thinh Nguyen
2023-01-19 1:57 ` Jack Pham
2023-01-19 2:32 ` Thinh Nguyen
2023-01-15 11:41 ` [RFC v4 4/5] usb: dwc3: qcom: Add multiport controller support for qcom wrapper Krishna Kurapati
2023-01-15 11:41 ` [RFC v4 5/5] arm: dts: msm: Add multiport controller node for usb Krishna Kurapati
2023-01-18 18:28 ` Bjorn Andersson
2023-01-18 18:31 ` Krishna Kurapati PSSNV
2023-01-19 3:43 ` [RFC v4 0/5] Add multiport support for DWC3 controllers Bjorn Andersson
2023-01-19 5:17 ` Krishna Kurapati PSSNV
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=20230125190805.l7yo5lls7gfhoo4b@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=balbi@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=quic_harshq@quicinc.com \
--cc=quic_jackp@quicinc.com \
--cc=quic_kriskura@quicinc.com \
--cc=quic_pkondeti@quicinc.com \
--cc=quic_ppratap@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=quic_wcheng@quicinc.com \
--cc=robh+dt@kernel.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