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