Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752066AbbFHEVk (ORCPT ); Mon, 8 Jun 2015 00:21:40 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:38805 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751278AbbFHEVa (ORCPT ); Mon, 8 Jun 2015 00:21:30 -0400 MIME-Version: 1.0 In-Reply-To: <5574F97A.5030104@samsung.com> References: <1433683242-3945-1-git-send-email-linux.amoon@gmail.com> <5574F97A.5030104@samsung.com> From: Anand Moon Date: Mon, 8 Jun 2015 09:51:08 +0530 Message-ID: Subject: Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators To: Krzysztof Kozlowski Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Kukjin Kim , Alan Stern , Greg Kroah-Hartman , Vivek Gautam , Felipe Balbi , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "linux-samsung-soc@vger.kernel.org" , Linux Kernel , linux-usb@vger.kernel.org, Jingoo Han Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6027 Lines: 164 Hi Krzysztof , On 8 June 2015 at 07:40, Krzysztof Kozlowski wrote: > On 07.06.2015 22:20, Anand Moon wrote: >> Facilitate getting required 3.3V and 1.0V VDD supply for >> EHCI controller on Exynos. >> >> With the patches for regulators' nodes merged in 3.15: >> c8c253f ARM: dts: Add regulator entries to smdk5420 >> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250, >> the exynos systems turn on only minimal number of regulators. >> >> Until now, the VDD regulator supplies were either turned on >> by the bootloader, or the regulators were enabled by default >> in the kernel, so that the controller drivers did not need to >> care about turning on these regulators on their own. >> This was rather bad about these controller drivers. >> So ensuring now that the controller driver requests the necessary >> VDD regulators (if available, unless there are direct VDD rails), >> and enable them so as to make them working. >> >> Signed-off-by: Vivek Gautam >> Signed-off-by: Anand Moon >> Cc: Jingoo Han >> Cc: Alan Stern >> --- >> Initial version of this patch was part of following series, though >> they are not dependent on each other, resubmitting after rebasing. >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html > > So you just took Vivek's patch along with all the credits... That is not > how we usually do this. > > I would expect that rebasing a patch won't change the author unless this > is fine with Vivek. > Sorry If I have done some mistake on my part. I just looked at below mail chain. Before I send it. http://www.spinics.net/lists/linux-samsung-soc/msg44136.html I don't want to take any credit out of it. I just re-base on the new kernel. I could not test this patch as it meant for exynos5440 boards. -Anand Moon >> --- >> .../devicetree/bindings/usb/exynos-usb.txt | 2 + >> drivers/usb/host/ehci-exynos.c | 55 +++++++++++++++++++++- >> 2 files changed, 56 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt >> index 9b4dbe3..776fa03 100644 >> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt >> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt >> @@ -23,6 +23,8 @@ Required properties: >> Optional properties: >> - samsung,vbus-gpio: if present, specifies the GPIO that >> needs to be pulled up for the bus to be powered. >> + - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller. >> + - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller. >> >> Example: >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c >> index df538fd..4f8f9d2 100644 >> --- a/drivers/usb/host/ehci-exynos.c >> +++ b/drivers/usb/host/ehci-exynos.c >> @@ -21,6 +21,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> >> @@ -45,6 +46,8 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver; >> struct exynos_ehci_hcd { >> struct clk *clk; >> struct phy *phy[PHY_NUMBER]; >> + struct regulator *vdd33; >> + struct regulator *vdd10; >> }; >> >> #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv) >> @@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device *pdev) >> >> err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci); >> if (err) >> - goto fail_clk; >> + goto fail_regulator1; >> + >> + exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33"); >> + if (!IS_ERR(exynos_ehci->vdd33)) { >> + err = regulator_enable(exynos_ehci->vdd33); >> + if (err) { >> + dev_err(&pdev->dev, >> + "Failed to enable 3.3V Vdd supply\n"); >> + goto fail_regulator1; >> + } >> + } >> + >> + exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10"); >> + if (!IS_ERR(exynos_ehci->vdd10)) { >> + err = regulator_enable(exynos_ehci->vdd10); >> + if (err) { >> + dev_err(&pdev->dev, >> + "Failed to enable 1.0V Vdd supply\n"); >> + goto fail_regulator2; >> + } >> + } >> >> skip_phy: >> >> @@ -231,6 +254,10 @@ fail_add_hcd: >> fail_io: >> clk_disable_unprepare(exynos_ehci->clk); >> fail_clk: >> + regulator_disable(exynos_ehci->vdd10); >> +fail_regulator2: >> + regulator_disable(exynos_ehci->vdd33); > > if (!IS_ERR()). > >> +fail_regulator1: >> usb_put_hcd(hcd); >> return err; >> } >> @@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device *pdev) >> >> clk_disable_unprepare(exynos_ehci->clk); >> >> + if (!IS_ERR(exynos_ehci->vdd33)) >> + regulator_disable(exynos_ehci->vdd33); >> + if (!IS_ERR(exynos_ehci->vdd10)) >> + regulator_disable(exynos_ehci->vdd10); >> + >> usb_put_hcd(hcd); >> >> return 0; >> @@ -268,6 +300,11 @@ static int exynos_ehci_suspend(struct device *dev) >> >> clk_disable_unprepare(exynos_ehci->clk); >> >> + if (!IS_ERR(exynos_ehci->vdd33)) >> + regulator_disable(exynos_ehci->vdd33); >> + if (!IS_ERR(exynos_ehci->vdd10)) >> + regulator_disable(exynos_ehci->vdd10); >> + > > > Is EHCI a wakeup source? If yes then how disabling regulators during > suspend affects waking up process? > > Best regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/