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, [email protected] wrote:
>>>>>>> From: Patrice Chotard <[email protected]>
>>>>>>>
>>>>>>> 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 <[email protected]>
>>>>>>> ---
>>>>>>> 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 <[email protected]>
>>>>>>> + *
>>>>>>> + * 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 ?
>>
>> 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
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot

Reply via email to