From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 12 May 2017 13:20:41 +0200 Subject: [U-Boot] [PATCH v5 05/14] usb: xhci: Add STi xhci support In-Reply-To: <8c5a79d1-9891-fcc9-98ca-b6d029ab63d3@st.com> References: <1494432599-17924-1-git-send-email-patrice.chotard@st.com> <1494432599-17924-6-git-send-email-patrice.chotard@st.com> <8a96c388-6305-4ff6-e617-ca6862eeef95@denx.de> <49b3122a-47ec-dda4-3bc5-dfda38c1d95e@denx.de> <8c5a79d1-9891-fcc9-98ca-b6d029ab63d3@st.com> Message-ID: <51ba412d-ecf0-4f9e-7e99-64a4899d58cf@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 05/12/2017 01:15 PM, Patrice CHOTARD wrote: > Hi Marek > > On 05/12/2017 12:54 PM, Marek Vasut wrote: >> On 05/12/2017 10:40 AM, Patrice CHOTARD wrote: >>> Hi Marek >>> >>> On 05/11/2017 01:54 PM, Marek Vasut wrote: >>>> On 05/11/2017 09:08 AM, Patrice CHOTARD wrote: >>>>> Hi Marek >>>>> >>>>> On 05/10/2017 11:16 PM, Marek Vasut wrote: >>>>>> On 05/10/2017 06:09 PM, patrice.chotard at st.com wrote: >>>>>>> From: Patrice Chotard >>>>>>> >>>>>>> Add support for on-chip DWC3 controller available >>>>>>> on STMicrolectronics STiH407 family SoCs. >>>>>>> On B2260 board, the type AB USB connector is managed >>>>>>> by a DWC3 IP. As USB3 signals are not wired, only USB2 >>>>>>> is supported. >>>>>>> >>>>>>> Signed-off-by: Patrice Chotard >>>>>>> --- >>>>>>> v5: _ none >>>>>>> >>>>>>> v4: _ update to use the new PHY uclass currently available on dm-next branch >>>>>>> >>>>>>> v3: _ update to use the new USB PHY uclass >>>>>>> _ previously, xhci-sti driver binded dwc3-sti (STi glue driver) which was not correct. >>>>>>> Now we respect the device tree hierarchy, ie the STi dwc3 glue driver is first probed, >>>>>>> then bind the xhci-sti driver. >>>>>>> >>>>>>> v2: _ none >>>>>>> >>>>>>> drivers/usb/host/Kconfig | 8 +++ >>>>>>> drivers/usb/host/Makefile | 1 + >>>>>>> drivers/usb/host/xhci-sti.c | 128 ++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> 3 files changed, 137 insertions(+) >>>>>>> create mode 100644 drivers/usb/host/xhci-sti.c >>>>>>> >>>>>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig >>>>>>> index 0bf8274..bf12ba7 100644 >>>>>>> --- a/drivers/usb/host/Kconfig >>>>>>> +++ b/drivers/usb/host/Kconfig >>>>>>> @@ -38,6 +38,14 @@ config USB_XHCI_ROCKCHIP >>>>>>> help >>>>>>> Enables support for the on-chip xHCI controller on Rockchip SoCs. >>>>>>> >>>>>>> +config USB_XHCI_STI >>>>>>> + bool "Support for STMicroelectronics STiH407 family on-chip xHCI USB controller" >>>>>>> + depends on ARCH_STI >>>>>>> + default y >>>>>>> + help >>>>>>> + Enables support for the on-chip xHCI controller on STMicroelectronics >>>>>>> + STiH407 family SoCs. >>>>>>> + >>>>>>> config USB_XHCI_ZYNQMP >>>>>>> bool "Support for Xilinx ZynqMP on-chip xHCI USB controller" >>>>>>> depends on ARCH_ZYNQMP >>>>>>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile >>>>>>> index 58c0cf5..48a99f4 100644 >>>>>>> --- a/drivers/usb/host/Makefile >>>>>>> +++ b/drivers/usb/host/Makefile >>>>>>> @@ -64,6 +64,7 @@ obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o >>>>>>> obj-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o >>>>>>> obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o >>>>>>> obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o >>>>>>> +obj-$(CONFIG_USB_XHCI_STI) += xhci-sti.o >>>>>>> >>>>>>> # designware >>>>>>> obj-$(CONFIG_USB_DWC2) += dwc2.o >>>>>>> diff --git a/drivers/usb/host/xhci-sti.c b/drivers/usb/host/xhci-sti.c >>>>>>> new file mode 100644 >>>>>>> index 0000000..3ad149c >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/usb/host/xhci-sti.c >>>>>>> @@ -0,0 +1,128 @@ >>>>>>> +/* >>>>>>> + * Copyright (c) 2017 >>>>>>> + * Patrice Chotard >>>>>>> + * >>>>>>> + * SPDX-License-Identifier: GPL-2.0+ >>>>>>> + */ >>>>>>> + >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> + >>>>>>> +#include "xhci.h" >>>>>>> +#include >>>>>>> + >>>>>>> +DECLARE_GLOBAL_DATA_PTR; >>>>>>> + >>>>>>> +__weak int __board_usb_init(int index, enum usb_init_type init) >>>>>>> +{ >>>>>>> + return 0; >>>>>>> +} >>>>>>> +/*int board_usb_init(int index, enum usb_init_type init)*/ >>>>>>> +/* __attribute__((weak, alias("__board_usb_init")));*/ >>>>>>> + >>>>>>> +struct sti_xhci_platdata { >>>>>>> + struct phy usb_phy; >>>>>>> + phys_addr_t dwc3_regs; >>>>>>> +}; >>>>>>> + >>>>>>> +struct sti_xhci_priv { >>>>>>> + struct xhci_ctrl ctrl; >>>>>>> +}; >>>>>>> + >>>>>>> +static int sti_xhci_core_init(struct dwc3 *dwc3_reg) >>>>>>> +{ >>>>>>> + int ret; >>>>>>> + >>>>>>> + ret = dwc3_core_init(dwc3_reg); >>>>>>> + if (ret) { >>>>>>> + debug("failed to initialize core\n"); >>>>>>> + return ret; >>>>>>> + } >>>>>>> + >>>>>>> + /* We are hard-coding DWC3 core to Host Mode */ >>>>>>> + dwc3_set_mode(dwc3_reg, DWC3_GCTL_PRTCAP_HOST); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static int sti_xhci_ofdata_to_platdata(struct udevice *dev) >>>>>>> +{ >>>>>>> + struct sti_xhci_platdata *plat = dev_get_platdata(dev); >>>>>>> + u32 reg[2]; >>>>>>> + int ret; >>>>>>> + >>>>>>> + /* get the dwc3 register space base address */ >>>>>>> + if (fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev), "reg", reg, >>>>>>> + ARRAY_SIZE(reg))) { >>>>>>> + debug("dwc3 node has bad/missing 'reg' property\n"); >>>>>>> + return -FDT_ERR_NOTFOUND; >>>>>>> + } >>>>>>> + plat->dwc3_regs = reg[0]; >>>>>>> + >>>>>>> + ret = generic_phy_get_by_name(dev, "usb2-phy", &plat->usb_phy); >>>>>>> + if (ret) >>>>>>> + error("USB PHY DT node not found for %s\n", dev->name); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static int sti_xhci_probe(struct udevice *dev) >>>>>>> +{ >>>>>>> + struct sti_xhci_platdata *plat = dev_get_platdata(dev); >>>>>>> + struct xhci_hcor *hcor; >>>>>>> + struct xhci_hccr *hccr; >>>>>>> + struct dwc3 *dwc3_reg; >>>>>>> + int ret; >>>>>>> + >>>>>>> + hccr = (struct xhci_hccr *)plat->dwc3_regs; >>>>>>> + hcor = (struct xhci_hcor *)((phys_addr_t)hccr + >>>>>>> + HC_LENGTH(xhci_readl(&(hccr)->cr_capbase))); >>>>>>> + >>>>>>> + ret = generic_phy_init(&plat->usb_phy); >>>>>>> + if (ret) { >>>>>>> + error("Can't init USB PHY for %s\n", dev->name); >>>>>>> + return ret; >>>>>>> + } >>>>>>> + >>>>>>> + dwc3_reg = (struct dwc3 *)((char *)(hccr) + DWC3_REG_OFFSET); >>>>>>> + >>>>>>> + sti_xhci_core_init(dwc3_reg); >>>>>>> + >>>>>>> + return xhci_register(dev, hccr, hcor); >>>>>>> +} >>>>>>> + >>>>>>> +static int sti_xhci_remove(struct udevice *dev) >>>>>>> +{ >>>>>>> + struct sti_xhci_platdata *plat = dev_get_platdata(dev); >>>>>>> + int ret; >>>>>>> + >>>>>>> + ret = generic_phy_exit(&plat->usb_phy); >>>>>>> + if (ret) { >>>>>>> + error("Can't deinit USB PHY for %s\n", dev->name); >>>>>>> + return ret; >>>>>>> + } >>>>>>> + >>>>>>> + return xhci_deregister(dev); >>>>>>> +} >>>>>>> + >>>>>>> +static const struct udevice_id sti_xhci_ids[] = { >>>>>>> + { .compatible = "snps,dwc3" }, >>>>>> >>>>>> You probably want some more descriptive compatible string here ... >>>>> >>>>> I simply reuse the same compatible string used by kernel driver and DT. >>>>> >>>>> It's already used in fsl-dt-fixup.c : #define SNPS_DWC3 "snps,dwc3" >>>> >>>> And how does this allow you to discern this ST controller from other >>>> (potential) DWC3 controllers in your system ? Answer: it does not. Why? >>>> Because it's the generic compatible and if your controller has some sort >>>> of quirks, you won't be able to identify that. On the other hand, if >>>> this really is generic dwc3, then this should be called something like >>>> xhci-dwc3-generic and not xhci-sti . >>>> >>> >>> Ok i get your point, yes it's a generic dwc3 driver. >>> >>> It could make sense to merge xhci-sti.c (this patch) into existing >>> xhci-dwc3.c ? >>> What do you think ? >> >> Might be even better, yes >> > Do you prefer i include this merge into this series or to send it > separately as for ehci/hci generic update ? Split it so the stuff can go in independently as it matures ... -- Best regards, Marek Vasut