| Message ID | 20230727223307.8096-1-quic_kriskura@quicinc.com |
|---|---|
| Headers | show |
| Series | Add multiport support for DWC3 controllers | expand |
On Fri, Jul 28, 2023, Krishna Kurapati wrote: > Currently host-only capable DWC3 controllers support Multiport. > Temporarily map XHCI address space for host-only controllers and parse > XHCI Extended Capabilities registers to read number of usb2 ports and > usb3 ports present on multiport controller. Each USB Port is at least HS > capable. > > Since the extcaps header is only being used, move port_count related > macros and structure from xhci.h to xhci-ext-caps.h. > > The port info for usb2 and usb3 phy are identified as num_usb2_ports > and num_usb3_ports. The intention is as follows: > > Wherever we need to perform phy operations like: > > LOOP_OVER_NUMBER_OF_AVAILABLE_PORTS() > { > phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST); > phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST); > } > > If number of usb2 ports is 3, loop can go from index 0-2 for > usb2_generic_phy. If number of usb3-ports is 2, we don't know for sure, > if the first 2 ports are SS capable or some other ports like (2 and 3) > are SS capable. So instead, num_usb2_ports is used to loop around all > phy's (both hs and ss) for performing phy operations. If any > usb3_generic_phy turns out to be NULL, phy operation just bails out. > > num_usb3_ports is used to modify GUSB3PIPECTL registers while setting up > phy's as we need to know how many SS capable ports are there for this. > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > drivers/usb/dwc3/core.c | 61 ++++++++++++++++++++++++++++++++ > drivers/usb/dwc3/core.h | 5 +++ > drivers/usb/host/xhci-ext-caps.h | 27 ++++++++++++++ > drivers/usb/host/xhci.h | 27 -------------- > 4 files changed, 93 insertions(+), 27 deletions(-) Please split the moving of code for xhci in a separate commit. Thanks, Thinh
On Fri, Jul 28, 2023, Krishna Kurapati wrote: > On some SoC's like SA8295P where the tertiary controller is host-only > capable, GEVTADDRHI/LO, GEVTSIZ, GEVTCOUNT registers are not accessible. > Trying to access them leads to a crash. > > For DRD/Peripheral supported controllers, event buffer setup is done > again in gadget_pullup. Skip setup or cleanup of event buffers if > controller is host-only capable. > > Suggested-by: Johan Hovold <johan@kernel.org> > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > drivers/usb/dwc3/core.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > index edc79ce70588..0aa58600a566 100644 > --- a/drivers/usb/dwc3/core.c > +++ b/drivers/usb/dwc3/core.c > @@ -486,6 +486,13 @@ static void dwc3_free_event_buffers(struct dwc3 *dwc) > static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned int length) > { > struct dwc3_event_buffer *evt; > + unsigned int hw_mode; > + > + hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0); > + if (hw_mode == DWC3_GHWPARAMS0_MODE_HOST) { > + dwc->ev_buf = NULL; > + return 0; > + } > > evt = dwc3_alloc_one_event_buffer(dwc, length); > if (IS_ERR(evt)) { > @@ -507,6 +514,9 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc) > { > struct dwc3_event_buffer *evt; > > + if (!dwc->ev_buf) > + return 0; > + > evt = dwc->ev_buf; > evt->lpos = 0; > dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0), > @@ -524,6 +534,9 @@ void dwc3_event_buffers_cleanup(struct dwc3 *dwc) > { > struct dwc3_event_buffer *evt; > > + if (!dwc->ev_buf) > + return; > + > evt = dwc->ev_buf; > > evt->lpos = 0; > -- > 2.40.0 > Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Thanks, Thinh
On Fri, Jul 28, 2023 at 04:03:02AM +0530, Krishna Kurapati wrote: > Refactor setup_irq call to facilitate reading multiport IRQ's along > with non mulitport ones. For SA8295, there are 4-DP/4-DM and 2-SS > IRQ's. Check whether device is multiport capable or not and read all > interrupts for DP/DM/SS on each port accordingly. > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > drivers/usb/dwc3/dwc3-qcom.c | 277 ++++++++++++++++++++++++----------- > 1 file changed, 190 insertions(+), 87 deletions(-) > > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c > index 3de43df6bbe8..ad89ded116d3 100644 > --- a/drivers/usb/dwc3/dwc3-qcom.c > +++ b/drivers/usb/dwc3/dwc3-qcom.c > @@ -64,33 +64,61 @@ struct dwc3_acpi_pdata { > bool is_urs; > }; > > +struct dwc3_qcom_of_match_data { > + u8 num_ports; > +}; > + > struct dwc3_qcom { > - struct device *dev; > - void __iomem *qscratch_base; > - struct platform_device *dwc3; > - struct platform_device *urs_usb; > - struct clk **clks; > - int num_clocks; > - struct reset_control *resets; > - > - int hs_phy_irq; > - int dp_hs_phy_irq; > - int dm_hs_phy_irq; > - int ss_phy_irq; > - enum usb_device_speed usb2_speed; > - > - struct extcon_dev *edev; > - struct extcon_dev *host_edev; > - struct notifier_block vbus_nb; > - struct notifier_block host_nb; > + struct device *dev; > + void __iomem *qscratch_base; > + struct platform_device *dwc3; > + struct platform_device *urs_usb; > + struct clk **clks; > + int num_clocks; > + struct reset_control *resets; > + > + int hs_phy_irq; > + int dp_hs_phy_irq[DWC3_MAX_PORTS]; > + int dm_hs_phy_irq[DWC3_MAX_PORTS]; > + int ss_phy_irq[DWC3_MAX_PORTS]; > + enum usb_device_speed usb2_speed; > + > + struct extcon_dev *edev; > + struct extcon_dev *host_edev; > + struct notifier_block vbus_nb; > + struct notifier_block host_nb; > + > + const struct dwc3_acpi_pdata *acpi_pdata; > + > + enum usb_dr_mode mode; > + bool is_suspended; > + bool pm_suspended; > + struct icc_path *icc_path_ddr; > + struct icc_path *icc_path_apps; > + const struct dwc3_qcom_of_match_data *data; Please don't adjust indentation of unrelated code, it makes it hard to see what actually changed. > +}; > + > +static const struct dwc3_qcom_of_match_data qcom_dwc3 = { > + .num_ports = 1, > +}; > > - const struct dwc3_acpi_pdata *acpi_pdata; > +static const struct dwc3_qcom_of_match_data sx8280xp_qcom_dwc3 = { > + .num_ports = 4, > +}; > > - enum usb_dr_mode mode; > - bool is_suspended; > - bool pm_suspended; > - struct icc_path *icc_path_ddr; > - struct icc_path *icc_path_apps; > +/* > + * Driver needs to read HS/DP_HS/DM_HS/SS IRQ's. Currently, for > + * SA8295 which supports mutliport, thre are 4 DP/ 4 DM/ 2 SS IRQ's > + * and 1 HS IRQ present. So avoid trying to read HS_PHY_IRQ for 4 > + * ports of SA8295. > + */ The last part here is relevant information, but it doesn't seem to relate to this define. Also, does all platforms have this configuration of interrupts? > +#define MAX_PHY_IRQ 4 > + > +enum dwc3_qcom_phy_irq_identifier { > + HS_PHY_IRQ = 0, > + DP_HS_PHY_IRQ, > + DM_HS_PHY_IRQ, > + SS_PHY_IRQ, > }; This enum is unused. > [..] > +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) > +{ > + int acpi_index = -1; > + > + if (!pdata) > + return -1; > + > + if (irq_index == DP_HS_PHY_IRQ) > + acpi_index = pdata->dp_hs_phy_irq_index; > + else if (irq_index == DM_HS_PHY_IRQ) > + acpi_index = pdata->dm_hs_phy_irq_index; > + else if (irq_index == SS_PHY_IRQ) > + acpi_index = pdata->ss_phy_irq_index; It looks favourable to put these in an array, instead of having to pull them out of 4 different variables conditionally. > + > + return acpi_index; > +} > + > +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) > +{ > + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); > + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; > + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; > + char *disp_name; > + int acpi_index; > + char *dt_name; > + int ret; > + int irq; > + int i; > + > + /* > + * We need to read only DP/DM/SS IRQ's here. > + * So loop over from 1->3 and accordingly modify respective phy_irq[]. > + */ > + for (i = 1; i < MAX_PHY_IRQ; i++) { > + > + if (!is_mp_supported && (port_index == 0)) { > + if (i == DP_HS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "dp_hs_phy_irq"); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 DP_HS"); > + } else if (i == DM_HS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "dm_hs_phy_irq"); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 DM_HS"); > + } else if (i == SS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "ss_phy_irq"); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 SS"); > + } > + } else { > + if (i == DP_HS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "dp_hs_phy_%d", port_index + 1); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 DP_HS%d", port_index + 1); > + } else if (i == DM_HS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "dm_hs_phy_%d", port_index + 1); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 DM_HS%d", port_index + 1); > + } else if (i == SS_PHY_IRQ) { > + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "ss_phy_%d", port_index + 1); > + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, > + "qcom_dwc3 SS%d", port_index + 1); > + } There is too much repetition in this for my liking. > } > - qcom->hs_phy_irq = irq; > - } > > - irq = dwc3_qcom_get_irq(pdev, "dp_hs_phy_irq", > - pdata ? pdata->dp_hs_phy_irq_index : -1); > - if (irq > 0) { > - irq_set_status_flags(irq, IRQ_NOAUTOEN); > - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, > - qcom_dwc3_resume_irq, > - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, > - "qcom_dwc3 DP_HS", qcom); > - if (ret) { > - dev_err(qcom->dev, "dp_hs_phy_irq failed: %d\n", ret); > - return ret; > + if (!dt_name || !disp_name) > + return -ENOMEM; > + > + acpi_index = !is_mp_supported ? dwc3_get_acpi_index(pdata, i) : -1; > + > + irq = dwc3_qcom_get_irq(pdev, dt_name, acpi_index); > + if (irq > 0) { > + ret = dwc3_qcom_prep_irq(qcom, dt_name, disp_name, irq); > + if (ret) > + return ret; > + > + if (i == DP_HS_PHY_IRQ) > + qcom->dp_hs_phy_irq[port_index] = irq; > + else if (i == DM_HS_PHY_IRQ) > + qcom->dm_hs_phy_irq[port_index] = irq; > + else if (i == SS_PHY_IRQ) > + qcom->ss_phy_irq[port_index] = irq; > } > - qcom->dp_hs_phy_irq = irq; > } > > - irq = dwc3_qcom_get_irq(pdev, "dm_hs_phy_irq", > - pdata ? pdata->dm_hs_phy_irq_index : -1); > + return 0; > +} > + > +static int dwc3_qcom_setup_irq(struct platform_device *pdev) > +{ > + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); > + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; > + int irq; > + int ret; > + int i; > + > + irq = dwc3_qcom_get_irq(pdev, "hs_phy_irq", > + pdata ? pdata->hs_phy_irq_index : -1); > if (irq > 0) { > - irq_set_status_flags(irq, IRQ_NOAUTOEN); > - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, > - qcom_dwc3_resume_irq, > - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, > - "qcom_dwc3 DM_HS", qcom); > - if (ret) { > - dev_err(qcom->dev, "dm_hs_phy_irq failed: %d\n", ret); > + ret = dwc3_qcom_prep_irq(qcom, "hs_phy_irq", "qcom_dwc3 HS",irq); > + if (ret) It would be nice to have this refactored out in a separate commit. > return ret; > - } > - qcom->dm_hs_phy_irq = irq; > + qcom->hs_phy_irq = irq; > } > > - irq = dwc3_qcom_get_irq(pdev, "ss_phy_irq", > - pdata ? pdata->ss_phy_irq_index : -1); > - if (irq > 0) { > - irq_set_status_flags(irq, IRQ_NOAUTOEN); > - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, > - qcom_dwc3_resume_irq, > - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, > - "qcom_dwc3 SS", qcom); > - if (ret) { > - dev_err(qcom->dev, "ss_phy_irq failed: %d\n", ret); > + for (i = 0; i < qcom->data->num_ports; i++) { > + ret = dwc3_get_port_irq(pdev, i); > + if (ret) > return ret; > - } > - qcom->ss_phy_irq = irq; > } > > return 0; > @@ -811,6 +905,8 @@ static int dwc3_qcom_probe(struct platform_device *pdev) > platform_set_drvdata(pdev, qcom); > qcom->dev = &pdev->dev; > > + qcom->data = of_device_get_match_data(qcom->dev); > + > if (has_acpi_companion(dev)) { > qcom->acpi_pdata = acpi_device_get_match_data(dev); > if (!qcom->acpi_pdata) { > @@ -1023,8 +1119,15 @@ static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = { > }; > > static const struct of_device_id dwc3_qcom_of_match[] = { > - { .compatible = "qcom,dwc3" }, > - { } > + { > + .compatible = "qcom,dwc3", > + .data = &qcom_dwc3, > + }, > + { > + .compatible = "qcom,sc8280xp-dwc3-mp", > + .data = &sx8280xp_qcom_dwc3, > + }, I would prefer that we don't add a separate compatible, but rather just try to parse the interrupts for multiport and fall back to single port. If/when we figure out how to peak into the dwc3 core, we could potentially introduce a check to aid the developer. Regards, Bjorn > + { }, > }; > MODULE_DEVICE_TABLE(of, dwc3_qcom_of_match); > > -- > 2.40.0 >
On 8/6/2023 10:41 AM, Bjorn Andersson wrote: > On Fri, Jul 28, 2023 at 04:03:02AM +0530, Krishna Kurapati wrote: >> Refactor setup_irq call to facilitate reading multiport IRQ's along >> with non mulitport ones. For SA8295, there are 4-DP/4-DM and 2-SS >> IRQ's. Check whether device is multiport capable or not and read all >> interrupts for DP/DM/SS on each port accordingly. >> +/* >> + * Driver needs to read HS/DP_HS/DM_HS/SS IRQ's. Currently, for >> + * SA8295 which supports mutliport, thre are 4 DP/ 4 DM/ 2 SS IRQ's >> + * and 1 HS IRQ present. So avoid trying to read HS_PHY_IRQ for 4 >> + * ports of SA8295. >> + */ > > The last part here is relevant information, but it doesn't seem to > relate to this define. > > Also, does all platforms have this configuration of interrupts? > Hi Bjorn, Yes, all targets have the same IRQ's. Just that MP one's have multiple IRQ's of each type. But hs-phy_irq is only one in SC8280 as well. >> +#define MAX_PHY_IRQ 4 >> + >> +enum dwc3_qcom_phy_irq_identifier { >> + HS_PHY_IRQ = 0, >> + DP_HS_PHY_IRQ, >> + DM_HS_PHY_IRQ, >> + SS_PHY_IRQ, >> }; > > This enum is unused. > >> > [..] >> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) >> +{ >> + int acpi_index = -1; >> + >> + if (!pdata) >> + return -1; >> + >> + if (irq_index == DP_HS_PHY_IRQ) >> + acpi_index = pdata->dp_hs_phy_irq_index; >> + else if (irq_index == DM_HS_PHY_IRQ) >> + acpi_index = pdata->dm_hs_phy_irq_index; >> + else if (irq_index == SS_PHY_IRQ) >> + acpi_index = pdata->ss_phy_irq_index; > > It looks favourable to put these in an array, instead of having to pull > them out of 4 different variables conditionally. > Sure, will move them to an array to remove this if-else stuff. >> + >> + return acpi_index; >> + } else { >> + if (i == DP_HS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "dp_hs_phy_%d", port_index + 1); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 DP_HS%d", port_index + 1); >> + } else if (i == DM_HS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "dm_hs_phy_%d", port_index + 1); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 DM_HS%d", port_index + 1); >> + } else if (i == SS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "ss_phy_%d", port_index + 1); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 SS%d", port_index + 1); >> + } > > There is too much repetition in this for my liking. Will try to put dp/dm/ss too in an array in dwc3_qcom structure and merge these 3 loops into '1'. But that would mean I need to add a global structure to avoid adding if else statements to do proper kasprintf stuff. If its fine to add a global array with all names and use them here, then it would be easy to merge the loops into one for loop. But if we are not supposed to add global array of names, then I would keep these 3 repetitive code blocks as is. > >> } >> - qcom->hs_phy_irq = irq; >> - } >> >> - irq = dwc3_qcom_get_irq(pdev, "dp_hs_phy_irq", >> - pdata ? pdata->dp_hs_phy_irq_index : -1); >> - if (irq > 0) { >> - irq_set_status_flags(irq, IRQ_NOAUTOEN); >> - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, >> - qcom_dwc3_resume_irq, >> - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, >> - "qcom_dwc3 DP_HS", qcom); >> - if (ret) { >> - dev_err(qcom->dev, "dp_hs_phy_irq failed: %d\n", ret); >> - return ret; >> + if (!dt_name || !disp_name) >> + return -ENOMEM; >> + >> + acpi_index = !is_mp_supported ? dwc3_get_acpi_index(pdata, i) : -1; >> + >> + irq = dwc3_qcom_get_irq(pdev, dt_name, acpi_index); >> + if (irq > 0) { >> + ret = dwc3_qcom_prep_irq(qcom, dt_name, disp_name, irq); >> + if (ret) >> + return ret; >> + >> + if (i == DP_HS_PHY_IRQ) >> + qcom->dp_hs_phy_irq[port_index] = irq; >> + else if (i == DM_HS_PHY_IRQ) >> + qcom->dm_hs_phy_irq[port_index] = irq; >> + else if (i == SS_PHY_IRQ) >> + qcom->ss_phy_irq[port_index] = irq; >> } >> - qcom->dp_hs_phy_irq = irq; >> } >> >> - irq = dwc3_qcom_get_irq(pdev, "dm_hs_phy_irq", >> - pdata ? pdata->dm_hs_phy_irq_index : -1); >> + return 0; >> +} >> + >> +static int dwc3_qcom_setup_irq(struct platform_device *pdev) >> +{ >> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >> + int irq; >> + int ret; >> + int i; >> + >> + irq = dwc3_qcom_get_irq(pdev, "hs_phy_irq", >> + pdata ? pdata->hs_phy_irq_index : -1); >> if (irq > 0) { >> - irq_set_status_flags(irq, IRQ_NOAUTOEN); >> - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, >> - qcom_dwc3_resume_irq, >> - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, >> - "qcom_dwc3 DM_HS", qcom); >> - if (ret) { >> - dev_err(qcom->dev, "dm_hs_phy_irq failed: %d\n", ret); >> + ret = dwc3_qcom_prep_irq(qcom, "hs_phy_irq", "qcom_dwc3 HS",irq); >> + if (ret) > > It would be nice to have this refactored out in a separate commit. > Sure, will add the prep irq in a seperate commit before we read the MP IRQ's. >> return ret; >> - } >> - qcom->dm_hs_phy_irq = irq; >> + qcom->hs_phy_irq = irq; >> } >> >> - irq = dwc3_qcom_get_irq(pdev, "ss_phy_irq", >> - pdata ? pdata->ss_phy_irq_index : -1); >> - if (irq > 0) { >> - irq_set_status_flags(irq, IRQ_NOAUTOEN); >> - ret = devm_request_threaded_irq(qcom->dev, irq, NULL, >> - qcom_dwc3_resume_irq, >> - IRQF_TRIGGER_HIGH | IRQF_ONESHOT, >> - "qcom_dwc3 SS", qcom); >> - if (ret) { >> - dev_err(qcom->dev, "ss_phy_irq failed: %d\n", ret); >> + for (i = 0; i < qcom->data->num_ports; i++) { >> + ret = dwc3_get_port_irq(pdev, i); >> + if (ret) >> return ret; >> - } >> - qcom->ss_phy_irq = irq; >> } >> >> return 0; >> @@ -811,6 +905,8 @@ static int dwc3_qcom_probe(struct platform_device *pdev) >> platform_set_drvdata(pdev, qcom); >> qcom->dev = &pdev->dev; >> >> + qcom->data = of_device_get_match_data(qcom->dev); >> + >> if (has_acpi_companion(dev)) { >> qcom->acpi_pdata = acpi_device_get_match_data(dev); >> if (!qcom->acpi_pdata) { >> @@ -1023,8 +1119,15 @@ static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = { >> }; >> >> static const struct of_device_id dwc3_qcom_of_match[] = { >> - { .compatible = "qcom,dwc3" }, >> - { } >> + { >> + .compatible = "qcom,dwc3", >> + .data = &qcom_dwc3, >> + }, >> + { >> + .compatible = "qcom,sc8280xp-dwc3-mp", >> + .data = &sx8280xp_qcom_dwc3, >> + }, > > I would prefer that we don't add a separate compatible, but rather just > try to parse the interrupts for multiport and fall back to single port. > > If/when we figure out how to peak into the dwc3 core, we could > potentially introduce a check to aid the developer. > Only reason I chose this path is it is unabiguous. With this path, we don't need to worry about whether the user skipped any irq's in the DT or not. If we rely on the IRQ parsing from DT, then we might need to calculate effective port count while parsing the irq loop making it ambigous and prone to error I believe. I would like to keep this compatible as it and use this in the file wherever needed. And since peeking into dwc3-core before we call of_platform_populate is not possible and we need port_count, I kept a compatible here. I could move the setup_irq call to after completion of of_platform_populate, but still there is risk of dwc3 probe getting deferred or failing and we end up not being able to peek into dwc3. Request you to reconsider and accept adding a compatible here. Regards, Krishna,
+ >> +enum dwc3_qcom_phy_irq_identifier { >> + HS_PHY_IRQ = 0, >> + DP_HS_PHY_IRQ, >> + DM_HS_PHY_IRQ, >> + SS_PHY_IRQ, >> }; > > This enum is unused. > Hi Bjorn, I didn't use the enum directly, but used its members in the get_port_irq call below. > [..] >> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) >> +{ >> + int acpi_index = -1; >> + >> + if (!pdata) >> + return -1; >> + >> + if (irq_index == DP_HS_PHY_IRQ) >> + acpi_index = pdata->dp_hs_phy_irq_index; >> + else if (irq_index == DM_HS_PHY_IRQ) >> + acpi_index = pdata->dm_hs_phy_irq_index; >> + else if (irq_index == SS_PHY_IRQ) >> + acpi_index = pdata->ss_phy_irq_index; > > It looks favourable to put these in an array, instead of having to pull > them out of 4 different variables conditionally. > >> + >> + return acpi_index; >> +} >> + >> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >> +{ >> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >> + char *disp_name; >> + int acpi_index; >> + char *dt_name; >> + int ret; >> + int irq; >> + int i; >> + >> + /* >> + * We need to read only DP/DM/SS IRQ's here. >> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >> + */ >> + for (i = 1; i < MAX_PHY_IRQ; i++) { >> + >> + if (!is_mp_supported && (port_index == 0)) { >> + if (i == DP_HS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "dp_hs_phy_irq"); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 DP_HS"); >> + } else if (i == DM_HS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "dm_hs_phy_irq"); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 DM_HS"); >> + } else if (i == SS_PHY_IRQ) { >> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "ss_phy_irq"); >> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >> + "qcom_dwc3 SS"); Bjorn, Konrad, If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. Please let me know your thoughts on this. Regards, Krishna,
On 8.08.2023 10:32, Krishna Kurapati PSSNV wrote: > + >>> +enum dwc3_qcom_phy_irq_identifier { >>> + HS_PHY_IRQ = 0, >>> + DP_HS_PHY_IRQ, >>> + DM_HS_PHY_IRQ, >>> + SS_PHY_IRQ, >>> }; >> >> This enum is unused. >> > > Hi Bjorn, > > I didn't use the enum directly, but used its members in the get_port_irq call below. > >> [..] >>> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) >>> +{ >>> + int acpi_index = -1; >>> + >>> + if (!pdata) >>> + return -1; >>> + >>> + if (irq_index == DP_HS_PHY_IRQ) >>> + acpi_index = pdata->dp_hs_phy_irq_index; >>> + else if (irq_index == DM_HS_PHY_IRQ) >>> + acpi_index = pdata->dm_hs_phy_irq_index; >>> + else if (irq_index == SS_PHY_IRQ) >>> + acpi_index = pdata->ss_phy_irq_index; >> >> It looks favourable to put these in an array, instead of having to pull >> them out of 4 different variables conditionally. >> >>> + >>> + return acpi_index; >>> +} >>> + >>> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >>> +{ >>> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >>> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >>> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >>> + char *disp_name; >>> + int acpi_index; >>> + char *dt_name; >>> + int ret; >>> + int irq; >>> + int i; >>> + >>> + /* >>> + * We need to read only DP/DM/SS IRQ's here. >>> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >>> + */ >>> + for (i = 1; i < MAX_PHY_IRQ; i++) { >>> + >>> + if (!is_mp_supported && (port_index == 0)) { >>> + if (i == DP_HS_PHY_IRQ) { >>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "dp_hs_phy_irq"); >>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "qcom_dwc3 DP_HS"); >>> + } else if (i == DM_HS_PHY_IRQ) { >>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "dm_hs_phy_irq"); >>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "qcom_dwc3 DM_HS"); >>> + } else if (i == SS_PHY_IRQ) { >>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "ss_phy_irq"); >>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>> + "qcom_dwc3 SS"); > Bjorn, Konrad, > > If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. > > Please let me know your thoughts on this. Can we not just reuse the associated interrupt-names from the devicetree if present? Konrad
On 8/8/2023 5:20 PM, Konrad Dybcio wrote: > On 8.08.2023 10:32, Krishna Kurapati PSSNV wrote: >> + >>>> +enum dwc3_qcom_phy_irq_identifier { >>>> + HS_PHY_IRQ = 0, >>>> + DP_HS_PHY_IRQ, >>>> + DM_HS_PHY_IRQ, >>>> + SS_PHY_IRQ, >>>> }; >>> >>> This enum is unused. >>> >> >> Hi Bjorn, >> >> I didn't use the enum directly, but used its members in the get_port_irq call below. >> >>> [..] >>>> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) >>>> +{ >>>> + int acpi_index = -1; >>>> + >>>> + if (!pdata) >>>> + return -1; >>>> + >>>> + if (irq_index == DP_HS_PHY_IRQ) >>>> + acpi_index = pdata->dp_hs_phy_irq_index; >>>> + else if (irq_index == DM_HS_PHY_IRQ) >>>> + acpi_index = pdata->dm_hs_phy_irq_index; >>>> + else if (irq_index == SS_PHY_IRQ) >>>> + acpi_index = pdata->ss_phy_irq_index; >>> >>> It looks favourable to put these in an array, instead of having to pull >>> them out of 4 different variables conditionally. >>> >>>> + >>>> + return acpi_index; >>>> +} >>>> + >>>> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >>>> +{ >>>> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >>>> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >>>> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >>>> + char *disp_name; >>>> + int acpi_index; >>>> + char *dt_name; >>>> + int ret; >>>> + int irq; >>>> + int i; >>>> + >>>> + /* >>>> + * We need to read only DP/DM/SS IRQ's here. >>>> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >>>> + */ >>>> + for (i = 1; i < MAX_PHY_IRQ; i++) { >>>> + >>>> + if (!is_mp_supported && (port_index == 0)) { >>>> + if (i == DP_HS_PHY_IRQ) { >>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "dp_hs_phy_irq"); >>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "qcom_dwc3 DP_HS"); >>>> + } else if (i == DM_HS_PHY_IRQ) { >>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "dm_hs_phy_irq"); >>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "qcom_dwc3 DM_HS"); >>>> + } else if (i == SS_PHY_IRQ) { >>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "ss_phy_irq"); >>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>> + "qcom_dwc3 SS"); >> Bjorn, Konrad, >> >> If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. >> >> Please let me know your thoughts on this. > Can we not just reuse the associated interrupt-names from the devicetree > if present? > Hi Konrad, Thanks for the comments but one more confirmation. We can read the interrupts from DT but I believe the compatible would still need to stay. We need the num_ports information not just for registering interrupts but for modifying the pwr_event_irq registers during suspend/resume. If we rely on the interrupts to find the number of ports, the user is free to remove any IRQ and we might end up in a situation where glue and core are not having same view of how many number of ports present. So I believe its best to keep the compatible and get num_ports info from there and rely on reading interrupt-names to get interrupts cleanly. Can you let me know your view on the same. Regards, Krishna,
On 9.08.2023 08:06, Krishna Kurapati PSSNV wrote: > > > On 8/8/2023 5:20 PM, Konrad Dybcio wrote: >> On 8.08.2023 10:32, Krishna Kurapati PSSNV wrote: >>> + >>>>> +enum dwc3_qcom_phy_irq_identifier { >>>>> + HS_PHY_IRQ = 0, >>>>> + DP_HS_PHY_IRQ, >>>>> + DM_HS_PHY_IRQ, >>>>> + SS_PHY_IRQ, >>>>> }; >>>> >>>> This enum is unused. >>>> >>> >>> Hi Bjorn, >>> >>> I didn't use the enum directly, but used its members in the get_port_irq call below. >>> >>>> [..] >>>>> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index) >>>>> +{ >>>>> + int acpi_index = -1; >>>>> + >>>>> + if (!pdata) >>>>> + return -1; >>>>> + >>>>> + if (irq_index == DP_HS_PHY_IRQ) >>>>> + acpi_index = pdata->dp_hs_phy_irq_index; >>>>> + else if (irq_index == DM_HS_PHY_IRQ) >>>>> + acpi_index = pdata->dm_hs_phy_irq_index; >>>>> + else if (irq_index == SS_PHY_IRQ) >>>>> + acpi_index = pdata->ss_phy_irq_index; >>>> >>>> It looks favourable to put these in an array, instead of having to pull >>>> them out of 4 different variables conditionally. >>>> >>>>> + >>>>> + return acpi_index; >>>>> +} >>>>> + >>>>> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >>>>> +{ >>>>> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >>>>> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >>>>> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >>>>> + char *disp_name; >>>>> + int acpi_index; >>>>> + char *dt_name; >>>>> + int ret; >>>>> + int irq; >>>>> + int i; >>>>> + >>>>> + /* >>>>> + * We need to read only DP/DM/SS IRQ's here. >>>>> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >>>>> + */ >>>>> + for (i = 1; i < MAX_PHY_IRQ; i++) { >>>>> + >>>>> + if (!is_mp_supported && (port_index == 0)) { >>>>> + if (i == DP_HS_PHY_IRQ) { >>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "dp_hs_phy_irq"); >>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "qcom_dwc3 DP_HS"); >>>>> + } else if (i == DM_HS_PHY_IRQ) { >>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "dm_hs_phy_irq"); >>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "qcom_dwc3 DM_HS"); >>>>> + } else if (i == SS_PHY_IRQ) { >>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "ss_phy_irq"); >>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>> + "qcom_dwc3 SS"); >>> Bjorn, Konrad, >>> >>> If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. >>> >>> Please let me know your thoughts on this. >> Can we not just reuse the associated interrupt-names from the devicetree >> if present? >> > Hi Konrad, > > Thanks for the comments but one more confirmation. > We can read the interrupts from DT but I believe the compatible would still need to stay. We need the num_ports information not just for registering interrupts but for modifying the pwr_event_irq registers during suspend/resume. If we rely on the interrupts to find the number of ports, the user is free to remove any IRQ and we might end up in a situation where glue and core are not having same view of how many number of ports present. So I believe its best to keep the compatible and get num_ports info from there and rely on reading interrupt-names to get interrupts cleanly. Can you let me know your view on the same. So is "is it okay to add SoC-specific compatibles and add the port number in match data" what you're asking? If so, that doesn't seem right. The user should not "feel free to remove any IRQ", modifying the devicetree to depict a subset of the hardware is not something we want to support. The driver has to work with the "full" description in accordance with the bindings. Konrad
On 8/11/2023 10:35 PM, Konrad Dybcio wrote: >>>>>> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >>>>>> +{ >>>>>> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >>>>>> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >>>>>> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >>>>>> + char *disp_name; >>>>>> + int acpi_index; >>>>>> + char *dt_name; >>>>>> + int ret; >>>>>> + int irq; >>>>>> + int i; >>>>>> + >>>>>> + /* >>>>>> + * We need to read only DP/DM/SS IRQ's here. >>>>>> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >>>>>> + */ >>>>>> + for (i = 1; i < MAX_PHY_IRQ; i++) { >>>>>> + >>>>>> + if (!is_mp_supported && (port_index == 0)) { >>>>>> + if (i == DP_HS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "dp_hs_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 DP_HS"); >>>>>> + } else if (i == DM_HS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "dm_hs_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 DM_HS"); >>>>>> + } else if (i == SS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "ss_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 SS"); >>>> Bjorn, Konrad, >>>> >>>> If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. >>>> >>>> Please let me know your thoughts on this. >>> Can we not just reuse the associated interrupt-names from the devicetree >>> if present? >>> >> Hi Konrad, >> >> Thanks for the comments but one more confirmation. >> We can read the interrupts from DT but I believe the compatible would still need to stay. We need the num_ports information not just for registering interrupts but for modifying the pwr_event_irq registers during suspend/resume. If we rely on the interrupts to find the number of ports, the user is free to remove any IRQ and we might end up in a situation where glue and core are not having same view of how many number of ports present. So I believe its best to keep the compatible and get num_ports info from there and rely on reading interrupt-names to get interrupts cleanly. Can you let me know your view on the same. > So is "is it okay to add SoC-specific compatibles and add the port number in > match data" what you're asking? > > If so, that doesn't seem right. > > The user should not "feel free to remove any IRQ", modifying the devicetree to > depict a subset of the hardware is not something we want to support. The driver > has to work with the "full" description in accordance with the bindings. > Hi Konrad, Thanks for the review. While I agree with you that we must not skip any hw specifics in DT, there is nothing stopping the user from doing so right ? And whatever be the case, we must be a fool-proof and fail safe system able to handle all such situations. While we can read interrupt IRQ prefixes to get port count in one way or other, adding a compatible would be the least ambiguous path. Is there any other concern you see in adding a compatible ? I might be missing something because even Bjorn's suggestion too was to try and avoid a new compatible addition and to add it only if we have no other way of reliably reading the port count (which I believe would be an issue if we need to rely on interrupt name reading). Regards, Krishna,
On 8/11/2023 10:35 PM, Konrad Dybcio wrote: >>>>>> + >>>>>> +static int dwc3_get_port_irq(struct platform_device *pdev, u8 port_index) >>>>>> +{ >>>>>> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev); >>>>>> + bool is_mp_supported = (qcom->data->num_ports > 1) ? true : false; >>>>>> + const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata; >>>>>> + char *disp_name; >>>>>> + int acpi_index; >>>>>> + char *dt_name; >>>>>> + int ret; >>>>>> + int irq; >>>>>> + int i; >>>>>> + >>>>>> + /* >>>>>> + * We need to read only DP/DM/SS IRQ's here. >>>>>> + * So loop over from 1->3 and accordingly modify respective phy_irq[]. >>>>>> + */ >>>>>> + for (i = 1; i < MAX_PHY_IRQ; i++) { >>>>>> + >>>>>> + if (!is_mp_supported && (port_index == 0)) { >>>>>> + if (i == DP_HS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "dp_hs_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 DP_HS"); >>>>>> + } else if (i == DM_HS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "dm_hs_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 DM_HS"); >>>>>> + } else if (i == SS_PHY_IRQ) { >>>>>> + dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "ss_phy_irq"); >>>>>> + disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL, >>>>>> + "qcom_dwc3 SS"); >>>> Bjorn, Konrad, >>>> >>>> If we are to remove this repetitive loops, we might need to make a 2D array for all of Dp/Dm/Ss interrutps and make a global array of names to be used for irq lookup and use them to reduce the if-else-if stuff here. If that is fine, I can make those changes, else I would like to stick to this approach for now because if we don't add the global array of names, prepping them seperately for dp/dm/ss would again lead us to making if-else loops like above. >>>> >>>> Please let me know your thoughts on this. >>> Can we not just reuse the associated interrupt-names from the devicetree >>> if present? >>> >> Hi Konrad, >> >> Thanks for the comments but one more confirmation. >> We can read the interrupts from DT but I believe the compatible would still need to stay. We need the num_ports information not just for registering interrupts but for modifying the pwr_event_irq registers during suspend/resume. If we rely on the interrupts to find the number of ports, the user is free to remove any IRQ and we might end up in a situation where glue and core are not having same view of how many number of ports present. So I believe its best to keep the compatible and get num_ports info from there and rely on reading interrupt-names to get interrupts cleanly. Can you let me know your view on the same. > So is "is it okay to add SoC-specific compatibles and add the port number in > match data" what you're asking? > > If so, that doesn't seem right. > > The user should not "feel free to remove any IRQ", modifying the devicetree to > depict a subset of the hardware is not something we want to support. The driver > has to work with the "full" description in accordance with the bindings. > Hi Konrad, Johan, Thanks for the suggestions / review comments and taking the time out for reviewing them. Pushed v11 implementing the above suggestion of identifying port_count by reading through the interrupt-names. Please help let know your review on the same. Regards, Krishna,
Currently the DWC3 driver supports only single port controller which requires at most two PHYs ie HS and SS PHYs. There are SoCs that has DWC3 controller with multiple ports that can operate in host mode. Some of the port supports both SS+HS and other port supports only HS mode. This change primarily refactors the Phy logic in core driver to allow multiport support with Generic Phy's. Changes have been tested on QCOM SoC SA8295P which has 4 ports (2 are HS+SS capable and 2 are HS only capable). Changes in v10: Refactored phy init/exit/power-on/off functions in dwc3 core Refactored dwc3-qcom irq registration and handling Implemented wakeup for multiport irq's Moved few macros from xhci.h to xhci-ext-caps.h Fixed nits pointed out in v9 Fixed Co-developed by and SOB tags in patches 5 and 11 Changes in v9: Added IRQ support for DP/DM/SS MP Irq's of SC8280 Refactored code to read port count by accessing xhci registers Changes in v8: Reorganised code in patch-5 Fixed nitpicks in code according to comments received on v7 Fixed indentation in DT patches Added drive strength for pinctrl nodes in SA8295 DT Changes in v7: Added power event irq's for Multiport controller. Udpated commit text for patch-9 (adding DT changes for enabling first port of multiport controller on sa8540-ride). Fixed check-patch warnings for driver code. Fixed DT binding errors for changes in snps,dwc3.yaml Reabsed code on top of usb-next Changes in v6: Updated comments in code after. Updated variables names appropriately as per review comments. Updated commit text in patch-2 and added additional info as per review comments. The patch header in v5 doesn't have "PATHCH v5" notation present. Corrected it in this version. Changes in v5: Added DT support for first port of Teritiary USB controller on SA8540-Ride Added support for reading port info from XHCI Extended Params registers. Changes in RFC v4: Added DT support for SA8295p. Changes in RFC v3: Incase any PHY init fails, then clear/exit the PHYs that are already initialized. Changes in RFC v2: Changed dwc3_count_phys to return the number of PHY Phandles in the node. This will be used now in dwc3_extract_num_phys to increment num_usb2_phy and num_usb3_phy. Added new parameter "ss_idx" in dwc3_core_get_phy_ny_node and changed its structure such that the first half is for HS-PHY and second half is for SS-PHY. In dwc3_core_get_phy, for multiport controller, only if SS-PHY phandle is present, pass proper SS_IDX else pass -1. Tests done on v10: Enumeration: / # lsusb Bus 003 Device 001: ID 1d6b:0002 Bus 001 Device 001: ID 1d6b:0002 Bus 001 Device 002: ID 045e:0040 Bus 004 Device 001: ID 1d6b:0003 Bus 002 Device 001: ID 1d6b:0003 Bus 001 Device 003: ID 17ef:60d1 Interrupt registration: / # cat /proc/interrupts | grep dwc 184: 0 0 0 0 0 0 0 0 PDC 127 Level qcom_dwc3 DP_HS1 185: 0 0 0 0 0 0 0 0 PDC 126 Level qcom_dwc3 DM_HS1 186: 0 0 0 0 0 0 0 0 PDC 16 Level qcom_dwc3 SS1 187: 0 0 0 0 0 0 0 0 PDC 129 Level qcom_dwc3 DP_HS2 188: 0 0 0 0 0 0 0 0 PDC 128 Level qcom_dwc3 DM_HS2 189: 0 0 0 0 0 0 0 0 PDC 17 Level qcom_dwc3 SS2 190: 0 0 0 0 0 0 0 0 PDC 131 Level qcom_dwc3 DP_HS3 191: 0 0 0 0 0 0 0 0 PDC 130 Level qcom_dwc3 DM_HS3 192: 0 0 0 0 0 0 0 0 PDC 133 Level qcom_dwc3 DP_HS4 193: 0 0 0 0 0 0 0 0 PDC 132 Level qcom_dwc3 DM_HS4 195: 0 0 0 0 0 0 0 0 PDC 14 Level qcom_dwc3 DP_HS 196: 0 0 0 0 0 0 0 0 PDC 15 Level qcom_dwc3 DM_HS 197: 0 0 0 0 0 0 0 0 PDC 138 Level qcom_dwc3 SS 198: 32 0 0 0 0 0 0 0 GICv3 835 Leel dwc3 199: 0 0 0 0 0 0 0 0 PDC 12 Level qcom_dwc3 DP_HS 200: 0 0 0 0 0 0 0 0 PDC 13 Level qcom_dwc3 DM_HS 201: 0 0 0 0 0 0 0 0 PDC 136 Level qcom_dwc3 SS Interrupt connfiguration during suspend entry and suspend exit upon device connect. Speed here in the following log indicates enum usb_device_speed in dwc3-qcom. [ 151.625326] K: dwc3_qcom_enable_interrupts index: 0 speed: 0 [ 151.680985] K: dwc3_qcom_enable_interrupts index: 0 speed: 2 [ 151.686841] K: dwc3_qcom_enable_interrupts index: 1 speed: 2 [ 151.692665] K: dwc3_qcom_enable_interrupts index: 2 speed: 0 [ 151.692678] K: dwc3_qcom_enable_interrupts index: 3 speed: 0 [ 151.724912] K: dwc3_qcom_disable_interrupts index: 0 speed: 2 [ 151.730832] K: dwc3_qcom_disable_interrupts index: 1 speed: 2 [ 151.736740] K: dwc3_qcom_disable_interrupts index: 2 speed: 0 [ 151.742646] K: dwc3_qcom_disable_interrupts index: 3 speed: 0 [ 152.010699] K: dwc3_qcom_disable_interrupts index: 0 speed: 0 [ 152.107836] OOM killer enabled. [ 152.111070] Restarting tasks ... done. [ 152.115742] random: crng reseeded on system resumption [ 152.121298] PM: suspend exit / # [ 152.240015] usb 1-3: new low-speed USB device number 8 using xhci-hcd On SC7280 CRD Herobrine variant, enumeration and wakeup was tested and it works fine: Enumeration: localhost ~ # lsusb Bus 002 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. USB 10/100/1000 LAN Bus 002 Device 003: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. 4-Port USB 3.1 Hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 024: ID 046d:c06a Logitech, Inc. USB Optical Mouse Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. 4-Port USB 2.1 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub localhost ~ # dmesg | grep hub [ 3.713331] hub 1-0:1.0: USB hub found [ 3.717222] hub 1-0:1.0: 1 port detected [ 3.764330] hub 2-0:1.0: USB hub found [ 3.768216] hub 2-0:1.0: 1 port detected [ 4.159720] hub 1-1:1.0: USB hub found [ 4.165010] hub 1-1:1.0: 4 ports detected [ 4.322363] hub 2-1:1.0: USB hub found [ 4.327220] hub 2-1:1.0: 4 ports detected [ 5.504227] hub 2-1.4:1.0: USB hub found [ 5.508724] hub 2-1.4:1.0: 4 ports detected [ 7.263756] hub 1-1.4:1.0: USB hub found [ 7.268273] hub 1-1.4:1.0: 4 ports detected [ 10.030906] hub 1-1.4:1.0: USB hub found [ 10.035352] hub 1-1.4:1.0: 4 ports detected Interrupt registration on SC7280-CRD: localhost ~ # cat /proc/interrupts | grep dwc 82: 0 0 0 0 0 0 0 0 GICv3 163 Level qcom_dwc3 HS 211: 0 0 0 0 0 0 0 0 PDC 14 Level qcom_dwc3 DP_HS 212: 0 0 0 0 0 0 0 0 PDC 15 Level qcom_dwc3 DM_HS 213: 0 0 0 0 0 0 0 0 PDC 17 Level qcom_dwc3 SS Wakeup from system suspend upon mouse click: [ 1159.589739] K: dwc3_qcom_enable_interrupts port: 0 speed: 3 [ 1160.025300] K: qcom_dwc3_resume_irq irq: 211 [ 1160.149660] K: dwc3_qcom_disable_interrupts port: 0 speed: 3 [ 1161.649610] Resume caused by IRQ 211, qcom_dwc3 DP_HS Also DT Binding checks were done on both modified yaml files. Links to previous versions: Link to v9: https://lore.kernel.org/all/20230621043628.21485-1-quic_kriskura@quicinc.com/ Link to v8: https://lore.kernel.org/all/20230514054917.21318-1-quic_kriskura@quicinc.com/ Link to v7: https://lore.kernel.org/all/20230501143445.3851-1-quic_kriskura@quicinc.com/ Link to v6: https://lore.kernel.org/all/20230405125759.4201-1-quic_kriskura@quicinc.com/ Link to v5: https://lore.kernel.org/all/20230310163420.7582-1-quic_kriskura@quicinc.com/ Link to RFC v4: https://lore.kernel.org/all/20230115114146.12628-1-quic_kriskura@quicinc.com/ Link to RFC v3: https://lore.kernel.org/all/1654709787-23686-1-git-send-email-quic_harshq@quicinc.com/#r Link to RFC v2: https://lore.kernel.org/all/1653560029-6937-1-git-send-email-quic_harshq@quicinc.com/#r Andrew Halaney (1): arm64: dts: qcom: sa8540-ride: Enable first port of tertiary usb controller Harsh Agarwal (1): usb: dwc3: core: Refactor PHY logic to support Multiport Controller Krishna Kurapati (9): dt-bindings: usb: qcom,dwc3: Add bindings for SC8280 Multiport dt-bindings: usb: Add bindings for multiport properties on DWC3 controller usb: dwc3: core: Access XHCI address space temporarily to read port info usb: dwc3: core: Skip setting event buffers for host only controllers usb: dwc3: qcom: Refactor IRQ handling in QCOM Glue driver usb: dwc3: qcom: Enable wakeup for applicable ports of multiport usb: dwc3: qcom: Add multiport suspend/resume support for wrapper arm64: dts: qcom: sc8280xp: Add multiport controller node for SC8280 arm64: dts: qcom: sa8295p: Enable tertiary controller and its 4 USB ports .../devicetree/bindings/usb/qcom,dwc3.yaml | 29 ++ .../devicetree/bindings/usb/snps,dwc3.yaml | 13 +- arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 53 +++ arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 22 ++ arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 77 ++++ drivers/usb/dwc3/core.c | 326 ++++++++++++---- drivers/usb/dwc3/core.h | 16 +- drivers/usb/dwc3/drd.c | 15 +- drivers/usb/dwc3/dwc3-qcom.c | 358 ++++++++++++------ drivers/usb/host/xhci-ext-caps.h | 5 + drivers/usb/host/xhci.h | 3 - 11 files changed, 714 insertions(+), 203 deletions(-)