[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D958900912E20642BCBC71664EFECE3E6DDEFB8D80@BGMAIL02.nvidia.com>
Date: Thu, 13 Sep 2012 09:19:41 +0530
From: Venu Byravarasu <vbyravarasu@...dia.com>
To: Stephen Warren <swarren@...dotorg.org>
CC: "balbi@...com" <balbi@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: RE: [PATCH] USB: phy: re-organize tegra phy driver
> -----Original Message-----
> From: Stephen Warren [mailto:swarren@...dotorg.org]
> Sent: Thursday, September 13, 2012 12:06 AM
> To: Venu Byravarasu
> Cc: balbi@...com; linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org;
> linux-tegra@...r.kernel.org
> Subject: Re: [PATCH] USB: phy: re-organize tegra phy driver
>
> On 09/12/2012 04:58 AM, Venu Byravarasu wrote:
> > Nvidia produces several Tegra SOCs viz Tegra2, Tegra3 etc.
> > In order to support USB phy drivers on these SOCs, existing
> > phy driver is split into SOC agnostic common USB phy driver and
> > tegra2 specific USB phy driver.
> > This will facilitate easy addition & deletion of phy drivers for
> > Tegra SOCs.
>
> For capitalization/related reasons, I would re-write the commit
> description as:
>
> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
> In order to support USB PHY drivers on these SoCs, existing
Will change tegra2 to Tegra20 and similar for Tegra30 & NVIDIA.
However as phy is not an acronym, should we still have it in Caps?
> PHY driver is split into SoC agnostic common USB PHY driver and
> Tegra20-specific USB phy driver. This will facilitate easy addition
> and deletion of phy drivers for Tegra SoCs.
>
> ... and s/tegra/Tegra/ in the patch subject.
>
> Tested-by: Stephen Warren <swarren@...dotorg.org>
>
> (On Harmony, both the USB Ethernet on USB3/UTMI and USB2's ULPI to a
> breakout board)
>
> > diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
>
> > @@ -706,9 +709,22 @@ static int tegra_ehci_probe(struct platform_device
> *pdev)
> > }
> > }
> >
> > + phy_type = of_property_match_string(np, "phy_type", "utmi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_UTMI;
> > + else {
> > + phy_type = of_property_match_string(np, "phy_type",
> "ulpi");
> > + if (phy_type >= 0)
> > + params.type = TEGRA_USB_PHY_TYPE_ULPI;
> > + else
> > + params.type = TEGRA_USB_PHY_TYPE_INVALID;
> > + }
> > +
> > + params.mode = TEGRA_USB_PHY_MODE_HOST;
>
> Do we not support device mode yet? There's a dr_mode property in the DT
> that's supposed to indicate host/device/otg.
>
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.c
> b/drivers/usb/phy/tegra2_usb_phy.c
>
> > +#include <mach/gpio-tegra.h>
>
> Please remove that #include statement; the heaer is not needed, and will
> be deleted in the kernel 3.7 merge window.
>
> > +static int tegra2_utmip_pad_open(struct tegra_usb_phy *phy)
> > +{
> > + phy->pad_clk = clk_get_sys("utmip-pad", NULL);
> > + if (IS_ERR(phy->pad_clk)) {
> > + pr_err("%s: can't get utmip pad clock\n", __func__);
> > + return PTR_ERR(phy->pad_clk);
> > + }
> > +
> > + if (phy->instance == 0) {
> > + phy->pad_regs = phy->regs;
> > + } else {
>
> Can we use something other than phy->instance here? I see lots of usage
> of this field, but we should really be deleting the following code from
> ehci-tegra.c, rather the propagating the use of that field.
>
> /* This is pretty ugly and needs to be fixed when we do only
> * device-tree probing. Old code relies on the platform_device
> * numbering that we lack for device-tree-instantiated devices.
> */
> if (instance < 0) {
> switch (res->start) {
> case TEGRA_USB_BASE:
> instance = 0;
> break;
> case TEGRA_USB2_BASE:
> instance = 1;
> break;
> case TEGRA_USB3_BASE:
> instance = 2;
> break;
> default:
> err = -ENODEV;
> dev_err(&pdev->dev, "unknown usb instance\n");
> goto fail_io;
> }
> }
>
> Still, I suppose the cleanup not to use the instance value could be a
> later patch as long as you're aware of the issue and planning to solve it.
>
> > + phy->pad_regs = ioremap(TEGRA_USB_BASE,
> TEGRA_USB_SIZE);
>
> Hmmm. Why do we need to remap the registers again? Didn't the EHCI
> controller already map them? I'm a little confused what in HW causes the
> need for this whole if statement.
>
> > + if (!phy->pad_regs) {
> > + pr_err("%s: can't remap usb registers\n", __func__);
> > + clk_put(phy->pad_clk);
> > + return -ENOMEM;
> > + }
> > + }
>
> > +static void tegra2_utmi_phy_clk_disable(struct tegra_usb_phy *phy)
> > +{
> > + unsigned long val;
> > + void __iomem *base = phy->regs;
> > +
> > + if (phy->instance == 0) {
>
> Hmmm. There sure are a lot of places where the code is conditional based
> on instance. This seems to be crying out to be split into more ops
> functions that get set up once at probe() time and then just used.
>
> > +static int tegra2_utmi_phy_power_off(struct tegra_usb_phy *phy)
> > +{
> > + unsigned long val;
> > + void __iomem *base = phy->regs;
> > +
> > + tegra2_utmi_phy_clk_disable(phy);
> > +
> > + if (phy->mode == TEGRA_USB_PHY_MODE_DEVICE) {
>
> Hmm. Yet here, we have some support for device-mode.
>
> > +static int tegra2_usb_phy_open(struct tegra_usb_phy *phy)
> > +{
> > + struct tegra_ulpi_config *ulpi_config;
> > + int err;
> > +
> > + if (phy_is_ulpi(phy)) {
>
> Similarly, this seems like it'd be better as two separate functions,
> since there's already an op defined for open.
>
> > + ulpi_config = phy->config;
> > + phy->clk = clk_get_sys(NULL, ulpi_config->clk);
> > + if (IS_ERR(phy->clk)) {
> > + pr_err("%s: can't get ulpi clock\n", __func__);
> > + err = -ENXIO;
> > + goto err1;
> > + }
> > + if (!gpio_is_valid(ulpi_config->reset_gpio))
> > + ulpi_config->reset_gpio =
> > + of_get_named_gpio(phy->dev->of_node,
> > + "nvidia,phy-reset-gpio", 0);
> > + if (!gpio_is_valid(ulpi_config->reset_gpio)) {
> > + pr_err("%s: invalid reset gpio: %d\n", __func__,
> > + ulpi_config->reset_gpio);
> > + err = -EINVAL;
> > + goto err1;
> > + }
> > + gpio_request(ulpi_config->reset_gpio, "ulpi_phy_reset_b");
> > + gpio_direction_output(ulpi_config->reset_gpio, 0);
> > + phy->ulpi = otg_ulpi_create(&ulpi_viewport_access_ops, 0);
> > + phy->ulpi->io_priv = phy->regs + ULPI_VIEWPORT;
> > + } else {
> > + err = tegra2_utmip_pad_open(phy);
> > + if (err < 0)
> > + goto err1;
> > + }
> > + return 0;
> > +err1:
> > + clk_disable_unprepare(phy->pll_u);
> > + clk_put(phy->pll_u);
>
> In the else clause above, phy->pll_u was never assigned, yet failure
> jumps here...
>
> > + return err;
> > +}
>
> > diff --git a/drivers/usb/phy/tegra2_usb_phy.h
> b/drivers/usb/phy/tegra2_usb_phy.h
>
> > +static const struct tegra_xtal_freq tegra_freq_table[] = {
> > + {
> > + .freq = 12000000,
> > + .enable_delay = 0x02,
> ...
>
> It doesn't seem like a good idea to put data into a header file.
>
> > diff --git a/include/linux/usb/tegra_usb_phy.h
> b/include/linux/usb/tegra_usb_phy.h
>
> > +struct usb_phy_ops {
>
> Shouldn't that be tegra_usb_phy_ops to avoid namespace collisions?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists