From: gregory.clement@free-electrons•com (Gregory CLEMENT)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv5 10/20] phy: add support for USB cluster on the Armada 375 SoC
Date: Wed, 14 May 2014 16:08:48 +0200 [thread overview]
Message-ID: <537378F0.8020905@free-electrons.com> (raw)
In-Reply-To: <5371E8BF.50303@free-electrons.com>
Hi Kishon,
Given the answers I provided to your concerns. I don't see any modification
to do to this driver. Do you agree?
If not which change is mandatory from your point of view?
Thanks,
Gregory
On 13/05/2014 11:41, Gregory CLEMENT wrote:
> On 13/05/2014 10:06, Gregory CLEMENT wrote:
>> On 13/05/2014 07:53, Kishon Vijay Abraham I wrote:
>>> Hi,
>>>
>>> On Sunday 11 May 2014 11:47 PM, Thomas Petazzoni wrote:
>>>> From: Gregory CLEMENT <gregory.clement@free-electrons•com>
>>>>
>>>> The Armada 375 SoC comes with an USB2 host and device controller and
>>>> an USB3 controller. The USB cluster control register allows to manage
>>>> common features of both USB controllers.
>>>>
>>>> This commit adds a driver integrated in the generic PHY framework to
>>>> control this USB cluster feature.
>>>>
>>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons•com>
>>>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons•com>
>>>> ---
>>>> drivers/phy/Kconfig | 6 ++
>>>> drivers/phy/Makefile | 1 +
>>>> drivers/phy/phy-armada375-usb2.c | 157 +++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 164 insertions(+)
>>>> create mode 100644 drivers/phy/phy-armada375-usb2.c
>>>>
>>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>>> index 3bb05f1..e63cf9d 100644
>>>> --- a/drivers/phy/Kconfig
>>>> +++ b/drivers/phy/Kconfig
>>>> @@ -15,6 +15,12 @@ config GENERIC_PHY
>>>> phy users can obtain reference to the PHY. All the users of this
>>>> framework should select this config.
>>>>
>>>> +config ARMADA375_USBCLUSTER_PHY
>>>> + def_bool y
>>>> + depends on MACH_ARMADA_375 || COMPILE_TEST
>>>> + depends on OF
>>>> + select GENERIC_PHY
>>>> +
>>>> config PHY_EXYNOS_MIPI_VIDEO
>>>> tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
>>>> depends on HAS_IOMEM
>>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>>>> index 2faf78e..47d5a86 100644
>>>> --- a/drivers/phy/Makefile
>>>> +++ b/drivers/phy/Makefile
>>>> @@ -3,6 +3,7 @@
>>>> #
>>>>
>>>> obj-$(CONFIG_GENERIC_PHY) += phy-core.o
>>>> +obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
>>>> obj-$(CONFIG_BCM_KONA_USB2_PHY) += phy-bcm-kona-usb2.o
>>>> obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
>>>> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
>>>> diff --git a/drivers/phy/phy-armada375-usb2.c b/drivers/phy/phy-armada375-usb2.c
>>>> new file mode 100644
>>>> index 0000000..a6f746d
>>>> --- /dev/null
>>>> +++ b/drivers/phy/phy-armada375-usb2.c
>>>> @@ -0,0 +1,157 @@
>>>> +/*
>>>> + * USB cluster support for Armada 375 platform.
>>>> + *
>>>> + * Copyright (C) 2014 Marvell
>>>> + *
>>>> + * Gregory CLEMENT <gregory.clement@free-electrons•com>
>>>> + *
>>>> + * This file is licensed under the terms of the GNU General Public
>>>> + * License version 2 or later. This program is licensed "as is"
>>>> + * without any warranty of any kind, whether express or implied.
>>>> + *
>>>> + * Armada 375 comes with an USB2 host and device controller and an
>>>> + * USB3 controller. The USB cluster control register allows to manage
>>>> + * common features of both USB controllers.
>>>> + */
>>>> +
>>>> +#include <linux/init.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of_address.h>
>>>> +#include <linux/phy/phy.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/slab.h>
>>>> +
>>>> +#define USB2_PHY_CONFIG_DISABLE BIT(0)
>>>> +
>>>> +/* The USB cluster allows to choose between two PHYs */
>>>> +#define NB_PHY 2
>>>> +
>>>> +enum {
>>>> + PHY_USB2 = 0,
>>>> + PHY_USB3 = 1,
>>>> +};
>>>> +
>>>> +struct armada375_cluster_phy {
>>>> + struct phy *phy;
>>>> + void __iomem *reg;
>>>> + bool enable;
>>>> + bool use_usb3;
>>>> +};
>>>> +
>>>> +struct armada375_cluster_phy usb_cluster_phy[NB_PHY];
>>>> +
>>>> +static int armada375_usb_phy_init(struct phy *phy)
>>>> +{
>>>> + struct armada375_cluster_phy *cluster_phy = phy_get_drvdata(phy);
>>>> + u32 reg;
>>>
>>> This function should be protected since both your PHYs use this ops.
>>
>> Right
>
> Actually only one PHY can access this register. See the probe function,
> cluster_phy->enable is only set to true for one PHY.
>
>>
>>>> +
>>>> + if (!cluster_phy->enable)
>>>> + return -ENODEV;
>>>> +
>>>> + reg = readl(cluster_phy->reg);
>>>> + if (cluster_phy->use_usb3)
>>>> + reg |= USB2_PHY_CONFIG_DISABLE;
>>>> + else
>>>> + reg &= ~USB2_PHY_CONFIG_DISABLE;
>>>> + writel(reg, cluster_phy->reg);
>>>
>>> This is confusing since both your PHYs control the same bit?
>
> Same here at the end the bit is accessed by only one PHY.
>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct phy_ops armada375_usb_phy_ops = {
>>>> + .init = armada375_usb_phy_init,
>>>> + .owner = THIS_MODULE,
>>>> +};
>>>> +
>>>> +static struct phy *armada375_usb_phy_xlate(struct device *dev,
>>>> + struct of_phandle_args *args)
>>>> +{
>>>> + if (WARN_ON(args->args[0] >= NB_PHY))
>>>> + return ERR_PTR(-ENODEV);
>>>> +
>>>> + return usb_cluster_phy[args->args[0]].phy;
>>>> +}
>>>> +
>>>> +static int armada375_usb_phy_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct device *dev = &pdev->dev;
>>>> + struct phy *phy;
>>>> + struct phy_provider *phy_provider;
>>>> + void __iomem *usb_cluster_base;
>>>> + struct device_node *xhci_node;
>>>> + struct resource *res;
>>>> + int i;
>>>> +
>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> + usb_cluster_base = devm_ioremap_resource(&pdev->dev, res);
>>>> + if (!usb_cluster_base)
>>>> + return -ENOMEM;
>>>> +
>>>> + for (i = 0; i < NB_PHY; i++) {
>>>
>>> For devices which have multiple PHYs, each PHY should be modelled as the
>>> sub-node of the *PHY provider* device node.
>>
>> Actually it is the opposite the same PHY is shared between the EHCI
>> and the xHCI controllers. It is more a PHY muxer than a PHY itself.
>>
>> I had to create 2 logical PHYs because once the phy_init() is called
>> by a USB driver then the .init ops is not called anymore by the next
>> call to phy_init(). One of the goal of this is to disable a port for
>> the USB controller which can't use it due to the configuration of the
>> USB cluster.
>>
>> But I can see how to make this two "pseudo" PHYs sub-node of the *PHY
>> provider* device node. It shouldn't change the internal logic of this
>> driver.
>
> I need to make a distinction when the PHY access by the xHCI or when
> it was access by the EHCI. If I create two new sub-node then I will
> also need to add a property to make this distinction. It seems a little
> overkill for the need.
>
>>
>>
>>>> + phy = devm_phy_create(dev, &armada375_usb_phy_ops, NULL);
>>>> + if (IS_ERR(phy)) {
>>>> + dev_err(dev, "failed to create PHY n%d\n", i);
>>>> + return PTR_ERR(phy);
>>>> + }
>>>> +
>>>> + usb_cluster_phy[i].phy = phy;
>>>> + usb_cluster_phy[i].reg = usb_cluster_base;
>>>> + usb_cluster_phy[i].enable = false;
>>>> + phy_set_drvdata(phy, &usb_cluster_phy[i]);
>>>> + }
>>>> +
>>>> + usb_cluster_phy[PHY_USB2].use_usb3 = false;
>>>> + usb_cluster_phy[PHY_USB3].use_usb3 = true;
>>>> +
>>>> + /*
>>>> + * We can't use the first usb2 unit and usb3 at the same time
>>>> + * to manage a USB2 device, so let's disable usb2 if usb3 is
>>>> + * selected. In this case the USB2 device will be managed by
>>>> + * the xhci controller.
>>>> + */
>>>> +
>>>> + xhci_node = of_find_compatible_node(NULL, NULL,
>>>> + "marvell,armada-375-xhci");
>>>
>>> huh.. that's too much binding between the controller and the PHY.
>>>
>>
>> That's why initially it was not part of the PHY framework. The USB
>> cluster is really a part managing common feature between the USB
>> controllers which are part of the Armada 375 SoC.
>>
>> However the initial version was not really good, because this piece of
>> code was located in the mach- directory whereas we are trying to move
>> most of the files out of this directory now. The USB cluster is not a
>> real PHY as it is related to the PHY management this framework remains
>> the best place for it.
>>
>>>> +
>>>> + if (xhci_node && of_device_is_available(xhci_node)) {
>>>> + usb_cluster_phy[PHY_USB3].enable = true;
>>>> + } else {
>>>> + struct device_node *ehci_node;
>>>> + ehci_node = of_find_compatible_node(NULL, NULL,
>>>> + "marvell,orion-ehci");
>>>> + if (ehci_node && of_device_is_available(ehci_node))
>>>> + usb_cluster_phy[PHY_USB2].enable = true;
>>>> + of_node_put(ehci_node);
>>>> + }
>>>> +
>>>> + of_node_put(xhci_node);
>>>> +
>>>> + phy_provider = devm_of_phy_provider_register(&pdev->dev,
>>>> + armada375_usb_phy_xlate);
>>>> + if (IS_ERR(phy_provider))
>>>> + return PTR_ERR(phy_provider);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static const struct of_device_id of_usb_cluster_table[] = {
>>>> + { .compatible = "marvell,armada-375-usb-cluster", },
>>>> + { /* end of list */ },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, of_usb_cluster_table);
>>>> +
>>>> +static struct platform_driver armada375_usb_phy_driver = {
>>>> + .probe = armada375_usb_phy_probe,
>>>> + .driver = {
>>>> + .of_match_table = of_usb_cluster_table,
>>>> + .name = "armada-375-usb-cluster",
>>>> + .owner = THIS_MODULE,
>>>> + }
>>>> +};
>>>> +module_platform_driver(armada375_usb_phy_driver);
>>>> +
>>>> +MODULE_DESCRIPTION("Armada 375 USB cluster driver");
>>>> +MODULE_AUTHOR("Gregory CLEMENT <gregory.clement@free-electrons•com>");
>>>> +MODULE_LICENSE("GPL");
>>>
>>> GPL v2?
>>
>> No it is really GPL v2 or latter as written at the top of this file
>>
>>
>> Thanks,
>>
>> Gregory
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2014-05-14 14:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-11 18:17 [PATCHv5 00/20] USB support for Armada 38x and Armada 375 Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 01/20] usb: ehci-orion: use platform_get_irq() for DT probing Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 02/20] usb: ehci-orion: rename error goto labels in ehci_orion_drv_probe() Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 03/20] usb: ehci-orion: fix clock reference leaking Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 04/20] usb: ehci-orion: add optional PHY support Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 05/20] Documentation: dt-bindings: update ehci-orion binding documentation Thomas Petazzoni
2014-05-12 14:34 ` Gregory CLEMENT
2014-05-12 15:46 ` Alan Stern
2014-05-12 16:00 ` Gregory CLEMENT
2014-05-11 18:17 ` [PATCHv5 06/20] usb: host: xhci-plat: sort the headers in alphabetic order Thomas Petazzoni
2014-05-11 18:17 ` [PATCHv5 07/20] usb: host: xhci-plat: add clock support Thomas Petazzoni
2014-05-12 14:46 ` Gregory CLEMENT
2014-05-12 17:43 ` Mathias Nyman
2014-05-12 17:37 ` Felipe Balbi
2014-05-11 18:17 ` [PATCHv5 08/20] usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers Thomas Petazzoni
2014-05-12 17:24 ` Mathias Nyman
2014-05-12 17:36 ` Thomas Petazzoni
2014-05-13 8:24 ` Mathias Nyman
2014-05-11 18:17 ` [PATCHv5 09/20] Documentation: dt-bindings: update xhci-platform DT binding Thomas Petazzoni
2014-05-12 17:38 ` Mathias Nyman
2014-05-11 18:17 ` [PATCHv5 10/20] phy: add support for USB cluster on the Armada 375 SoC Thomas Petazzoni
2014-05-12 14:57 ` Gregory CLEMENT
2014-05-13 5:53 ` Kishon Vijay Abraham I
2014-05-13 8:06 ` Gregory CLEMENT
2014-05-13 9:41 ` Gregory CLEMENT
2014-05-14 14:08 ` Gregory CLEMENT [this message]
2014-05-14 14:27 ` Kishon Vijay Abraham I
2014-05-14 15:35 ` Gregory CLEMENT
2014-05-15 7:01 ` Gregory CLEMENT
2014-05-15 9:01 ` Kishon Vijay Abraham I
2014-05-15 9:35 ` Gregory CLEMENT
2014-05-15 9:38 ` Kishon Vijay Abraham I
2014-05-11 18:17 ` [PATCHv5 11/20] Documentation: dt-bindings: document the Armada 375 USB cluster binding Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 12/20] ARM: mvebu: add USB3 support for Armada 38x Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 13/20] ARM: mvebu: add USB3 support for Armada 375 Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 14/20] ARM: configs: enable XHCI mvebu support in mvebu_v7_defconfig Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 15/20] ARM: configs: enable XHCI mvebu support in multi_v7_defconfig Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 16/20] ARM: mvebu: add Device Tree description of xHCI controllers on Armada 38x Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 17/20] ARM: mvebu: add Device Tree description of the EHCI controller " Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 18/20] ARM: mvebu: add Device Tree description of USB cluster controller on Armada 375 Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 19/20] ARM: mvebu: add Device Tree description of the xHCI " Thomas Petazzoni
2014-05-11 18:18 ` [PATCHv5 20/20] ARM: mvebu: add Device Tree description of the EHCI " Thomas Petazzoni
2014-05-12 14:29 ` [PATCHv5 00/20] USB support for Armada 38x and " Gregory CLEMENT
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=537378F0.8020905@free-electrons.com \
--to=gregory.clement@free-electrons$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox