[U-Boot] [PATCH 06/21] usb: ehci: Add STi ehci support
Simon Glass
sjg at chromium.org
Sat Apr 1 04:21:55 UTC 2017
Hi Patrice,
On 23 March 2017 at 03:59, Patrice CHOTARD <patrice.chotard at 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 at st.com> wrote:
>>> From: Patrice Chotard <patrice.chotard at 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 at 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 at 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.
Regards.
Simon
More information about the U-Boot
mailing list