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.chot...@st.com wrote: >>>> From: Patrice Chotard <patrice.chot...@st.com> >>>> >>>> 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 <patrice.chot...@st.com> >>>> --- >>>> 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 <patrice.chot...@st.com> >>>> + * >>>> + * SPDX-License-Identifier: GPL-2.0+ >>>> + */ >>>> + >>>> +#include <asm/io.h> >>>> +#include <common.h> >>>> +#include <dm.h> >>>> +#include <fdtdec.h> >>>> +#include <generic-phy.h> >>>> +#include <usb.h> >>>> + >>>> +#include "xhci.h" >>>> +#include <linux/usb/dwc3.h> >>>> + >>>> +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 ? Thanks Patrice _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot