[U-Boot] [PATCH 06/21] usb: ehci: Add STi ehci support

[Simon Glass]

On 18 April 2017 at 00:56, Patrice CHOTARD <patrice.chotard at 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 at 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 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.
>>>
>>> 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 at chromium.org>