On 18 April 2017 at 00:56, Patrice CHOTARD patrice.chotard@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.chotard@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.chotard@st.com wrote:
Hi Simon
On 03/22/2017 02:05 PM, Simon Glass wrote:
Hi,
On 17 March 2017 at 10:25, patrice.chotard@st.com wrote: > From: Patrice Chotard patrice.chotard@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.chotard@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.chotard@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 sjg@chromium.org