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? Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot