On 18 April 2017 at 00:56, Patrice CHOTARD <patrice.chot...@st.com> wrote: > Hi Simon > > On 04/09/2017 09:27 PM, Simon Glass wrote: >> Hi Patrice, >> >> On 3 April 2017 at 03:39, Patrice CHOTARD <patrice.chot...@st.com> wrote: >>> Hi Simon >>> >>> On 04/01/2017 06:21 AM, Simon Glass wrote: >>>> Hi Patrice, >>>> >>>> On 23 March 2017 at 03:59, Patrice CHOTARD <patrice.chot...@st.com> wrote: >>>>> Hi Simon >>>>> >>>>> On 03/22/2017 02:05 PM, Simon Glass wrote: >>>>>> Hi, >>>>>> >>>>>> On 17 March 2017 at 10:25, <patrice.chot...@st.com> wrote: >>>>>>> From: Patrice Chotard <patrice.chot...@st.com> >>>>>>> >>>>>>> Add support for on-chip ehci controller available >>>>>>> on STMicrolectronics SoCs. >>>>>>> ehci support will be then available on both type A >>>>>>> USB 2.0 connectors. >>>>>>> >>>>>>> Signed-off-by: Patrice Chotard <patrice.chot...@st.com> >>>>>>> --- >>>>>>> drivers/usb/host/Kconfig | 9 +++++ >>>>>>> drivers/usb/host/Makefile | 1 + >>>>>>> drivers/usb/host/ehci-sti.c | 91 >>>>>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> 3 files changed, 101 insertions(+) >>>>>>> create mode 100644 drivers/usb/host/ehci-sti.c >>>>>>> >>>>>>> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig >>>>>>> index 5129a57..d66f49e 100644 >>>>>>> --- a/drivers/usb/host/Kconfig >>>>>>> +++ b/drivers/usb/host/Kconfig >>>>>>> @@ -120,6 +120,15 @@ config USB_EHCI_MSM >>>>>>> This driver supports combination of Chipidea USB controller >>>>>>> and Synapsys USB PHY in host mode only. >>>>>>> >>>>>>> +config USB_EHCI_STI >>>>>>> + bool "Support for STMicroelectronics on-chip EHCI USB >>>>>>> controller" >>>>>>> + depends on ARCH_STI >>>>>>> + select STI_PHY_USB >>>>>>> + default y >>>>>>> + ---help--- >>>>>>> + Enables support for the on-chip EHCI controller on >>>>>>> + STMicroelectronics SoCs. >>>>>>> + >>>>>>> config USB_EHCI_ZYNQ >>>>>>> bool "Support for Xilinx Zynq on-chip EHCI USB controller" >>>>>>> depends on ARCH_ZYNQ >>>>>>> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile >>>>>>> index 58c0cf5..303aa32 100644 >>>>>>> --- a/drivers/usb/host/Makefile >>>>>>> +++ b/drivers/usb/host/Makefile >>>>>>> @@ -46,6 +46,7 @@ obj-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o >>>>>>> obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o >>>>>>> obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o >>>>>>> obj-$(CONFIG_USB_EHCI_SPEAR) += ehci-spear.o >>>>>>> +obj-$(CONFIG_USB_EHCI_STI) += ehci-sti.o >>>>>>> obj-$(CONFIG_USB_EHCI_SUNXI) += ehci-sunxi.o >>>>>>> obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o >>>>>>> obj-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o >>>>>>> diff --git a/drivers/usb/host/ehci-sti.c b/drivers/usb/host/ehci-sti.c >>>>>>> new file mode 100644 >>>>>>> index 0000000..89ca66a >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/usb/host/ehci-sti.c >>>>>>> @@ -0,0 +1,91 @@ >>>>>>> +/* >>>>>>> + * Copyright (c) 2017 >>>>>>> + * Patrice Chotard <patrice.chot...@st.com> >>>>>>> + * >>>>>>> + * SPDX-License-Identifier: GPL-2.0+ >>>>>>> + */ >>>>>>> + >>>>>>> +#include <common.h> >>>>>>> +#include <asm/io.h> >>>>>>> +#include <dm.h> >>>>>>> +#include <errno.h> >>>>>>> +#include "ehci.h" >>>>>>> +#include <reset-uclass.h> >>>>>>> +#include <usb.h> >>>>>>> + >>>>>>> +DECLARE_GLOBAL_DATA_PTR; >>>>>>> + >>>>>>> +struct sti_ehci_priv { >>>>>>> + struct ehci_ctrl ctrl; >>>>>>> + struct reset_ctl power_ctl; >>>>>>> + struct reset_ctl softreset_ctl; >>>>>>> +}; >>>>>>> + >>>>>>> +static int sti_ehci_probe(struct udevice *dev) >>>>>>> +{ >>>>>>> + struct sti_ehci_priv *priv = dev_get_priv(dev); >>>>>>> + struct ehci_hccr *hccr = priv->ctrl.hccr; >>>>>>> + struct ehci_hcor *hcor; >>>>>>> + struct udevice *dev_phy; >>>>>>> + int ret, phy_node; >>>>>>> + >>>>>>> + hccr = (struct ehci_hccr *)dev_get_addr(dev); >>>>>>> + >>>>>>> + if (hccr == (void *)FDT_ADDR_T_NONE) >>>>>>> + return -EINVAL; >>>>>>> + >>>>>>> + ret = reset_get_by_name(dev, "power", &priv->power_ctl); >>>>>> >>>>>> This is OK, but can you instead access it via a phandle in the device's >>>>>> node? >>>>> >>>>> Sorry i didn't get your point. Why getting it using a phandle ? >>>> >>>> I mean that generally when a device needs another device this is >>>> expressed by adding a phandle in the client device's node, or perhaps >>>> some sort of name. That way it is possible (e.g.) to specify *which* >>>> reset rather than hard-coding it. >>> >>> Agree with you, but i get one constraint. For this ehci IP, there are 2 >>> resets (power and softreset). I must identify each other to be able to >>> assert/deassert them in the correct order. >> >> One of those sounds like a reset. The other sounds like a regulator. >> >>> >>> I checked other U-boot drivers which already used reset, and all of them >>> are using reset_get_by_name(). >> >> OK well it was a suggestion so will leave it to you. Is that how Linux >> does it also? > > Yes, i reproduce exactly what is done in Linux.
Reviewed-by: Simon Glass <s...@chromium.org> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot