Re: [PATCH v4 1/2] usb: ehci-exynos: Make provision for vdd regulators

2015-06-11 Thread Vivek Gautam
Hi,


On Mon, Jun 8, 2015 at 8:47 PM, Alan Stern  wrote:
> On Mon, 8 Jun 2015, Vivek Gautam wrote:
>
>> Facilitate getting required 3.3V and 1.0V VDD supply for
>> EHCI controller on Exynos.
>>
>> For example, patches for regulators' nodes:
>> c8c253f ARM: dts: Add regulator entries to smdk5420
>> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> enable only minimum number of regulators on smdk5250.
>>
>> 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 on exynos systems.
>>
>> Signed-off-by: Vivek Gautam 
>
> Something about this looks a little fishy...

Sorry, i didn't get you.
This patch was initially posted by me sometime back.

>
>> @@ -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");
>
> Just before this region of code, there is:
>
> if (of_device_is_compatible(pdev->dev.of_node,
> "samsung,exynos5440-ehci"))
> goto skip_phy;
>
> If that "goto" is taken, exynos_ehci->vdd33 and ->vdd10 will be NULL,
> not an ERR_PTR code.

Right. This will hit NULL pointer dereferencing later in the code.

>
>> + 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;
>> + }
>> + }

May be we can have something like this:

 if (IS_ERR(exynos_ehci->vdd33)) {
 exynos_ehci->vdd33 = NULL;
 } else {
 err = regulator_enable(exynos_ehci->vdd33);
 if (err) {
 dev_err(&pdev->dev,
 "Failed to enable 3.3V Vdd supply\n");
 goto fail_regulator1;
 }
 }

and later in the code check for NULL pointer before enabling the regulator.

>> +
>> + 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,12 @@ fail_add_hcd:
>>  fail_io:
>>   clk_disable_unprepare(exynos_ehci->clk);
>>  fail_clk:
>> + if (!IS_ERR(exynos_ehci->vdd10))
>> + regulator_disable(exynos_ehci->vdd10);
>> +fail_regulator2:
>> + if (!IS_ERR(exynos_ehci->vdd33))
>> +     regulator_disable(exynos_ehci->vdd33);
>
> Which means these regulator_disable() calls will crash when they
> dereference a NULL pointer.
>
> I think it would be simpler in the end to let a NULL pointer mean the
> regulator isn't present.  If devm_regulator_get_optional() returns an
> error, convert it to NULL (or don't do the assignment to
> exynos_ehci->vdd?? in the first place).
>
> The same criticism applies to the other patch in this series.

Sure, i will amend both the patches.

Thanks !

-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 1/2] usb: ehci-exynos: Make provision for vdd regulators

2015-06-08 Thread Vivek Gautam
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.

For example, patches for regulators' nodes:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
enable only minimum number of regulators on smdk5250.

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 on exynos systems.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Krzysztof Kozlowski 
Cc: Alan Stern 
---

These patches had long been posted, and i lost track of them.
My apologies for that.
Thanks to Krzysztof for catching this.

Kindly review.

Changes since v3:
 - added a if (!IS_ERR()) check for regulators before disabling
   them in error path.

Changes since v2:
 - replaced devm_regulator_get() with devm_regulator_get_optional().
 - Added Documentation for the vdd supplies for the controller.
 - Re-did the commit message.

 .../devicetree/bindings/usb/exynos-usb.txt |  2 +
 drivers/usb/host/ehci-exynos.c | 57 +-
 2 files changed, 58 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..160ad66 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,12 @@ fail_add_hcd:
 fail_io:
clk_disable_unprepare(exynos_ehci->clk);
 fail_clk:
+   if (!IS_ERR(exynos_ehci->vdd10))
+   regulator_disable(exynos_ehci->vdd10);
+fail_regulator2:
+   if (!IS_ERR(exynos_ehci->vdd33))
+   regulator_disable(exynos_ehci->vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
 }
@@ -246,6 +275,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 +302,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);
+
return rc;
 }
 
@@ -277,6 +316,22 @@ static int exynos_ehci_resume(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int ret;
 
+   if (!IS_ERR(exynos_ehci->vdd33)) {
+   ret = regulator_enable(exynos_ehci->vdd33);
+   if (ret) {
+   dev_

[PATCH v4 2/2] usb: ohci-exynos: Make provision for vdd regulators

2015-06-08 Thread Vivek Gautam
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.

For example, patches for regulators' nodes:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
enable only minimum number of regulators on smdk5250.

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 on exynos systems.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Krzysztof Kozlowski 
Cc: Alan Stern 
---

Changes since v3:
 - added a if (!IS_ERR()) check for regulators before disabling
   them in error path.

Changes since v2:
 - replaced devm_regulator_get() with devm_regulator_get_optional().
 - Added Documentation for the vdd supplies for the controller.
 - Re-did the commit message.

 .../devicetree/bindings/usb/exynos-usb.txt |  2 +
 .../devicetree/bindings/usb/exynos-usb.txt |  4 ++
 drivers/usb/host/ohci-exynos.c | 57 +-
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 776fa03..3883baa 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -63,6 +63,10 @@ Required properties:
  port 2 is HSIC phy1
- phys: from the *Generic PHY* bindings, specifying phy used by port.
 
+Optional properties:
+ - 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:
usb@1212 {
compatible = "samsung,exynos4210-ohci";
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 2cd105b..4d6dea4 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -36,6 +37,8 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 struct exynos_ohci_hcd {
struct clk *clk;
struct phy *phy[PHY_NUMBER];
+   struct regulator *vdd33;
+   struct regulator *vdd10;
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -139,7 +142,27 @@ static int exynos_ohci_probe(struct platform_device *pdev)
 
err = exynos_ohci_get_phy(&pdev->dev, exynos_ohci);
if (err)
-   goto fail_clk;
+   goto fail_regulator1;
+
+   exynos_ohci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
+   if (!IS_ERR(exynos_ohci->vdd33)) {
+   err = regulator_enable(exynos_ohci->vdd33);
+   if (err) {
+   dev_err(&pdev->dev,
+   "Failed to enable 3.3V Vdd supply\n");
+   goto fail_regulator1;
+   }
+   }
+
+   exynos_ohci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
+   if (!IS_ERR(exynos_ohci->vdd10)) {
+   err = regulator_enable(exynos_ohci->vdd10);
+   if (err) {
+   dev_err(&pdev->dev,
+   "Failed to enable 1.0V Vdd supply\n");
+   goto fail_regulator2;
+   }
+   }
 
 skip_phy:
exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
@@ -191,6 +214,12 @@ fail_add_hcd:
 fail_io:
clk_disable_unprepare(exynos_ohci->clk);
 fail_clk:
+   if (!IS_ERR(exynos_ohci->vdd10))
+   regulator_disable(exynos_ohci->vdd10);
+fail_regulator2:
+   if (!IS_ERR(exynos_ohci->vdd33))
+   regulator_disable(exynos_ohci->vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
 }
@@ -206,6 +235,11 @@ static int exynos_ohci_remove(struct platform_device *pdev)
 
clk_disable_unprepare(exynos_ohci->clk);
 
+   if (!IS_ERR(exynos_ohci->vdd33))
+   regulator_disable(exynos_ohci->vdd33);
+   if (!IS_ERR(exynos_ohci->vdd10))
+   regulator_disable(exynos_ohci->vdd10);
+
usb_put_hcd(hcd);
 
return 0;
@@ -234,6 +268,11 @@ static int exynos_ohci_suspend(struct device *dev)
 
clk_disable_unprepare(exynos_ohci->clk);
 
+   if (!IS_ERR(exynos_ohci->vdd33))
+   regulator_disable(exynos_ohci->vdd33);
+   if (!IS_ERR(exynos_ohci->vdd10))
+   regulator_disable(exynos_ohci->vdd10);
+
return 0;
 }
 
@@ -243,6 +282,22 @@ static int exynos_ohci_resume(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int ret;
 
+   if (!IS_ERR(exynos_ohci->vdd33)) {
+   ret =

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

2015-06-08 Thread Vivek Gautam

Hi,


On Monday, June 08, 2015 3:50 PM, "Anand Moon" 


On 8 June 2015 at 10:58, Vivek Gautam  wrote:

Hi,



On Monday, June 08, 2015 10:44 AM, "Krzysztof Kozlowski"
 wrote:

my apologies for being late in replying to this thread.


2015-06-08 13:21 GMT+09:00 Anand Moon :


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 get it. The patch you are referring to has a proper "From"
field. So please use it as an example.



I don't want to take any credit out of it. I just re-base on the new
kernel.


Perhaps, you would have maintained the authorship !


I could not test this patch as it meant for exynos5440 boards.



Are you sure? I think the driver is used on almost all of Exynos SoCs
(Exynos4, Exynos5250, Exynos542x).



That's correct, as pointed by Krzysztof Kozlowski, the driver is same for
Exynos4 and Exynos5 series
of SoCs.


Untested code should not go to the kernel. Additionally you should
mark it as not-tested. Marking such patch as non-tested could help you
finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with
proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing
IS_ERR(), how disabling the regulator during suspend affects waking
up).
3. The patchset must be tested, even after rebasing.



Unfortunately, I got busy  with a different project and lost track of the
patches posted upstream.
If it's not too late I can post a rebased version of the patch with 
previous

review comments addressed.



Best regards,
Krzysztof





Hi All,

I have learned my lesson not to interfere in others work.
It will never happen from my side again.

Please accept my apology.


Please don't apologise. It's just a part of learning; learning how linux 
mainlining works.

Hope you understand. :-)


thanks
Vivek 


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

2015-06-08 Thread Vivek Gautam



--
From: "Krzysztof Kozlowski" 
Sent: Monday, June 08, 2015 7:40 AM
To: "Anand Moon" ; "Rob Herring" 
; "Pawel Moll" ; "Mark Rutland" 
; "Ian Campbell" ; 
"Kumar Gala" ; "Kukjin Kim" ; "Alan 
Stern" ; "Greg Kroah-Hartman" 
; "Vivek Gautam" ; 
"Felipe Balbi" 
Cc: ; ; 
; ; 
; "Jingoo Han" 
Subject: Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd 
regulators



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.


---
 .../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 ye

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

2015-06-08 Thread Vivek Gautam

Hi,



On Monday, June 08, 2015 10:44 AM, "Krzysztof Kozlowski" 
 wrote:


my apologies for being late in replying to this thread.


2015-06-08 13:21 GMT+09:00 Anand Moon :

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 get it. The patch you are referring to has a proper "From"
field. So please use it as an example.



I don't want to take any credit out of it. I just re-base on the new 
kernel.

Perhaps, you would have maintained the authorship !


I could not test this patch as it meant for exynos5440 boards.


Are you sure? I think the driver is used on almost all of Exynos SoCs
(Exynos4, Exynos5250, Exynos542x).


That's correct, as pointed by Krzysztof Kozlowski, the driver is same for 
Exynos4 and Exynos5 series

of SoCs.


Untested code should not go to the kernel. Additionally you should
mark it as not-tested. Marking such patch as non-tested could help you
finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with
proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing
IS_ERR(), how disabling the regulator during suspend affects waking
up).
3. The patchset must be tested, even after rebasing.


Unfortunately, I got busy  with a different project and lost track of the 
patches posted upstream.
If it's not too late I can post a rebased version of the patch with previous 
review comments addressed.




Best regards,
Krzysztof 


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC

2015-03-25 Thread Vivek Gautam
On Thu, Mar 26, 2015 at 7:48 AM, Jaewon Kim  wrote:
> This patch adds driver data to support for Exynos5433 SoC.
> The Exynos5433 has one USB3.0 Host and USB3.0 DRD(Dual Role Device).
> Exynos5433 is simplar to Eyxnos7 but Exynos5433 have
> one more USB3.0 Host controller.
>
> Signed-off-by: Jaewon Kim 
> Tested-by: Chanwoo Choi 
> ---

Patch looks good to me.

Reviewed-by: Vivek Gautam 

>  .../devicetree/bindings/phy/samsung-phy.txt|3 ++-
>  drivers/phy/phy-exynos5-usbdrd.c   |   10 ++
>  include/linux/mfd/syscon/exynos5-pmu.h |3 +++
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 91e38cf..60c6f2a 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -128,6 +128,7 @@ Required properties:
>  - compatible : Should be set to one of the following supported values:
> - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
> - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
> +   - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC.
> - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
>  - reg : Register offset and length of USB DRD PHY register set;
>  - clocks: Clock IDs array as required by the controller
> @@ -139,7 +140,7 @@ Required properties:
>PHY operations, associated by phy name. It is used to
>determine bit values for clock settings register.
>For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
> -   - optional clocks: Exynos7 SoC has now following additional
> +   - optional clocks: Exynos5433 & Exynos7 SoC has now following 
> additional
>gate clocks available:
>- phy_pipe: for PIPE3 phy
>- phy_utmi: for UTMI+ phy
> diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
> b/drivers/phy/phy-exynos5-usbdrd.c
> index e2a0be7..d72ef15 100644
> --- a/drivers/phy/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/phy-exynos5-usbdrd.c
> @@ -624,6 +624,13 @@ static const struct exynos5_usbdrd_phy_drvdata 
> exynos5250_usbdrd_phy = {
> .has_common_clk_gate= true,
>  };
>
> +static const struct exynos5_usbdrd_phy_drvdata exynos5433_usbdrd_phy = {
> +   .phy_cfg= phy_cfg_exynos5,
> +   .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
> +   .pmu_offset_usbdrd1_phy = EXYNOS5433_USBHOST30_PHY_CONTROL,
> +   .has_common_clk_gate= false,
> +};
> +
>  static const struct exynos5_usbdrd_phy_drvdata exynos7_usbdrd_phy = {
> .phy_cfg= phy_cfg_exynos5,
> .pmu_offset_usbdrd0_phy = EXYNOS5_USBDRD_PHY_CONTROL,
> @@ -638,6 +645,9 @@ static const struct of_device_id 
> exynos5_usbdrd_phy_of_match[] = {
> .compatible = "samsung,exynos5420-usbdrd-phy",
> .data = &exynos5420_usbdrd_phy
> }, {
> +   .compatible = "samsung,exynos5433-usbdrd-phy",
> +   .data = &exynos5433_usbdrd_phy
> +   }, {
> .compatible = "samsung,exynos7-usbdrd-phy",
> .data = &exynos7_usbdrd_phy
> },
> diff --git a/include/linux/mfd/syscon/exynos5-pmu.h 
> b/include/linux/mfd/syscon/exynos5-pmu.h
> index 00ef24b..9352adc 100644
> --- a/include/linux/mfd/syscon/exynos5-pmu.h
> +++ b/include/linux/mfd/syscon/exynos5-pmu.h
> @@ -36,6 +36,9 @@
>  #define EXYNOS5420_MTCADC_PHY_CONTROL  (0x724)
>  #define EXYNOS5420_DPTX_PHY_CONTROL(0x728)
>
> +/* Exynos5433 specific register definitions */
> +#define EXYNOS5433_USBHOST30_PHY_CONTROL   (0x728)
> +
>  #define EXYNOS5_PHY_ENABLE     BIT(0)
>
>  #define EXYNOS5_MIPI_PHY_S_RESETN  BIT(1)
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: remove usb2-phy on Exynos5 series SoC

2015-03-12 Thread Vivek Gautam
Hi,


On Thu, Mar 12, 2015 at 3:40 PM, Jaewon Kim  wrote:
> Exynos5 series SoC does not have usb2-phy on USB3.0 Controller.
> It is controlled by only usb3-phy. So, this patch remove usb2-phy
> property.

Why would you want to remove the usb2-phy property ?
The usb2-phy projected here is actually the UTMI+ phy which is present
as a part of a hybrid PHY controller (that includes both UTMI+ as well
as PIPE3 phys).

And the exynos5-usbdrd phy driver also differentiates between the two PHYs.
It does try to separate out the initializations for UTMI+ and PIPE3
phy, if you notice
the functions:
exynos5_usbdrd_utmi_init() and exynos5_usbdrd_pipe3_init().

I don't think this change seems valid.

>
> Signed-off-by: Jaewon Kim 
> ---
>  arch/arm/boot/dts/exynos5250.dtsi |4 ++--
>  arch/arm/boot/dts/exynos5420.dtsi |8 
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 9bb1b0b..b58b169 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -565,8 +565,8 @@
> compatible = "synopsys,dwc3";
> reg = <0x1200 0x1>;
> interrupts = <0 72 0>;
> -   phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
> -   phy-names = "usb2-phy", "usb3-phy";
> +   phys = <&usbdrd_phy 0>;
> +   phy-names = "usb3-phy";
> };
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 9dc2e97..0df14bb 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -845,8 +845,8 @@
> compatible = "snps,dwc3";
> reg = <0x1200 0x1>;
> interrupts = <0 72 0>;
> -   phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>;
> -   phy-names = "usb2-phy", "usb3-phy";
> +   phys = <&usbdrd_phy0 0>;
> +   phy-names = "usb3-phy";
> };
> };
>
> @@ -871,8 +871,8 @@
> compatible = "snps,dwc3";
> reg = <0x1240 0x1>;
> interrupts = <0 73 0>;
> -   phys = <&usbdrd_phy1 0>, <&usbdrd_phy1 1>;
> -   phy-names = "usb2-phy", "usb3-phy";
> +       phys = <&usbdrd_phy1 1>;
> +   phy-names = "usb3-phy";
> };
> };
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] phy: exynos5-usbdrd: Fix off-by-one valid value checking for args->args[0]

2015-03-02 Thread Vivek Gautam

Hi,

On Friday, February 27, 2015 9:14 PM "Axel Lin"  wrote:

Current code uses args->args[0] as array subscript of phy_drd->phys[].
So the valid value range for args->args[0] is 0 ... EXYNOS5_DRDPHYS_NUM - 
1.


Signed-off-by: Axel Lin 


Reviewed by: Vivek Gautam 


---
drivers/phy/phy-exynos5-usbdrd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
b/drivers/phy/phy-exynos5-usbdrd.c

index 0437401..e2a0be7 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -531,7 +531,7 @@ static struct phy *exynos5_usbdrd_phy_xlate(struct 
device *dev,

{
 struct exynos5_usbdrd_phy *phy_drd = dev_get_drvdata(dev);

- if (WARN_ON(args->args[0] > EXYNOS5_DRDPHYS_NUM))
+ if (WARN_ON(args->args[0] >= EXYNOS5_DRDPHYS_NUM))
 return ERR_PTR(-ENODEV);

 return phy_drd->phys[args->args[0]].phy;
--
1.9.1



BRs
Vivek 


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 0/2] mmc: dw_mmc: exynos: Add HS400 support

2015-02-05 Thread Vivek Gautam
Hi,


On Fri, Feb 6, 2015 at 11:33 AM, Jaehoon Chung  wrote:
> Hi, Vivek.
>
> On 02/06/2015 02:52 PM, Vivek Gautam wrote:
>> Hi Jaehoon,
>>
>>
>> On Fri, Feb 6, 2015 at 6:48 AM, Jaehoon Chung  wrote:
>>> Hi, Alim.
>>>
>>> On my board, this patch isn't working fine.
>>> So when i complete to test on my board(exynos5), i will reply with comments.
>>> Sorry for late testing.
>>
>> I tested this series on linux-next, on Exynos5800-peach-pi board, and HS400
>> seems to be working fine.
>> I can see the card getting detected as HS400, and then i ran iozone as well.
>> The iozone numbers are also as required.
>>
>> On peach-pit board too, the HS200 mode seems to be working good.
>>
>> What are the observations you saw on your board ?
>
> Thanks for testing on your board. I have exynos5422 and exynos5433.(One is 
> eMMC5.0, other is eMMC5.1)
> I want to see that it's working fine on my board.
> I should miss something..so i will check more detail after complete my other 
> job, or on this weekend.
> (It failed for hs400 tuning sequence..I needs to check that it has the board 
> dependency)

Ok
Thanks for testing it on your side.

>
> Best Regards,
> Jaehoon Chung
>
>>
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>> On 01/29/2015 11:41 AM, Alim Akhtar wrote:
>>>> This adds HS400 mode support for exynos dw_mmc host controller.
>>>>
>>>> Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 
>>>> mode.
>>>> Tested HS200 mode with this series applied, HS200 still works.
>>>>
>>>> Appreciate testing on other exynos5/7 platform which supports emmc5.0
>>>>
>>>> Changes in V5:
>>>>   * Enable HS400 on Exynos5800-peach-pi boards
>>>>   * Addressed other review comments from Jaehoon Chung
>>>>
>>>> Changes in V4:
>>>>   * drop the idea of changing existing binding for ciu_div as per [1]
>>>> * addressed comments from Jaehoon Chung [2]
>>>>
>>>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html
>>>> [2] http://www.spinics.net/lists/devicetree/msg64373.html
>>>>
>>>> Changes in V3:
>>>>   rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block 
>>>> patterns static)
>>>>
>>>> Seungwon Jeon (2):
>>>>   mmc: dw_mmc: exynos: Support eMMC's HS400 mode
>>>>   ARM: dts: Add HS400 support for exynos5420 and exynos5800
>>>>
>>>>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 +
>>>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +-
>>>>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 +
>>>>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |4 +-
>>>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |    7 +-
>>>>  drivers/mmc/host/dw_mmc-exynos.c   |  185 
>>>> 
>>>>  drivers/mmc/host/dw_mmc-exynos.h   |   19 +-
>>>>  drivers/mmc/host/dw_mmc.c  |   16 +-
>>>>  drivers/mmc/host/dw_mmc.h  |2 +
>>>>  9 files changed, 213 insertions(+), 38 deletions(-)
>>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 0/2] mmc: dw_mmc: exynos: Add HS400 support

2015-02-05 Thread Vivek Gautam
Hi Jaehoon,


On Fri, Feb 6, 2015 at 6:48 AM, Jaehoon Chung  wrote:
> Hi, Alim.
>
> On my board, this patch isn't working fine.
> So when i complete to test on my board(exynos5), i will reply with comments.
> Sorry for late testing.

I tested this series on linux-next, on Exynos5800-peach-pi board, and HS400
seems to be working fine.
I can see the card getting detected as HS400, and then i ran iozone as well.
The iozone numbers are also as required.

On peach-pit board too, the HS200 mode seems to be working good.

What are the observations you saw on your board ?

>
> Best Regards,
> Jaehoon Chung
>
> On 01/29/2015 11:41 AM, Alim Akhtar wrote:
>> This adds HS400 mode support for exynos dw_mmc host controller.
>>
>> Currently tested on Exynos5800-peach-pi and Exyons7 platform for HS400 mode.
>> Tested HS200 mode with this series applied, HS200 still works.
>>
>> Appreciate testing on other exynos5/7 platform which supports emmc5.0
>>
>> Changes in V5:
>>   * Enable HS400 on Exynos5800-peach-pi boards
>>   * Addressed other review comments from Jaehoon Chung
>>
>> Changes in V4:
>>   * drop the idea of changing existing binding for ciu_div as per [1]
>> * addressed comments from Jaehoon Chung [2]
>>
>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg40923.html
>> [2] http://www.spinics.net/lists/devicetree/msg64373.html
>>
>> Changes in V3:
>>   rebased on ulf's next (commit: 607b448 mmc: core: Make tuning block 
>> patterns static)
>>
>> Seungwon Jeon (2):
>>   mmc: dw_mmc: exynos: Support eMMC's HS400 mode
>>   ARM: dts: Add HS400 support for exynos5420 and exynos5800
>>
>>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 +
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +-
>>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 +
>>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |4 +-
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |7 +-
>>  drivers/mmc/host/dw_mmc-exynos.c   |  185 
>> 
>>  drivers/mmc/host/dw_mmc-exynos.h   |   19 +-
>>  drivers/mmc/host/dw_mmc.c  |   16 +-
>>  drivers/mmc/host/dw_mmc.h  |2 +
>>  9 files changed, 213 insertions(+), 38 deletions(-)
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V7 RESEND 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

2015-02-02 Thread Vivek Gautam
Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 1 file changed, 203 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 0437401..5834529 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -37,13 +37,11 @@
 
 /* EXYNOS5: USB 3.0 DRD PHY registers */
 #define EXYNOS5_DRD_LINKSYSTEM 0x04
-
 #define LINKSYSTEM_FLADJ_MASK  (0x3f << 1)
 #define LINKSYSTEM_FLADJ(_x)   ((_x) << 1)
 #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27)
 
 #define EXYNOS5_DRD_PHYUTMI0x08
-
 #define PHYUTMI_OTGDISABLE BIT(6)
 #define PHYUTMI_FORCESUSPEND   BIT(1)
 #define PHYUTMI_FORCESLEEP BIT(0)
@@ -51,26 +49,20 @@
 #define EXYNOS5_DRD_PHYPIPE0x0c
 
 #define EXYNOS5_DRD_PHYCLKRST  0x10
-
 #define PHYCLKRST_EN_UTMISUSPEND   BIT(31)
-
 #define PHYCLKRST_SSC_REFCLKSEL_MASK   (0xff << 23)
 #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23)
-
 #define PHYCLKRST_SSC_RANGE_MASK   (0x03 << 21)
 #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21)
-
 #define PHYCLKRST_SSC_EN   BIT(20)
 #define PHYCLKRST_REF_SSP_EN   BIT(19)
 #define PHYCLKRST_REF_CLKDIV2  BIT(18)
-
 #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF   (0x19 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF  (0x32 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
-
 #define PHYCLKRST_FSEL_UTMI_MASK   (0x7 << 5)
 #define PHYCLKRST_FSEL_PIPE_MASK   (0x7 << 8)
 #define PHYCLKRST_FSEL(_x) ((_x) << 5)
@@ -78,46 +70,68 @@
 #define PHYCLKRST_FSEL_PAD_24MHZ   (0x2a << 5)
 #define PHYCLKRST_FSEL_PAD_20MHZ   (0x31 << 5)
 #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
-
 #define PHYCLKRST_RETENABLEN   BIT(4)
-
 #define PHYCLKRST_REFCLKSEL_MASK   (0x03 << 2)
 #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
 #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
-
 #define PHYCLKRST_PORTRESETBIT(1)
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
-
 #define PHYPARAM0_REF_USE_PAD  BIT(31)
 #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26)
 #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
 
 #define EXYNOS5_DRD_PHYPARAM1  0x20
-
 #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
 #define PHYPARAM1_PCS_TXDEEMPH (0x1c)
 
 #define EXYNOS5_DRD_PHYTERM0x24
 
 #define EXYNOS5_DRD_PHYTEST0x28
-
 #define PHYTEST_POWERDOWN_SSP  BIT(3)
 #define PHYTEST_POWERDOWN_HSP  BIT(2)
 
 #define EXYNOS5_DR

[PATCH V7 RESEND 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

2015-02-02 Thread Vivek Gautam
The host controller by itself may sometimes need to handle PHY
and re-initialize it to re-configure some of the PHY parameters
to get full support out of the PHY controller.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/host/xhci-plat.c |   74 ++
 1 file changed, 74 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..c478627 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -127,10 +128,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
 
+   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->phy)) {
+   ret = PTR_ERR(hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto disable_clk;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb2 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
 
+   /*
+* Initialize and power-on USB 2.0 PHY
+* FIXME: Isn't this a hacky way of initializing the PHY again ?
+* xhci's parent would have already initialized the PHY, but we
+* wanna do it again.
+*/
+   hcd->phy->init_count = 0;
+   ret = phy_init(hcd->phy);
+   if (ret)
+   goto dealloc_usb2_hcd;
+
+   hcd->phy->power_count = 0;
+   ret = phy_power_on(hcd->phy);
+   if (ret) {
+   phy_exit(hcd->phy);
+   goto dealloc_usb2_hcd;
+   }
+
device_wakeup_enable(hcd->self.controller);
 
/* USB 2.0 roothub is stored in the platform_device now. */
@@ -156,12 +188,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
+   if (IS_ERR(xhci->shared_hcd->phy)) {
+   ret = PTR_ERR(xhci->shared_hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto put_usb3_hcd;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   xhci->shared_hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb3 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
 
+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+
return 0;
 
+dealloc_usb3_hcd:
+   usb_remove_hcd(xhci->shared_hcd);
+
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
@@ -184,9 +245,15 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   phy_power_off(xhci->shared_hcd->phy);
+   phy_exit(xhci->shared_hcd->phy);
+
usb_remove_hcd(xhci->shared_hcd);
usb_put_hcd(xhci->shared_hcd);
 
+   phy_power_off(hcd->phy);
+   phy_exit(hcd->phy);
+
usb_remove_hcd(hcd);
if (!IS_ERR(clk))
clk_disable_unprepare(clk);
@@ -202,6 +269,8 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   phy_exit(hcd->phy);
+
/*
 * xhci_suspend() needs `do_wakeup` to know whether host is allowed
 * to do wakeup during suspend. Since xhci_plat_suspend is currently
@@ -217,6 +286,11 @@ static int xhci_plat_resume(struct device *dev)
 {
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   int ret;
+
+   ret = phy_init(hcd->phy);
+   if (ret)
+   return ret;
 

[PATCH V7 RESEND 0/2] Fine tune USB 3.0 PHY on exynos5420

2015-02-02 Thread Vivek Gautam
This series is tested on usb-next with Heikki's patch [1]:
base: platform: name the device already during allocation

Changes since v6:
 - Dropped the changes for adding additional phy_calibrate() callback.
 - Added phy_init() and phy_power_on() sequence in xhci-plat driver;
   NOTE: both phy_init() and phy_power_on() will now require PHY's
 'init_count' and 'power_count' to be reset to '0' so that
 we can actually re-initialize the phy. Though this has already been
 pointed out in discussion for the previous patch-series. [2]
 - Refactored return codes and error handling in cr_port functions as pointed
   out by Felipe.

Changes since v5:
 - Assigned NULL to hcd->gen_phy in error path in xhci-plat.c, so that
   we don't need to check for IS_ERR() while calibrating the PHYs in
   core/hcd.c
 - Removed extra empty lines in register definitions in exynos5-usbdrd
   phy driver.
 - Added write access for EXYNOS5_DRD_PHYREG0 register before any
   crport_handshake() call as suggested by Jingoo Han.
 - Renamed member 'calibrate' to 'phy_exynos_calibrate' of
   struct exynos5_usbdrd_phy_drvdata.

Changes since v4:
 - Rebased on latest patches by Heikki.
 - Took care of handling -EPROBE_DEFER error number while getting PHY in
   xhci plat.

Changes from v3:
 - Modified error message as per review comments from Julius.

Changes since v2:
 - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy,
   in order to make it more generic.
 - Moved the phy_calibration calls to core/hcd.c to enable a more generic
   solution for issues of calibrating the PHYs.

Changes since v1:
 - Using 'gen_phy' member of 'hcd' instead of declaring more variables
   to hold phys.
 - Added a check for compatible match for 'Synopsys-dwc3' controller,
   since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY
   in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that,
   instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs
   (main hcd and shared hcd).
 - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()'
   to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3
   controller while trying to calibrate the PHY.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420/5800
SoCs is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://lkml.org/lkml/2014/11/19/367
[2] https://lkml.org/lkml/2014/9/2/170;   (to be specific 
https://lkml.org/lkml/2014/9/10/132)

Vivek Gautam (2):
  usb: host: xhci-plat: Get PHYs for xhci's hcds
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 drivers/usb/host/xhci-plat.c |   74 +
 2 files changed, 277 insertions(+), 16 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block

2015-01-13 Thread Vivek Gautam
Hi Padma,


On Fri, Dec 19, 2014 at 6:53 PM, Padmavathi Venna  wrote:
> Add required clk support for I2S,PCM amd SPDIF
>
> Signed-off-by: Padmavathi Venna 
> ---

verified from Exynos7 datasheet. The patch looks good.
Reviewed-by: Vivek Gautam 

>  .../devicetree/bindings/clock/exynos7-clock.txt|6 +
>  drivers/clk/samsung/clk-exynos7.c  |  144 
> +++-
>  include/dt-bindings/clock/exynos7-clk.h|   24 +++-
>  3 files changed, 169 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
> index 6d3d5f8..3b439ed 100644
> --- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos7-clock.txt
> @@ -34,6 +34,7 @@ Required Properties for Clock Controller:
> - "samsung,exynos7-clock-peris"
> - "samsung,exynos7-clock-fsys0"
> - "samsung,exynos7-clock-fsys1"
> +   - "samsung,exynos7-clock-aud"
>
>   - reg: physical base address of the controller and the length of
> memory mapped region.
> @@ -53,6 +54,7 @@ Input clocks for top0 clock controller:
> - dout_sclk_bus1_pll
> - dout_sclk_cc_pll
> - dout_sclk_mfc_pll
> +   - dout_sclk_aud_pll
>
>  Input clocks for top1 clock controller:
> - fin_pll
> @@ -91,3 +93,7 @@ Input clocks for fsys1 clock controller:
> - dout_aclk_fsys1_200
> - dout_sclk_mmc0
> - dout_sclk_mmc1
> +
> +Input clocks for aud clock controller:
> +   - fin_pll
> +   - fout_aud_pll
> diff --git a/drivers/clk/samsung/clk-exynos7.c 
> b/drivers/clk/samsung/clk-exynos7.c
> index cf5e50e..e4bc241 100644
> --- a/drivers/clk/samsung/clk-exynos7.c
> +++ b/drivers/clk/samsung/clk-exynos7.c
> @@ -45,6 +45,7 @@ static struct samsung_fixed_factor_clock 
> topc_fixed_factor_clks[] __initdata = {
>  };
>
>  /* List of parent clocks for Muxes in CMU_TOPC */
> +PNAME(mout_aud_pll_ctrl_p) = { "fin_pll", "fout_aud_pll" };
>  PNAME(mout_bus0_pll_ctrl_p)= { "fin_pll", "fout_bus0_pll" };
>  PNAME(mout_bus1_pll_ctrl_p)= { "fin_pll", "fout_bus1_pll" };
>  PNAME(mout_cc_pll_ctrl_p)  = { "fin_pll", "fout_cc_pll" };
> @@ -104,6 +105,7 @@ static struct samsung_mux_clock topc_mux_clks[] 
> __initdata = {
>
> MUX(0, "mout_sclk_bus0_pll_out", mout_sclk_bus0_pll_out_p,
> MUX_SEL_TOPC1, 16, 1),
> +   MUX(0, "mout_aud_pll_ctrl", mout_aud_pll_ctrl_p, MUX_SEL_TOPC1, 0, 1),
>
> MUX(0, "mout_aclk_ccore_133", mout_topc_group2, MUX_SEL_TOPC2, 4, 2),
>
> @@ -125,6 +127,13 @@ static struct samsung_div_clock topc_div_clks[] 
> __initdata = {
> DIV_TOPC3, 12, 3),
> DIV(DOUT_SCLK_MFC_PLL, "dout_sclk_mfc_pll", "mout_mfc_pll_ctrl",
> DIV_TOPC3, 16, 3),
> +   DIV(DOUT_SCLK_AUD_PLL, "dout_sclk_aud_pll", "mout_aud_pll_ctrl",
> +   DIV_TOPC3, 28, 3),
> +};
> +
> +static struct samsung_pll_rate_table pll1460x_24mhz_tbl[] __initdata = {
> +   PLL_36XX_RATE(49152, 20, 1, 0, 31457),
> +   {},
>  };
>
>  static struct samsung_pll_clock topc_pll_clks[] __initdata = {
> @@ -136,8 +145,8 @@ static struct samsung_pll_clock topc_pll_clks[] 
> __initdata = {
> BUS1_DPLL_CON0, NULL),
> PLL(pll_1452x, 0, "fout_mfc_pll", "fin_pll", MFC_PLL_LOCK,
> MFC_PLL_CON0, NULL),
> -   PLL(pll_1460x, 0, "fout_aud_pll", "fin_pll", AUD_PLL_LOCK,
> -   AUD_PLL_CON0, NULL),
> +   PLL(pll_1460x, FOUT_AUD_PLL, "fout_aud_pll", "fin_pll", AUD_PLL_LOCK,
> +   AUD_PLL_CON0, pll1460x_24mhz_tbl),
>  };
>
>  static struct samsung_cmu_info topc_cmu_info __initdata = {
> @@ -166,13 +175,16 @@ CLK_OF_DECLARE(exynos7_clk_topc, 
> "samsung,exynos7-clock-topc",
>  #define MUX_SEL_TOP00  0x0200
>  #define MUX_SEL_TOP01  0x0204
>  #define MUX_SEL_TOP03  0x020C
> +#define MUX_SEL_TOP0_PERIC00x0230
>  #define MUX_SEL_TOP0_PERIC10x0234
>  #define MUX_SEL_TOP0_PERIC20x0238
>  #define MUX_SEL_TOP0_PERIC30x023C
>  #define DIV_TOP03  0x060C
> +#define DIV_TOP0_PERIC00x0630
>  #define DIV_TOP0_PERIC10x0634
>  #define DIV_TOP0_PERIC20x0638
>  #defi

Re: [PATCH 2/4] clk: samsung: exynos7: add clocks for SPI block

2015-01-09 Thread Vivek Gautam
On Fri, Jan 9, 2015 at 5:18 PM, Vivek Gautam  wrote:
> Hi Padma,
>
>
> On Fri, Dec 19, 2014 at 6:53 PM, Padmavathi Venna  wrote:
>> Add clock support for 5 SPI channels.
>>
>> Signed-off-by: Padmavathi Venna 
>> ---
>>  drivers/clk/samsung/clk-exynos7.c   |   73 
>> +++
>>  include/dt-bindings/clock/exynos7-clk.h |   22 -
>>  2 files changed, 93 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos7.c 
>> b/drivers/clk/samsung/clk-exynos7.c
>> index 954f9a0..cf5e50e 100644
>> --- a/drivers/clk/samsung/clk-exynos7.c
>> +++ b/drivers/clk/samsung/clk-exynos7.c
>> @@ -166,9 +166,15 @@ CLK_OF_DECLARE(exynos7_clk_topc, 
>> "samsung,exynos7-clock-topc",
>>  #define MUX_SEL_TOP00  0x0200
>>  #define MUX_SEL_TOP01  0x0204
>>  #define MUX_SEL_TOP03  0x020C
>> +#define MUX_SEL_TOP0_PERIC10x0234
>> +#define MUX_SEL_TOP0_PERIC20x0238
>>  #define MUX_SEL_TOP0_PERIC30x023C
>>  #define DIV_TOP03  0x060C
>> +#define DIV_TOP0_PERIC10x0634
>> +#define DIV_TOP0_PERIC20x0638
>>  #define DIV_TOP0_PERIC30x063C
>> +#define ENABLE_SCLK_TOP0_PERIC10x0A34
>> +#define ENABLE_SCLK_TOP0_PERIC20x0A38
>>  #define ENABLE_SCLK_TOP0_PERIC30x0A3C
>>
>>  /* List of parent clocks for Muxes in CMU_TOP0 */
>> @@ -194,9 +200,15 @@ static unsigned long top0_clk_regs[] __initdata = {
>> MUX_SEL_TOP00,
>> MUX_SEL_TOP01,
>> MUX_SEL_TOP03,
>> +   MUX_SEL_TOP0_PERIC1,
>> +   MUX_SEL_TOP0_PERIC2,
>> MUX_SEL_TOP0_PERIC3,
>> DIV_TOP03,
>> +   DIV_TOP0_PERIC1,
>> +   DIV_TOP0_PERIC2,
>> DIV_TOP0_PERIC3,
>> +   ENABLE_SCLK_TOP0_PERIC1,
>> +   ENABLE_SCLK_TOP0_PERIC2,
>> ENABLE_SCLK_TOP0_PERIC3,
>>  };
>>
>> @@ -218,10 +230,16 @@ static struct samsung_mux_clock top0_mux_clks[] 
>> __initdata = {
>> MUX(0, "mout_aclk_peric1_66", mout_top0_group1, MUX_SEL_TOP03, 12, 
>> 2),
>> MUX(0, "mout_aclk_peric0_66", mout_top0_group1, MUX_SEL_TOP03, 20, 
>> 2),
>>
>> +   MUX(0, "mout_sclk_spi1", mout_top0_group1, MUX_SEL_TOP0_PERIC1, 8, 
>> 2),
>> +   MUX(0, "mout_sclk_spi0", mout_top0_group1, MUX_SEL_TOP0_PERIC1, 20, 
>> 2),
>> +
>> +   MUX(0, "mout_sclk_spi3", mout_top0_group1, MUX_SEL_TOP0_PERIC2, 8, 
>> 2),
>> +   MUX(0, "mout_sclk_spi2", mout_top0_group1, MUX_SEL_TOP0_PERIC2, 20, 
>> 2),
>> MUX(0, "mout_sclk_uart3", mout_top0_group1, MUX_SEL_TOP0_PERIC3, 4, 
>> 2),
>> MUX(0, "mout_sclk_uart2", mout_top0_group1, MUX_SEL_TOP0_PERIC3, 8, 
>> 2),
>> MUX(0, "mout_sclk_uart1", mout_top0_group1, MUX_SEL_TOP0_PERIC3, 12, 
>> 2),
>> MUX(0, "mout_sclk_uart0", mout_top0_group1, MUX_SEL_TOP0_PERIC3, 16, 
>> 2),
>> +   MUX(0, "mout_sclk_spi4", mout_top0_group1, MUX_SEL_TOP0_PERIC3, 20, 
>> 2),
>>  };
>>
>>  static struct samsung_div_clock top0_div_clks[] __initdata = {
>> @@ -230,13 +248,29 @@ static struct samsung_div_clock top0_div_clks[] 
>> __initdata = {
>> DIV(DOUT_ACLK_PERIC0, "dout_aclk_peric0_66", "mout_aclk_peric0_66",
>> DIV_TOP03, 20, 6),
>>
>> +   DIV(0, "dout_sclk_spi1", "mout_sclk_spi1", DIV_TOP0_PERIC1, 8, 12),
>> +   DIV(0, "dout_sclk_spi0", "mout_sclk_spi0", DIV_TOP0_PERIC1, 20, 12),
>> +
>> +   DIV(0, "dout_sclk_spi3", "mout_sclk_spi3", DIV_TOP0_PERIC2, 8, 12),
>> +   DIV(0, "dout_sclk_spi2", "mout_sclk_spi2", DIV_TOP0_PERIC2, 20, 12),
>> +
>> DIV(0, "dout_sclk_uart3", "mout_sclk_uart3", DIV_TOP0_PERIC3, 4, 4),
>> DIV(0, "dout_sclk_uart2", "mout_sclk_uart2", DIV_TOP0_PERIC3, 8, 4),
>> DIV(0, "dout_sclk_uart1", "mout_sclk_uart1", DIV_TOP0_PERIC3, 12, 4),
>> DIV(0, "dout_sclk_uart0", "mout_sclk_uart0", DIV_TOP0_PERIC3, 16, 4),
>> +   DIV(0, "dout_sclk_spi4", "mout_sclk_spi4", DIV_TOP0_PERIC3, 20, 12),
>>  };
>>
>>  static struct samsung_gate_clock top0_gate_clks[] __

Re: [PATCH 2/4] clk: samsung: exynos7: add clocks for SPI block

2015-01-09 Thread Vivek Gautam
 "sclk_uart3_user", "mout_sclk_uart3_user",
> ENABLE_SCLK_PERIC10, 11, 0, 0),
> +   GATE(SCLK_SPI0, "sclk_spi0_user", "mout_sclk_spi0_user",
> +   ENABLE_SCLK_PERIC10, 12, CLK_SET_RATE_PARENT, 0),
> +   GATE(SCLK_SPI1, "sclk_spi1_user", "mout_sclk_spi1_user",
> +   ENABLE_SCLK_PERIC10, 13, CLK_SET_RATE_PARENT, 0),
> +   GATE(SCLK_SPI2, "sclk_spi2_user", "mout_sclk_spi2_user",
> +   ENABLE_SCLK_PERIC10, 14, CLK_SET_RATE_PARENT, 0),
> +   GATE(SCLK_SPI3, "sclk_spi3_user", "mout_sclk_spi3_user",
> +   ENABLE_SCLK_PERIC10, 15, CLK_SET_RATE_PARENT, 0),
> +   GATE(SCLK_SPI4, "sclk_spi4_user", "mout_sclk_spi4_user",
> +   ENABLE_SCLK_PERIC10, 16, CLK_SET_RATE_PARENT, 0),
>  };
>
>  static struct samsung_cmu_info peric1_cmu_info __initdata = {
> diff --git a/include/dt-bindings/clock/exynos7-clk.h 
> b/include/dt-bindings/clock/exynos7-clk.h
> index a6c4d8e..3bba9ec 100644
> --- a/include/dt-bindings/clock/exynos7-clk.h
> +++ b/include/dt-bindings/clock/exynos7-clk.h
> @@ -26,7 +26,13 @@
>  #define CLK_SCLK_UART1 4
>  #define CLK_SCLK_UART2 5
>  #define CLK_SCLK_UART3 6
> -#define TOP0_NR_CLK7
> +#define CLK_SCLK_SPI0  7
> +#define CLK_SCLK_SPI1  8
> +#define CLK_SCLK_SPI2  9
> +#define CLK_SCLK_SPI3  10
> +#define CLK_SCLK_SPI4  11
> +#define CLK_SCLK_SPI5  12

I don't see this CLK_SCLK_SPI5 being used anywhere in the patch.
Possibly you didn't want to add it here.

> +#define TOP0_NR_CLK13
>
>  /* TOP1 */
>  #define DOUT_ACLK_FSYS1_2001
> @@ -70,7 +76,19 @@
>  #define PCLK_HSI2C69
>  #define PCLK_HSI2C710
>  #define PCLK_HSI2C811
> -#define PERIC1_NR_CLK  12
> +#define PCLK_SPI0  12
> +#define PCLK_SPI1  13
> +#define PCLK_SPI2  14
> +#define PCLK_SPI3  15
> +#define PCLK_SPI4  16
> +#define PCLK_SPI5  17
> +#define SCLK_SPI0  18
> +#define SCLK_SPI1  19
> +#define SCLK_SPI2  20
> +#define SCLK_SPI3  21
> +#define SCLK_SPI4  22
> +#define SCLK_SPI5  23

Same here for SCLK_SPI5, unused in the patch.

[snip]

The rest all looks good in this patch. I have also verified from the Exynos7 UM.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] arm64: dts: exynos7: Fix wrong base address of i2c7 bus

2015-01-09 Thread Vivek Gautam
Hi Padma,


On Fri, Dec 19, 2014 at 7:03 PM, Padmavathi Venna  wrote:
> I2C7 base address corrected.
>
> Signed-off-by: Padmavathi Venna 
> ---

Verified from Exynos7 datasheet. LGTM.

Reviewed-by: Vivek Gautam 

>  arch/arm64/boot/dts/exynos/exynos7.dtsi |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index db7058a..84a57c8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -386,9 +386,9 @@
> status = "disabled";
> };
>
> -   hsi2c_7: hsi2c@13e1 {
> +   hsi2c_7: hsi2c@14e1 {
> compatible = "samsung,exynos7-hsi2c";
> -   reg = <0x13e1 0x1000>;
> +   reg = <0x14e1 0x1000>;
> interrupts = <0 462 0>;
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 1.7.4.4



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/4] phy: samsung-usb2: Add support for Vbus regulator

2014-12-11 Thread Vivek Gautam
On Thu, Dec 11, 2014 at 5:52 PM, David Laight  wrote:
> From: Vivek Gautam
>> This has been on my to-do list for sometime.
>> Until now the host controller (specifically ehci-exynos) is responsible
>> for enabling VBUS supply. This opens up one more issue which is, when
>> only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was
>> never enabled (since ohci did not have the code to enabled the VBUS supply).
>>
>> Rather it should be wise to move the VBUS related stuff to phy driver and
>> let phy take care of enabling it.
>>
>> This patch series adds that VBUS regulator to phy-samsung-usb2 driver,
>> adds necessary binding information as well as vbus-supply properties
>> to phy nodes on exynos5250 systems.
> ...
>
> Does this go anyway to allowing devices to be powered from a micro-usb
> connector while acting as a USB host (USB OTG).
> ie when you want VBUS disabled even though it would normally
> need to be enabled.

Sorry i didn't get your second line.

This change allows HOST and HSIC phys to enable VBUS for the devices
connected to it.
Although now i think there can be a flaw in this approach
when only in OTG mode, when DEVICE phy is being used, even then
the regulator will be turned on causing power unnecessary consumption.




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/4] arm: dts: exynos5250: Remove vbus gpio property from usb 2.0 host

2014-12-11 Thread Vivek Gautam
Now that we can use the VBUS regulator for USB 2.0 phy, we can
remove the vbus-gpio property from usb 2.0 host to avoid
duplicate gpio settings.

Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 
 arch/arm/boot/dts/exynos5250-snow.dts |4 
 2 files changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 85e74df..281b962 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -372,10 +372,6 @@
enable-active-high;
};
 
-   usb@1211 {
-   samsung,vbus-gpio = <&gpx2 6 0>;
-   };
-
dp-controller@145B {
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 8085750..ee966c3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -296,10 +296,6 @@
enable-active-high;
};
 
-   usb@1211 {
-   samsung,vbus-gpio = <&gpx1 1 0>;
-   };
-
fixed-rate-clocks {
xxti {
compatible = "samsung,clock-xxti";
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/4] arm: dts: exynos5250: Use regulator for USB 2.0 VBUS supply

2014-12-11 Thread Vivek Gautam
Start using VBUS regulator for USB 2.0 phy, so that we can
remove the gpio property from host's node later.

Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   22 ++
 arch/arm/boot/dts/exynos5250-snow.dts |   22 ++
 2 files changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a759100..85e74df 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -361,6 +361,17 @@
samsung,audio-codec = <&wm8994>;
};
 
+   usb2_vbus_reg: regulator-usb2 {
+   compatible = "regulator-fixed";
+   regulator-name = "P5.0V_USB2";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpx2 6 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb2_vbus_en>;
+   enable-active-high;
+   };
+
usb@1211 {
samsung,vbus-gpio = <&gpx2 6 0>;
};
@@ -418,4 +429,15 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   usb2_vbus_en: usb2-vbus-en {
+   samsung,pins = "gpx2-6";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+};
+
+&usb2_phy_gen {
+   vbus-supply = <&usb2_vbus_reg>;
 };
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 60429ad..8085750 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -285,6 +285,17 @@
vbus-supply = <&usb3_vbus_reg>;
};
 
+   usb2_vbus_reg: regulator-usb2 {
+   compatible = "regulator-fixed";
+   regulator-name = "P5.0V_USB2";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpx1 1 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb2_vbus_en>;
+   enable-active-high;
+   };
+
usb@1211 {
samsung,vbus-gpio = <&gpx1 1 0>;
};
@@ -616,6 +627,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+   usb2_vbus_en: usb2-vbus-en {
+   samsung,pins = "gpx1-1";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
 };
 
 &spi_1 {
@@ -628,4 +646,8 @@
dr_mode = "host";
 };
 
+&usb2_phy_gen {
+   vbus-supply = <&usb2_vbus_reg>;
+};
+
 #include "cros-ec-keyboard.dtsi"
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] phy: samsung-usb2: Add facility for VBUS supply

2014-12-11 Thread Vivek Gautam
Adding support to enable/disable VBUS controlled by a regulator
on USB 2.0 port.
This is a part of moving vbus setting out of ehci-exynos.
Since vbus can be handled by USB 2.0 phy itself, so the host
need not care about it.
Moreover, setting VBUS in USB 2.0 phy helps both ehci as well
as ohci. This issue was not taken care of until now; when
ehci is not enabled and only ohci is enabled the VBUS was never
set.

Keeping the vbus setting code in ehci-exynos intact for now
to keep supporting older dt bindings.

Signed-off-by: Vivek Gautam 
---
 .../devicetree/bindings/phy/samsung-phy.txt|3 ++
 drivers/phy/phy-samsung-usb2.c |   30 
 drivers/phy/phy-samsung-usb2.h |1 +
 3 files changed, 34 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 0090ad1..44d82ba 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -44,6 +44,9 @@ Required properties:
- the "ref" clock is used to get the rate of the clock provided to the
  PHY module
 
+Optional properties:
+- vbus-supply : Reference to regulator node which supplies VBUS on the PHY.
+
 The first phandle argument in the PHY specifier identifies the PHY, its
 meaning is compatible dependent. For the currently supported SoCs (Exynos 4210
 and Exynos 4212) it is as follows:
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index 4a12f66..7fe7c84 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "phy-samsung-usb2.h"
 
@@ -33,6 +34,16 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
ret = clk_prepare_enable(drv->ref_clk);
if (ret)
goto err_instance_clk;
+
+   /* Enable VBUS supply */
+   if (drv->vbus) {
+   ret = regulator_enable(drv->vbus);
+   if (ret) {
+   dev_err(drv->dev, "Failed to enable VBUS supply\n");
+   goto err_fail_vbus;
+   }
+   }
+
if (inst->cfg->power_on) {
spin_lock(&drv->lock);
ret = inst->cfg->power_on(inst);
@@ -41,6 +52,8 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
 
return 0;
 
+err_fail_vbus:
+   clk_disable_unprepare(drv->ref_clk);
 err_instance_clk:
clk_disable_unprepare(drv->clk);
 err_main_clk:
@@ -60,8 +73,14 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
ret = inst->cfg->power_off(inst);
spin_unlock(&drv->lock);
}
+
+   /* Disable VBUS supply */
+   if (drv->vbus)
+   regulator_disable(drv->vbus);
+
clk_disable_unprepare(drv->ref_clk);
clk_disable_unprepare(drv->clk);
+
return ret;
 }
 
@@ -197,6 +216,17 @@ static int samsung_usb2_phy_probe(struct platform_device 
*pdev)
return ret;
}
 
+   /* Get Vbus regulators */
+   drv->vbus = devm_regulator_get(dev, "vbus");
+   if (IS_ERR(drv->vbus)) {
+   ret = PTR_ERR(drv->vbus);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   dev_warn(dev, "Failed to get VBUS supply regulator\n");
+   drv->vbus = NULL;
+   }
+
for (i = 0; i < drv->cfg->num_phys; i++) {
char *label = drv->cfg->phys[i].label;
struct samsung_usb2_phy_instance *p = &drv->instances[i];
diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
index 44bead9..cb92e3e 100644
--- a/drivers/phy/phy-samsung-usb2.h
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -43,6 +43,7 @@ struct samsung_usb2_phy_driver {
void __iomem *reg_phy;
struct regmap *reg_pmu;
struct regmap *reg_sys;
+   struct regulator *vbus;
spinlock_t lock;
struct samsung_usb2_phy_instance instances[0];
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/4] Doc/devicetree: bindings: Update bindings information for USB3.0 DRD PHY

2014-12-11 Thread Vivek Gautam
Add missing VBUS-supply information and consumer usage information for
USB 3.0 DRD PHY.

Signed-off-by: Vivek Gautam 
---
 Documentation/devicetree/bindings/phy/samsung-phy.txt |9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index d5bad92..0090ad1 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -148,6 +148,9 @@ Required properties:
  control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 1;
 
+Optional properties:
+- vbus-supply : Reference to regulator node which supplies VBUS on the PHY.
+
 For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
 compatible PHYs, the second cell in the PHY specifier identifies the
 PHY id, which is interpreted as follows:
@@ -164,6 +167,12 @@ Example:
#phy-cells = <1>;
};
 
+Then the PHY can be used in other nodes such as:
+   phy-consumer@1234 {
+   phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
+   phy-names = "usb2-phy", "usb3-phy";
+   };
+
 - aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY 
controllers,
   'usbdrd_phy' nodes should have numbered alias in the aliases node,
   in the form of usbdrdphyN, N = 0, 1... (depending on number of
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/4] phy: samsung-usb2: Add support for Vbus regulator

2014-12-11 Thread Vivek Gautam
This has been on my to-do list for sometime.
Until now the host controller (specifically ehci-exynos) is responsible
for enabling VBUS supply. This opens up one more issue which is, when
only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was
never enabled (since ohci did not have the code to enabled the VBUS supply).

Rather it should be wise to move the VBUS related stuff to phy driver and
let phy take care of enabling it.

This patch series adds that VBUS regulator to phy-samsung-usb2 driver,
adds necessary binding information as well as vbus-supply properties
to phy nodes on exynos5250 systems.
Also we have removed the samsung,vbus-gpio property from usb2 (ehci) node
on exynos5250 systems.

**[The older code in ehci-exynos for vbus setting is left intact to keep
supporting older dt bindings].

Vivek Gautam (4):
  Doc/devicetree: bindings: Update bindings information for USB3.0 DRD
PHY
  phy: samsung-usb2: Add facility for VBUS supply
  arm: dts: exynos5250: Use regulator for USB 2.0 VBUS supply
  arm: dts: exynos5250: Remove vbus gpio property from usb 2.0 host

 .../devicetree/bindings/phy/samsung-phy.txt|   12 
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   22 --
 arch/arm/boot/dts/exynos5250-snow.dts  |   22 --
 drivers/phy/phy-samsung-usb2.c |   30 
 drivers/phy/phy-samsung-usb2.h |1 +
 5 files changed, 83 insertions(+), 4 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] Documentation: dt-bindings: Add aliases information for Exynos7 pin controllers

2014-12-10 Thread Vivek Gautam
Adding list of aliases for supported Exynos7 pin controller blocks.

Signed-off-by: Vivek Gautam 
Cc: Tomasz Figa 
Cc: Linus Walleij 
---
 .../devicetree/bindings/pinctrl/samsung-pinctrl.txt  |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 8425838..742e472 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -171,6 +171,16 @@ Aliases:
 All the pin controller nodes should be represented in the aliases node using
 the following format 'pinctrl{n}' where n is a unique number for the alias.
 
+Aliases for controllers compatible with "samsung,exynos7-pinctrl":
+- pinctrl0: pin controller of ALIVE block,
+- pinctrl1: pin controller of BUS0 block,
+- pinctrl2: pin controller of NFC block,
+- pinctrl3: pin controller of TOUCH block,
+- pinctrl4: pin controller of FF block,
+- pinctrl5: pin controller of ESE block,
+- pinctrl6: pin controller of FSYS0 block,
+- pinctrl7: pin controller of FSYS1 block,
+
 Example: A pin-controller node with pin banks:
 
pinctrl_0: pinctrl@1140 {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V3 2/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-10 Thread Vivek Gautam
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Vivek Gautam 
Cc: Tomasz Figa 
Cc: Linus Walleij 
---

Changes since V2:
 - Added documentation on alias for BUS1 pin controller block.

Changes since V1:
 - Added support for all pin banks which are part of BUS1 pin controller.

 .../devicetree/bindings/pinctrl/samsung-pinctrl.txt |1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c|   19 +++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 742e472..c88ba35 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -180,6 +180,7 @@ Aliases for controllers compatible with 
"samsung,exynos7-pinctrl":
 - pinctrl5: pin controller of ESE block,
 - pinctrl6: pin controller of FSYS0 block,
 - pinctrl7: pin controller of FSYS1 block,
+- pinctrl8: pin controller of BUS1 block,
 
 Example: A pin-controller node with pin banks:
 
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
 };
 
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
+   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
+   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
+   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
+};
+
 const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
__initconst = {
.pin_banks  = exynos7_pin_banks7,
.nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+   }, {
+   /* pin-controller instance 8 BUS1 data */
+   .pin_banks  = exynos7_pin_banks8,
+   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
+   .eint_gpio_init = exynos_eint_gpio_init,
},
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-10 Thread Vivek Gautam
Hi Tomasz,


On Mon, Dec 1, 2014 at 9:37 PM, Tomasz Figa  wrote:
> Hi Vivek,
>
> Please see my comments below.
>
> 2014-11-24 22:02 GMT+09:00 Vivek Gautam :
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> Cc: Linus Walleij 
>> ---
>>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>  https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>
>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>>  1 file changed, 19 insertions(+)
>
> I have missed this with previous patch, but DT bindings documentation
> should list all aliases for all supported compatible strings, because
> they are required for correct operation. There is a small section
> about aliases in [1] already, so please add there information about
> aliases for Exynos7 pin controllers along with their names, e.g.
>
> Aliases for controllers compatible with "samsung,exynos7-pinctrl":
>  - pinctrl0: pin controller of ALIVE block,
>  - pinctrl1: pin controller of BUS0 block,
>  [...]
>  - pinctrl8: pin controller of BUS1 block.
>
> [1] Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
>
> I guess you can do this in separate patch or respin this one with this added.

Sure, i will add the aliases in a separate patch.
I missed to update the patch in this cycle :-(
So we can queue up the reworked version for 3.20.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-12-01 Thread Vivek Gautam
On Fri, Nov 28, 2014 at 9:15 PM, Linus Walleij  wrote:
> On Fri, Nov 28, 2014 at 4:39 AM, Vivek Gautam  
> wrote:
>> On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam  
>> wrote:
>
>>>> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  
>>>> wrote:
>>>>> USB and Power regulator on Exynos7 require gpios available
>>>>> in BUS1 pin controller block.
>>>>> So adding the BUS1 pinctrl support.
>>>>>
>>>>> Signed-off-by: Naveen Krishna Ch 
>>>>> Signed-off-by: Vivek Gautam 
>>>>> Cc: Linus Walleij 
>>
>> If the change looks good, will it be possible to pick it fo 3.19-rc1 ?
>> That will really help enabling USB IP on exynos7.
>
> As you know the Exynos driver has a maintainer, Tomasz Figa, I will not
> merge patches without his ACK.
>
> Apart from that, there are *again* a lot of Exynos patches flying around and
> I start to loose track of them. If they do not apply together and start to
> conflict I will just ask Tomasz to stack them and provide a pull request
> again.

True, this merge cycle has surely got number of exynos7 related
patches in flight,
which are difficult to keep track of.
Thanks for asking Tomasz.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7

2014-11-27 Thread Vivek Gautam
Hi Kukjin,


On Wed, Nov 26, 2014 at 6:59 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:36 PM, Vivek Gautam  
> wrote:
>> BUS1 pinctrl provides gpios for usb and power regulator
>> available on exynos7-espresso board. So add relevant device
>> node for pinctrl-bus1.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> ---

We can pick this up for 3.19 rc1 ?

>>
> Looks good to me.
> Reviewed-by: Alim Akhtar 
>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>  https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>
>>  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |   82 
>> +++
>>  arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
>>  2 files changed, 89 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> index 2eef4a2..c367f0a 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> @@ -335,6 +335,88 @@
>> };
>>  };
>>
>> +&pinctrl_bus1 {
>> +   gpf0: gpf0 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf1: gpf1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf2: gpf2 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf3: gpf3 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf4: gpf4 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf5: gpf5 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpg1: gpg1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpg2: gpg2 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gph1: gph1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpv6: gpv6 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +};
>> +
>>  &pinctrl_nfc {
>> gpj0: gpj0 {
>> gpio-controller;
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 1d9e4c9..e633b02 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -26,6 +26,7 @@
>> pinctrl5 = &pinctrl_ese;
>> pinctrl6 = &pinctrl_fsys0;
>> pinctrl7 = &pinctrl_fsys1;
>> +   pinctrl8 = &pinctrl_bus1;
>> };
>>
>> cpus {
>> @@ -242,6 +243,12 @@
>> interrupts = <0 383 0>;
>> };
>>
>> +   pinctrl_bus1: pinctrl@1487 {
>> +   compatible =

Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-27 Thread Vivek Gautam
Hi Linus,


On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam  wrote:
> Hi Alim,
>
>
> On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar  wrote:
>> Hi Vivek,
>>
>> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  
>> wrote:
>>> USB and Power regulator on Exynos7 require gpios available
>>> in BUS1 pin controller block.
>>> So adding the BUS1 pinctrl support.
>>>
>>> Signed-off-by: Naveen Krishna Ch 
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Linus Walleij 

If the change looks good, will it be possible to pick it fo 3.19-rc1 ?
That will really help enabling USB IP on exynos7.

>>> ---
>> Looks good to me.
>> Thanks!
>>
>> Reviewed-by: Alim Akhtar 
>
> Thanks for the review.
>
>>
>>>
>>> This patch was part of series:
>>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>>  https://lkml.org/lkml/2014/11/21/247
>>>
>>> Changes since V1:
>>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>>
>>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> index d5d4cfc..44e60dc 100644
>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
>>> exynos7_pin_banks7[] __initconst = {
>>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>>  };
>>>
>>> +/* pin banks of exynos7 pin-controller - BUS1 */
>>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>>> = {
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>>> +   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>>> +   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>>> +};
>>> +
>>>  const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>>> {
>>> /* pin-controller instance 0 Alive data */
>>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
>>> __initconst = {
>>> .pin_banks  = exynos7_pin_banks7,
>>> .nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
>>> .eint_gpio_init = exynos_eint_gpio_init,
>>> +   }, {
>>> +   /* pin-controller instance 8 BUS1 data */
>>> +   .pin_banks  = exynos7_pin_banks8,
>>> +   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
>>> +   .eint_gpio_init = exynos_eint_gpio_init,
>>> },
>>>  };
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Alim
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-27 Thread Vivek Gautam
Hi Alim,


On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  
> wrote:
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> Cc: Linus Walleij 
>> ---
> Looks good to me.
> Thanks!
>
> Reviewed-by: Alim Akhtar 

Thanks for the review.

>
>>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>  https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>
>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index d5d4cfc..44e60dc 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
>> exynos7_pin_banks7[] __initconst = {
>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>  };
>>
>> +/* pin banks of exynos7 pin-controller - BUS1 */
>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>> = {
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>> +   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>> +   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>> +};
>> +
>>  const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>> {
>> /* pin-controller instance 0 Alive data */
>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
>> __initconst = {
>> .pin_banks  = exynos7_pin_banks7,
>> .nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
>> .eint_gpio_init = exynos_eint_gpio_init,
>> +   }, {
>> +   /* pin-controller instance 8 BUS1 data */
>> +   .pin_banks  = exynos7_pin_banks8,
>> +   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
>> +   .eint_gpio_init = exynos_eint_gpio_init,
>> },
>>  };
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Alim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/11] Exynos7: Adding USB 3.0 support

2014-11-25 Thread Vivek Gautam
Hi Sylwester,


On Sat, Nov 22, 2014 at 8:42 PM, Kukjin Kim  wrote:
> On 11/22/14 17:40, Kishon Vijay Abraham I wrote:
>>
>> On Friday 21 November 2014 08:41 PM, Felipe Balbi wrote:
>>> On Fri, Nov 21, 2014 at 07:05:43PM +0530, Vivek Gautam wrote:
>>>> The series has dependency on
>>>> a) "[PATCH v7 0/7] Enable support for Samsung Exynos7 SoC"
>>>>http://www.spinics.net/lists/linux-samsung-soc/msg38734.html
>>>> b) "[GIT PULL] Samsung clock changes for 3.19" - specifically the clock dt
>>>>bindings header.
>>>>http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142
>>>> c) "tty: serial: samsung: Clean-up selection of number of available UARTs"
>>>>http://www.spinics.net/lists/linux-samsung-soc/msg37418.html
>>>> d) "dts, kbuild: Implement support for dtb vendor subdirs"(merged in 
>>>> linux-next)
>>>>https://lkml.org/lkml/2014/10/21/654
>>>> e) "Samsung pinctrl patches for v3.19"
>>>>http://www.spinics.net/lists/linux-samsung-soc/msg38744.html
>>>>
>>>> Tested on Exynos7-espresso board with 3.18-rc5 and above dependencies.
>>>>
>>>> Clubbing the pinctrl, clk, and usb driver changes alongwith the dt changes
>>>> together in this series only so as to avoid having 'n' number of 
>>>> dependencies.
>>>>
>>>> The USB driver patches in this series were part of [1] sent earlier.
>>>> [1] [PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7
>>>> https://lkml.org/lkml/2014/10/7/191
>>>
>>> I took dwc3 driver patches.
>>
>> I took the phy patches.
>>
> I'll take DT changes once exynos7 is landing into samsung tree :)
>

You too may want to pick the sole clock driver patch in this series
for 3.19 ? :-)
"clk: exynos7: Add required clock tree for USB"

Please let me know if the merge window is still open on your side so
that you can
pick this patch.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Peach Pi/Pit boot failures in linux-next (was Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init)

2014-11-24 Thread Vivek Gautam
On Mon, Nov 24, 2014 at 6:46 PM, Javier Martinez Canillas
 wrote:
> [adding Tushar Behera and Doug Anderson to cc list]
>
> Hello,
>
> On 11/24/2014 12:12 PM, Krzysztof Kozlowski wrote:
>> On pon, 2014-11-24 at 12:07 +0100, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> > It seems that mau_epll has to be enabled... or something is wrong with
>>> > clock hierarchy.
>>> >
>>>
>>> Another strange thing is that the problem does not happen for some people
>>> using the same board, kernel and config options. For example Vivek and Ajay
>>> report that they can't reproduce the issue on a Peach Pi using next-20141121
>>> and exynos_defconfig without using clk_ignore_unused.
>>
>> Maybe they have different bootloader which messes here by enabling some
>> clock?
>>
>> Anyway it is reproducible on at least some Arndale Octa (Kevin's and
>> mine) and Peach Pi boards (yours).
>>
>
> This issue started to look extremely familiar to me so I searched in
> my mail inbox and found that the same problem was previously reported
> by Kevin a couple of months ago [0] and Tushar provided a fix [1].
>
> I tested linux-next + [1] and that indeed fixes the hang on Peach.
>
> To save you a click, the problem as explained by Tushar is that the
> AUDSS mux has two parents: XXTI crystal and MAU_EPLL clock. But when
> the output of AUDSS mux is gated, no operations can be made on the
> clocks provided by MAU block. For some reason the kernel just oops
> so it seems to be a H/W errata?
>
> Mike was not fond about the solution proposed in [1] but something
> along those lines would be needed maybe Tushar can comment on that.
>
> Vivek and Ajay,
>
> As explained in [0], you are not facing this issue because your RW
> U-Boot seems to predate when audio support was enabled by default.

We are using one from Google's build-bot:
"U-Boot 2013.04-g1eced1c (Nov 20 2014 - 21:27:46) for Peach"

>
> Can you try executing "sound init" in the U-Boot prompt and see if
> that triggers the hang for you?

But yes, doing *sound init* do trigger the hang.

>
> Best regards,
> Javier
>
> [0]: 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html
> [1]: http://www.spinics.net/lists/arm-kernel/msg337970.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7

2014-11-24 Thread Vivek Gautam
BUS1 pinctrl provides gpios for usb and power regulator
available on exynos7-espresso board. So add relevant device
node for pinctrl-bus1.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Vivek Gautam 
---

This patch was part of series:
"[PATCH 00/11] Exynos7: Adding USB 3.0 support"
 https://lkml.org/lkml/2014/11/21/247

Changes since V1:
 - Added support for all pin banks which are part of BUS1 pin controller.

 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |   82 +++
 arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
 2 files changed, 89 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..c367f0a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -335,6 +335,88 @@
};
 };
 
+&pinctrl_bus1 {
+   gpf0: gpf0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf1: gpf1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf2: gpf2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf3: gpf3 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf4: gpf4 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf5: gpf5 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpg1: gpg1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpg2: gpg2 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gph1: gph1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpv6: gpv6 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
+
 &pinctrl_nfc {
gpj0: gpj0 {
gpio-controller;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 1d9e4c9..e633b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = &pinctrl_ese;
pinctrl6 = &pinctrl_fsys0;
pinctrl7 = &pinctrl_fsys1;
+   pinctrl8 = &pinctrl_bus1;
};
 
cpus {
@@ -242,6 +243,12 @@
interrupts = <0 383 0>;
};
 
+   pinctrl_bus1: pinctrl@1487 {
+   compatible = "samsung,exynos7-pinctrl";
+   reg = <0x1487 0x1000>;
+   interrupts = <0 384 0>;
+   };
+
pinctrl_nfc: pinctrl@14cd {
compatible = "samsung,exynos7-pinctrl";
reg = <0x14cd 0x1000>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-24 Thread Vivek Gautam
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Vivek Gautam 
Cc: Linus Walleij 
---

This patch was part of series:
"[PATCH 00/11] Exynos7: Adding USB 3.0 support"
 https://lkml.org/lkml/2014/11/21/247

Changes since V1:
 - Added support for all pin banks which are part of BUS1 pin controller.

 drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
 };
 
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
+   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
+   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
+   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
+   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
+   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
+   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
+};
+
 const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
__initconst = {
.pin_banks  = exynos7_pin_banks7,
.nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+   }, {
+   /* pin-controller instance 8 BUS1 data */
+   .pin_banks  = exynos7_pin_banks8,
+   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
+   .eint_gpio_init = exynos_eint_gpio_init,
},
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-11-24 Thread Vivek Gautam
On Mon, Nov 24, 2014 at 4:26 PM, Thierry Reding
 wrote:
> On Mon, Nov 24, 2014 at 04:17:18PM +0530, Vivek Gautam wrote:
>> Hi,
>>
>>
>> On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
>>  wrote:
>> > On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
>> >> DP PHY now require pmu-system-controller to handle PMU register
>> >> to control PHY's power isolation. Adding the same to dp-phy
>> >> node.
>> >>
>> >> Signed-off-by: Vivek Gautam 
>> >> Reviewed-by: Jingoo Han 
>> >> Tested-by: Javier Martinez Canillas 
>> >> Cc: Kukjin Kim 
>> >> ---
>> >>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>> >>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>> >>  2 files changed, 3 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> >> b/arch/arm/boot/dts/exynos5250.dtsi
>> >> index 0a588b4..bebd099 100644
>> >> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> >> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> >> @@ -732,7 +732,7 @@
>> >>
>> >>   dp_phy: video-phy@10040720 {
>> >>   compatible = "samsung,exynos5250-dp-video-phy";
>> >> - reg = <0x10040720 4>;
>> >> + samsung,pmu-syscon = <&pmu_system_controller>;
>> >>   #phy-cells = <0>;
>> >>   };
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> >> b/arch/arm/boot/dts/exynos5420.dtsi
>> >> index 8617a03..1353a09 100644
>> >> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> >> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> >> @@ -503,8 +503,8 @@
>> >>   };
>> >>
>> >>   dp_phy: video-phy@10040728 {
>> >> - compatible = "samsung,exynos5250-dp-video-phy";
>> >> - reg = <0x10040728 4>;
>> >> + compatible = "samsung,exynos5420-dp-video-phy";
>> >> + samsung,pmu-syscon = <&pmu_system_controller>;
>> >>   #phy-cells = <0>;
>> >>   };
>> >>
>> >
>> > It seems like these nodes have been in the Linux tree since 3.12 and
>> > 3.17, respectively and these changes break backwards-compatibility. Has
>> > anyone thought about the possible consequences?
>>
>> Sorry for my ignorance, but i have a doubt.
>> If the bindings and device node both are being changed in the same kernel
>> version (as fixes),
>> so that the stable will have both; then the only scenerio of backward
>> compatibility comes when kernel is upgraded but not dtbs.
>
> Correct.
>
>> Does such upgradation makes sense for distros ?
>
> Yes. Back at the time a decision was made that device trees need to be
> stable ABI because eventually they'd be shipped with the device rather
> than the distribution. As such it may not at all be possible to update
> them (they could be in some sort of ROM).
>
> For that reason new kernels need to keep working with old DTBs unless an
> argument can be made that would justify breaking things. I don't think I
> have ever seen anyone win such an argument.
> One of the rare exceptions
> that I know of is if you can prove that a given hardware block has never
> been used in an upstream kernel, then changing the DTB in backwards-
> incompatible ways would be okay because you wouldn't be breaking things
> for existing users.

I am pretty sure about the Chrome devices (which have not been
upgraded to any kernel after
3.8).
Probably Javier may have better knowledge.

Javier, is there any other device using upstream kernel post 3.12 (any
arndale octa based) ?




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-11-24 Thread Vivek Gautam
Hi,


On Mon, Nov 24, 2014 at 4:02 PM, Thierry Reding
 wrote:
> On Mon, Nov 24, 2014 at 11:11:23AM +0530, Vivek Gautam wrote:
>> DP PHY now require pmu-system-controller to handle PMU register
>> to control PHY's power isolation. Adding the same to dp-phy
>> node.
>>
>> Signed-off-by: Vivek Gautam 
>> Reviewed-by: Jingoo Han 
>> Tested-by: Javier Martinez Canillas 
>> Cc: Kukjin Kim 
>> ---
>>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 0a588b4..bebd099 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -732,7 +732,7 @@
>>
>>   dp_phy: video-phy@10040720 {
>>   compatible = "samsung,exynos5250-dp-video-phy";
>> - reg = <0x10040720 4>;
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>>   #phy-cells = <0>;
>>   };
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 8617a03..1353a09 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -503,8 +503,8 @@
>>   };
>>
>>   dp_phy: video-phy@10040728 {
>> - compatible = "samsung,exynos5250-dp-video-phy";
>> - reg = <0x10040728 4>;
>> + compatible = "samsung,exynos5420-dp-video-phy";
>> + samsung,pmu-syscon = <&pmu_system_controller>;
>>   #phy-cells = <0>;
>>   };
>>
>
> It seems like these nodes have been in the Linux tree since 3.12 and
> 3.17, respectively and these changes break backwards-compatibility. Has
> anyone thought about the possible consequences?

Sorry for my ignorance, but i have a doubt.
If the bindings and device node both are being changed in the same kernel
version (as fixes),
so that the stable will have both; then the only scenerio of backward
compatibility comes when kernel is upgraded but not dtbs.
Does such upgradation makes sense for distros ?

>
> Although, looking more closely it seems like this isn't the first time
> that backwards-compatibility was broken in these files, so perhaps
> nobody cares...
>
> Thierry



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-11-24 Thread Vivek Gautam
On Sun, Nov 23, 2014 at 12:26 AM, Javier Martinez Canillas
 wrote:
> Hello Vivek
>
> On Wed, Nov 19, 2014 at 1:03 PM, Vivek Gautam  
> wrote:
>>>
>>> Tested-by: Javier Martinez Canillas 
>>
>> Thanks for testing.
>>
>
> You are welcome
>
>>>
>>> Kukjin,
>>
>> Sorry for not adding Kukjin to the list and thereby for the delay
>> about this patch.
>>
>
> No worries but I'm not sure if Kukjin is aware of this patch. I see he
> has been applying other patches but didn't pick $subject.
Right,

>
> Maybe you can resend it to Kukjin just to be sure he will have it in
> his mailbox?

Posted a RESEND version of this patch. Thanks again for noticing.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: screen blank causing lockup in exynos-reference/exynos5-v3.18-rc2

2014-11-24 Thread Vivek Gautam
Hi Kevin,


On Sat, Nov 22, 2014 at 12:53 AM, Kevin Hilman  wrote:
> Hi Ajay,
>
> AJAY KUMAR RAMAKRISHNA SHYMALAMMA  writes:
>
>> I tried to reproduce the issue which you reported,
>>
>> but I am sorry I am not able to reproduce it.
>>
>> I tried with my patches for DRM on top of Linux-next.
>
> I don't see the issue on linux-next either.  As I mentioned in the
> original post, I only see it on the v3.18 branch in the exynos-reference
> tree.

While checking the issue along with Ajay on "exynos5-v3.18-rc2" branch
on exynos-reference
tree, we found out the culprit to be FIMD-SYSMMU.
The IOMMU on exynos systems is still WIP, and that's the reason it is
disabled in
exynos_defconfig too.
So we have a small workaround in this branch to stop using FIMD-SYSMMUs.

Now, at the bootup time things are OK, since the FIMD-SMMU clocks
(CLK_SMMU_FIMD**)
are still available. But after bootup all unused clocks are disabled
(since we don't want to
use clk_ignore_unused in boot arguments), and the consequent blanking-unblanking
causes the system to hang.

So we have pushed a patch on the same branch "exynos5-v3.18-rc2" which sets
CLK_IGNORE_UNUSED flag for these SMMU_FIMD** clocks.

This fixes the issue of hang what we were seeing.

There's another branch "exynos5-v3.18-rc5" available, and we have
pushed the same patch
on that branch too.
Please test on your side, and do let us know if things are working fine for you.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH V2 RESEND] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-11-23 Thread Vivek Gautam
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.

Signed-off-by: Vivek Gautam 
Reviewed-by: Jingoo Han 
Tested-by: Javier Martinez Canillas 
Cc: Kukjin Kim 
---
 arch/arm/boot/dts/exynos5250.dtsi |2 +-
 arch/arm/boot/dts/exynos5420.dtsi |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0a588b4..bebd099 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
 
dp_phy: video-phy@10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040720 4>;
+   samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
 
dp_phy: video-phy@10040728 {
-   compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040728 4>;
+   compatible = "samsung,exynos5420-dp-video-phy";
+   samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 01/11] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-23 Thread Vivek Gautam
Hi Alim,


On Sat, Nov 22, 2014 at 7:07 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Fri, Nov 21, 2014 at 7:05 PM, Vivek Gautam  
> wrote:
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> Cc: Linus Walleij 
>> ---
>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index d5d4cfc..caca5b5 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1300,6 +1300,13 @@ static const struct samsung_pin_bank_data 
>> exynos7_pin_banks7[] __initconst = {
>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>  };
>>
>> +/* pin banks of exynos7 pin-controller - BUS1 */
>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>> = {
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>> +};
>> +
> Looks like you are just trying to touch pin banks only related to USB
> stuffs, but as this patch does not have any dependencies on other
> patches in this series, will you consider adding other pin banks of
> BUS1, just for completeness of BUS1 pin-controller.

True, this just touches the USB related pinctrl.
Will add the rest pin banks of BUS1 for completeness.
Thanks for pointing out. :-)

[snip]



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 11/11] arm64: dts: exynos7-espresso: Add regulators for Vbus and Vbus-Boost

2014-11-21 Thread Vivek Gautam
Adding fixed voltage regulators for Vbus and Vbus-boost required
by USB 3.0 DRD controller on Exynos7-espresso board.

Signed-off-by: Vivek Gautam 
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts 
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 5424cc4..2dedd5e 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -30,6 +30,28 @@
device_type = "memory";
reg = <0x0 0x4000 0x0 0xC000>;
};
+
+   usb30_vbus_reg: regulator-usb30 {
+   compatible = "regulator-fixed";
+   regulator-name = "VBUS_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gph1 1 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb30_vbus_en>;
+   enable-active-high;
+   };
+
+   usb3drd_vboost_5v: regulator-usb3drd-vboost {
+   compatible = "regulator-fixed";
+   regulator-name = "VUSB_VBUS_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpf4 1 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&usb3drd_vboost_en>;
+   enable-active-high;
+   };
 };
 
 &fin_pll {
@@ -40,6 +62,22 @@
status = "okay";
 };
 
+&pinctrl_bus1 {
+   usb30_vbus_en: usb30-vbus-en {
+   samsung,pins = "gph1-1";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+
+   usb3drd_vboost_en: usb3drd-vboost-en {
+   samsung,pins = "gpf4-1";
+   samsung,pin-function = <1>;
+   samsung,pin-pud = <0>;
+   samsung,pin-drv = <0>;
+   };
+};
+
 &rtc {
status = "okay";
 };
@@ -82,3 +120,8 @@
bus-width = <4>;
disable-wp;
 };
+
+&usbdrd_phy {
+   vbus-supply = <&usb30_vbus_reg>;
+   vbus-boost-supply = <&usb3drd_vboost_5v>;
+};
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 10/11] arm64: dts: Enable USB 3.0 controller on exynos7

2014-11-21 Thread Vivek Gautam
Adding USB 3.0 DRD controller device node, with its clock
and phy information to enable using the same on Exynos7.

Signed-off-by: Vivek Gautam 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 90048b2..e633b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -531,6 +531,41 @@
clocks = <&clock_peric0 PCLK_PWM>;
clock-names = "timers";
};
+
+   usbdrd3: usb@1540 {
+   compatible = "samsung,exynos7-dwusb3";
+   clocks = <&clock_fsys0 ACLK_USBDRD300>,
+<&clock_fsys0 SCLK_USBDRD300_SUSPENDCLK>,
+<&clock_fsys0 ACLK_AXIUS_USBDRD30X_FSYS0X>;
+   clock-names = "usbdrd30", "usbdrd30_susp_clk",
+ "usbdrd30_axius_clk";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   dwc3 {
+   compatible = "snps,dwc3";
+   reg = <0x1540 0x1>;
+   interrupts = <0 223 0>;
+   phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
+   phy-names = "usb2-phy", "usb3-phy";
+   };
+   };
+
+   usbdrd_phy: phy@1550 {
+   compatible = "samsung,exynos7-usbdrd-phy";
+   reg = <0x1550 0x100>;
+   clocks =
+ <&clock_fsys0 ACLK_USBDRD300>,
+ <&clock_fsys0 OSCCLK_PHY_CLKOUT_USB30_PHY>,
+ <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PIPE_PCLK_USER>,
+ <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PHYCLK_USER>,
+ <&clock_fsys0 SCLK_USBDRD300_REFCLK>;
+   clock-names = "phy", "ref", "phy_pipe", "phy_utmi",
+ "itp";
+   samsung,pmu-syscon = <&pmu_system_controller>;
+   #phy-cells = <1>;
+   };
};
 };
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 09/11] arm64: exynos: Add bus1 pinctrl node on exynos7

2014-11-21 Thread Vivek Gautam
BUS1 pinctrl provides gpios for usb and power regulator
available on exynos7-espresso board. So add relevant device
node for pinctrl-bus1.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Vivek Gautam 
---
 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |   26 +++
 arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..9648e03 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -335,6 +335,32 @@
};
 };
 
+&pinctrl_bus1 {
+   gpf0: gpf0 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gpf4: gpf4 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+
+   gph1: gph1 {
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
+
 &pinctrl_nfc {
gpj0: gpj0 {
gpio-controller;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index d7a37c3..90048b2 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = &pinctrl_ese;
pinctrl6 = &pinctrl_fsys0;
pinctrl7 = &pinctrl_fsys1;
+   pinctrl8 = &pinctrl_bus1;
};
 
cpus {
@@ -242,6 +243,12 @@
interrupts = <0 383 0>;
};
 
+   pinctrl_bus1: pinctrl@1487 {
+   compatible = "samsung,exynos7-pinctrl";
+   reg = <0x1487 0x1000>;
+   interrupts = <0 384 0>;
+   };
+
pinctrl_nfc: pinctrl@14cd {
compatible = "samsung,exynos7-pinctrl";
reg = <0x14cd 0x1000>;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 08/11] clk: exynos7: Add required clock tree for USB

2014-11-21 Thread Vivek Gautam
Adding required gate clocks for USB3.0 DRD controller
present on Exynos7.

Signed-off-by: Vivek Gautam 
---
 drivers/clk/samsung/clk-exynos7.c   |   64 +++
 include/dt-bindings/clock/exynos7-clk.h |9 -
 2 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos7.c 
b/drivers/clk/samsung/clk-exynos7.c
index ea4483b..3128593 100644
--- a/drivers/clk/samsung/clk-exynos7.c
+++ b/drivers/clk/samsung/clk-exynos7.c
@@ -343,6 +343,8 @@ static struct samsung_mux_clock top1_mux_clks[] __initdata 
= {
MUX(0, "mout_aclk_fsys0_200", mout_top1_group1, MUX_SEL_TOP13, 28, 2),
 
MUX(0, "mout_sclk_mmc2", mout_top1_group1, MUX_SEL_TOP1_FSYS0, 24, 2),
+   MUX(0, "mout_sclk_usbdrd300", mout_top1_group1,
+   MUX_SEL_TOP1_FSYS0, 28, 2),
 
MUX(0, "mout_sclk_mmc1", mout_top1_group1, MUX_SEL_TOP1_FSYS1, 24, 2),
MUX(0, "mout_sclk_mmc0", mout_top1_group1, MUX_SEL_TOP1_FSYS1, 28, 2),
@@ -356,6 +358,8 @@ static struct samsung_div_clock top1_div_clks[] __initdata 
= {
 
DIV(DOUT_SCLK_MMC2, "dout_sclk_mmc2", "mout_sclk_mmc2",
DIV_TOP1_FSYS0, 24, 4),
+   DIV(0, "dout_sclk_usbdrd300", "mout_sclk_usbdrd300",
+   DIV_TOP1_FSYS0, 28, 4),
 
DIV(DOUT_SCLK_MMC1, "dout_sclk_mmc1", "mout_sclk_mmc1",
DIV_TOP1_FSYS1, 24, 4),
@@ -366,6 +370,8 @@ static struct samsung_div_clock top1_div_clks[] __initdata 
= {
 static struct samsung_gate_clock top1_gate_clks[] __initdata = {
GATE(CLK_SCLK_MMC2, "sclk_mmc2", "dout_sclk_mmc2",
ENABLE_SCLK_TOP1_FSYS0, 24, CLK_SET_RATE_PARENT, 0),
+   GATE(0, "sclk_usbdrd300", "dout_sclk_usbdrd300",
+   ENABLE_SCLK_TOP1_FSYS0, 28, 0, 0),
 
GATE(CLK_SCLK_MMC1, "sclk_mmc1", "dout_sclk_mmc1",
ENABLE_SCLK_TOP1_FSYS1, 24, CLK_SET_RATE_PARENT, 0),
@@ -647,7 +653,12 @@ CLK_OF_DECLARE(exynos7_clk_peris, 
"samsung,exynos7-clock-peris",
 /* Register Offset definitions for CMU_FSYS0 (0x10E9) */
 #define MUX_SEL_FSYS00 0x0200
 #define MUX_SEL_FSYS01 0x0204
+#define MUX_SEL_FSYS02 0x0208
+#define ENABLE_ACLK_FSYS00 0x0800
 #define ENABLE_ACLK_FSYS01 0x0804
+#define ENABLE_SCLK_FSYS01 0x0A04
+#define ENABLE_SCLK_FSYS02 0x0A08
+#define ENABLE_SCLK_FSYS04 0x0A10
 
 /*
  * List of parent clocks for Muxes in CMU_FSYS0
@@ -655,10 +666,29 @@ CLK_OF_DECLARE(exynos7_clk_peris, 
"samsung,exynos7-clock-peris",
 PNAME(mout_aclk_fsys0_200_p)   = { "fin_pll", "dout_aclk_fsys0_200" };
 PNAME(mout_sclk_mmc2_p)= { "fin_pll", "sclk_mmc2" };
 
+PNAME(mout_sclk_usbdrd300_p)   = { "fin_pll", "sclk_usbdrd300" };
+PNAME(mout_phyclk_usbdrd300_udrd30_phyclk_p)   = { "fin_pll",
+   "phyclk_usbdrd300_udrd30_phyclock" };
+PNAME(mout_phyclk_usbdrd300_udrd30_pipe_pclk_p)= { "fin_pll",
+   "phyclk_usbdrd300_udrd30_pipe_pclk" };
+
+/* fixed rate clocks used in the FSYS0 block */
+struct samsung_fixed_rate_clock fixed_rate_clks_fsys0[] __initdata = {
+   FRATE(0, "phyclk_usbdrd300_udrd30_phyclock", NULL,
+   CLK_IS_ROOT, 6000),
+   FRATE(0, "phyclk_usbdrd300_udrd30_pipe_pclk", NULL,
+   CLK_IS_ROOT, 12500),
+};
+
 static unsigned long fsys0_clk_regs[] __initdata = {
MUX_SEL_FSYS00,
MUX_SEL_FSYS01,
+   MUX_SEL_FSYS02,
+   ENABLE_ACLK_FSYS00,
ENABLE_ACLK_FSYS01,
+   ENABLE_SCLK_FSYS01,
+   ENABLE_SCLK_FSYS02,
+   ENABLE_SCLK_FSYS04,
 };
 
 static struct samsung_mux_clock fsys0_mux_clks[] __initdata = {
@@ -666,11 +696,45 @@ static struct samsung_mux_clock fsys0_mux_clks[] 
__initdata = {
MUX_SEL_FSYS00, 24, 1),
 
MUX(0, "mout_sclk_mmc2_user", mout_sclk_mmc2_p, MUX_SEL_FSYS01, 24, 1),
+   MUX(0, "mout_sclk_usbdrd300_user", mout_sclk_usbdrd300_p,
+   MUX_SEL_FSYS01, 28, 1),
+
+   MUX(0, "mout_phyclk_usbdrd300_udrd30_pipe_pclk_user",
+   mout_phyclk_usbdrd300_udrd30_pipe_pclk_p,
+   MUX_SEL_FSYS02, 24, 1),
+   MUX(0, "mout_phyclk_usbdrd300_udrd30_phyclk_user",
+   mout_phyclk_usbdrd300_udrd30_phyclk_p,
+   MUX_SEL_FSYS02, 28, 1),
 };
 
 static struct samsung_gate_clock fsys0_gate_clks[] __initdata = {
+   GATE(ACLK_AXIUS_USBDRD30X_FSYS0X, "aclk_axius_usbdrd30x_fsys0x",
+   "mout_aclk_fsys0_200_user",
+   ENABLE_ACLK_FSYS00, 19, 0, 0),
+
+   GATE(ACLK_USBD

[PATCH 07/11] phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

2014-11-21 Thread Vivek Gautam
This PHY controller is also present on Exynos7 platform
in arch-exynos family.
So PHY_EXYNOS5_USBDRD should now depend on ARCH_EXYNOS.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..1514e40 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,7 +193,7 @@ config PHY_EXYNOS5250_USB2
 
 config PHY_EXYNOS5_USBDRD
tristate "Exynos5 SoC series USB DRD PHY driver"
-   depends on ARCH_EXYNOS5 && OF
+   depends on ARCH_EXYNOS && OF
depends on HAS_IOMEM
depends on USB_DWC3_EXYNOS
select GENERIC_PHY
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 06/11] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

2014-11-21 Thread Vivek Gautam
Some Exynos boards have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |   32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 3654712..1f54639 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -159,6 +159,8 @@ struct exynos5_usbdrd_phy_drvdata {
  *reference clocks' for SS and HS operations
  * @ref_clk: reference clock to PHY block from which PHY's
  *  operational clocks are derived
+ * vbus: VBUS regulator for phy
+ * vbus_boost: Boost regulator for VBUS present on few Exynos boards
  */
 struct exynos5_usbdrd_phy {
struct device *dev;
@@ -178,6 +180,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+   struct regulator *vbus_boost;
 };
 
 static inline
@@ -460,11 +463,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
}
 
/* Enable VBUS supply */
+   if (phy_drd->vbus_boost) {
+   ret = regulator_enable(phy_drd->vbus_boost);
+   if (ret) {
+   dev_err(phy_drd->dev,
+   "Failed to enable VBUS boost supply\n");
+   goto fail_vbus;
+   }
+   }
+
if (phy_drd->vbus) {
ret = regulator_enable(phy_drd->vbus);
if (ret) {
dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
-   goto fail_vbus;
+   goto fail_vbus_boost;
}
}
 
@@ -473,6 +485,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
return 0;
 
+fail_vbus_boost:
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
+
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
if (!phy_drd->drv_data->has_common_clk_gate) {
@@ -497,6 +513,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd->vbus)
regulator_disable(phy_drd->vbus);
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
 
clk_disable_unprepare(phy_drd->ref_clk);
if (!phy_drd->drv_data->has_common_clk_gate) {
@@ -690,7 +708,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
break;
}
 
-   /* Get Vbus regulator */
+   /* Get Vbus regulators */
phy_drd->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(phy_drd->vbus)) {
ret = PTR_ERR(phy_drd->vbus);
@@ -701,6 +719,16 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
phy_drd->vbus = NULL;
}
 
+   phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
+   if (IS_ERR(phy_drd->vbus_boost)) {
+   ret = PTR_ERR(phy_drd->vbus_boost);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   dev_warn(dev, "Failed to get VBUS boost supply regulator\n");
+   phy_drd->vbus_boost = NULL;
+   }
+
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
 
for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 05/11] phy: exynos5-usbdrd: Add pipe-clk, utmi-clk and itp-clk support

2014-11-21 Thread Vivek Gautam
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
Additionally, separate gate control is available for the clock
used for ITP (Isochronous Transfer Packet) generation.

So get the same and control in the phy-exynos5-usbdrd driver.

Suggested-by: Anton Tikhomirov 
Signed-off-by: Vivek Gautam 
---
 .../devicetree/bindings/phy/samsung-phy.txt|6 ++
 drivers/phy/phy-exynos5-usbdrd.c   |  104 
 2 files changed, 92 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 15e0f2c..d5bad92 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -128,6 +128,7 @@ Required properties:
 - compatible : Should be set to one of the following supported values:
- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+   - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC.
 - reg : Register offset and length of USB DRD PHY register set;
 - clocks: Clock IDs array as required by the controller
 - clock-names: names of clocks correseponding to IDs in the clock property;
@@ -138,6 +139,11 @@ Required properties:
   PHY operations, associated by phy name. It is used to
   determine bit values for clock settings register.
   For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+   - optional clocks: Exynos7 SoC has now following additional
+  gate clocks available:
+  - phy_pipe: for PIPE3 phy
+  - phy_utmi: for UTMI+ phy
+  - itp: for ITP generation
 - samsung,pmu-syscon: phandle for PMU system controller interface, used to
  control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index f756aca..3654712 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -141,6 +141,7 @@ struct exynos5_usbdrd_phy_drvdata {
const struct exynos5_usbdrd_phy_config *phy_cfg;
u32 pmu_offset_usbdrd0_phy;
u32 pmu_offset_usbdrd1_phy;
+   bool has_common_clk_gate;
 };
 
 /**
@@ -148,6 +149,9 @@ struct exynos5_usbdrd_phy_drvdata {
  * @dev: pointer to device instance of this platform device
  * @reg_phy: usb phy controller register memory base
  * @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
+ * @itpclk: clock for ITP generation
  * @drv_data: pointer to SoC level driver data structure
  * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
  * instances each with its 'phy' and 'phy_cfg'.
@@ -155,12 +159,14 @@ struct exynos5_usbdrd_phy_drvdata {
  *reference clocks' for SS and HS operations
  * @ref_clk: reference clock to PHY block from which PHY's
  *  operational clocks are derived
- * @ref_rate: rate of above reference clock
  */
 struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+   struct clk *pipeclk;
+   struct clk *utmiclk;
+   struct clk *itpclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -447,6 +453,11 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
 
clk_prepare_enable(phy_drd->ref_clk);
+   if (!phy_drd->drv_data->has_common_clk_gate) {
+   clk_prepare_enable(phy_drd->pipeclk);
+   clk_prepare_enable(phy_drd->utmiclk);
+   clk_prepare_enable(phy_drd->itpclk);
+   }
 
/* Enable VBUS supply */
if (phy_drd->vbus) {
@@ -464,6 +475,11 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
+   if (!phy_drd->drv_data->has_common_clk_gate) {
+   clk_disable_unprepare(phy_drd->itpclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   }
 
return ret;
 }
@@ -483,6 +499,11 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd->vbus);
 
clk_disable_unprepare(phy_drd->ref_clk);
+   if (!phy_drd->drv_data->has_common_clk_gate) {
+   clk_disable_unprepare(phy_drd->itpclk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
+ 

[PATCH 04/11] dwc3: exynos: Add provision for AXI UpScaler clock on exynos7

2014-11-21 Thread Vivek Gautam
DWC3 controller on Exynos7 SoC has separate control for
AXI UpScaler which connects DWC3 DRD controller to AXI bus.
Get the gate clock for the same to control it across power
cycles.

Suggested-by: Anton Tikhomirov 
Signed-off-by: Vivek Gautam 
---
 Documentation/devicetree/bindings/usb/exynos-usb.txt |6 --
 drivers/usb/dwc3/dwc3-exynos.c   |   17 +
 2 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index a3b5990..9b4dbe3 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -82,8 +82,10 @@ Example:
 
 DWC3
 Required properties:
- - compatible: should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3
-  controller.
+ - compatible: should be one of the following -
+  "samsung,exynos5250-dwusb3": for USB 3.0 DWC3 controller on
+   Exynos5250/5420.
+  "samsung,exynos7-dwusb3": for USB 3.0 DWC3 controller on Exynos7.
  - #address-cells, #size-cells : should be '1' if the device has sub-nodes
 with 'reg' property.
  - ranges: allows valid 1:1 translation between child's address space and
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index af15ab3..6ae8fe5 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -36,6 +36,7 @@ struct dwc3_exynos {
 
struct clk  *clk;
struct clk  *susp_clk;
+   struct clk  *axius_clk;
 
struct regulator*vdd33;
struct regulator*vdd10;
@@ -150,6 +151,17 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
}
clk_prepare_enable(exynos->susp_clk);
 
+   if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
+   exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
+   if (IS_ERR(exynos->axius_clk)) {
+   dev_err(dev, "no AXI UpScaler clk specified\n");
+   return -ENODEV;
+   }
+   clk_prepare_enable(exynos->axius_clk);
+   } else {
+   exynos->axius_clk = NULL;
+   }
+
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
@@ -191,6 +203,7 @@ err4:
 err3:
regulator_disable(exynos->vdd33);
 err2:
+   clk_disable_unprepare(exynos->axius_clk);
clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
return ret;
@@ -204,6 +217,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
 
+   clk_disable_unprepare(exynos->axius_clk);
clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
 
@@ -216,6 +230,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
 #ifdef CONFIG_OF
 static const struct of_device_id exynos_dwc3_match[] = {
{ .compatible = "samsung,exynos5250-dwusb3" },
+   { .compatible = "samsung,exynos7-dwusb3" },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
@@ -226,6 +241,7 @@ static int dwc3_exynos_suspend(struct device *dev)
 {
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
+   clk_disable(exynos->axius_clk);
clk_disable(exynos->clk);
 
regulator_disable(exynos->vdd33);
@@ -251,6 +267,7 @@ static int dwc3_exynos_resume(struct device *dev)
}
 
clk_enable(exynos->clk);
+   clk_enable(exynos->axius_clk);
 
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/11] dwc3: exynos: Add provision for suspend clock

2014-11-21 Thread Vivek Gautam
DWC3 controller on Exynos SoC series have separate control for
suspend clock which replaces pipe3_rx_pclk as clock source to
a small part of DWC3 core that operates when SS PHY is in its
lowest power state (P3) in states SS.disabled and U3.

Suggested-by: Anton Tikhomirov 
Signed-off-by: Vivek Gautam 
---
 drivers/usb/dwc3/dwc3-exynos.c |   11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 7109de7..af15ab3 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,8 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
+   struct clk  *susp_clk;
+
struct regulator*vdd33;
struct regulator*vdd10;
 };
@@ -141,6 +143,13 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
}
clk_prepare_enable(exynos->clk);
 
+   exynos->susp_clk = devm_clk_get(dev, "usbdrd30_susp_clk");
+   if (IS_ERR(exynos->susp_clk)) {
+   dev_dbg(dev, "no suspend clk specified\n");
+   exynos->susp_clk = NULL;
+   }
+   clk_prepare_enable(exynos->susp_clk);
+
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
@@ -182,6 +191,7 @@ err4:
 err3:
regulator_disable(exynos->vdd33);
 err2:
+   clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
return ret;
 }
@@ -194,6 +204,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
 
+   clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
 
regulator_disable(exynos->vdd33);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/11] dwc3: exynos: Remove local variable for clock from probe

2014-11-21 Thread Vivek Gautam
There's no need to keep one local variable for clock, and
then assign the same to 'clk' member of dwc3_exynos.
Just cleaning it up.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/dwc3/dwc3-exynos.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3951a65..7109de7 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -106,7 +106,6 @@ static int dwc3_exynos_remove_child(struct device *dev, 
void *unused)
 static int dwc3_exynos_probe(struct platform_device *pdev)
 {
struct dwc3_exynos  *exynos;
-   struct clk  *clk;
struct device   *dev = &pdev->dev;
struct device_node  *node = dev->of_node;
 
@@ -133,15 +132,13 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return ret;
}
 
-   clk = devm_clk_get(dev, "usbdrd30");
-   if (IS_ERR(clk)) {
+   exynos->dev = dev;
+
+   exynos->clk = devm_clk_get(dev, "usbdrd30");
+   if (IS_ERR(exynos->clk)) {
dev_err(dev, "couldn't get clock\n");
return -EINVAL;
}
-
-   exynos->dev = dev;
-   exynos->clk = clk;
-
clk_prepare_enable(exynos->clk);
 
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
@@ -185,7 +182,7 @@ err4:
 err3:
regulator_disable(exynos->vdd33);
 err2:
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(exynos->clk);
return ret;
 }
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/11] pinctrl: exynos: Add BUS1 pin controller for exynos7

2014-11-21 Thread Vivek Gautam
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.

Signed-off-by: Naveen Krishna Ch 
Signed-off-by: Vivek Gautam 
Cc: Linus Walleij 
---
 drivers/pinctrl/samsung/pinctrl-exynos.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..caca5b5 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,13 @@ static const struct samsung_pin_bank_data 
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
 };
 
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst = {
+   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
+   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
+   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
+};
+
 const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1349,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
__initconst = {
.pin_banks  = exynos7_pin_banks7,
.nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+   }, {
+   /* pin-controller instance 8 BUS1 data */
+   .pin_banks  = exynos7_pin_banks8,
+   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
+   .eint_gpio_init = exynos_eint_gpio_init,
},
 };
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/11] Exynos7: Adding USB 3.0 support

2014-11-21 Thread Vivek Gautam
The series has dependency on
a) "[PATCH v7 0/7] Enable support for Samsung Exynos7 SoC"
   http://www.spinics.net/lists/linux-samsung-soc/msg38734.html
b) "[GIT PULL] Samsung clock changes for 3.19" - specifically the clock dt
   bindings header.
   http://comments.gmane.org/gmane.linux.kernel.samsung-soc/39142
c) "tty: serial: samsung: Clean-up selection of number of available UARTs"
   http://www.spinics.net/lists/linux-samsung-soc/msg37418.html
d) "dts, kbuild: Implement support for dtb vendor subdirs"(merged in linux-next)
   https://lkml.org/lkml/2014/10/21/654
e) "Samsung pinctrl patches for v3.19"
   http://www.spinics.net/lists/linux-samsung-soc/msg38744.html

Tested on Exynos7-espresso board with 3.18-rc5 and above dependencies.

Clubbing the pinctrl, clk, and usb driver changes alongwith the dt changes
together in this series only so as to avoid having 'n' number of dependencies.

The USB driver patches in this series were part of [1] sent earlier.
[1] [PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7
https://lkml.org/lkml/2014/10/7/191

Vivek Gautam (11):
  pinctrl: exynos: Add BUS1 pin controller for exynos7
  dwc3: exynos: Remove local variable for clock from probe
  dwc3: exynos: Add provision for suspend clock
  dwc3: exynos: Add provision for AXI UpScaler clock on exynos7
  phy: exynos5-usbdrd: Add pipe-clk, utmi-clk and itp-clk support
  phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
  phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS
  clk: exynos7: Add required clock tree for USB
  arm64: exynos: Add bus1 pinctrl node on exynos7
  arm64: dts: Enable USB 3.0 controller on exynos7
  arm64: dts: exynos7-espresso: Add regulators for Vbus and Vbus-Boost

 .../devicetree/bindings/phy/samsung-phy.txt|6 +
 .../devicetree/bindings/usb/exynos-usb.txt |6 +-
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts|   43 +++
 arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi|   26 
 arch/arm64/boot/dts/exynos/exynos7.dtsi|   42 ++
 drivers/clk/samsung/clk-exynos7.c  |   64 +
 drivers/phy/Kconfig|2 +-
 drivers/phy/phy-exynos5-usbdrd.c   |  136 +---
 drivers/pinctrl/samsung/pinctrl-exynos.c   |   12 ++
 drivers/usb/dwc3/dwc3-exynos.c |   39 +-
 include/dt-bindings/clock/exynos7-clk.h|9 +-
 11 files changed, 354 insertions(+), 31 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver

2014-11-20 Thread Vivek Gautam
Hi Pankaj,


On Tue, Nov 18, 2014 at 4:17 PM, Pankaj Dubey  wrote:
> Let's register restart handler from PMU driver for restart
> functionality. So that we can remove restart hooks from
> machine specific file, and thus moving ahead when PMU moved
> to driver folder, this functionality can be reused for ARM64
> based Exynos SoC's.
>
> Signed-off-by: Pankaj Dubey 
> Acked-by: Guenter Roeck 
> ---

Tested on Exynos5800 peach-pi board with linux-samsung/for-next.
Reboot works as expected mutiple times.

Tested-by: Vivek Gautam 

>  arch/arm/mach-exynos/common.h |1 -
>  arch/arm/mach-exynos/exynos.c |6 --
>  arch/arm/mach-exynos/pmu.c|   23 +++
>  3 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index 431be1b..865f878 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -12,7 +12,6 @@
>  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
>  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>
> -#include 
>  #include 
>
>  #define EXYNOS3250_SOC_ID  0xE3472000
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 8f995b7..c13d083 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -87,11 +87,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
> },
>  };
>
> -static void exynos_restart(enum reboot_mode mode, const char *cmd)
> -{
> -   __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET);
> -}
> -
>  static struct platform_device exynos_cpuidle = {
> .name  = "exynos_cpuidle",
>  #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
> @@ -316,7 +311,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened 
> Device Tree)")
> .init_machine   = exynos_dt_machine_init,
> .init_late  = exynos_init_late,
> .dt_compat  = exynos_dt_compat,
> -   .restart= exynos_restart,
> .reserve= exynos_reserve,
> .dt_fixup   = exynos_dt_fixup,
>  MACHINE_END
> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> index 6c8a76d..e4c3512 100644
> --- a/arch/arm/mach-exynos/pmu.c
> +++ b/arch/arm/mach-exynos/pmu.c
> @@ -11,8 +11,11 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>
>  #include "exynos-pmu.h"
> @@ -716,6 +719,13 @@ static void exynos5420_pmu_init(void)
> pr_info("EXYNOS5420 PMU initialized\n");
>  }
>
> +static int pmu_restart_notify(struct notifier_block *this,
> +   unsigned long code, void *unused)
> +{
> +   pmu_raw_writel(0x1, EXYNOS_SWRESET);
> +
> +   return NOTIFY_DONE;
> +}
>
>  static const struct exynos_pmu_data exynos4210_pmu_data = {
> .pmu_config = exynos4210_pmu_config,
> @@ -765,11 +775,20 @@ static const struct of_device_id 
> exynos_pmu_of_device_ids[] = {
> { /*sentinel*/ },
>  };
>
> +/*
> + * Exynos PMU restart notifier, handles restart functionality
> + */
> +static struct notifier_block pmu_restart_handler = {
> +   .notifier_call = pmu_restart_notify,
> +   .priority = 128,
> +};
> +
>  static int exynos_pmu_probe(struct platform_device *pdev)
>  {
> const struct of_device_id *match;
> struct device *dev = &pdev->dev;
> struct resource *res;
> +   int ret;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> pmu_base_addr = devm_ioremap_resource(dev, res);
> @@ -794,6 +813,10 @@ static int exynos_pmu_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, pmu_context);
>
> +   ret = register_restart_handler(&pmu_restart_handler);
> +   if (ret)
> +   dev_warn(dev, "can't register restart handler err=%d\n", ret);
> +
> dev_dbg(dev, "Exynos PMU Driver probe done\n");
> return 0;
>  }
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Vivek Gautam
Hi Javier,


On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas
 wrote:
> Hello Vivek,
>
> On 11/20/2014 08:51 AM, Vivek Gautam wrote:
>>>
>>> I tested linux-next on Exynos5800 peach-pi board with linux-next and and 
>>> the two
>>> patches $Subject and [0].
>>>
>>> Below is my git hash:
>>> 4d9e6ee drm/exynos: Move platform drivers registration to module init
>>> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>>> phy
>>> 36391a5 Add linux-next specific files for 20141119
>>> 9b1ced1 Merge branch 'akpm/master'
>>> 282497e mm: add strictlimit knob
>>
>> used exynos_defconfig
>>
>
> Same here.
>
>>>
>>> With this display works for me.
>>> Without $Subject patch i get lookup in drm.
>>>
>
> I tested with today linux-next (next-20141120) and display is indeed
> working for me. So it seems that whatever caused the error in the
> phy-exynos-mipi-video driver reported by Paolo, got fixed recently.
>
> My working git hash is:
>
> 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> a9b43cb drm/exynos: Move platform drivers registration to module init
> 5b83d7a Add linux-next specific files for 20141120
> 1172916 mm: add strictlimit knob
>
> I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
> did not boot due the issue reported previously by Kevin.
>
>>> Javier can you tell me your git hash. Was it on yesterday's linux-next ?
>>
>
> In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
> was not based on yesterday's next but next-20141117. The git hash is:
>
> 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
> f740096 drm/exynos: Move platform drivers registration to module init
> efefb5c Add linux-next specific files for 20141117
> 8c944d7 mm: add strictlimit knob
>
>> With 3.18-rc5 i could see display on Exynos5800 peach-pi with
>> following git hash:
>>
>> b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
>> 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
>> d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>> fc14f9c Linux 3.18-rc5
>> e35c5a2 Merge tag 'armsoc-for-rc5' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
>>
>> I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).
>>
>
> Yes, that works because the commit that caused the Exynos DRM lockup was:
>
> 43c0767 ("of/platform: Move platform devices under /sys/devices/platform")
>
> which landed in next-20141105.
>
> Reverting 43c0767 and only applying [0] should have the same effect.
>
>> I am checking further with linux-samsung, coz i could see weird
>> behavior as mentioned
>> in [1] with linux-samsun/for-next merged with above git hash.
>>
>
> Great, it should be good to know what caused:

On linux-samsung tree the only patch that's missing apart from dptx-phy patches
is the syscon patch from Pankaj Dubey:
b784b98 mfd: syscon: Decouple syscon interface from platform devices

So with below git hash, linux-samsung/for-next display works fine along with
other devices that request PMU system controller :

7bd219e drm/exynos: dp: Remove support for unused dptx-phy
e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
7099bde Revert "Revert "ARM: exynos_defconfig: Enable options for
display panel support""
713a994 mfd: syscon: Decouple syscon interface from platform devices
7552917 Revert "ARM: exynos_defconfig: Enable options for display
panel support" /* This is Kukjin's for-next today */
ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
fc14f9c Linux 3.18-rc5


>
> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
> [mem 0x10040714-0x1004071f]

The only reason i see this fails is since PMU is now requesting the
entire memory
region with base 0x1004. We should convert the mipi-phy pmu
register handling
too through syscon.

>
> even when I could not reproduce it anymore with today's linux-next.
>
>>>> [0]: https://lkml.org/lkml/2014/10/30/394
>>>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-19 Thread Vivek Gautam
Hi,


On Thu, Nov 20, 2014 at 12:36 PM, Vivek Gautam
 wrote:
> Hi Javier, Kevin,
>
>
>
> On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
>  wrote:
>> [adding Paolo and Vivek as cc]
>>
>> Hello,
>>
>> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>>
>>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>>> it proceeds to panic in the workqueue code called by the asoc max98090
>>> codec[1].
>>>
>>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>>> but I still don't have display output.
>>>
>>
>> Paolo Pisati pointed out in another thread that he needed the patch
>> "[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
>> phy"
>> is also needed to get display working for exynos on linux-next.
>>
>> I've pinged Kukjin to apply this as a -rc fix since is needed after
>> a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
>> landed in 3.18 which broke the Exynos Display Port PHY:
>>
>> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
>>
>> I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
>> $subject
>> and [0] should be enough to have display working on Peach Pi with linux-next 
>> but
>> it fails to me with:
>>
>> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
>> [mem 0x10040714-0x1004071f]
>>
>> The same issue was reported by Paolo a couple of days ago [1].
>>
>> Vivek,
>>
>> Any idea what could cause this regression on linux-next? As reported by 
>> Paolo this
>> works well for me in 3.18-rc5.
>
> I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
> two
> patches $Subject and [0].
>
> Below is my git hash:
> 4d9e6ee drm/exynos: Move platform drivers registration to module init
> 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
> phy
> 36391a5 Add linux-next specific files for 20141119
> 9b1ced1 Merge branch 'akpm/master'
> 282497e mm: add strictlimit knob

used exynos_defconfig

>
> With this display works for me.
> Without $Subject patch i get lookup in drm.
>
> Javier can you tell me your git hash. Was it on yesterday's linux-next ?

With 3.18-rc5 i could see display on Exynos5800 peach-pi with
following git hash:

b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
fc14f9c Linux 3.18-rc5
e35c5a2 Merge tag 'armsoc-for-rc5' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).

I am checking further with linux-samsung, coz i could see weird
behavior as mentioned
in [1] with linux-samsun/for-next merged with above git hash.

>> [0]: https://lkml.org/lkml/2014/10/30/394
>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-19 Thread Vivek Gautam
Hi Javier, Kevin,



On Wed, Nov 19, 2014 at 10:22 PM, Javier Martinez Canillas
 wrote:
> [adding Paolo and Vivek as cc]
>
> Hello,
>
> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>
>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>> it proceeds to panic in the workqueue code called by the asoc max98090
>> codec[1].
>>
>> If I then disable CONFIG_SND_SOC_SNOW, I can get it to boot to a shell,
>> but I still don't have display output.
>>
>
> Paolo Pisati pointed out in another thread that he needed the patch
> "[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
> phy"
> is also needed to get display working for exynos on linux-next.
>
> I've pinged Kukjin to apply this as a -rc fix since is needed after
> a5ec598 ("phy: exynos-dp-video: Use syscon support to control pmu register")
> landed in 3.18 which broke the Exynos Display Port PHY:
>
> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap
>
> I've an Exynos5800 Peach Pi now so I wanted to test display on it. Just 
> $subject
> and [0] should be enough to have display working on Peach Pi with linux-next 
> but
> it fails to me with:
>
> exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
> [mem 0x10040714-0x1004071f]
>
> The same issue was reported by Paolo a couple of days ago [1].
>
> Vivek,
>
> Any idea what could cause this regression on linux-next? As reported by Paolo 
> this
> works well for me in 3.18-rc5.

I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two
patches $Subject and [0].

Below is my git hash:
4d9e6ee drm/exynos: Move platform drivers registration to module init
4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
36391a5 Add linux-next specific files for 20141119
9b1ced1 Merge branch 'akpm/master'
282497e mm: add strictlimit knob

With this display works for me.
Without $Subject patch i get lookup in drm.

Javier can you tell me your git hash. Was it on yesterday's linux-next ?

>
> Best regards,
> Javier
>
> [0]: https://lkml.org/lkml/2014/10/30/394
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-11-19 Thread Vivek Gautam
Hi Javier,


On Wed, Nov 19, 2014 at 5:06 PM, Javier Martinez Canillas
 wrote:
> [adding Kukjin to cc list]
>
> Hello Vivek,
>
> On Wed, Nov 12, 2014 at 5:21 AM, Jingoo Han  wrote:
>> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>>
>>> DP PHY now require pmu-system-controller to handle PMU register
>>> to control PHY's power isolation. Adding the same to dp-phy
>>> node.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Jingoo Han 
>>
>> Reviewed-by: Jingoo Han 
>>
>
> Tested-by: Javier Martinez Canillas 

Thanks for testing.

>
> Kukjin,

Sorry for not adding Kukjin to the list and thereby for the delay
about this patch.

>
> This patch is -rc material and is needed to have display working in
> 3.18 again since commit a5ec598 ("phy: exynos-dp-video: Use syscon
> support to control pmu register") landed in 3.18 and broke the Exynos
> Display Port PHY:
>
> exynos-dp-video-phy 10040728.video-phy: Failed to lookup PMU regmap

Yes, we should pick this up and merge it since the driver patch is merged now.



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

2014-11-18 Thread Vivek Gautam
On Mon, Nov 17, 2014 at 9:46 PM, Sergei Shtylyov
 wrote:
> Hello.
>
> On 11/17/2014 9:36 AM, Vivek Gautam wrote:
>
>>>> The host controller by itself may sometimes need to handle PHY
>>>> and re-initialize it to re-configure some of the PHY parameters
>>>> to get full support out of the PHY controller.
>>>> Therefore, facilitate getting the two possible PHYs, viz.
>>>> USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.
>
>
>>>> Signed-off-by: Vivek Gautam 
>>>> ---
>>>>drivers/usb/host/xhci-plat.c |   74
>>>> ++
>>>>1 file changed, 74 insertions(+)
>
>
>>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>>> index 3d78b0c..5207d5b 100644
>>>> --- a/drivers/usb/host/xhci-plat.c
>>>> +++ b/drivers/usb/host/xhci-plat.c
>
> [...]
>>>>
>>>> @@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev)
>>>>  struct usb_hcd  *hcd = dev_get_drvdata(dev);
>>>>  struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>>>
>>>> +   phy_exit(hcd->phy);
>
>
>>> Hm, in the suspend() method?
>
>
>> phy_exit() should eventually be suspending the PHY and put it to
>> low power state.
>
>
>I thought it's a role that the power_off() mothod should play,
> considering that the power_on() method gets called after the init()
> method

phy_power_off() should be cutting the clocks and power from PHY
completely, no ?
In that case one may not be able to wakeup the system from USB.

So phy_exit() gets the responsibility to put the PHY into low power state.

Ccing Kishon also to get his opinion on actual role of the two callbacks -
phy_init/exit() and phy_power_on/off().

>
>> phy_init() in resume() will then take up the task of activating the
>> PHY again.
>
>
>> phy_power_on() and phy_power_off() are called at xhci_probe() and remove()
>> time.
>
>
>Of course.
>
>> Does this makes sense ?
>
>
>Not much, really.
>
> WBR, Sergei
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

2014-11-16 Thread Vivek Gautam
Hi Felipe,



On Fri, Oct 31, 2014 at 6:56 PM, Vivek Gautam  wrote:
> The host controller by itself may sometimes need to handle PHY
> and re-initialize it to re-configure some of the PHY parameters
> to get full support out of the PHY controller.
> Therefore, facilitate getting the two possible PHYs, viz.
> USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.
>
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/usb/host/xhci-plat.c |   74 
> ++
>  1 file changed, 74 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 3d78b0c..5207d5b 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -129,10 +130,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
> goto put_hcd;
> }
>
> +   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
> +   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
> +   if (IS_ERR(hcd->phy)) {
> +   ret = PTR_ERR(hcd->phy);
> +   if (ret == -EPROBE_DEFER) {
> +   goto disable_clk;
> +   } else if (ret != -ENOSYS && ret != -ENODEV) {
> +   hcd->phy = NULL;
> +   dev_warn(&pdev->dev,
> +"Error retrieving usb2 phy: %d\n", ret);
> +   }
> +   }
> +
> ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (ret)
> goto disable_clk;
>
> +   /*
> +* Initialize and power-on USB 2.0 PHY
> +* FIXME: Isn't this a hacky way of initializing the PHY again ?
> +* xhci's parent would have already initialized the PHY, but we
> +* wanna do it again.
> +*/

Does this change looks anywhere close to what you suggested to
re-initialize PHYs in XHCI even after DWC3 has initialized them once,
in order to avoid adding phy_calibration() callback ? ;-)

> +   hcd->phy->init_count = 0;
> +   ret = phy_init(hcd->phy);
> +   if (ret)
> +   goto dealloc_usb2_hcd;
> +
> +   hcd->phy->power_count = 0;
> +   ret = phy_power_on(hcd->phy);
> +   if (ret) {
> +   phy_exit(hcd->phy);
> +   goto dealloc_usb2_hcd;
> +   }
> +
> device_wakeup_enable(hcd->self.controller);
>
> /* USB 2.0 roothub is stored in the platform_device now. */
> @@ -158,12 +190,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> xhci->shared_hcd->can_do_streams = 1;
>
> +   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
> +   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
> +   if (IS_ERR(xhci->shared_hcd->phy)) {
> +   ret = PTR_ERR(xhci->shared_hcd->phy);
> +   if (ret == -EPROBE_DEFER) {
> +   goto put_usb3_hcd;
> +   } else if (ret != -ENOSYS && ret != -ENODEV) {
> +   xhci->shared_hcd->phy = NULL;
> +   dev_warn(&pdev->dev,
> +"Error retrieving usb3 phy: %d\n", ret);
> +   }
> +   }
> +
> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> if (ret)
> goto put_usb3_hcd;
>
> +   /* Initialize and power-on USB 3.0 PHY */
> +   xhci->shared_hcd->phy->init_count = 0;
> +   ret = phy_init(xhci->shared_hcd->phy);
> +   if (ret)
> +   goto dealloc_usb3_hcd;
> +
> +   xhci->shared_hcd->phy->power_count = 0;
> +   ret = phy_power_on(xhci->shared_hcd->phy);
> +   if (ret) {
> +   phy_exit(xhci->shared_hcd->phy);
> +   goto dealloc_usb3_hcd;
> +   }
> +
> return 0;
>
> +dealloc_usb3_hcd:
> +   usb_remove_hcd(xhci->shared_hcd);
> +
>  put_usb3_hcd:
> usb_put_hcd(xhci->shared_hcd);
>
> @@ -186,9 +247,15 @@ static int xhci_plat_remove(struct platform_device *dev)
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> struct clk *clk = xhci->clk;
>
> +   phy_power_off(xhci->shared_hcd->phy);
> +   phy_exit(xhci->shared_hcd->phy);
> +
> usb_remove_hcd(xhci->shared_hcd);
> usb_put_hcd(xhci->shared_hcd)

Re: [PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

2014-11-16 Thread Vivek Gautam
Hi,


On Fri, Oct 31, 2014 at 7:21 PM, Sergei Shtylyov
 wrote:
> Hello.
>
> On 10/31/2014 4:26 PM, Vivek Gautam wrote:
>
>> The host controller by itself may sometimes need to handle PHY
>> and re-initialize it to re-configure some of the PHY parameters
>> to get full support out of the PHY controller.
>> Therefore, facilitate getting the two possible PHYs, viz.
>> USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.
>
>
>> Signed-off-by: Vivek Gautam 
>> ---
>>   drivers/usb/host/xhci-plat.c |   74
>> ++
>>   1 file changed, 74 insertions(+)
>
>
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index 3d78b0c..5207d5b 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>
> [...]
>>
>> @@ -129,10 +130,41 @@ static int xhci_plat_probe(struct platform_device
>> *pdev)
>> goto put_hcd;
>> }
>>
>> +   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
>> +   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
>> +   if (IS_ERR(hcd->phy)) {
>> +   ret = PTR_ERR(hcd->phy);
>> +   if (ret == -EPROBE_DEFER) {
>> +   goto disable_clk;
>> +   } else if (ret != -ENOSYS && ret != -ENODEV) {
>
>
>Asking to be a *switch* statement instead...

Sure, will change this to *switch* statement. That will improve the
readability.

>
>> +   hcd->phy = NULL;
>> +   dev_warn(&pdev->dev,
>> +"Error retrieving usb2 phy: %d\n", ret);
>> +   }
>> +   }
>> +
>
> [...]
>>
>> @@ -158,12 +190,41 @@ static int xhci_plat_probe(struct platform_device
>> *pdev)
>> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
>> xhci->shared_hcd->can_do_streams = 1;
>>
>> +   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
>> +   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
>> +   if (IS_ERR(xhci->shared_hcd->phy)) {
>> +   ret = PTR_ERR(xhci->shared_hcd->phy);
>> +   if (ret == -EPROBE_DEFER) {
>> +   goto put_usb3_hcd;
>> +   } else if (ret != -ENOSYS && ret != -ENODEV) {
>
>
>Likewise...

ok

>
>> +   xhci->shared_hcd->phy = NULL;
>> +   dev_warn(&pdev->dev,
>> +"Error retrieving usb3 phy: %d\n", ret);
>> +   }
>> +   }
>> +
>
> [...]
>>
>> @@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev)
>> struct usb_hcd  *hcd = dev_get_drvdata(dev);
>> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>>
>> +   phy_exit(hcd->phy);
>
>
>Hm, in the suspend() method?

phy_exit() should eventually be suspending the PHY and put it to
low power state.
phy_init() in resume() will then take up the task of activating the
PHY again.

phy_power_on() and phy_power_off() are called at xhci_probe() and remove() time.

Does this makes sense ?



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 RESEND 1/2] drm/exynos: dp: Remove support for unused dptx-phy

2014-11-12 Thread Vivek Gautam
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Inki Dae 
---

Problem with my mail client caused change in author's mail id.
So resending it with authorship under my Samsung id.

 drivers/gpu/drm/exynos/exynos_dp_core.c |   74 +++
 drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
 2 files changed, 17 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cd50ece..dbe9add 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_on(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg |= dp->enable_mask;
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_off(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg &= ~(dp->enable_mask);
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_poweron(struct exynos_drm_display *display)
@@ -1210,44 +1196,6 @@ static struct video_info 
*exynos_dp_dt_parse_pdata(struct device *dev)
return dp_video_config;
 }
 
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-   u32 phy_base;
-   int ret = 0;
-
-   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-   if (!dp_phy_node) {
-   dp->phy = devm_phy_get(dp->dev, "dp");
-   return PTR_ERR_OR_ZERO(dp->phy);
-   }
-
-   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
-   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-   &dp->enable_mask)) {
-   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   dp->phy_addr = ioremap(phy_base, SZ_4);
-   if (!dp->phy_addr) {
-   dev_err(dp->dev, "failed to ioremap dp-phy\n");
-   ret = -ENOMEM;
-   goto err;
-   }
-
-err:
-   of_node_put(dp_phy_node);
-
-   return ret;
-}
-
 static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
 {
int ret;
@@ -1277,9 +1225,21 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
if (IS_ERR(dp->video_info))
return PTR_ERR(dp->video_info);
 
-   ret = exynos_dp_dt_parse_phydata(dp);
-   if (ret)
-   return ret;
+   dp->phy = devm_phy_get(dp->dev, "dp");
+   if (IS_ERR(dp->phy)) {
+   dev_err(dp->dev, "no DP phy configured\n");
+   ret = PTR_ERR(dp->phy);
+   if (ret) {
+   /*
+* phy itself is not enabled, so we can move forward
+* assigning NULL to phy pointer.
+*/
+   if (ret == -ENOSYS || ret == -ENODEV)
+   dp->phy = NULL;
+   else
+   return ret;
+   }
+   }
 
if (!dp->panel) {
ret = exynos_dp_dt_parse_panel(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..6426201 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,8 +153,6 @@ struct exynos_dp_device {
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-   void __iomem*phy_addr;
-   unsigned intenable_mask;
 
struct video_info   *video_info;
struct link_train   link_train;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/2] drm/exynos: dp: Remove support for unused dptx-phy

2014-11-12 Thread Vivek Gautam
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam 
Cc: Inki Dae 
Cc: Jingoo Han 
---

Changes from V2:
 - Moved devm_phy_get() call out of exynos_dp_dt_parse_phydata() to
   exynos_dp_bind() function and,
   removed exynos_dp_dt_parse_phydata() function, since it was only
   getting the PHY.

Changes from V1:
 - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
   by Inki.

 drivers/gpu/drm/exynos/exynos_dp_core.c |   74 +++
 drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
 2 files changed, 17 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cd50ece..dbe9add 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_on(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg |= dp->enable_mask;
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_off(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg &= ~(dp->enable_mask);
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_poweron(struct exynos_drm_display *display)
@@ -1210,44 +1196,6 @@ static struct video_info 
*exynos_dp_dt_parse_pdata(struct device *dev)
return dp_video_config;
 }
 
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
-   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-   u32 phy_base;
-   int ret = 0;
-
-   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-   if (!dp_phy_node) {
-   dp->phy = devm_phy_get(dp->dev, "dp");
-   return PTR_ERR_OR_ZERO(dp->phy);
-   }
-
-   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
-   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-   &dp->enable_mask)) {
-   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   dp->phy_addr = ioremap(phy_base, SZ_4);
-   if (!dp->phy_addr) {
-   dev_err(dp->dev, "failed to ioremap dp-phy\n");
-   ret = -ENOMEM;
-   goto err;
-   }
-
-err:
-   of_node_put(dp_phy_node);
-
-   return ret;
-}
-
 static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
 {
int ret;
@@ -1277,9 +1225,21 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
if (IS_ERR(dp->video_info))
return PTR_ERR(dp->video_info);
 
-   ret = exynos_dp_dt_parse_phydata(dp);
-   if (ret)
-   return ret;
+   dp->phy = devm_phy_get(dp->dev, "dp");
+   if (IS_ERR(dp->phy)) {
+   dev_err(dp->dev, "no DP phy configured\n");
+   ret = PTR_ERR(dp->phy);
+   if (ret) {
+   /*
+* phy itself is not enabled, so we can move forward
+* assigning NULL to phy pointer.
+*/
+   if (ret == -ENOSYS || ret == -ENODEV)
+   dp->phy = NULL;
+   else
+   return ret;
+   }
+   }
 
if (!dp->panel) {
ret = exynos_dp_dt_parse_panel(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..6426201 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,8 +153,6 @@ struct exynos_dp_device {
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-   void __iomem*phy_addr;
-   unsigned intenable_mask;
 
struct video_info   *video_info;
struct link_train   link_train;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

2014-11-12 Thread Vivek Gautam
On Wed, Nov 12, 2014 at 9:38 AM, Jingoo Han  wrote:
> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>
> Right, older dptx-phy was replaced long time ago.
> However, it was not removed for DT compatibility.
> I think that now these old DT properties can be removed.
>
> I added some comments below.

Thanks Jingoo for reviewing.

>
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Inki Dae 
>> Cc: Jingoo Han 
>> ---
>>
>> Changes from V1:
>>  - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
>>by Inki.
>>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   67 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
>>  2 files changed, 17 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index cd50ece..206163b 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_on(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg |= dp->enable_mask;
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_off(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg &= ~(dp->enable_mask);
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1212,40 +1198,13 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> - u32 phy_base;
>> - int ret = 0;
>> -
>> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> - if (!dp_phy_node) {
>> - dp->phy = devm_phy_get(dp->dev, "dp");
>> - return PTR_ERR_OR_ZERO(dp->phy);
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
>> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> - &dp->enable_mask)) {
>> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - dp->phy_addr = ioremap(phy_base, SZ_4);
>> - if (!dp->phy_addr) {
>> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + dp->phy = devm_phy_get(dp->dev, "dp");
>> + if (IS_ERR(dp->phy)) {
>> + dev_err(dp->dev, "no DP phy configured\n");
>> + return PTR_ERR(dp->phy);
>>   }
>>
>> -err:
>> - of_node_put(dp_phy_node);
>> -
>> - return ret;
>> + return 0;
>>  }
>>
>>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
>> @@ -1278,8 +1237,16 @@ static int exynos_dp_bind(struct device *dev, struct 
>> device *master, void *data)
>>   return PTR_ERR(dp->video_info);
>>
>>   ret = exynos_dp_dt_parse_phydata(dp);
>
> In your patch, exynos_dp_dt_parse_phydata() calls only devm_phy_get().
> Then, how about calling devm_phy_get() directly and removing
> exynos_dp_dt_parse_phydata()? It looks simpler.

Right,

[PATCH v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds

2014-10-31 Thread Vivek Gautam
The host controller by itself may sometimes need to handle PHY
and re-initialize it to re-configure some of the PHY parameters
to get full support out of the PHY controller.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/host/xhci-plat.c |   74 ++
 1 file changed, 74 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..5207d5b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -129,10 +130,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
 
+   /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->phy)) {
+   ret = PTR_ERR(hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto disable_clk;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb2 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
 
+   /*
+* Initialize and power-on USB 2.0 PHY
+* FIXME: Isn't this a hacky way of initializing the PHY again ?
+* xhci's parent would have already initialized the PHY, but we
+* wanna do it again.
+*/
+   hcd->phy->init_count = 0;
+   ret = phy_init(hcd->phy);
+   if (ret)
+   goto dealloc_usb2_hcd;
+
+   hcd->phy->power_count = 0;
+   ret = phy_power_on(hcd->phy);
+   if (ret) {
+   phy_exit(hcd->phy);
+   goto dealloc_usb2_hcd;
+   }
+
device_wakeup_enable(hcd->self.controller);
 
/* USB 2.0 roothub is stored in the platform_device now. */
@@ -158,12 +190,41 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+   xhci->shared_hcd->phy = devm_phy_get(&pdev->dev, "usb3-phy");
+   if (IS_ERR(xhci->shared_hcd->phy)) {
+   ret = PTR_ERR(xhci->shared_hcd->phy);
+   if (ret == -EPROBE_DEFER) {
+   goto put_usb3_hcd;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   xhci->shared_hcd->phy = NULL;
+   dev_warn(&pdev->dev,
+"Error retrieving usb3 phy: %d\n", ret);
+   }
+   }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
 
+   /* Initialize and power-on USB 3.0 PHY */
+   xhci->shared_hcd->phy->init_count = 0;
+   ret = phy_init(xhci->shared_hcd->phy);
+   if (ret)
+   goto dealloc_usb3_hcd;
+
+   xhci->shared_hcd->phy->power_count = 0;
+   ret = phy_power_on(xhci->shared_hcd->phy);
+   if (ret) {
+   phy_exit(xhci->shared_hcd->phy);
+   goto dealloc_usb3_hcd;
+   }
+
return 0;
 
+dealloc_usb3_hcd:
+   usb_remove_hcd(xhci->shared_hcd);
+
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
@@ -186,9 +247,15 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   phy_power_off(xhci->shared_hcd->phy);
+   phy_exit(xhci->shared_hcd->phy);
+
usb_remove_hcd(xhci->shared_hcd);
usb_put_hcd(xhci->shared_hcd);
 
+   phy_power_off(hcd->phy);
+   phy_exit(hcd->phy);
+
usb_remove_hcd(hcd);
if (!IS_ERR(clk))
clk_disable_unprepare(clk);
@@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   phy_exit(hcd->phy);
+
return xhci_suspend(xhci);
 }
 
@@ -211,6 +280,11 @@ static int xhci_plat_resume(struct device *dev)
 {
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   int ret;
+
+   ret = phy_init(hcd->phy);
+   if (ret)
+   return ret;
 
return xhci_resume(xhci, 0);
 }
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v7 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

2014-10-31 Thread Vivek Gautam
Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 1 file changed, 203 insertions(+), 16 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b3ca3bc..1a63634 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -37,13 +37,11 @@
 
 /* EXYNOS5: USB 3.0 DRD PHY registers */
 #define EXYNOS5_DRD_LINKSYSTEM 0x04
-
 #define LINKSYSTEM_FLADJ_MASK  (0x3f << 1)
 #define LINKSYSTEM_FLADJ(_x)   ((_x) << 1)
 #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27)
 
 #define EXYNOS5_DRD_PHYUTMI0x08
-
 #define PHYUTMI_OTGDISABLE BIT(6)
 #define PHYUTMI_FORCESUSPEND   BIT(1)
 #define PHYUTMI_FORCESLEEP BIT(0)
@@ -51,26 +49,20 @@
 #define EXYNOS5_DRD_PHYPIPE0x0c
 
 #define EXYNOS5_DRD_PHYCLKRST  0x10
-
 #define PHYCLKRST_EN_UTMISUSPEND   BIT(31)
-
 #define PHYCLKRST_SSC_REFCLKSEL_MASK   (0xff << 23)
 #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23)
-
 #define PHYCLKRST_SSC_RANGE_MASK   (0x03 << 21)
 #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21)
-
 #define PHYCLKRST_SSC_EN   BIT(20)
 #define PHYCLKRST_REF_SSP_EN   BIT(19)
 #define PHYCLKRST_REF_CLKDIV2  BIT(18)
-
 #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF   (0x19 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF  (0x32 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11)
 #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11)
-
 #define PHYCLKRST_FSEL_UTMI_MASK   (0x7 << 5)
 #define PHYCLKRST_FSEL_PIPE_MASK   (0x7 << 8)
 #define PHYCLKRST_FSEL(_x) ((_x) << 5)
@@ -78,46 +70,68 @@
 #define PHYCLKRST_FSEL_PAD_24MHZ   (0x2a << 5)
 #define PHYCLKRST_FSEL_PAD_20MHZ   (0x31 << 5)
 #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5)
-
 #define PHYCLKRST_RETENABLEN   BIT(4)
-
 #define PHYCLKRST_REFCLKSEL_MASK   (0x03 << 2)
 #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2)
 #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2)
-
 #define PHYCLKRST_PORTRESETBIT(1)
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
-
 #define PHYPARAM0_REF_USE_PAD  BIT(31)
 #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26)
 #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26)
 
 #define EXYNOS5_DRD_PHYPARAM1  0x20
-
 #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0)
 #define PHYPARAM1_PCS_TXDEEMPH (0x1c)
 
 #define EXYNOS5_DRD_PHYTERM0x24
 
 #define EXYNOS5_DRD_PHYTEST0x28
-
 #define PHYTEST_POWERDOWN_SSP  BIT(3)
 #define PHYTEST_POWERDOWN_HSP  BIT(2)
 
 #define EXYNOS5_DR

[PATCH v7 0/2] Fine tune USB 3.0 PHY on exynos5420

2014-10-31 Thread Vivek Gautam
This series is tested with V3 of Heikki's patches for simpliefied phy lookup 
table:
[PATCHv3 0/6] phy: simplified phy lookup [1] on 'usb-next' branch.
V4 of this series is giving some issue, which i have already pointed out in the
patch: [PATCHv4 2/6] phy: improved lookup method

Changes since v6:
 - Dropped the changes for adding additional phy_calibrate() callback.
 - Added phy_init() and phy_power_on() sequence in xhci-plat driver;
   NOTE: both phy_init() and phy_power_on() will now require PHY's
 'init_count' and 'power_count' to be reset to '0' so that
 we can actually re-initialize the phy. Though this has already been
 pointed out in discussion for the previous patch-series. [2]
 - Refactored return codes and error handling in cr_port functions as pointed
   out by Felipe.

Changes since v5:
 - Assigned NULL to hcd->gen_phy in error path in xhci-plat.c, so that
   we don't need to check for IS_ERR() while calibrating the PHYs in
   core/hcd.c
 - Removed extra empty lines in register definitions in exynos5-usbdrd
   phy driver.
 - Added write access for EXYNOS5_DRD_PHYREG0 register before any
   crport_handshake() call as suggested by Jingoo Han.
 - Renamed member 'calibrate' to 'phy_exynos_calibrate' of
   struct exynos5_usbdrd_phy_drvdata.

Changes since v4:
 - Rebased on latest patches by Heikki.
 - Took care of handling -EPROBE_DEFER error number while getting PHY in
   xhci plat.

Changes from v3:
 - Modified error message as per review comments from Julius.

Changes since v2:
 - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy,
   in order to make it more generic.
 - Moved the phy_calibration calls to core/hcd.c to enable a more generic
   solution for issues of calibrating the PHYs.

Changes since v1:
 - Using 'gen_phy' member of 'hcd' instead of declaring more variables
   to hold phys.
 - Added a check for compatible match for 'Synopsys-dwc3' controller,
   since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY
   in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that,
   instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs
   (main hcd and shared hcd).
 - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()'
   to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3
   controller while trying to calibrate the PHY.

Explanation for the need of this patch-series:
"The DWC3-exynos eXtensible host controller present on Exynos5420/5800
SoCs is quirky. The PHY serving this controller operates at High-Speed
by default, so it detects even Super-speed devices as high-speed ones.
Certain PHY parameters like Tx LOS levels and Boost levels need to be
calibrated further post initialization of xHCI controller, to get
SuperSpeed operations working."

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html
[2] https://lkml.org/lkml/2014/9/2/170;   (to be specific 
https://lkml.org/lkml/2014/9/10/132)

Vivek Gautam (2):
  usb: host: xhci-plat: Get PHYs for xhci's hcds
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-exynos5-usbdrd.c |  219 +++---
 drivers/usb/host/xhci-plat.c |   74 +
 2 files changed, 277 insertions(+), 16 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-10-30 Thread Vivek Gautam
DP PHY now require pmu-system-controller to handle PMU register
to control PHY's power isolation. Adding the same to dp-phy
node.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
---

Changes from V1:
 - none.

 arch/arm/boot/dts/exynos5250.dtsi |2 +-
 arch/arm/boot/dts/exynos5420.dtsi |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 012b021..69f5eb0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -732,7 +732,7 @@
 
dp_phy: video-phy@10040720 {
compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040720 4>;
+   samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8617a03..1353a09 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -503,8 +503,8 @@
};
 
dp_phy: video-phy@10040728 {
-   compatible = "samsung,exynos5250-dp-video-phy";
-   reg = <0x10040728 4>;
+   compatible = "samsung,exynos5420-dp-video-phy";
+   samsung,pmu-syscon = <&pmu_system_controller>;
#phy-cells = <0>;
};
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/2] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-30 Thread Vivek Gautam
Now that we have moved to generic phy based bindings,
we don't need to have any code related to older dptx-phy.
Nobody is using this dptx-phy anymore, so removing the
same.

Signed-off-by: Vivek Gautam 
Cc: Inki Dae 
Cc: Jingoo Han 
---

Changes from V1:
 - Reworked error handling in exynos_dp_dt_parse_phydata() as commented
   by Inki.

 drivers/gpu/drm/exynos/exynos_dp_core.c |   67 ---
 drivers/gpu/drm/exynos/exynos_dp_core.h |2 -
 2 files changed, 17 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cd50ece..206163b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1052,28 +1052,14 @@ static int exynos_dp_create_connector(struct 
exynos_drm_display *display,
 
 static void exynos_dp_phy_init(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_on(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg |= dp->enable_mask;
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
 {
-   if (dp->phy) {
+   if (dp->phy)
phy_power_off(dp->phy);
-   } else if (dp->phy_addr) {
-   u32 reg;
-
-   reg = __raw_readl(dp->phy_addr);
-   reg &= ~(dp->enable_mask);
-   __raw_writel(reg, dp->phy_addr);
-   }
 }
 
 static void exynos_dp_poweron(struct exynos_drm_display *display)
@@ -1212,40 +1198,13 @@ static struct video_info 
*exynos_dp_dt_parse_pdata(struct device *dev)
 
 static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
 {
-   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
-   u32 phy_base;
-   int ret = 0;
-
-   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
-   if (!dp_phy_node) {
-   dp->phy = devm_phy_get(dp->dev, "dp");
-   return PTR_ERR_OR_ZERO(dp->phy);
-   }
-
-   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
-   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
-   &dp->enable_mask)) {
-   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
-   ret = -EINVAL;
-   goto err;
-   }
-
-   dp->phy_addr = ioremap(phy_base, SZ_4);
-   if (!dp->phy_addr) {
-   dev_err(dp->dev, "failed to ioremap dp-phy\n");
-   ret = -ENOMEM;
-   goto err;
+   dp->phy = devm_phy_get(dp->dev, "dp");
+   if (IS_ERR(dp->phy)) {
+   dev_err(dp->dev, "no DP phy configured\n");
+   return PTR_ERR(dp->phy);
}
 
-err:
-   of_node_put(dp_phy_node);
-
-   return ret;
+   return 0;
 }
 
 static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
@@ -1278,8 +1237,16 @@ static int exynos_dp_bind(struct device *dev, struct 
device *master, void *data)
return PTR_ERR(dp->video_info);
 
ret = exynos_dp_dt_parse_phydata(dp);
-   if (ret)
-   return ret;
+   if (ret) {
+   /*
+* phy itself is not enabled, so we can move forward
+* assigning NULL to phy pointer.
+*/
+   if (ret == -ENOSYS || ret == -ENODEV)
+   dp->phy = NULL;
+   else
+   return ret;
+   }
 
if (!dp->panel) {
ret = exynos_dp_dt_parse_panel(dp);
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
b/drivers/gpu/drm/exynos/exynos_dp_core.h
index a1aee69..6426201 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.h
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
@@ -153,8 +153,6 @@ struct exynos_dp_device {
struct clk  *clock;
unsigned intirq;
void __iomem*reg_base;
-   void __iomem*phy_addr;
-   unsigned intenable_mask;
 
struct video_info   *video_info;
struct link_train   link_train;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-30 Thread Vivek Gautam
Hi Inki,


On Thu, Oct 30, 2014 at 5:50 PM, Inki Dae  wrote:
>
> Sorry for late. I missed this patch a little bit for long time.

Thanks for reviewing.

>
>
> On 2014년 09월 15일 22:13, Vivek Gautam wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_on(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg |= dp->enable_mask;
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> - if (dp->phy) {
>> + if (dp->phy)
>>   phy_power_off(dp->phy);
>> - } else if (dp->phy_addr) {
>> - u32 reg;
>> -
>> - reg = __raw_readl(dp->phy_addr);
>> - reg &= ~(dp->enable_mask);
>> - __raw_writel(reg, dp->phy_addr);
>> - }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> - u32 phy_base;
>>   int ret = 0;
>>
>> - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> - if (!dp_phy_node) {
>> - dp->phy = devm_phy_get(dp->dev, "dp");
>> - return PTR_ERR_OR_ZERO(dp->phy);
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
>> - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> - &dp->enable_mask)) {
>> - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> - ret = -EINVAL;
>> - goto err;
>> - }
>> -
>> - dp->phy_addr = ioremap(phy_base, SZ_4);
>> - if (!dp->phy_addr) {
>> - dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> - ret = -ENOMEM;
>> - goto err;
>> + dp->phy = devm_phy_get(dp->dev, "dp");
>> + if (IS_ERR(dp->phy)) {
>> + ret = PTR_ERR(dp->phy);
>> + if (ret == -ENOSYS || ret == -ENODEV) {
>> + dp->phy = NULL;
>> + } else if (ret == -EPROBE_DEFER) {
>> + return ret;
>> + } else {
>
> WARNING: else is not generally useful after a break or return
> #146: FILE: drivers/gpu/drm/exynos/exynos_dp_core.c:1208:
> +   return ret;
> +   } else {
>
> How about just returning ret like below?
> if (IS_ERR(dp->phy)) {
> dev_err(dp->dev, "no DP phy configured\n");
> return PTR_ERR(ret);
> }
>
> And then you can handle the error at probe function properly.

Right, point taken. Will post the reworked patch.

[snip]

-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/3] iio: exyno-adc: use syscon for PMU register access

2014-10-28 Thread Vivek Gautam
ice 
> *pdev)
>
>
> if (info->data->needs_adc_phy) {
> -   mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -   info->enable_reg = devm_ioremap_resource(&pdev->dev, mem);
> -   if (IS_ERR(info->enable_reg))
> -   return PTR_ERR(info->enable_reg);
> +   info->pmu_map = syscon_regmap_lookup_by_phandle(
> +   pdev->dev.of_node,
> +   "samsung,syscon-phandle");
> +       if (IS_ERR(info->pmu_map)) {
> +   dev_err(&pdev->dev, "syscon regmap lookup failed.\n");
> +   return PTR_ERR(info->pmu_map);
> +   }
> }
>
> irq = platform_get_irq(pdev, 0);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7

2014-10-21 Thread Vivek Gautam
On Tue, Oct 21, 2014 at 1:47 PM, Vivek Gautam  wrote:

Corrected Tomasz's mail id, as the earlier samsung one is not valid now.
Also giving a Tested-by

> On Mon, Sep 1, 2014 at 11:14 AM, Abhilash Kesavan
>  wrote:
>> Hi Jaehoon,
>>
>> +Prabu Thangamuthu
>>
>> On Fri, Aug 29, 2014 at 4:14 PM, Jaehoon Chung  
>> wrote:
>>> Hi, Abhilash.
>>>
>>> On 08/28/2014 10:18 PM, Yuvaraj Kumar C D wrote:
>>>> From: Abhilash Kesavan 
>>>>
>>>> The Exynos7 has a DWMMC controller (v2.70a) which is different from
>>>> prior versions. This patch adds new compatible strings for exynos7.
>>>> This patch also fixes the CLKSEL register offset on exynos7.
>>>
>>> If support the 64bit, dw-mmc.c need to modify.(according to v2.70, some 
>>> offset is changed for 64-bit address)
>>> But i didn't see any patches at mailing.
>>> Do you have the plan which send patch of dw-mmc.c?
>>
>> We are using a rebased version of
>> http://www.spinics.net/lists/linux-mmc/msg21742.html to handle the
>> dwmmc side changes. We should have mentioned this dependency as the
>> patch is required for proper functioning of dwmmc on Exynos7.
>> Stress tests are on-going with that patch and once it looks good, we
>> will post our results so that the original patch may be taken forward.
>>
>> Regards,
>> Abhilash
>>>
>>> Best Regards,
>>> Jaehoon Chung
>>>>
>>>> Signed-off-by: Abhilash Kesavan 
>>>> Signed-off-by: Yuvaraj Kumar C D 
>>>> ---
>
> I have tested this patch following set of patches:
>
> On Exynos7 support side:
> 1) dts, kbuild: Implement support for dtb vendor subdirs" patchset
> http://comments.gmane.org/gmane.linux.kbuild.devel/12131
> 2) arch: arm64: Enable support for Samsung Exynos7 SoC  (V5)
> http://www.spinics.net/lists/linux-samsung-soc/msg37047.html
> 3) Serial clean-up patches for Exynos7
> http://www.spinics.net/lists/arm-kernel/msg367348.html
> http://www.spinics.net/lists/arm-kernel/msg367349.html
> 4) Add initial support for pinctrl on Exynos7  (V5)
> http://www.spinics.net/lists/linux-samsung-soc/msg37708.html
>
> On MMC side:
> 1) mmc: dw_mmc: Add IDMAC 64-bit address mode support  (V7)
> https://lkml.org/lkml/2014/10/20/58
> 2) mmc: dw_mmc: Reset DMA before enabling IDMAC  (V2)
> http://www.gossamer-threads.com/lists/linux/kernel/2028229
>
> eMMC and SD are running fine on Exynos7.

Tested-by: Vivek Gautam 

>
> If this change looks good, then we can take it in.
>
>>>>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |4 +
>>>>  drivers/mmc/host/dw_mmc-exynos.c   |   91 
>>>> +---
>>>>  2 files changed, 82 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
>>>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>>> index 6cd3525..ee4fc05 100644
>>>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>>>> @@ -18,6 +18,10 @@ Required Properties:
>>>> specific extensions.
>>>>   - "samsung,exynos5420-dw-mshc": for controllers with Samsung 
>>>> Exynos5420
>>>> specific extensions.
>>>> + - "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
>>>> +   specific extensions.
>>>> + - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>>>> +   specific extensions having an SMU.
>>>>
>>>>  * samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
>>>> interface
>>>>unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
>>>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
>>>> b/drivers/mmc/host/dw_mmc-exynos.c
>>>> index 0fbc53a..509365c 100644
>>>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>>>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>>>> @@ -25,6 +25,7 @@
>>>>  #define NUM_PINS(x)  (x + 2)
>>>>
>>>>  #define SDMMC_CLKSEL 0x09C
>>>> +#define SDMMC_CLKSEL64   0x0A8
>>>>  #define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x) & 7) << 0)
>>>>  #define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x) & 7) << 16)
>>>>  #define SDMMC_CLKSEL_CCLK_DIVIDER(x) ((

Re: [PATCH] mmc: dw_mmc: exynos: Add support for exynos7

2014-10-21 Thread Vivek Gautam
gt; + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> + mci_writel(host, CLKSEL64, priv->sdr_timing);
>>> + else
>>> + mci_writel(host, CLKSEL, priv->sdr_timing);
>>>   }
>>>
>>>   /* Don't care if wanted clock is zero */
>>> @@ -265,26 +301,51 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
>>>
>>>  static inline u8 dw_mci_exynos_get_clksmpl(struct dw_mci *host)
>>>  {
>>> - return SDMMC_CLKSEL_CCLK_SAMPLE(mci_readl(host, CLKSEL));
>>> + struct dw_mci_exynos_priv_data *priv = host->priv;
>>> +
>>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> + return SDMMC_CLKSEL_CCLK_SAMPLE(mci_readl(host, CLKSEL64));
>>> + else
>>> + return SDMMC_CLKSEL_CCLK_SAMPLE(mci_readl(host, CLKSEL));
>>>  }
>>>
>>>  static inline void dw_mci_exynos_set_clksmpl(struct dw_mci *host, u8 
>>> sample)
>>>  {
>>>   u32 clksel;
>>> - clksel = mci_readl(host, CLKSEL);
>>> + struct dw_mci_exynos_priv_data *priv = host->priv;
>>> +
>>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> + clksel = mci_readl(host, CLKSEL64);
>>> + else
>>> + clksel = mci_readl(host, CLKSEL);
>>>   clksel = (clksel & ~0x7) | SDMMC_CLKSEL_CCLK_SAMPLE(sample);
>>> - mci_writel(host, CLKSEL, clksel);
>>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> +     mci_writel(host, CLKSEL64, clksel);
>>> + else
>>> + mci_writel(host, CLKSEL, clksel);
>>>  }
>>>
>>>  static inline u8 dw_mci_exynos_move_next_clksmpl(struct dw_mci *host)
>>>  {
>>> + struct dw_mci_exynos_priv_data *priv = host->priv;
>>>   u32 clksel;
>>>   u8 sample;
>>>
>>> - clksel = mci_readl(host, CLKSEL);
>>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> + clksel = mci_readl(host, CLKSEL64);
>>> + else
>>> + clksel = mci_readl(host, CLKSEL);
>>>   sample = (clksel + 1) & 0x7;
>>>   clksel = (clksel & ~0x7) | sample;
>>> - mci_writel(host, CLKSEL, clksel);
>>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>>> + mci_writel(host, CLKSEL64, clksel);
>>> + else
>>> + mci_writel(host, CLKSEL, clksel);
>>>   return sample;
>>>  }
>>>
>>> @@ -411,6 +472,10 @@ static const struct of_device_id dw_mci_exynos_match[] 
>>> = {
>>>   .data = &exynos_drv_data, },
>>>   { .compatible = "samsung,exynos5420-dw-mshc-smu",
>>>   .data = &exynos_drv_data, },
>>> + { .compatible = "samsung,exynos7-dw-mshc",
>>> + .data = &exynos_drv_data, },
>>> + { .compatible = "samsung,exynos7-dw-mshc-smu",
>>> + .data = &exynos_drv_data, },
>>>   {},
>>>  };
>>>  MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/7] clk: samsung: exynos7: add clocks for MMC block

2014-10-20 Thread Vivek Gautam
sclk_mmc2_p, MUX_SEL_FSYS01, 24, 
> 1),
> +};
> +
> +static struct samsung_gate_clock fsys0_gate_clks[] __initdata = {
> +   GATE(ACLK_MMC2, "aclk_mmc2", "mout_aclk_fsys0_200_user",
> +   ENABLE_ACLK_FSYS01, 31, 0, 0),
> +};
> +
> +static struct samsung_cmu_info fsys0_cmu_info __initdata = {
> +   .mux_clks   = fsys0_mux_clks,
> +   .nr_mux_clks= ARRAY_SIZE(fsys0_mux_clks),
> +   .gate_clks  = fsys0_gate_clks,
> +   .nr_gate_clks   = ARRAY_SIZE(fsys0_gate_clks),
> +   .nr_clk_ids = TOP1_NR_CLK,
> +   .clk_regs   = fsys0_clk_regs,
> +   .nr_clk_regs= ARRAY_SIZE(fsys0_clk_regs),
> +};
> +
> +static void __init exynos7_clk_fsys0_init(struct device_node *np)
> +{
> +   samsung_cmu_register_one(np, &fsys0_cmu_info);
> +}
> +
> +CLK_OF_DECLARE(exynos7_clk_fsys0, "samsung,exynos7-clock-fsys0",
> +   exynos7_clk_fsys0_init);
> +
> +/* Register Offset definitions for CMU_FSYS1 (0x156E) */
> +#define MUX_SEL_FSYS10 0x0200
> +#define MUX_SEL_FSYS11 0x0204
> +#define ENABLE_ACLK_FSYS1  0x0800
> +
> +/*
> + * List of parent clocks for Muxes in CMU_FSYS1
> + */
> +PNAME(mout_aclk_fsys1_200_p)   = { "fin_pll",  "dout_aclk_fsys1_200" };
> +PNAME(mout_sclk_mmc0_p)= { "fin_pll", "sclk_mmc0" };
> +PNAME(mout_sclk_mmc1_p)= { "fin_pll", "sclk_mmc1" };
> +
> +static unsigned long fsys1_clk_regs[] __initdata = {
> +   MUX_SEL_FSYS10,
> +   MUX_SEL_FSYS11,
> +   ENABLE_ACLK_FSYS1,
> +};
> +
> +static struct samsung_mux_clock fsys1_mux_clks[] __initdata = {
> +   MUX(0, "mout_aclk_fsys1_200_user", mout_aclk_fsys1_200_p,
> +   MUX_SEL_FSYS10, 28, 1),
> +
> +   MUX(0, "mout_sclk_mmc1_user", mout_sclk_mmc1_p, MUX_SEL_FSYS11, 24, 
> 1),
> +   MUX(0, "mout_sclk_mmc0_user", mout_sclk_mmc0_p, MUX_SEL_FSYS11, 28, 
> 1),
> +};
> +
> +static struct samsung_gate_clock fsys1_gate_clks[] __initdata = {
> +   GATE(ACLK_MMC1, "aclk_mmc1", "mout_aclk_fsys1_200_user",
> +   ENABLE_ACLK_FSYS1, 29, 0, 0),
> +   GATE(ACLK_MMC0, "aclk_mmc0", "mout_aclk_fsys1_200_user",
> +   ENABLE_ACLK_FSYS1, 30, 0, 0),
> +};
> +
> +static struct samsung_cmu_info fsys1_cmu_info __initdata = {
> +   .mux_clks   = fsys1_mux_clks,
> +   .nr_mux_clks= ARRAY_SIZE(fsys1_mux_clks),
> +   .gate_clks  = fsys1_gate_clks,
> +   .nr_gate_clks   = ARRAY_SIZE(fsys1_gate_clks),
> +   .nr_clk_ids = TOP1_NR_CLK,
> +   .clk_regs   = fsys1_clk_regs,
> +   .nr_clk_regs= ARRAY_SIZE(fsys1_clk_regs),
> +};
> +
> +static void __init exynos7_clk_fsys1_init(struct device_node *np)
> +{
> +   samsung_cmu_register_one(np, &fsys1_cmu_info);
> +}
> +
> +CLK_OF_DECLARE(exynos7_clk_fsys1, "samsung,exynos7-clock-fsys1",
> +   exynos7_clk_fsys1_init);
> diff --git a/include/dt-bindings/clock/exynos7-clk.h 
> b/include/dt-bindings/clock/exynos7-clk.h
> index 6d07b6f..ff63c4e 100644
> --- a/include/dt-bindings/clock/exynos7-clk.h
> +++ b/include/dt-bindings/clock/exynos7-clk.h
> @@ -27,6 +27,17 @@
>  #define CLK_SCLK_UART3 6
>  #define TOP0_NR_CLK7
>
> +/* TOP1 */
> +#define DOUT_ACLK_FSYS1_2001
> +#define DOUT_ACLK_FSYS0_2002
> +#define DOUT_SCLK_MMC2 3
> +#define DOUT_SCLK_MMC1 4
> +#define DOUT_SCLK_MMC0 5
> +#define CLK_SCLK_MMC2  6
> +#define CLK_SCLK_MMC1  7
> +#define CLK_SCLK_MMC0  8
> +#define TOP1_NR_CLK9
> +
>  /* PERIC0 */
>  #define PCLK_UART0 1
>  #define SCLK_UART0 2
> @@ -58,4 +69,13 @@
>  #define SCLK_CHIPID2
>  #define PERIS_NR_CLK   3
>
> +/* FSYS0 */
> +#define ACLK_MMC2  1
> +#define FSYS0_NR_CLK   2
> +
> +/* FSYS1 */
> +#define ACLK_MMC1  1
> +#define ACLK_MMC0  2
> +#define FSYS1_NR_CLK   3
> +
>  #endif /* _DT_BINDINGS_CLOCK_EXYNOS7_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/7] clk: samsung: exynos7: add clocks for RTC block

2014-10-20 Thread Vivek Gautam
 device_node *np)
> +{
> +   samsung_cmu_register_one(np, &ccore_cmu_info);
> +}
> +
> +CLK_OF_DECLARE(exynos7_clk_ccore, "samsung,exynos7-clock-ccore",
> +   exynos7_clk_ccore_init);
> +
>  /* Register Offset definitions for CMU_PERIC0 (0x1361) */
>  #define MUX_SEL_PERIC0 0x0200
>  #define ENABLE_PCLK_PERIC0 0x0900
> diff --git a/include/dt-bindings/clock/exynos7-clk.h 
> b/include/dt-bindings/clock/exynos7-clk.h
> index ff63c4e..3227679 100644
> --- a/include/dt-bindings/clock/exynos7-clk.h
> +++ b/include/dt-bindings/clock/exynos7-clk.h
> @@ -11,12 +11,13 @@
>  #define _DT_BINDINGS_CLOCK_EXYNOS7_H
>
>  /* TOPC */
> -#define DOUT_ACLK_PERIS1
> -#define DOUT_SCLK_BUS0_PLL 2
> -#define DOUT_SCLK_BUS1_PLL 3
> -#define DOUT_SCLK_CC_PLL   4
> -#define DOUT_SCLK_MFC_PLL  5
> -#define TOPC_NR_CLK6
> +#define DOUT_ACLK_CCORE_1331
> +#define DOUT_ACLK_PERIS2
> +#define DOUT_SCLK_BUS0_PLL 3
> +#define DOUT_SCLK_BUS1_PLL 4
> +#define DOUT_SCLK_CC_PLL   5
> +#define DOUT_SCLK_MFC_PLL  6
> +#define TOPC_NR_CLK        7
>
>  /* TOP0 */
>  #define DOUT_ACLK_PERIC1   1
> @@ -38,6 +39,10 @@
>  #define CLK_SCLK_MMC0  8
>  #define TOP1_NR_CLK9
>
> +/* CCORE */
> +#define PCLK_RTC   1
> +#define CCORE_NR_CLK   2
> +
>  /* PERIC0 */
>  #define PCLK_UART0 1
>  #define SCLK_UART0 2
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-13 Thread Vivek Gautam
Hi Felipe,


On Tue, Oct 14, 2014 at 4:14 AM, Felipe Balbi  wrote:
> Hi,
>
> On Mon, Oct 13, 2014 at 01:54:59PM +0900, Anton Tikhomirov wrote:
>> Hi Vivek,
>>
>> > Exynos7 also has a separate special gate clock going to the IP
>> > apart from the usual AHB clock. So add support for the same.
>>
>> As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
>> by the driver. Adding only sclk is not enough.
>>
>> >
>> > Signed-off-by: Vivek Gautam 
>> > ---
>> >  drivers/usb/dwc3/dwc3-exynos.c |   16 
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
>> > exynos.c
>> > index 3951a65..7dc6a98 100644
>> > --- a/drivers/usb/dwc3/dwc3-exynos.c
>> > +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> > @@ -35,6 +35,7 @@ struct dwc3_exynos {
>> > struct device   *dev;
>> >
>> > struct clk  *clk;
>>
>> The clock "clk" in Exynos5 just gated all that above 7 clocks, which
>> we should control separately now in Exynos7.
>>
>
> should I drop this patch for now ?

Yes, better to hold this for some time till we get more clarity
from our h/w team.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-13 Thread Vivek Gautam
Hi Tomasz,


On Tue, Oct 14, 2014 at 6:56 AM, Anton Tikhomirov
 wrote:
> Hello,
>
>> Hi Anton,
>>
>> On 13.10.2014 06:54, Anton Tikhomirov wrote:
>> > Hi Vivek,
>> >
>> >> Exynos7 also has a separate special gate clock going to the IP
>> >> apart from the usual AHB clock. So add support for the same.
>> >
>> > As we discussed before, Exynos7 SoCs have 7 clocks to be controlled
>> > by the driver. Adding only sclk is not enough.
>> >
>>
>> I'm quite interested in this discussion. Has it happened on mailing
>> lists?
>
> No, we used company messenger for the discussion.

Yea, we head a round of discussion at our end regarding this, and we are
going to get more clarity on this from our H/W team too, this week.

>
>>
>> In general, previous SoCs also gave the possibility of controlling all
>> the bus clocks separately, in addition to bulk gates, but there was no
>
> correct
>
>> real advantage in using those, while burdening the clock tree with
>> numerous clocks. Isn't Exynos7 similar in this aspect?
>
> Exynos7 doesn't have "Gating all clocks for USBDRD30" bit. The clocks
> should be controlled separately.

true, on Exynos7 we have separate gates for the available clocks going to
USB-DRD block. So we will have to add these basic required number of
clocks.





-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/4] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

2014-10-12 Thread Vivek Gautam
On Mon, Oct 13, 2014 at 10:36 AM, Anton Tikhomirov
 wrote:
> Hi Vivek,
>
>> Some Exynos SoCs have a separate regulator controlling a
>
> I guess you meant the Exynos based *boards* instead of SoCs,
> since Exynos SoCs don't have any boost regulators.

Right, should be boards instead. Thanks for pointing it out.

>
>> Boost 5V supply which goes as input for VBUS regulator.
>> So adding a control for the same in driver, to enable
>> vbus supply on the port.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/phy/phy-exynos5-usbdrd.c |   30 --
>>  1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-
>> exynos5-usbdrd.c
>> index 013ee84..57e8a0a 100644
>> --- a/drivers/phy/phy-exynos5-usbdrd.c
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>> @@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
>>   u32 extrefclk;
>>   struct clk *ref_clk;
>>   struct regulator *vbus;
>> + struct regulator *vbus_boost;
>>  };
>>
>>  static inline
>> @@ -455,11 +456,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy
>> *phy)
>>   clk_prepare_enable(phy_drd->ref_clk);
>>
>>   /* Enable VBUS supply */
>> + if (phy_drd->vbus_boost) {
>> + ret = regulator_enable(phy_drd->vbus_boost);
>> + if (ret) {
>> + dev_err(phy_drd->dev,
>> + "Failed to enable VBUS boost supply\n");
>> + goto fail_vbus;
>> + }
>> + }
>> +
>>   if (phy_drd->vbus) {
>>   ret = regulator_enable(phy_drd->vbus);
>>   if (ret) {
>>   dev_err(phy_drd->dev, "Failed to enable VBUS
>> supply\n");
>> - goto fail_vbus;
>> + goto fail_vbus_boost;
>>   }
>>   }
>>
>> @@ -468,6 +478,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy
>> *phy)
>>
>>   return 0;
>>
>> +fail_vbus_boost:
>> + if (phy_drd->vbus_boost)
>> + regulator_disable(phy_drd->vbus_boost);
>> +
>>  fail_vbus:
>>   clk_disable_unprepare(phy_drd->ref_clk);
>>   clk_disable_unprepare(phy_drd->pipeclk);
>> @@ -489,6 +503,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy
>> *phy)
>>   /* Disable VBUS supply */
>>   if (phy_drd->vbus)
>>   regulator_disable(phy_drd->vbus);
>> + if (phy_drd->vbus_boost)
>> + regulator_disable(phy_drd->vbus_boost);
>>
>>   clk_disable_unprepare(phy_drd->ref_clk);
>>   clk_disable_unprepare(phy_drd->pipeclk);
>> @@ -644,7 +660,7 @@ static int exynos5_usbdrd_phy_probe(struct
>> platform_device *pdev)
>>   break;
>>   }
>>
>> - /* Get Vbus regulator */
>> + /* Get Vbus regulators */
>>   phy_drd->vbus = devm_regulator_get(dev, "vbus");
>>   if (IS_ERR(phy_drd->vbus)) {
>>   ret = PTR_ERR(phy_drd->vbus);
>> @@ -655,6 +671,16 @@ static int exynos5_usbdrd_phy_probe(struct
>> platform_device *pdev)
>>   phy_drd->vbus = NULL;
>>   }
>>
>> + phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
>> + if (IS_ERR(phy_drd->vbus_boost)) {
>> + ret = PTR_ERR(phy_drd->vbus_boost);
>> + if (ret == -EPROBE_DEFER)
>> + return ret;
>> +
>> + dev_warn(dev, "Failed to get VBUS boost supply
>> regulator\n");
>> + phy_drd->vbus_boost = NULL;
>> + }
>> +
>>   dev_vdbg(dev, "Creating usbdrd_phy phy\n");
>>
>>   for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

2014-10-09 Thread Vivek Gautam
Ajay,


On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar  wrote:
> Hi,
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> These patches are based on 'for-next' branch of kgene's linux-samsung tree.
>>
>> Refactoring the exynos-dp-video phy to use pmu-system-controller handle
>> and access the register using mfd-syscon and regmap.
>> Simultaneously, removing the support for older dptx-phy, since it's obsolete
>> now and noone uses it.
>>
>> Vivek Gautam (3):
>>   phy: exynos-dp-video: Use syscon support to control pmu register
>>   drm/exynos: dp: Remove support for unused dptx-phy
>>   arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
>>
>>  .../devicetree/bindings/phy/samsung-phy.txt|7 +-
>>  arch/arm/boot/dts/exynos5250.dtsi  |2 +-
>>  arch/arm/boot/dts/exynos5420.dtsi  |4 +-
>>  drivers/gpu/drm/exynos/exynos_dp_core.c|   58 ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 -
>>  drivers/phy/phy-exynos-dp-video.c  |   76 
>> ++--
>>  6 files changed, 75 insertions(+), 74 deletions(-)
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> I have tested this patchset on exynos5800-peach-pi, and I can see DP
> display with the above patches.

we expect "Tested-by", if you have tested please give the same.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-07 Thread Vivek Gautam
On Tue, Oct 7, 2014 at 7:41 PM, Felipe Balbi  wrote:
> On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
>> Exynos7 also has a separate special gate clock going to the IP
>> apart from the usual AHB clock. So add support for the same.
>>
>> Signed-off-by: Vivek Gautam 
>
> I'll take this one once -rc1 is tagged. The others have no direct
> dependency on this so I'll leave them to Kishon.

Thanks Felipe !



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-07 Thread Vivek Gautam
Hi,


CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Wed, Oct 8, 2014 at 8:27 AM, Vivek Gautam  wrote:
> Hi,
>
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
>
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_on(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg |= dp->enable_mask;
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_off(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg &= ~(dp->enable_mask);
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> -   u32 phy_base;
>> int ret = 0;
>>
>> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> -   if (!dp_phy_node) {
>> -   dp->phy = devm_phy_get(dp->dev, "dp");
>> -   return PTR_ERR_OR_ZERO(dp->phy);
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
>> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> -   &dp->enable_mask)) {
>> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   dp->phy_addr = ioremap(phy_base, SZ_4);
>> -   if (!dp->phy_addr) {
>> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> -   ret = -ENOMEM;
>> -   goto err;
>> +   dp->phy = devm_phy_get(dp->dev, "dp");
>> +   if (IS_ERR(dp->phy)) {
>> +   ret = PTR_ERR(dp->phy);
>> +   if (ret == -ENOSYS || ret == -ENODEV) {
>> +   dp->phy = NULL;
>> +   } else if (ret == -EPROBE_DEFER) {
>> +   return ret;
>> +   } else {
>> +   dev_err(dp->dev, "no DP phy configured\n");
>> +   return ret;
>> +   }
>> }
>>
>> -err:
>> -   of_node_put(dp_phy_node);
>> -
>> return ret;
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk  *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> -   void __iomem*phy_addr;
>> -   unsigned intenable_mask;
>>
>> struct video_info   *video_info;
>> struct link_train   link_train;
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

2014-10-07 Thread Vivek Gautam
Hi,

CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  wrote:
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index f21b9aa..9b85a2b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
>
> dp_phy: video-phy@10040720 {
> compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040720 4>;
> +   samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index bfe056d..a677812 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
> };
>
> dp_phy: video-phy@10040728 {
> -   compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040728 4>;
> +   compatible = "samsung,exynos5420-dp-video-phy";
> +   samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

2014-10-07 Thread Vivek Gautam
Hi,


On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
> +++
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>  2 files changed, 13 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4f3c7eb..5ffc1b2 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
>
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_on(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg |= dp->enable_mask;
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_off(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg &= ~(dp->enable_mask);
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1210,39 +1196,21 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
>
>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>  {
> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> -   u32 phy_base;
> int ret = 0;
>
> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> -   if (!dp_phy_node) {
> -   dp->phy = devm_phy_get(dp->dev, "dp");
> -   return PTR_ERR_OR_ZERO(dp->phy);
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> -   &dp->enable_mask)) {
> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   dp->phy_addr = ioremap(phy_base, SZ_4);
> -   if (!dp->phy_addr) {
> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
> -   ret = -ENOMEM;
> -   goto err;
> +   dp->phy = devm_phy_get(dp->dev, "dp");
> +   if (IS_ERR(dp->phy)) {
> +   ret = PTR_ERR(dp->phy);
> +   if (ret == -ENOSYS || ret == -ENODEV) {
> +   dp->phy = NULL;
> +   } else if (ret == -EPROBE_DEFER) {
> +   return ret;
> +   } else {
> +   dev_err(dp->dev, "no DP phy configured\n");
> +   return ret;
> +   }
> }
>
> -err:
> -   of_node_put(dp_phy_node);
> -
> return ret;
>  }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
> struct clk  *clock;
> unsigned intirq;
> void __iomem*reg_base;
> -   void __iomem*phy_addr;
> -   unsigned intenable_mask;
>
> struct video_info   *video_info;
> struct link_train   link_train;
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/4] dwc3: exynos: Add support for SCLK present on Exynos7

2014-10-07 Thread Vivek Gautam
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.

Signed-off-by: Vivek Gautam 
---
 drivers/usb/dwc3/dwc3-exynos.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3951a65..7dc6a98 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device   *dev;
 
struct clk  *clk;
+   struct clk  *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
 };
@@ -139,10 +140,21 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+   /*
+* Exynos7 has a special gate clock going to this IP,
+* which in earlier SoCs was probably concealed.
+*/
+   exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
+   if (IS_ERR(exynos->sclk)) {
+   dev_info(dev, "no sclk specified\n");
+   exynos->sclk = NULL;
+   }
+
exynos->dev = dev;
exynos->clk = clk;
 
clk_prepare_enable(exynos->clk);
+   clk_prepare_enable(exynos->sclk);
 
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
@@ -185,6 +197,7 @@ err4:
 err3:
regulator_disable(exynos->vdd33);
 err2:
+   clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(clk);
return ret;
 }
@@ -197,6 +210,7 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
 
+   clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(exynos->clk);
 
regulator_disable(exynos->vdd33);
@@ -218,6 +232,7 @@ static int dwc3_exynos_suspend(struct device *dev)
 {
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
 
+   clk_disable(exynos->sclk);
clk_disable(exynos->clk);
 
regulator_disable(exynos->vdd33);
@@ -243,6 +258,7 @@ static int dwc3_exynos_resume(struct device *dev)
}
 
clk_enable(exynos->clk);
+   clk_enable(exynos->sclk);
 
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 3/4] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply

2014-10-07 Thread Vivek Gautam
Some Exynos SoCs have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/phy-exynos5-usbdrd.c |   30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 013ee84..57e8a0a 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+   struct regulator *vbus_boost;
 };
 
 static inline
@@ -455,11 +456,20 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
 
/* Enable VBUS supply */
+   if (phy_drd->vbus_boost) {
+   ret = regulator_enable(phy_drd->vbus_boost);
+   if (ret) {
+   dev_err(phy_drd->dev,
+   "Failed to enable VBUS boost supply\n");
+   goto fail_vbus;
+   }
+   }
+
if (phy_drd->vbus) {
ret = regulator_enable(phy_drd->vbus);
if (ret) {
dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
-   goto fail_vbus;
+   goto fail_vbus_boost;
}
}
 
@@ -468,6 +478,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
return 0;
 
+fail_vbus_boost:
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
+
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
clk_disable_unprepare(phy_drd->pipeclk);
@@ -489,6 +503,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd->vbus)
regulator_disable(phy_drd->vbus);
+   if (phy_drd->vbus_boost)
+   regulator_disable(phy_drd->vbus_boost);
 
clk_disable_unprepare(phy_drd->ref_clk);
clk_disable_unprepare(phy_drd->pipeclk);
@@ -644,7 +660,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
break;
}
 
-   /* Get Vbus regulator */
+   /* Get Vbus regulators */
phy_drd->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(phy_drd->vbus)) {
ret = PTR_ERR(phy_drd->vbus);
@@ -655,6 +671,16 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
phy_drd->vbus = NULL;
}
 
+   phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
+   if (IS_ERR(phy_drd->vbus_boost)) {
+   ret = PTR_ERR(phy_drd->vbus_boost);
+   if (ret == -EPROBE_DEFER)
+   return ret;
+
+   dev_warn(dev, "Failed to get VBUS boost supply regulator\n");
+   phy_drd->vbus_boost = NULL;
+   }
+
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
 
for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/4] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support

2014-10-07 Thread Vivek Gautam
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.

Signed-off-by: Vivek Gautam 
---
 .../devicetree/bindings/phy/samsung-phy.txt|4 
 drivers/phy/phy-exynos5-usbdrd.c   |   22 
 2 files changed, 26 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 15e0f2c..c2bc9dc 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -138,6 +138,10 @@ Required properties:
   PHY operations, associated by phy name. It is used to
   determine bit values for clock settings register.
   For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+   - optional clocks: Exynos7 SoC has now following additional
+  gate clocks available:
+  - phy_pipe: for PIPE3 phy
+  - phy_utmi: for UTMI+ phy
 - samsung,pmu-syscon: phandle for PMU system controller interface, used to
  control pmu registers for power isolation.
 - #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index f756aca..013ee84 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
  * @dev: pointer to device instance of this platform device
  * @reg_phy: usb phy controller register memory base
  * @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
  * @drv_data: pointer to SoC level driver data structure
  * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
  * instances each with its 'phy' and 'phy_cfg'.
@@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+   struct clk *pipeclk;
+   struct clk *utmiclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -446,6 +450,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
 
+   clk_prepare_enable(phy_drd->utmiclk);
+   clk_prepare_enable(phy_drd->pipeclk);
clk_prepare_enable(phy_drd->ref_clk);
 
/* Enable VBUS supply */
@@ -464,6 +470,8 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
 
 fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
 
return ret;
 }
@@ -483,6 +491,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd->vbus);
 
clk_disable_unprepare(phy_drd->ref_clk);
+   clk_disable_unprepare(phy_drd->pipeclk);
+   clk_disable_unprepare(phy_drd->utmiclk);
 
return 0;
 }
@@ -582,6 +592,18 @@ static int exynos5_usbdrd_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(phy_drd->clk);
}
 
+   phy_drd->pipeclk = devm_clk_get(dev, "phy_pipe");
+   if (IS_ERR(phy_drd->pipeclk)) {
+   dev_info(dev, "PIPE3 phy operational clock not specified\n");
+   phy_drd->pipeclk = NULL;
+   }
+
+   phy_drd->utmiclk = devm_clk_get(dev, "phy_utmi");
+   if (IS_ERR(phy_drd->utmiclk)) {
+   dev_info(dev, "UTMI phy operational clock not specified\n");
+   phy_drd->utmiclk = NULL;
+   }
+
phy_drd->ref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(phy_drd->ref_clk)) {
dev_err(dev, "Failed to get reference clock of usbdrd phy\n");
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/4] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7

2014-10-07 Thread Vivek Gautam
Adding required support for clocks and additional VBUS regulators
to enable USB 3.0 support on Exynos7 SoC.

This series depends for ACRH_EXYNOS7 support on following series:
[PATCH v5 0/8] arch: arm64: Enable support for Samsung Exynos7 SoC
http://www.spinics.net/lists/linux-samsung-soc/msg37047.html

The series is based on usb-next branch.

Changes since v1:
 -- Addressed review comments for unnecessary warning messages after
clk_get() fails for dwc3-exynos and phy-exynos5-usbdrd.
 -- Assigned "exynos->sclk" as well as "phy_drd->utmiclk" and
"phy_drd->pipeclk" to NULL in case of clk_get() failure to avoid
unnecessary check for clock.
 -- Modified dependency for symbol PHY_EXYNOS5_USBDRD to depend on
ARCH_EXYNOS which includes both Exynos5 as well as Exynos7.
 -- Dropped [PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
from v1 of this series, since its not required now.

Vivek Gautam (4):
  dwc3: exynos: Add support for SCLK present on Exynos7
  phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
  phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
  phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

 .../devicetree/bindings/phy/samsung-phy.txt|4 ++
 drivers/phy/Kconfig|2 +-
 drivers/phy/phy-exynos5-usbdrd.c   |   52 +++-
 drivers/usb/dwc3/dwc3-exynos.c |   16 ++
 4 files changed, 71 insertions(+), 3 deletions(-)

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 4/4] phy: exynos7-usbdrd: Update dependency for ARCH_EXYNOS

2014-10-07 Thread Vivek Gautam
This PHY controller is also present on Exynos7 platform
in arch-exynos family.
So PHY_EXYNOS5_USBDRD should now depend on ARCH_EXYNOS.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 2a436e6..1514e40 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -193,7 +193,7 @@ config PHY_EXYNOS5250_USB2
 
 config PHY_EXYNOS5_USBDRD
tristate "Exynos5 SoC series USB DRD PHY driver"
-   depends on ARCH_EXYNOS5 && OF
+   depends on ARCH_EXYNOS && OF
depends on HAS_IOMEM
depends on USB_DWC3_EXYNOS
select GENERIC_PHY
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs

2014-10-05 Thread Vivek Gautam
On enabling CONFIG_OF_SELFTEST which enables CONFIG_OF_DYNAMIC,
we found out that while getting PHYs for the controller we were
doing an extra of_node_put on the child node in our routines -
exynos_e/ohci_get_phy().
This child is however already put by of_get_next_available_child()
which does a of_node_put() on the "prev" node. So there's no point
in putting the same node again in our routine.

Reported-by: Daniel Drake 
Signed-off-by: Vivek Gautam 
---
 drivers/usb/host/ehci-exynos.c |1 -
 drivers/usb/host/ohci-exynos.c |1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci->phy[phy_number] = phy;
-   of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index d28b658..39f366b 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -63,7 +63,6 @@ static int exynos_ohci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
exynos_ohci->phy[phy_number] = phy;
-   of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1

2014-10-05 Thread Vivek Gautam
On Wed, Oct 1, 2014 at 8:42 PM, Daniel Drake  wrote:
> On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam  
> wrote:
>> One reason i doubt why it could be coming is because we are
>> specifically putting the
>> child after doing everything with it.
>>
>> When we are getting the child node using for_each_available_child_of_node(),
>> which calls for of_get_next_available_child(). So 
>> of_get_next_available_child()
>> does a of_node_put() on the "prev" node, in case we have siblings to the 
>> child.
>>
>> Can you see if the below change helps ?
>>
>> 
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index 7189f2e..1b726bf 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
>>
>> phy = devm_of_phy_get(dev, child, NULL);
>> exynos_ehci->phy[phy_number] = phy;
>> -   of_node_put(child);
>> if (IS_ERR(phy)) {
>> ret = PTR_ERR(phy);
>> if (ret == -EPROBE_DEFER) {
>> 
>>
>>
>> This is on top of usb-next.
>> If you are testing on rc6 only, then probably you will have to cherrypick two
>> patches each for ehci-exynos and ohci-exynos:
>> usb: host: ehci-exynos: Remove unnecessary usb-phy support
>> usb: host: ohci-exynos: Remove unnecessary usb-phy support
>
> I made the equivalent change to 3.17-rc7 (right now 3.17 is my main
> interest), i.e. removed all of_node_put calls from
> exynos_ehci_get_phy(). Same change is needed in exynos_ohci_get_phy().
> Now the warnings are gone.
> BTW, I think the warning only appeared when CONFIG_OF_SELFTEST=y
>
> I didn't check the implementation details like you did, but I looked
> at a few other users of for_each_available_child_of_node and it looks
> like indeed you do not need to call of_node_put() on the children in
> the normal case, or at least, nobody else does.

Yes, i saw the same; and the reason i mentioned above looks like the
issue with us.
I will post necessary patches for removing this extra of_node_put()
from ehci/ohci-exynos



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1

2014-09-30 Thread Vivek Gautam
Hi Daniel,


On Sat, Sep 27, 2014 at 5:54 AM, Daniel Drake  wrote:
> Hi,

it's always good to keep the relevant mailing list also in CC (linux-usb).
Also added Alan here.

>
> Booting 3.17-rc6 on ODROID-U2, I see this message:
>
> ERROR: Bad of_node_put() on /ehci@1258/port@1
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00376-g85cd8fd #1031
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0xc4)
> [] (dump_stack) from [] (kobject_cleanup+0x58/0x6c)
> [] (kobject_cleanup) from []
> (of_get_next_available_child+0x78/0x98)
> [] (of_get_next_available_child) from []
> (exynos_ehci_probe+0x254/0x424)
> [] (exynos_ehci_probe) from []
> (platform_drv_probe+0x2c/0x5c)
> [] (platform_drv_probe) from []
> (driver_probe_device+0xe8/0x234)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x68/0x8c)
>
> This repeats for all of the ehci and ohci ports.
>
> Haven't had time to dig deeper. Is this a known issue?

I don't think it's a known issue, atleast i don't see it on exynos5250-smdk5250.

One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.

When we are getting the child node using for_each_available_child_of_node(),
which calls for of_get_next_available_child(). So of_get_next_available_child()
does a of_node_put() on the "prev" node, in case we have siblings to the child.

Can you see if the below change helps ?


diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,

phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci->phy[phy_number] = phy;
-   of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {



This is on top of usb-next.
If you are testing on rc6 only, then probably you will have to cherrypick two
patches each for ehci-exynos and ohci-exynos:
usb: host: ehci-exynos: Remove unnecessary usb-phy support
usb: host: ohci-exynos: Remove unnecessary usb-phy support



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v5 RESEND 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-28 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Acked-by: Alan Stern 
---

Changes since v4:
 - returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..7189f2e 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return ret;
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+

Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-28 Thread Vivek Gautam
On Mon, Sep 29, 2014 at 7:21 AM, Greg KH  wrote:
> On Thu, Sep 25, 2014 at 10:50:22AM +0530, Vivek Gautam wrote:
>> Hi Greg,
>>
>>
>> On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam  
>> wrote:
>> > Now that we have completely moved from older USB-PHY drivers
>> > to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> > on Exynos series of SoCs, we can remove the support for the same
>> > in our host drivers too.
>> >
>> > We also defer the probe for our host in case we end up getting
>> > EPROBE_DEFER error when getting PHYs.
>> >
>> > Signed-off-by: Vivek Gautam 
>> > Acked-by: Jingoo Han 
>> > Acked-by: Alan Stern 
>> > ---
>>
>> Did this one got missed for usb-next ?
>> I can only see "usb: host: ohci-exynos: Remove unnecessary usb-phy support"
>> in the next branch.
>>
>> Ignore me if you have already taken care of this, and plan to queue it up.
>
> If it's not in my tree already, please resend as I don't have this in my
> queue anymore.

yea, i don't see it in usb-next.
I will resend it then.

>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-24 Thread Vivek Gautam
Hi Greg,


On Mon, Sep 22, 2014 at 11:15 AM, Vivek Gautam  wrote:
> Now that we have completely moved from older USB-PHY drivers
> to newer GENERIC-PHY drivers for PHYs available with USB controllers
> on Exynos series of SoCs, we can remove the support for the same
> in our host drivers too.
>
> We also defer the probe for our host in case we end up getting
> EPROBE_DEFER error when getting PHYs.
>
> Signed-off-by: Vivek Gautam 
> Acked-by: Jingoo Han 
> Acked-by: Alan Stern 
> ---

Did this one got missed for usb-next ?
I can only see "usb: host: ohci-exynos: Remove unnecessary usb-phy support"
in the next branch.

Ignore me if you have already taken care of this, and plan to queue it up.

>
> Changes since v4:
>  - returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that 
> only.
>
> Changes since v3:
>  - Addressed review comments by Alan:
>-- Skipped renaming 'phy_number' variable,
>-- resorted to just adding minimal change required for phy assignment.
>-- updated patch description to mention EPROBE_DEFER support.
>
>  drivers/usb/host/ehci-exynos.c |   74 
> +++-
>  1 file changed, 20 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 2eed9a4..7189f2e 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -21,11 +21,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
> -#include 
>
>  #include "ehci.h"
>
> @@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
>
>  struct exynos_ehci_hcd {
> struct clk *clk;
> -   struct usb_phy *phy;
> -   struct usb_otg *otg;
> -   struct phy *phy_g[PHY_NUMBER];
> +   struct phy *phy[PHY_NUMBER];
>  };
>
>  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
> *)(hcd_to_ehci(hcd)->priv)
> @@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
> struct device_node *child;
> struct phy *phy;
> int phy_number;
> -   int ret = 0;
> +   int ret;
>
> +   /* Get PHYs for the controller */
> for_each_available_child_of_node(dev->of_node, child) {
> ret = of_property_read_u32(child, "reg", &phy_number);
> if (ret) {
> @@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
> }
>
> phy = devm_of_phy_get(dev, child, NULL);
> +   exynos_ehci->phy[phy_number] = phy;
> of_node_put(child);
> -   if (IS_ERR(phy))
> -   /* Lets fallback to older USB-PHYs */
> -   goto usb_phy_old;
> -   exynos_ehci->phy_g[phy_number] = phy;
> -   /* Make the older PHYs unavailable */
> -   exynos_ehci->phy = ERR_PTR(-ENXIO);
> -   }
> -
> -   return 0;
> -
> -usb_phy_old:
> -   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> -   if (IS_ERR(exynos_ehci->phy)) {
> -   ret = PTR_ERR(exynos_ehci->phy);
> -   if (ret != -ENXIO && ret != -ENODEV) {
> -   dev_err(dev, "no usb2 phy configured\n");
> -   return ret;
> +   if (IS_ERR(phy)) {
> +   ret = PTR_ERR(phy);
> +   if (ret == -EPROBE_DEFER) {
> +   return ret;
> +   } else if (ret != -ENOSYS && ret != -ENODEV) {
> +   dev_err(dev,
> +   "Error retrieving usb2 phy: %d\n", 
> ret);
> +   return ret;
> +   }
> }
> -   dev_dbg(dev, "Failed to get usb2 phy\n");
> -   } else {
> -   exynos_ehci->otg = exynos_ehci->phy->otg;
> }
>
> -   return ret;
> +   return 0;
>  }
>
>  static int exynos_ehci_phy_enable(struct device *dev)
> @@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
> int i;
> int ret = 0;
>
> -   if (!IS_ERR(exynos_ehci->phy))
> -   return usb_phy_init(exynos_ehci->phy);
> -
> for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> -   if (!IS_ERR(exynos_ehci->phy_g[i]))
> -   ret = phy_power_on(exynos_ehci->phy_g[i]);
> +   if (!IS_ERR(exynos_ehci->phy[i]))
> +   

[PATCH v5 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

2014-09-21 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Acked-by: Alan Stern 
---

Changes since v4:
 - returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ohci-exynos.c |   81 ++--
 1 file changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..d28b658 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ohci.h"
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci->phy)) {
-   ret = PTR_ERR(exynos_ohci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return ret;
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ohci->otg = exynos_ohci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci->phy))
-   return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   ret = phy_power_on(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exyn

[PATCH v5 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-21 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Acked-by: Alan Stern 
---

Changes since v4:
 - returning 'ret' instead of PTR_ERR(phy), since ret is nothing but that only.

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..7189f2e 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return ret;
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+

Re: [PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-21 Thread Vivek Gautam
On Thu, Sep 18, 2014 at 8:20 PM, Alan Stern  wrote:
> On Thu, 18 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> We also defer the probe for our host in case we end up getting
>> EPROBE_DEFER error when getting PHYs.
>
> Better now.  But I didn't notice this the first time:
>
>> + if (IS_ERR(phy)) {
>> + ret = PTR_ERR(phy);
>> + if (ret == -EPROBE_DEFER) {
>> + return ret;
>> + } else if (ret != -ENOSYS && ret != -ENODEV) {
>> + dev_err(dev,
>> + "Error retrieving usb2 phy: %d\n", 
>> ret);
>> + return PTR_ERR(phy);
>
> It doesn't make any real difference, but wouldn't you prefer to say
> "return ret" here?

sure, will update this.

>
> With or without that change, for both these two patches:
>
> Acked-by: Alan Stern 
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ohci-exynos.c |   81 ++--
 1 file changed, 20 insertions(+), 61 deletions(-)

diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 7c48e3f..e8bf4bb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ohci.h"
 
@@ -38,9 +35,7 @@ static struct hc_driver __read_mostly exynos_ohci_hc_driver;
 
 struct exynos_ohci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 static int exynos_ohci_get_phy(struct device *dev,
@@ -49,15 +44,9 @@ static int exynos_ohci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
-   /*
-* Getting generic phy:
-* We are keeping both types of phys as a part of transiting OHCI
-* to generic phy framework, so as to maintain backward compatibilty
-* with old DTB too.
-* We fallback to older USB-PHYs when we fail to get generic PHYs.
-*/
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -73,31 +62,21 @@ static int exynos_ohci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ohci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ohci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ohci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ohci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci->phy)) {
-   ret = PTR_ERR(exynos_ohci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ohci->otg = exynos_ohci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ohci_phy_enable(struct device *dev)
@@ -107,16 +86,13 @@ static int exynos_ohci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ohci->phy))
-   return usb_phy_init(exynos_ohci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   ret = phy_power_on(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   ret = phy_power_on(exynos_ohci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ohci->phy_g[i]))
-   phy_power_off(exynos_ohci->phy_g[i]);
+   if (!IS_ERR(exynos_ohci->phy[i]))
+   phy_power_off(exynos_ohci->phy[i]);
 
return ret;
 }
@@ -127,14 +103,9 @@ static void exynos_ohci_phy_disable(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ohci->phy)) {
-   usb_phy_shutdown(exynos_ohci->phy);
-   return;
-  

[PATCH v4 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Now that we have completely moved from older USB-PHY drivers
to newer GENERIC-PHY drivers for PHYs available with USB controllers
on Exynos series of SoCs, we can remove the support for the same
in our host drivers too.

We also defer the probe for our host in case we end up getting
EPROBE_DEFER error when getting PHYs.

Signed-off-by: Vivek Gautam 
Acked-by: Jingoo Han 
Cc: Alan Stern 
---

Changes since v3:
 - Addressed review comments by Alan:
   -- Skipped renaming 'phy_number' variable,
   -- resorted to just adding minimal change required for phy assignment.
   -- updated patch description to mention EPROBE_DEFER support.

 drivers/usb/host/ehci-exynos.c |   74 +++-
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 2eed9a4..f293453 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -21,11 +21,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include "ehci.h"
 
@@ -47,9 +44,7 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
 struct exynos_ehci_hcd {
struct clk *clk;
-   struct usb_phy *phy;
-   struct usb_otg *otg;
-   struct phy *phy_g[PHY_NUMBER];
+   struct phy *phy[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
@@ -60,8 +55,9 @@ static int exynos_ehci_get_phy(struct device *dev,
struct device_node *child;
struct phy *phy;
int phy_number;
-   int ret = 0;
+   int ret;
 
+   /* Get PHYs for the controller */
for_each_available_child_of_node(dev->of_node, child) {
ret = of_property_read_u32(child, "reg", &phy_number);
if (ret) {
@@ -77,31 +73,21 @@ static int exynos_ehci_get_phy(struct device *dev,
}
 
phy = devm_of_phy_get(dev, child, NULL);
+   exynos_ehci->phy[phy_number] = phy;
of_node_put(child);
-   if (IS_ERR(phy))
-   /* Lets fallback to older USB-PHYs */
-   goto usb_phy_old;
-   exynos_ehci->phy_g[phy_number] = phy;
-   /* Make the older PHYs unavailable */
-   exynos_ehci->phy = ERR_PTR(-ENXIO);
-   }
-
-   return 0;
-
-usb_phy_old:
-   exynos_ehci->phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci->phy)) {
-   ret = PTR_ERR(exynos_ehci->phy);
-   if (ret != -ENXIO && ret != -ENODEV) {
-   dev_err(dev, "no usb2 phy configured\n");
-   return ret;
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER) {
+   return ret;
+   } else if (ret != -ENOSYS && ret != -ENODEV) {
+   dev_err(dev,
+   "Error retrieving usb2 phy: %d\n", ret);
+   return PTR_ERR(phy);
+   }
}
-   dev_dbg(dev, "Failed to get usb2 phy\n");
-   } else {
-   exynos_ehci->otg = exynos_ehci->phy->otg;
}
 
-   return ret;
+   return 0;
 }
 
 static int exynos_ehci_phy_enable(struct device *dev)
@@ -111,16 +97,13 @@ static int exynos_ehci_phy_enable(struct device *dev)
int i;
int ret = 0;
 
-   if (!IS_ERR(exynos_ehci->phy))
-   return usb_phy_init(exynos_ehci->phy);
-
for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   ret = phy_power_on(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   ret = phy_power_on(exynos_ehci->phy[i]);
if (ret)
for (i--; i >= 0; i--)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_ehci->phy[i]);
 
return ret;
 }
@@ -131,14 +114,9 @@ static void exynos_ehci_phy_disable(struct device *dev)
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
int i;
 
-   if (!IS_ERR(exynos_ehci->phy)) {
-   usb_phy_shutdown(exynos_ehci->phy);
-   return;
-   }
-
for (i = 0; i < PHY_NUMBER; i++)
-   if (!IS_ERR(exynos_ehci->phy_g[i]))
-   phy_power_off(exynos_ehci->phy_g[i]);
+   if (!IS_ERR(exynos_ehci->phy[i]))
+   phy_power_off(exynos_e

Re: [PATCH v3 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Vivek Gautam
Hi Alan,


On Wed, Sep 17, 2014 at 8:27 PM, Alan Stern  wrote:
> On Wed, 17 Sep 2014, Vivek Gautam wrote:
>
>> Now that we have completely moved from older USB-PHY drivers
>> to newer GENERIC-PHY drivers for PHYs available with USB controllers
>> on Exynos series of SoCs, we can remove the support for the same
>> in our host drivers too.
>>
>> Signed-off-by: Vivek Gautam 
>
> I don't see why you made your changes in this awkward way.  For
> instance...
>
>> @@ -59,49 +54,39 @@ static int exynos_ehci_get_phy(struct device *dev,
>>  {
>>   struct device_node *child;
>>   struct phy *phy;
>> - int phy_number;
>> - int ret = 0;
>> + int phy_num;
>
> Why rename this variable?  Wasn't the original name good enough?

fair enough, don't need to rename the variable.

>
>> + int ret;
>>
>>   for_each_available_child_of_node(dev->of_node, child) {
>> - ret = of_property_read_u32(child, "reg", &phy_number);
>> + ret = of_property_read_u32(child, "reg", &phy_num);
>>   if (ret) {
>>   dev_err(dev, "Failed to parse device tree\n");
>>   of_node_put(child);
>>   return ret;
>>   }
>>
>> - if (phy_number >= PHY_NUMBER) {
>> + if (phy_num >= PHY_NUMBER) {
>>   dev_err(dev, "Invalid number of PHYs\n");
>>   of_node_put(child);
>>   return -EINVAL;
>>   }
>>
>> - phy = devm_of_phy_get(dev, child, NULL);
>> + exynos_ehci->phy[phy_num] = devm_of_phy_get(dev, child, NULL);
>> + phy = exynos_ehci->phy[phy_num];
>
> Why make two changes, resulting in more code, when you could have made
> just one change?
>
> phy = devm_of_phy_get(dev, child, NULL);
> +   exynos_ehci->phy[phy_num] = phy;

Right. i don't know what state of mind i was in while making these changes.
i should have kept the changes to minimal.

>
> Also, the patch description should mention that you are adding support
> for EPROBE_DEFER.

Sure, will add that description.




-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   3   4   5   6   7   8   >