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
