Re: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

2015-12-25 Thread Jingoo Han
On Thursday, December 24, 2015 10:23 AM, Yakir Yang wrote:
> 
> Hi Jingoo,
> 
> Okay, fine, I would drop this patch, until I found the the root cause.

OK, I see.

Best regards,
Jingoo Han

> 
> - Yakir
> 
> On 12/23/2015 11:10 PM, Jingoo Han wrote:
> > On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
> >> On Rockchip platform, sometimes driver would failed at reading EDID
> >> message, and it's caused by the AUX reply flag wouldn't received under
> >> the 100*10us wait time.
> > The problem is specific for Rockchip platform.
> > Also, 1 ms is long time.
> > The best way is that your hardware engineers find the root cause.
> > I cannot understand why your engineers cannot find the root cause. :-(
> >
> >> But after expand the wait time a little, the AUX reply flag would be
> >> set, so maybe the wait time is a little critical. Besides the analogix
> >> dp book haven't reminded the standard wait for looking AUX reply flag,
> >> so I thought it's okay to expand the wait time.
> >>
> >> And the external wait time won't hurt Exynos DP too much, cause they
> >> wouldn't meet this problem, then driver would received the reply command
> >> very soon, so no more additional wait time would bring to Exynos platform.
> > Then, when loop time happens on Exynos platform, it will take long time
> > to return error.
> >
> >> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> >> ---
> >> Changes in v12:
> >> - Using another way to expand the AUX reply wait time (Jingoo)
> >>
> >> Changes in v11: None
> >> Changes in v10: None
> >> Changes in v9: None
> >> Changes in v8: None
> >> Changes in v7: None
> >> Changes in v6: None
> >> Changes in v5: None
> >> Changes in v4: None
> >> Changes in v3: None
> >> Changes in v2: None
> >>
> >>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
> >>   1 file changed, 4 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> index cba3ffd..8687eea 100644
> >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >> @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>   {
> >>int reg;
> >>int retval = 0;
> >> -  int timeout_loop = 0;
> >> +  unsigned long timeout;
> >>
> >>/* Enable AUX CH operation */
> >>reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >> @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
> >> analogix_dp_device *dp)
> >>writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> >>
> >>/* Is AUX CH command reply received? */
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> >> -  while (!(reg & RPLY_RECEIV)) {
> >> -  timeout_loop++;
> >> -  if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> >> +  timeout = jiffies + msecs_to_jiffies(5);
> >> +  while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
> >> +  if (time_after(jiffies, timeout)) {
> >>dev_err(dp->dev, "AUX CH command reply failed!\n");
> >>return -ETIMEDOUT;
> >>}
> >> -  reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> > Sorry, I don't like your patch.
> >
> > The problem happens because of Rockchip platform.
> > So, you need to add workaround for only Rockchip platform.
> >
> > Just add new DT property and new variable for the value for wait time.
> > When, the probe is called, new wait time value is read from Rockchip DT 
> > file.
> > Then, the new wait time value can be written to the new variable.
> >
> >  new DT property: wait-time-aux
> >  new variable: wait_time_aux
> >
> >
> > If ( ) // New DT
> >  wait_time_aux = New DT;
> > else
> >  wait_time_aux = 10;
> >
> >
> >>usleep_range(10, 11);
> > If there is NO  new wait time value from DT file, the default value '10' is
> > used for sleep.
> >
> > But, if there is new wait time value from DT file, new wait time value
> > can be used for sleep.
> >
> >   usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);
> >
> > What I want to say is that there should be NO effect on Exynos platform,
> > because of the hardware bug of Rockchip platform.
> >
> > Best regards,
> > Jingoo Han
> >
> >>}
> >>
> >> --
> >> 1.9.1
> >
> >
> >
> >


--
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 v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

2015-12-23 Thread Jingoo Han
On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
> 
> On Rockchip platform, sometimes driver would failed at reading EDID
> message, and it's caused by the AUX reply flag wouldn't received under
> the 100*10us wait time.

The problem is specific for Rockchip platform.
Also, 1 ms is long time.
The best way is that your hardware engineers find the root cause.
I cannot understand why your engineers cannot find the root cause. :-(

> 
> But after expand the wait time a little, the AUX reply flag would be
> set, so maybe the wait time is a little critical. Besides the analogix
> dp book haven't reminded the standard wait for looking AUX reply flag,
> so I thought it's okay to expand the wait time.
> 
> And the external wait time won't hurt Exynos DP too much, cause they
> wouldn't meet this problem, then driver would received the reply command
> very soon, so no more additional wait time would bring to Exynos platform.

Then, when loop time happens on Exynos platform, it will take long time
to return error.

> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> ---
> Changes in v12:
> - Using another way to expand the AUX reply wait time (Jingoo)
> 
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index cba3ffd..8687eea 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
> analogix_dp_device *dp)
>  {
>   int reg;
>   int retval = 0;
> - int timeout_loop = 0;
> + unsigned long timeout;
> 
>   /* Enable AUX CH operation */
>   reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
> analogix_dp_device *dp)
>   writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> 
>   /* Is AUX CH command reply received? */
> - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> - while (!(reg & RPLY_RECEIV)) {
> - timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + timeout = jiffies + msecs_to_jiffies(5);
> + while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
> + if (time_after(jiffies, timeout)) {
>   dev_err(dp->dev, "AUX CH command reply failed!\n");
>   return -ETIMEDOUT;
>   }
> - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);

Sorry, I don't like your patch.

The problem happens because of Rockchip platform.
So, you need to add workaround for only Rockchip platform.

Just add new DT property and new variable for the value for wait time.
When, the probe is called, new wait time value is read from Rockchip DT file.
Then, the new wait time value can be written to the new variable.

new DT property: wait-time-aux
new variable: wait_time_aux


If ( ) // New DT 
wait_time_aux = New DT;
else 
wait_time_aux = 10;


>   usleep_range(10, 11);

If there is NO  new wait time value from DT file, the default value '10' is
used for sleep.

But, if there is new wait time value from DT file, new wait time value
can be used for sleep.

 usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);

What I want to say is that there should be NO effect on Exynos platform,
because of the hardware bug of Rockchip platform.

Best regards,
Jingoo Han

>   }
> 
> --
> 1.9.1


--
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 v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply

2015-12-23 Thread Jingoo Han
On Wednesday, December 23, 2015 3:01 PM, Yakir Yang wrote:
> 
> Hi Jingoo,
> 
> On 12/23/2015 12:24 PM, Yakir Yang wrote:
> > Hi Jingoo,
> >
> > On 12/22/2015 08:26 PM, Jingoo Han wrote:
> >> On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
> >>> After test on rockchiop platform, i found sometims driver would failed
> >>> at reading EDID message. After debugging more, i found that it's okay
> >>> to read_a byte from i2c, but it would failed at AUX transcation if we
> >>> try to ready multi-bytes from i2c.
> >>>
> >>> Driver just can't received the AUX CH reply command, even no AUX error
> >>> code. I may guess that the AUX wait time is not enough, so I try to
> >>> expand the AUX wait time, and i do see this could fix the EDID read
> >>> failed at rockchip platform.
> >>>
> >>> And I thought that expand the wait time won't hurt Exynos platform too
> >>> much, cause Exynos didn't have this problem, then driver would received
> >>> the reply command very soon, so no more additional wait time would
> >>> bring
> >>> to Exynos platform.
> >>>
> >>> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> >>> ---
> >>> Changes in v11: None
> >>> Changes in v10: None
> >>> Changes in v9: None
> >>> Changes in v8: None
> >>> Changes in v7: None
> >>> Changes in v6: None
> >>> Changes in v5: None
> >>> Changes in v4: None
> >>> Changes in v3: None
> >>> Changes in v2: None
> >>>
> >>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> index c7e2959..dc376bd 100644
> >>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> @@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
> >>> analogix_dp_device *dp)
> >>>   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> >>>   while (!(reg & RPLY_RECEIV)) {
> >>>   timeout_loop++;
> >>> -if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> >>> +if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
> >> No, I hate this coding.
> >> analogix_dp_reg.c is the common code that can be shared by various SoCs.
> >> Please, find another way.
> >
> > Okay, I have double checked that i do have this problem in my side.
> > Hmmm.
> > I thought it's okay for you if I expand the "DP_TIMEOUT_LOOP_COUNT"
> > directly,
> > it won't hurt Exynos platform too much, cause Exynos didn't have this
> > problem,
> > then driver would received,the reply command very soon, so no more
> > additional
> > wait time would bring to Exynos platform.
> >
> 
> Oh, sorry, little mistaken, I mean, is it okay for you to expand the
> "DP_TIMEOUT_LOOP_COUNT" directly ?

NO.

Don't change DP_TIMEOUT_LOOP_COUNT.
Just, change wait time by adding new DT property.

> 
> - Yakir
> 
> 
> > And actually the datasheet haven't described the spec of aux reply
> > delay time.

Right.
However, the problem is specific for Rockchip platform.
It is the hardware bug of Rockchip platform.
Your delay time is too long to apply to other SoCs platform.

Best regards,
Jingoo Han

> >
> > Thanks,
> > - Yakir
> >
> >> Best regards,
> >> Jingoo Han
> >>
> >>
> >>>   dev_err(dp->dev, "AUX CH command reply failed!\n");
> >>>   return -ETIMEDOUT;
> >>>   }
> >>> --
> >>> 1.9.1
> >>
> >>
> >>
> >>
> >
> >
> >
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> >
> >
> >


--
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 v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

2015-12-22 Thread Jingoo Han
On Wednesday, December 16, 2015 12:35 PM, Yakir Yang wrote:
> 
> After exynos_dp have been split the common IP code into analogix_dp driver,
> the analogix_dp driver have deprecated some Samsung platform properties which
> could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
> for Exynos DTS file for dp-controller.
> 
> Beside the backward compatibility is fully preserved, so there are no
> bisectability break that make this change in a separate patch.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Reviewed-by: Jingoo Han < jingooh...@gmail.com >

Best regards,
Jingoo Han

> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
> - Fix Peach Pit hpd property name error:
> -   hpd-gpio = < 6 0>;
> +   hpd-gpios = < 6 0>;
> 
> Changes in v5:
> - Correct the misspell in commit message. (Krzysztof)
> 
> Changes in v4:
> - Separate all DTS changes to a separate patch. (Krzysztof)
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/boot/dts/exynos5250-arndale.dts  | 2 --
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
>  arch/arm/boot/dts/exynos5250-spring.dts   | 4 +---
>  arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
>  arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
>  arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
>  7 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index c000532..b1790cf 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -124,8 +124,6 @@
>   {
>   status = "okay";
>   samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 0f5dcd4..f30c2db 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -80,8 +80,6 @@
> 
>   {
>   samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-
> common.dtsi
> index 5cb33ba..b96624b 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -236,12 +236,10 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd>;
>   samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <2>;
> - samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
> 
>   ports {
>   port@0 {
> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
> b/arch/arm/boot/dts/exynos5250-spring.dts
> index c1edd6d..91881d7 100644
> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> @@ -74,12 +74,10 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
>   samsung,color-depth = <1>;
>   samsung,link-rate = <0x0a>;
>   samsung,lane-count = <1>;
> - samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
>  };
> 
>   {
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 35cfb07..2f37c87 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -148,12 +148,10 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_gpio>;
>   samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-c

Re: [PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY

2015-12-22 Thread Jingoo Han
On Wednesday, December 16, 2015 12:41 PM, Yakir Yang wrote:
> 
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Reviewed-by: Heiko Stuebner <he...@sntech.de>
> ---
> Changes in v11: None
> Changes in v10:
> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
> BIT(4) -> BIT(20)
> 
> Changes in v9:
> - Removed the unused the variable "res" in probe function. (Heiko)
> - Removed the unused head file.
> 
> Changes in v8:
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
> 
> Changes in v7:
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
> 
> Changes in v6: None
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>   the exist "grf" syscon already. And rename the example DT node from
>   "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>   struct" to "static const struct". And correct the input paramters of
>   devm_phy_create() interfaces. (Heiko)
> 
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>   function, move those code to probe() method. And remove driver .owner
>   number. (Kishon)
> 
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>   power control. (Heiko)
> 
> Changes in v2: None
> 
>  drivers/phy/Kconfig   |   7 ++
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-rockchip-dp.c | 151 
> ++
>  3 files changed, 159 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859d..7355819 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
> 
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support the Rockchip Display Port PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a..b1700cd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..3cb3bf8
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang <ykk@@rock-chips.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please order these headers alphabetically.
It will enhance the readability.

Best regards,
Jingoo Han

> +
> +#define GRF_SOC_CON12   0x0274
> +
> +#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
> +#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
> +
> +#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + str

Re: [PATCH v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

2015-12-22 Thread Jingoo Han
On Wednesday, December 16, 2015 12:28 PM, Yakir Yang wrote:
> 
> link_rate and lane_count already configured in analogix_dp_set_link_train(),
> so we don't need to config those repeatly after training finished, just
> remove them out.
> 
> Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
> would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Update commit message more readable. (Jingoo)
> - Adjust the order from 05 to 04
> 
> Changes in v3:
> - The link_rate and lane_count shouldn't config to the DT property value
>   directly, but we can take those as hardware limite. For example, RK3288
>   only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
>   like "link-rate = 0x0a" "lane-count = 4". (Thierry)
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4a05c2b..6f899cd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
> analogix_dp_device *dp,
>   /*
>* For DP rev.1.1, Maximum link rate of Main Link lanes
>* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
> +  * For DP rev.1.2, Maximum link rate of Main Link lanes
> +  * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
>*/
>   analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
>   *bandwidth = data;
> @@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
> analogix_dp_device *dp,
>   analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
> 
>   if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
> - (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
> + (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
> + (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
>   dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
>   dp->link_train.link_rate);
>   dp->link_train.link_rate = LINK_RATE_1_62GBPS;
> @@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
> *dp)
>   analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
>   analogix_dp_enable_enhanced_mode(dp, 1);
> 
> - analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
> - analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
> -
>   analogix_dp_init_video(dp);
>   ret = analogix_dp_config_video(dp);
>   if (ret)
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 8e84208..57aa4b0d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -21,8 +21,9 @@
>  #define MAX_EQ_LOOP  5
> 
>  enum link_rate_type {
> - LINK_RATE_1_62GBPS = 0x06,
> - LINK_RATE_2_70GBPS = 0x0a
> + LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
> + LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
> + LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,

Then, how about removing 'enum link_rate_type'?
If DP_LINK_BW_* are used, LINK_RATE_* are not necessary.

Best regards,
Jingoo Han


>  };
> 
>  enum link_lane_count_type {
> --
> 1.9.1


--
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 v11 02/19] drm: bridge: analogix/dp: fix some obvious code style

2015-12-22 Thread Jingoo Han
On Wednesday, December 16, 2015 12:26 PM, Yakir Yang wrote:
> 
> Fix some obvious alignment problems, like alignment and line
> over 80 characters problems, make this easy to be maintained
> later.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Acked-by: Jingoo Han <jingooh...@gmail.com>

Best regards,
Jingoo Han

> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
>   DP_TEST_EDID_CHECKSUM_WRITE);
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Improved commit message more readable, and avoid using some
>   uncommon style like bellow: (Joe Preches)
> -  retval = exynos_dp_read_bytes_from_i2c(...
> ...);
> +  retval =
> +  exynos_dp_read_bytes_from_i2c(..);
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 
> ++---
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
>  3 files changed, 163 insertions(+), 162 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index fb8bda8..4a05c2b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
> *dp)
> 
>   while (analogix_dp_get_plug_in_status(dp) != 0) {
>   timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
>   dev_err(dp->dev, "failed to get hpd plug status\n");
>   return -ETIMEDOUT;
>   }
> @@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
> *dp)
> 
>   /* Read Extension Flag, Number of 128-byte EDID extension blocks */
>   retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_EXTENSION_FLAG,
> - _block);
> + EDID_EXTENSION_FLAG,
> + _block);
>   if (retval)
>   return retval;
> 
> @@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct 
> analogix_dp_device *dp)
>   dev_dbg(dp->dev, "EDID data includes a single extension!\n");
> 
>   /* Read EDID data */
> - retval = analogix_dp_read_bytes_from_i2c(dp, 
> I2C_EDID_DEVICE_ADDR,
> + retval = analogix_dp_read_bytes_from_i2c(dp,
> + I2C_EDID_DEVICE_ADDR,
>   EDID_HEADER_PATTERN,
>   EDID_BLOCK_LENGTH,
>   [EDID_HEADER_PATTERN]);
> @@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct 
> analogix_dp_device *dp)
>   }
> 
>   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> - _vector);
> + _vector);
>   if (test_vector & DP_TEST_LINK_EDID_READ) {
>   analogix_dp_write_byte_to_dpcd(dp,
>   DP_TEST_EDID_CHECKSUM,
> @@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct 
> analogix_dp_device *dp)
> 
>   /* Read EDID data */
>   retval = analogix_dp_read_bytes_from_i2c(dp,
> - I2C_EDID_DEVICE_ADDR,
> - EDID_HEADER_PATTERN,
> - EDID_BLOCK_LENGTH,
> - [EDID_HEADER_PATTERN]);
> + I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
> + EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
>   if (retval != 0) {
> 

Re: [PATCH v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply

2015-12-22 Thread Jingoo Han
On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
> 
> After test on rockchiop platform, i found sometims driver would failed
> at reading EDID message. After debugging more, i found that it's okay
> to read_a byte from i2c, but it would failed at AUX transcation if we
> try to ready multi-bytes from i2c.
> 
> Driver just can't received the AUX CH reply command, even no AUX error
> code. I may guess that the AUX wait time is not enough, so I try to
> expand the AUX wait time, and i do see this could fix the EDID read
> failed at rockchip platform.
> 
> And I thought that expand the wait time won't hurt Exynos platform too
> much, cause Exynos didn't have this problem, then driver would received
> the reply command very soon, so no more additional wait time would bring
> to Exynos platform.
> 
> Signed-off-by: Yakir Yang <y...@rock-chips.com>
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index c7e2959..dc376bd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct 
> analogix_dp_device *dp)
>   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
>   while (!(reg & RPLY_RECEIV)) {
>   timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {

No, I hate this coding.
analogix_dp_reg.c is the common code that can be shared by various SoCs.
Please, find another way.

Best regards,
Jingoo Han


>   dev_err(dp->dev, "AUX CH command reply failed!\n");
>   return -ETIMEDOUT;
>   }
> --
> 1.9.1


--
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 v3 06/14] Documentation: drm/bridge: add document for analogix_dp

2015-08-24 Thread Jingoo Han
On 2015. 8. 24., at AM 9:43, Krzysztof Kozlowski k.kozlow...@samsung.com 
wrote:
 
 2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com:
 On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com wrote:
 Analogix dp driver is split from exynos dp driver, so we just
 make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
 
 Beside update some exynos dtsi file with the latest change
 according to the devicetree binding documents.
 
 You can't just change the exynos bindings and break compatibility. Is
 there some agreement with exynos folks to do this?
 
 No, there is no agreement. This wasn't even sent to Exynos maintainers.
 Additionally the patchset did not look interesting to me because of
 misleading subject - Documentation instead of ARM: dts:.
 
 Yakir, please:
 1. Provide backward compatibility. Mark old properties as deprecated
 but still support them.
 2. Separate all DTS changes to a separate patch, unless bisectability
 would be hurt. Anyway you should prepare it in a such way that
 separation would be possible without breaking bisectability.
 3. Use proper subject for the patch changing DTS. This is not
 documentation change!
 4. Please use script get_maintainers to obtain list of valid
 maintainers and CC-them with at least cover letter and patches
 requiring their attention.

To Yakir Yang,

Please be careful when you CC people.

I don't find the reason why you CC'ed the following people. Of course, they
look to be one of the talented developers. However, they look to be
unrelated to your patchset.

 Takashi Iwai
 Vincent Palatin
 Fabio Estevam
 Philipp Zabel


Also, please add Exynos Architecture maintainers to CC list. I don't understand
why you removed them from CC list.
 Kukjin Kim
 Krzysztof Kozlowski

Without their Ack, you will not change the codes of ARM Exynos Architecture.

Best regards,
Jingoo Han

 
 Best regards,
 Krzysztof
 
 
 
 
 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
 Changes in v3:
 - Take Heiko suggest, add devicetree binding documents.
 - Take Thierry Reding suggest, remove sync pol  colorimetry properies
  from the new analogix dp driver devicetree binding.
 - Update the exist exynos dtsi file with the latest DP DT properies.
 
 Changes in v2: None
 
 .../devicetree/bindings/drm/bridge/analogix_dp.txt | 70 
 ++
 .../devicetree/bindings/video/exynos_dp.txt| 50 ++--
 arch/arm/boot/dts/exynos5250-arndale.dts   | 10 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 10 ++--
 arch/arm/boot/dts/exynos5250-snow.dts  | 12 ++--
 arch/arm/boot/dts/exynos5250-spring.dts| 12 ++--
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 10 ++--
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
 9 files changed, 119 insertions(+), 79 deletions(-)
 create mode 100644 
 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 
 diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
 b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 new file mode 100644
 index 000..6127018
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 @@ -0,0 +1,70 @@
 +Analogix Display Port bridge bindings
 +
 +Required properties for dp-controller:
 +   -compatible:
 +   platform specific such as:
 +* samsung,exynos5-dp
 +* rockchip,rk3288-dp
 +   -reg:
 +   physical base address of the controller and length
 +   of memory mapped region.
 +   -interrupts:
 +   interrupt combiner values.
 +   -clocks:
 +   from common clock binding: handle to dp clock.
 +   -clock-names:
 +   from common clock binding: Shall be dp.
 +   -interrupt-parent:
 +   phandle to Interrupt combiner node.
 +   -phys:
 +   from general PHY binding: the phandle for the PHY device.
 +   -phy-names:
 +   from general PHY binding: Should be dp.
 +   -analogix,color-space:
 +   input video data format.
 +   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 
 2
 +   -analogix,color-depth:
 +   number of bits per colour component.
 +   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
 
 This seems pretty generic. Just use 6, 8, 10, or 12 for values. And
 drop the vendor prefix.
 
 +   -analogix,link-rate:
 +   max link rate supported by the eDP controller.
 +   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A,
 +   LINK_RATE_5_40GBPS = 0x14
 
 Same here. I'd rather see something like link-rate-mbps and use the
 actual rate.
 
 +   -analogix,lane-count:
 +   max number of lanes supported by the eDP contoller.
 +   LANE_COUNT1 = 1, LANE_COUNT2 = 2

Re: [PATCH v3 0/14] Add Analogix Core Display Port Driver

2015-08-21 Thread Jingoo Han
On 2015. 8. 19., at PM 11:48, Yakir Yang y...@rock-chips.com wrote:
 
 

.

 .../bindings/video/analogix_dp-rockchip.txt|   83 ++
 .../devicetree/bindings/video/exynos_dp.txt|   51 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |   10 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   10 +-
 arch/arm/boot/dts/exynos5250-snow.dts  |   12 +-
 arch/arm/boot/dts/exynos5250-spring.dts|   12 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   12 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   10 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   12 +-
 drivers/gpu/drm/bridge/Kconfig |5 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix_dp_core.c  | 1382 +++
 drivers/gpu/drm/bridge/analogix_dp_core.h  |  286 
 drivers/gpu/drm/bridge/analogix_dp_reg.c   | 1294 ++
 .../exynos_dp_reg.h = bridge/analogix_dp_reg.h}   |  270 ++--
 drivers/gpu/drm/exynos/Kconfig |5 +-
 drivers/gpu/drm/exynos/Makefile|2 +-
 drivers/gpu/drm/exynos/analogix_dp-exynos.c|  347 +

Would you change this file name to exynos_dp.c?

Best regards,
Jingoo Han

 drivers/gpu/drm/exynos/exynos_dp_core.c| 1416 
 drivers/gpu/drm/exynos/exynos_dp_core.h|  282 
 drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 -
 drivers/gpu/drm/rockchip/Kconfig   |9 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  390 ++
 drivers/phy/Kconfig|7 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-rockchip-dp.c  |  185 +++
 include/drm/bridge/analogix_dp.h   |   40 +
 30 files changed, 4325 insertions(+), 3172 deletions(-)
 create mode 100644 
 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
 create mode 100644 
 Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.c
 create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix_dp_reg.c
 rename drivers/gpu/drm/{exynos/exynos_dp_reg.h = bridge/analogix_dp_reg.h} 
 (62%)
 create mode 100644 drivers/gpu/drm/exynos/analogix_dp-exynos.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
 create mode 100644 drivers/phy/phy-rockchip-dp.c
 create mode 100644 include/drm/bridge/analogix_dp.h
 
 -- 
 1.9.1
 
 
--
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 v3 13/14] drm: bridge/analogix_dp: move hpd detect to connector detect function

2015-08-20 Thread Jingoo Han
On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote:
 


What is the reason to make this patch?

Please make commit message including the reason.

Best regards,
Jingoo Han

 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
 Changes in v3:
 - move dp hpd detect to connector detect function.
 
 Changes in v2: None
 
 drivers/gpu/drm/bridge/analogix_dp_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
 b/drivers/gpu/drm/bridge/analogix_dp_core.c
 index 75dd44a..052b9b3 100644
 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
 +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
 @@ -915,12 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
 *dp)
DRM_ERROR(failed to disable the panel\n);
}
 
 -ret = analogix_dp_detect_hpd(dp);
 -if (ret) {
 -/* Cable has been disconnected, we're done */
 -return;
 -}
 -
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp-dev, unable to handle edid\n);
 @@ -953,6 +947,12 @@ static void analogix_dp_commit(struct analogix_dp_device 
 *dp)
 static enum drm_connector_status analogix_dp_detect(
struct drm_connector *connector, bool force)
 {
 +struct analogix_dp_device *dp = connector_to_dp(connector);
 +
 +if (analogix_dp_detect_hpd(dp))
 +/* Cable has been disconnected, we're done */
 +return connector_status_disconnected;
 +
return connector_status_connected;
 }
 
 -- 
 1.9.1
 
 
--
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 v3 0/14] Add Analogix Core Display Port Driver

2015-08-20 Thread Jingoo Han
On 2015. 8. 20., at PM 3:23, Yakir Yang y...@rock-chips.com wrote:
 
 Hi Jingoo  Archit,
 
 
 On 08/20/2015 12:54 AM, Jingoo Han wrote:
 On 2015. 8. 20., at PM 1:29, Archit Taneja arch...@codeaurora.org wrote:
 Hi,
 
 On 08/19/2015 08:18 PM, Yakir Yang wrote:
 
 Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
 share the same IP, so a lot of parts can be re-used. I split the common
 code into bridge directory, then rk3288 and exynos only need to keep
 some platform code. Cause I can't find the exact IP name of exynos dp
 controller, so I decide to name dp core driver with analogix which I
 find in rk3288 eDP TRM ;)
 
 Beyond that, there are three light registers setting differents bewteen
 exynos and rk3288.
 1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
 2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
 
 I have verified this series on two kinds of rockchip platform board, one
 is rk3288 sdk board which connect with a 2K display port monitor, the other
 is google jerry chromebook which connect with a eDP screen 
 cnm,n116bgeea2,
 both of them works rightlly.
 
 I haven't verified the dp function on samsung platform, cause I haven't got
 exynos boards. I can only ensure that there are no build error on samsung
 platform, wish some samsung guys help to test. ;)
 
 Thanks,
 - Yakir
 
 Changes in v3:
 - Take Thierry Reding suggest, move exynos's video_timing code
   to analogix_dp-exynos platform driver, add get_modes method
   to struct analogix_dp_plat_data.
 - Take Heiko suggest, rename some samsung* dts propery to analogix*.
 - Take Thierry Reding suggest, dynamic parse video timing info from
   struct drm_display_mode and struct drm_display_info.
 - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
   the DT property value directly, but we can take those as hardware limite.
   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
   so DT property would like link-rate = 0x0a lane-count = 4.
 - Take Heiko suggest, add devicetree binding documents.
 - Take Thierry Reding suggest, remove sync pol  colorimetry properies
   from the new analogix dp driver devicetree binding.
 - Update the exist exynos dtsi file with the latest DP DT properies.
 - Take Thierry Reding and Heiko suggest, leave sclk_edp_24m to rockchip
   dp phy driver which name to 24m, and leave sclk_edp to analogix dp
   core driver which name to dp, and leave pclk_edp to rockchip dp 
 platform
   driver which name to pclk.
 - Take Heiko suggest, add devicetree binding document.
 - Take Heiko suggest, remove rockchip,panel DT property, take use of 
 remote
   point to get panel node.
 - Add the new function point analogix_dp_platdata.get_modes init.
 - Take Heiko suggest, add rockchip dp phy driver,
   collect the phy clocks and power control.
 - Add analogix,need-force-hpd to indicate whether driver need foce
   hpd when hpd detect failed.
 - move dp hpd detect to connector detect function.
 - Add edid modes parse support
 
 Changes in v2:
 - Take Joe Preches advise, improved commit message more readable, and
   avoid using some uncommon style like bellow:
   -  retval = exynos_dp_read_bytes_from_i2c(...
...)
   +  retval =
   +  exynos_dp_read_bytes_from_i2c(..);
 - Take Jingoo Han suggest, just remove my name from author list.
 - Take Jingoo Han suggest, remove new copyright
 - Fix compiled failed dut to analogix_dp_device misspell
 - Take Heiko suggest, get panel node with remote-endpoint method,
   and create devicetree binding for driver.
 - Remove the clock enable/disbale with sclk_edp  sclk_edp_24m,
   leave those clock to rockchip dp phy driver.
 - Add GNU license v2 declared and samsung copyright
 - Fix compile failed dut to phy_pd_addr variable misspell error
 
 Yakir Yang (14):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: bridge/analogix_dp: dynamic parse sync_pol  interlace 
 colorimetry
   drm: bridge/analogix_dp: fix link_rate  lane_count bug
   Documentation: drm/bridge: add document for analogix_dp
   drm: rockchip/dp: add rockchip platform dp driver
   phy: Add driver for rockchip Display Port PHY
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
   drm: bridge/analogix_dp: expand the delay time for hpd detect
   drm: bridge/analogix_dp: move hpd detect to connector detect function
   drm: bridge/analogix_dp: add edid modes parse in get_modes method
 
  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +
  .../devicetree/bindings/phy/rockchip-dp-phy.txt|   26

Re: [PATCH v3 05/14] drm: bridge/analogix_dp: fix link_rate lane_count bug

2015-08-20 Thread Jingoo Han
On 2015. 8. 19., at PM 11:50, Yakir Yang y...@rock-chips.com wrote:
 
 link_rate and lane_count already configed in analogix_dp_set_link_train(),

s/configed/configured

Also, the commit name such as fix ... bug is not good.
How about following?

drm: bridge/analogix_dp: remove duplicate configuration of link rate and link 
count

Best regards,
Jingoo Han

 so we don't need to config those repeatly after training finished, just
 remove them out.
 
 Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
 would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
 
 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
 Changes in v3:
 - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
  the DT property value directly, but we can take those as hardware limite.
  For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
  so DT property would like link-rate = 0x0a lane-count = 4.
 
 Changes in v2: None
 
 drivers/gpu/drm/bridge/analogix_dp_core.c | 16 
 drivers/gpu/drm/bridge/analogix_dp_core.h |  9 +
 2 files changed, 13 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
 b/drivers/gpu/drm/bridge/analogix_dp_core.c
 index 480cc13..1778e0a 100644
 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
 +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
 @@ -635,6 +635,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
 analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
 + * For DP rev.1.2, Maximum link rate of Main Link lanes
 + * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, data);
*bandwidth = data;
 @@ -668,7 +670,8 @@ static void analogix_dp_init_training(struct 
 analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, dp-link_train.lane_count);
 
if ((dp-link_train.link_rate != LINK_RATE_1_62GBPS) 
 -(dp-link_train.link_rate != LINK_RATE_2_70GBPS)) {
 +(dp-link_train.link_rate != LINK_RATE_2_70GBPS) 
 +(dp-link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp-dev, Rx Max Link Rate is abnormal :%x !\n,
dp-link_train.link_rate);
dp-link_train.link_rate = LINK_RATE_1_62GBPS;
 @@ -901,8 +904,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
 *dp)
return;
}
 
 -ret = analogix_dp_set_link_train(dp, dp-video_info-lane_count,
 - dp-video_info-link_rate);
 +ret = analogix_dp_set_link_train(dp, dp-video_info-max_lane_count,
 + dp-video_info-max_link_rate);
if (ret) {
dev_err(dp-dev, unable to do link train\n);
return;
 @@ -912,9 +915,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
 *dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
 
 -analogix_dp_set_lane_count(dp, dp-video_info-lane_count);
 -analogix_dp_set_link_bandwidth(dp, dp-video_info-link_rate);
 -
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
 @@ -1198,13 +1198,13 @@ static struct video_info 
 *analogix_dp_dt_parse_pdata(struct device *dev)
}
 
if (of_property_read_u32(dp_node, analogix,link-rate,
 - dp_video_config-link_rate)) {
 + dp_video_config-max_link_rate)) {
dev_err(dev, failed to get link-rate\n);
return ERR_PTR(-EINVAL);
}
 
if (of_property_read_u32(dp_node, analogix,lane-count,
 - dp_video_config-lane_count)) {
 + dp_video_config-max_lane_count)) {
dev_err(dev, failed to get lane-count\n);
return ERR_PTR(-EINVAL);
}
 diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.h 
 b/drivers/gpu/drm/bridge/analogix_dp_core.h
 index 2cefde9..941b34f 100644
 --- a/drivers/gpu/drm/bridge/analogix_dp_core.h
 +++ b/drivers/gpu/drm/bridge/analogix_dp_core.h
 @@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP 5
 
 enum link_rate_type {
 -LINK_RATE_1_62GBPS = 0x06,
 -LINK_RATE_2_70GBPS = 0x0a
 +LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
 +LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
 +LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };
 
 enum link_lane_count_type {
 @@ -128,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
 
 -enum link_rate_type link_rate;
 -enum link_lane_count_type lane_count;
 +enum link_rate_type   max_link_rate;
 +enum link_lane_count_type max_lane_count;
 };
 
 struct link_train {
 -- 
 1.9.1
 
 
--
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 v3 12/14] drm: bridge/analogix_dp: expand the delay time for hpd detect

2015-08-20 Thread Jingoo Han
On 2015. 8. 19., at PM 11:52, Yakir Yang y...@rock-chips.com wrote:
 
 Some edp screen with no hpd signal would need some delay time
 to ensure that screen would be ready for work, so we can expand
 the delay time in hpd detect function, it works prefectly on my
 rk3288 sdk board.

Then, this delay has a dependency on the rk3288 sdk board.
Also, if the delay time is expanded, the booting time of some Exybos boards 
will be increased unnecessarily. :-(

So, please add new DT property such as 'hpd-delay' that can be added to board 
DT files.

If there is not that DT property in DT files, the default value '10' will 
written to a variable such as 'unsigned int hpd_delay'.
If there is the DT property in DT files, the delay value will written to the 
variable when parsing DT values
and will be used in analogix_dp_detect_hpd().

What I want to say is that there should not be harmful effect on the existing 
Exynos boards, due to unrelated reasons.

Best regards,
Jingoo Han

 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
 Changes in v3: None
 Changes in v2: None
 
 drivers/gpu/drm/bridge/analogix_dp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/bridge/analogix_dp_core.c 
 b/drivers/gpu/drm/bridge/analogix_dp_core.c
 index 99870f7..75dd44a 100644
 --- a/drivers/gpu/drm/bridge/analogix_dp_core.c
 +++ b/drivers/gpu/drm/bridge/analogix_dp_core.c
 @@ -68,7 +68,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
 *dp)
return 0;
 
timeout_loop++;
 -usleep_range(10, 11);
 +usleep_range(100, 110);
}
 
/*
 -- 
 1.9.1
 
 
--
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 v3 0/14] Add Analogix Core Display Port Driver

2015-08-19 Thread Jingoo Han
On 2015. 8. 20., at PM 1:29, Archit Taneja arch...@codeaurora.org wrote:
 
 Hi,
 
 On 08/19/2015 08:18 PM, Yakir Yang wrote:
 
 Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
 share the same IP, so a lot of parts can be re-used. I split the common
 code into bridge directory, then rk3288 and exynos only need to keep
 some platform code. Cause I can't find the exact IP name of exynos dp
 controller, so I decide to name dp core driver with analogix which I
 find in rk3288 eDP TRM ;)
 
 Beyond that, there are three light registers setting differents bewteen
 exynos and rk3288.
 1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
 2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
 
 I have verified this series on two kinds of rockchip platform board, one
 is rk3288 sdk board which connect with a 2K display port monitor, the other
 is google jerry chromebook which connect with a eDP screen cnm,n116bgeea2,
 both of them works rightlly.
 
 I haven't verified the dp function on samsung platform, cause I haven't got
 exynos boards. I can only ensure that there are no build error on samsung
 platform, wish some samsung guys help to test. ;)
 
 Thanks,
 - Yakir
 
 Changes in v3:
 - Take Thierry Reding suggest, move exynos's video_timing code
   to analogix_dp-exynos platform driver, add get_modes method
   to struct analogix_dp_plat_data.
 - Take Heiko suggest, rename some samsung* dts propery to analogix*.
 - Take Thierry Reding suggest, dynamic parse video timing info from
   struct drm_display_mode and struct drm_display_info.
 - Take Thierry Reding suggest, link_rate and lane_count shouldn't config to
   the DT property value directly, but we can take those as hardware limite.
   For example, RK3288 only support 4 physical lanes of 2.7/1.62 Gbps/lane,
   so DT property would like link-rate = 0x0a lane-count = 4.
 - Take Heiko suggest, add devicetree binding documents.
 - Take Thierry Reding suggest, remove sync pol  colorimetry properies
   from the new analogix dp driver devicetree binding.
 - Update the exist exynos dtsi file with the latest DP DT properies.
 - Take Thierry Reding and Heiko suggest, leave sclk_edp_24m to rockchip
   dp phy driver which name to 24m, and leave sclk_edp to analogix dp
   core driver which name to dp, and leave pclk_edp to rockchip dp 
 platform
   driver which name to pclk.
 - Take Heiko suggest, add devicetree binding document.
 - Take Heiko suggest, remove rockchip,panel DT property, take use of remote
   point to get panel node.
 - Add the new function point analogix_dp_platdata.get_modes init.
 - Take Heiko suggest, add rockchip dp phy driver,
   collect the phy clocks and power control.
 - Add analogix,need-force-hpd to indicate whether driver need foce
   hpd when hpd detect failed.
 - move dp hpd detect to connector detect function.
 - Add edid modes parse support
 
 Changes in v2:
 - Take Joe Preches advise, improved commit message more readable, and
   avoid using some uncommon style like bellow:
   -  retval = exynos_dp_read_bytes_from_i2c(...
...)
   +  retval =
   +  exynos_dp_read_bytes_from_i2c(..);
 - Take Jingoo Han suggest, just remove my name from author list.
 - Take Jingoo Han suggest, remove new copyright
 - Fix compiled failed dut to analogix_dp_device misspell
 - Take Heiko suggest, get panel node with remote-endpoint method,
   and create devicetree binding for driver.
 - Remove the clock enable/disbale with sclk_edp  sclk_edp_24m,
   leave those clock to rockchip dp phy driver.
 - Add GNU license v2 declared and samsung copyright
 - Fix compile failed dut to phy_pd_addr variable misspell error
 
 Yakir Yang (14):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: bridge/analogix_dp: dynamic parse sync_pol  interlace 
 colorimetry
   drm: bridge/analogix_dp: fix link_rate  lane_count bug
   Documentation: drm/bridge: add document for analogix_dp
   drm: rockchip/dp: add rockchip platform dp driver
   phy: Add driver for rockchip Display Port PHY
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
   drm: bridge/analogix_dp: expand the delay time for hpd detect
   drm: bridge/analogix_dp: move hpd detect to connector detect function
   drm: bridge/analogix_dp: add edid modes parse in get_modes method
 
  .../devicetree/bindings/drm/bridge/analogix_dp.txt |   73 +
  .../devicetree/bindings/phy/rockchip-dp-phy.txt|   26 +
  .../bindings/video/analogix_dp-rockchip.txt|   83 ++
  .../devicetree/bindings/video/exynos_dp.txt|   51 +-
  arch/arm/boot/dts

Re: [RFC PATCH 2/8] drm: exynos/dp: convert to drm bridge mode

2015-08-06 Thread Jingoo Han
On Thursday, August 06, 2015 11:07 PM, Yakir Yang wrote:
 
 In order to move exynos dp code to bridge directory,
 we need to convert driver drm bridge mode first. As
 dp driver already have a ptn3460 bridge, so we need
 to move ptn bridge to the next bridge of dp bridge.
 
 Signed-off-by: Yakir Yang y...@rock-chips.com
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c | 196 
 
  drivers/gpu/drm/exynos/exynos_dp_core.h |   2 +
  2 files changed, 126 insertions(+), 72 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index a8097a4..aa99e23 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -3,6 +3,7 @@
   *
   * Copyright (C) 2012 Samsung Electronics Co., Ltd.
   * Author: Jingoo Han jg1@samsung.com
 + * Yakir Yang y...@rock-chips.com

Please don't add this.
You just fixed some parts of this code. I don't find the reason
why you have to be added to author for this file.
If you want the title for an author, please send the patch
for a new IP, instead of modifying the exiting codes.

   *
   * This program is free software; you can redistribute it and/or modify it
   * under the terms of the GNU General Public License as published by the
 @@ -998,59 +999,6 @@ static struct drm_connector_helper_funcs 
 exynos_dp_connector_helper_funcs = {
   .best_encoder = exynos_dp_best_encoder,
  };
 
 -/* returns the number of bridges attached */
 -static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
 - struct drm_encoder *encoder)
 -{
 - int ret;
 -
 - encoder-bridge = dp-bridge;
 - dp-bridge-encoder = encoder;
 - ret = drm_bridge_attach(encoder-dev, dp-bridge);
 - if (ret) {
 - DRM_ERROR(Failed to attach bridge to drm\n);
 - return ret;
 - }
 -
 - return 0;
 -}
 -
 -static int exynos_dp_create_connector(struct exynos_drm_display *display,
 -   struct drm_encoder *encoder)
 -{
 - struct exynos_dp_device *dp = display_to_dp(display);
 - struct drm_connector *connector = dp-connector;
 - int ret;
 -
 - dp-encoder = encoder;
 -
 - /* Pre-empt DP connector creation if there's a bridge */
 - if (dp-bridge) {
 - ret = exynos_drm_attach_lcd_bridge(dp, encoder);
 - if (!ret)
 - return 0;
 - }
 -
 - connector-polled = DRM_CONNECTOR_POLL_HPD;
 -
 - ret = drm_connector_init(dp-drm_dev, connector,
 -  exynos_dp_connector_funcs,
 -  DRM_MODE_CONNECTOR_eDP);
 - if (ret) {
 - DRM_ERROR(Failed to initialize connector with drm\n);
 - return ret;
 - }
 -
 - drm_connector_helper_add(connector, exynos_dp_connector_helper_funcs);
 - drm_connector_register(connector);
 - drm_mode_connector_attach_encoder(connector, encoder);
 -
 - if (dp-panel)
 - ret = drm_panel_attach(dp-panel, dp-connector);
 -
 - return ret;
 -}
 -
  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
   if (dp-phy)
 @@ -1115,23 +1063,126 @@ static void exynos_dp_poweroff(struct 
 exynos_dp_device *dp)
   }
  }
 
 -static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
 +/* returns the number of bridges attached */
 +static int exynos_drm_attach_lcd_bridge(struct exynos_dp_device *dp,
 + struct drm_encoder *encoder)
 +{
 + int ret;
 +
 + dp-bridge-next = dp-ptn_bridge;
 + dp-bridge-encoder = encoder;
 + ret = drm_bridge_attach(encoder-dev, dp-bridge);
 + if (ret) {
 + DRM_ERROR(Failed to attach ptn bridge to drm\n);
 + return ret;
 + }
 +
 + return 0;
 +}
 +
 +static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 +{
 +
 + struct exynos_dp_device *dp = bridge-driver_private;
 + struct drm_encoder *encoder = dp-encoder;
 + struct drm_connector *connector = dp-connector;
 + int ret;
 +
 + if (!bridge-encoder) {
 + DRM_ERROR(Parent encoder object not found);
 + return -ENODEV;
 + }
 +
 + encoder-bridge = bridge;
 +
 + /* Pre-empt DP connector creation if there's a bridge */
 + if (dp-ptn_bridge) {
 + ret = exynos_drm_attach_lcd_bridge(dp, encoder);
 + if (ret)
 + return -ENODEV;
 + }
 +
 + connector-polled = DRM_CONNECTOR_POLL_HPD;
 +
 + ret = drm_connector_init(dp-drm_dev, connector,
 + exynos_dp_connector_funcs, DRM_MODE_CONNECTOR_eDP);
 + if (ret) {
 + DRM_ERROR(Failed to initialize connector with drm\n);
 + return ret;
 + }
 +
 + drm_connector_helper_add(connector, exynos_dp_connector_helper_funcs);
 + drm_connector_register(connector);
 + drm_mode_connector_attach_encoder(connector, encoder

Re: [RFC PATCH 0/8] Add Analogix Core Display Port Driver

2015-08-06 Thread Jingoo Han
On Thursday, August 06, 2015 10:49 PM, Yakir Yang wrote:
 
 Hi all,
Samsung exynos and Rockchip rk3288 almost share same dp controller,
 so I split the common code out, then rk3288 and exynos can re-used the
 same dp core driver. Cause I can't find the exact IP name of exynos dp
 controller, so I decide to name dp core driver with analogix which I
 find in rk3288 eDP TRM ;)


OK, I see.
The Samsung Exynos eDP contoller and Rockchip rk3288 eDP contoller share
the same IP. So, a lot of parts can be re-used. I agree with this.
However, we have to review the code carefully, as others did.

I also cannot find the exact IP name. The analogix may be the vendor name
of this IP.

Best regards,
Jingoo Han

 
 Beyond that, there are three light registers setting differents bewteen
 exynos and rk3288.
 1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
 2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).
 
 My series patches can be divider into two parts: One for spliting the
 analogix_dp code from exynos dp driver. Another are trying to add rk3288
 dp driver support.
 
 Best regards,
 - Yakir
 
 
 Yakir Yang (8):
   drm: exynos/dp: fix code style
   drm: exynos/dp: convert to drm bridge mode
   drm: bridge: analogix_dp: split exynos dp driver to bridge dir
   drm: rockchip/dp: add rockchip platform dp driver
   drm: bridge/analogix_dp: add platform device type support
   drm: bridge: analogix_dp: add some rk3288 special registers setting
   drm: bridge: analogix_dp: try force hpd after plug in lookup failed
   drm: bridge/analogix_dp: expand the delay time for hpd detect
 
  drivers/gpu/drm/bridge/Kconfig |5 +
  drivers/gpu/drm/bridge/Makefile|1 +
  drivers/gpu/drm/bridge/analogix_dp_core.c  | 1397 +++
  drivers/gpu/drm/bridge/analogix_dp_core.h  |  287 
  drivers/gpu/drm/bridge/analogix_dp_reg.c   | 1295 ++
  .../exynos_dp_reg.h = bridge/analogix_dp_reg.h}   |  272 ++--
  drivers/gpu/drm/exynos/Kconfig |5 +-
  drivers/gpu/drm/exynos/Makefile|2 +-
  drivers/gpu/drm/exynos/analogix_dp-exynos.c|  241 
  drivers/gpu/drm/exynos/exynos_dp_core.c| 1416 
 
  drivers/gpu/drm/exynos/exynos_dp_core.h|  282 
  drivers/gpu/drm/exynos/exynos_dp_reg.c |  100 +-
  drivers/gpu/drm/rockchip/Kconfig   |   10 +
  drivers/gpu/drm/rockchip/Makefile  |1 +
  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  420 ++
  include/drm/bridge/analogix_dp.h   |   28 +
  16 files changed, 3880 insertions(+), 1882 deletions(-)
  create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.c
  create mode 100644 drivers/gpu/drm/bridge/analogix_dp_core.h
  create mode 100644 drivers/gpu/drm/bridge/analogix_dp_reg.c
  rename drivers/gpu/drm/{exynos/exynos_dp_reg.h = bridge/analogix_dp_reg.h} 
 (62%)
  create mode 100644 drivers/gpu/drm/exynos/analogix_dp-exynos.c
  delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
  delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
  create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
  create mode 100644 include/drm/bridge/analogix_dp.h
 
 --
 2.1.2


--
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] drm/exynos: dp: Lower level of EDID read success message

2015-05-18 Thread Jingoo Han
 Don't pollute the dmesg with EDID read success message as an error.
 Printing as debug should be fine.

 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Right, dev_err() is not right.
Thank you for sending the patch.

Acked-by: Jingoo Han jingooh...@gmail.com

Best regards,
Jingoo Han

 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 441ef06b8894..30feb7d06624 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -195,7 +195,7 @@ static int exynos_dp_read_edid(struct exynos_dp_device 
 *dp)
   }
   }
  
 - dev_err(dp-dev, EDID Read success!\n);
 + dev_dbg(dp-dev, EDID Read success!\n);
   return 0;
  }
  
 -- 
 1.9.1

--
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-12-02 Thread Jingoo Han
On Tuesday, December 02, 2014 5:17 PM, Javier Martinez Canillas wrote:
 
 Hello Kukjin,
 
 On Mon, Nov 24, 2014 at 6:41 AM, Vivek Gautam gautam.vi...@samsung.com 
 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 gautam.vi...@samsung.com
  Reviewed-by: Jingoo Han jg1@samsung.com
  Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
  Cc: Kukjin Kim kg...@kernel.org
 
 Any opinions about $subject?
 
 This patch is -rc material since is needed after commit a5ec598 (phy:
 exynos-dp-video: Use syscon
 support to control pmu register) which landed in 3.18. That means
 that display for Exynos is currently broken in 3.18.
 
 I think it's too late for the 3.18 -rc cycle but at least it would be
 great to have this merged for 3.19 and backport to stable kernels to
 have display working again.

I agree with this suggestion.

 
 Thierry had concerns that this change breaks DT backward compability
 but actually it was already been broken by a5ec598 which changed the
 DT binding for the phy-exynos-dp-video driver so we should either
 apply this patch now or revert a5ec598.

I think that very few people might use old properties for Exynos DP.
Actually, DT backward compatibility will not be the considerable problem
in my opinion.

But, in order to keep the DT backward compatibility, we should revert
a5ec598, and send another patch for keeping the DT backward compatibility.

Best regards,
Jingoo Han

 
 Thanks a lot and best regards,
 Javier

--
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] drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

2014-12-02 Thread Jingoo Han
On Wednesday, December 03, 2014 10:54 AM, Rafael J. Wysocki wrote:
 
 From: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
 After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
 selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
 depending on CONFIG_PM_RUNTIME may now be changed to depend on
 CONFIG_PM.
 
 Replace CONFIG_PM_RUNTIME with CONFIG_PM in 4 files under
 gpu/drm/exynos/.
 
 Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 
 Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
 PM_SLEEP is selected) which is only in linux-next at the moment (via the
 linux-pm tree).
 
 Please let me know if it is OK to take this one into linux-pm.
 
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimc.c|2 +-
  drivers/gpu/drm/exynos/exynos_drm_g2d.c |2 +-
  drivers/gpu/drm/exynos/exynos_drm_gsc.c |2 +-
  drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)
 
 Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 ===
 --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 @@ -1817,7 +1817,7 @@ static int fimc_resume(struct device *de
  }
  #endif
 
 -#ifdef CONFIG_PM_RUNTIME
 +#ifdef CONFIG_PM
  static int fimc_runtime_suspend(struct device *dev)
  {
   struct fimc_context *ctx = get_fimc_context(dev);
 Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
 ===
 --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_gsc.c
 +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_gsc.c
 @@ -1764,7 +1764,7 @@ static int gsc_resume(struct device *dev
  }
  #endif
 
 -#ifdef CONFIG_PM_RUNTIME
 +#ifdef CONFIG_PM
  static int gsc_runtime_suspend(struct device *dev)
  {
   struct gsc_context *ctx = get_gsc_context(dev);
 Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 ===
 --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_rotator.c
 @@ -822,7 +822,7 @@ static int rotator_resume(struct device
  }
  #endif
 
 -#ifdef CONFIG_PM_RUNTIME
 +#ifdef CONFIG_PM
  static int rotator_runtime_suspend(struct device *dev)
  {
   struct rot_context *rot = dev_get_drvdata(dev);
 Index: linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 ===
 --- linux-pm.orig/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 +++ linux-pm/drivers/gpu/drm/exynos/exynos_drm_g2d.c
 @@ -1540,7 +1540,7 @@ static int g2d_resume(struct device *dev
  }
  #endif
 
 -#ifdef CONFIG_PM_RUNTIME
 +#ifdef CONFIG_PM
  static int g2d_runtime_suspend(struct device *dev)
  {
   struct g2d_data *g2d = dev_get_drvdata(dev);

--
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 1/3] drm/exynos: free DP if probe fails to find a panel or bridge

2014-11-23 Thread Jingoo Han
On Saturday, November 22, 2014 2:40 AM, Ajay kumar wrote:
 
 On Fri, Nov 21, 2014 at 5:24 AM, Gustavo Padovan gust...@padovan.org wrote:
  From: Gustavo Padovan gustavo.pado...@collabora.co.uk
 
  DP was leaked everytime function returns EPROBE_DEFER, free it before
  returning.
 
  Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
  ---
   drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
   1 file changed, 15 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
  b/drivers/gpu/drm/exynos/exynos_dp_core.c
  index 85762cf..6fd4a46 100644
  --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
  +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
  @@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device 
  *pdev)
  if (panel_node) {
  dp-panel = of_drm_find_panel(panel_node);
  of_node_put(panel_node);
  -   if (!dp-panel)
  -   return -EPROBE_DEFER;
  +   if (!dp-panel) {
  +   ret = -EPROBE_DEFER;
  +   goto free_dp;
  +   }
  }
 
  endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
  @@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device 
  *pdev)
  if (bridge_node) {
  dp-bridge = of_drm_find_bridge(bridge_node);
  of_node_put(bridge_node);
  -   if (!dp-bridge)
  -   return -EPROBE_DEFER;
  -   } else
  -   return -EPROBE_DEFER;
  +   if (!dp-bridge) {
  +   ret = -EPROBE_DEFER;
  +   goto free_dp;
  +   }
  +   } else {
  +   ret = -EPROBE_DEFER;
  +   goto free_dp;
  +   }
  }
 
  exynos_dp_display.ctx = dp;
  @@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device 
  *pdev)
  exynos_drm_component_del(pdev-dev,
  
  EXYNOS_DEVICE_TYPE_CONNECTOR);
 
  +free_dp:
  +   devm_kfree(dev, dp);
 I guess the driver core takes care of freeing the devm memory when the
 probe fails?
 Will it not happen during PROBE_DEFER?
 
 Inki/Jingoo - Is this change really necessary?

As far as I know, this devm_kfree() in unnecessary,
even though PROBE_DEFER is returned.
If I am wrong, please let me know. Thanks.

Best regards,
Jingoo Han

 
 Ajay
 
  return ret;
   }
 
  --
  1.9.3
 
  --
  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

--
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 v3 1/2] drm/exynos: dp: Remove support for unused dptx-phy

2014-11-12 Thread Jingoo Han
On Wednesday, November 12, 2014 6:28 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 gautam.vi...@samsung.com
 Cc: Inki Dae inki@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
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

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

2014-11-11 Thread Jingoo Han
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.

 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Inki Dae inki@samsung.com
 Cc: Jingoo Han jg1@samsung.com
 ---
 
 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.

Best regards,
Jingoo Han

 - 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

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

2014-11-11 Thread Jingoo Han
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 gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
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


Re: [PATCH] usb: Remove references to non-existent PLAT_S5P symbol

2014-10-06 Thread Jingoo Han
On Tuesday, October 07, 2014 12:47 AM, Sylwester Nawrocki wrote:
 
 The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
 (ARM: SAMSUNG: Remove remaining legacy code). There are still
 some references left, fix that by replacing them with ARCH_S5PV210.
 
 Reported-by: Paul Bolle pebo...@tiscali.nl
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/usb/host/Kconfig |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
 index 82800a7..6f1d48e 100644
 --- a/drivers/usb/host/Kconfig
 +++ b/drivers/usb/host/Kconfig
 @@ -220,7 +220,7 @@ config USB_EHCI_SH
 
  config USB_EHCI_EXYNOS
 tristate EHCI support for Samsung S5P/EXYNOS SoC Series
 -   depends on PLAT_S5P || ARCH_EXYNOS
 +   depends on ARCH_S5PV210 || ARCH_EXYNOS
 help
   Enable support for the Samsung Exynos SOC's on-chip EHCI controller.
 
 @@ -527,7 +527,7 @@ config USB_OHCI_SH
 
  config USB_OHCI_EXYNOS
   tristate OHCI support for Samsung S5P/EXYNOS SoC Series
 - depends on PLAT_S5P || ARCH_EXYNOS
 + depends on ARCH_S5PV210 || ARCH_EXYNOS
   help
Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
 
 --
 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


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

2014-09-17 Thread Jingoo Han
On Wednesday, September 17, 2014 8:18 PM, 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 gautam.vi...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/usb/host/ehci-exynos.c |   81 
 
  1 file changed, 23 insertions(+), 58 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index 2eed9a4..99c5f5f 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -21,11 +21,8 @@
  #include linux/of_gpio.h
  #include linux/phy/phy.h
  #include linux/platform_device.h
 -#include linux/usb/phy.h
 -#include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
  #include linux/usb/hcd.h
 -#include linux/usb/otg.h
 
  #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)
 @@ -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;
 + 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];
   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 +96,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 +113,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 v3 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support

2014-09-17 Thread Jingoo Han
On Wednesday, September 17, 2014 8:18 PM, 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 gautam.vi...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/usb/host/ohci-exynos.c |   89 
 +++-
  1 file changed, 24 insertions(+), 65 deletions(-)
 
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index 7c48e3f..992b28d 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -19,11 +19,8 @@
  #include linux/of.h
  #include linux/platform_device.h
  #include linux/phy/phy.h
 -#include linux/usb/phy.h
 -#include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
  #include linux/usb/hcd.h
 -#include linux/usb/otg.h
 
  #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,
 @@ -48,56 +43,40 @@ static int exynos_ohci_get_phy(struct device *dev,
  {
   struct device_node *child;
   struct phy *phy;
 - int phy_number;
 - int ret = 0;
 + int phy_num;
 + 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 the generic phys */
   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_ohci-phy[phy_num] = devm_of_phy_get(dev, child, NULL);
 + phy = exynos_ohci-phy[phy_num];
   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

Re: [PATCH] usb: dwc3: exynos: remove usb_phy_generic support

2014-08-27 Thread Jingoo Han
On Wednesday, August 27, 2014 4:53 PM, Bartlomiej Zolnierkiewicz wrote:
 
 dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
 (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
 looking at the following commits:
 
   7a4cf0fde054 (ARM: dts: Update DWC3 usb controller to use new
   phy driver for exynos5250)
 
   f070267b5fc1 (ARM: dts: Enable support for DWC3 controller for
   exynos5420)
 
 Thus remove unused usb_phy_generic support from dwc3 Exynos glue
 layer.
 
 [ The code that is being removed is harmful in the context of
   multi_v7_defconfig and enabling EHCI support for Samsung
   S5P/EXYNOS SoC Series (USB_EHCI_EXYNOS) + OHCI support for
   Samsung S5P/EXYNOS SoC Series (USB_OHCI_EXYNOS) because EHCI
   support for OMAP3 and later chips (USB_EHCI_HCD_OMAP) selects
   NOP USB Transceiver Driver (NOP_USB_XCEIV).  NOP USB driver
   attaches itself to usb_phy_generic platform devices created by
   dwc3 Exynos glue layer and later causes Exynos EHCI driver to
   fail probe and Exynos OHCI driver to hang on probe (as observed
   on Exynos5250 Arndale board). ]

I also agree with this patch, because dwc3 IPs of all Exynos SoCs
do not use NOP USB Transceiver Driver. So, usb_phy_generic can be
removed from Exynos dwc3 driver.

Is there any reason to support 'usb_phy_generic' for Exynos dwc3?
If so, please let me know. Thank you.

Best regards,
Jingoo Han

 
 Cc: Olof Johansson o...@lixom.net
 Cc: Kukjin Kim kgene@samsung.com
 Cc: Vivek Gautam gautam.vi...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 ---
  drivers/usb/dwc3/dwc3-exynos.c |   68 
 -
  1 file changed, 1 insertion(+), 67 deletions(-)
 
 Index: b/drivers/usb/dwc3/dwc3-exynos.c
 ===
 --- a/drivers/usb/dwc3/dwc3-exynos.c  2014-08-25 14:57:04.991781925 +0200
 +++ b/drivers/usb/dwc3/dwc3-exynos.c  2014-08-27 09:16:38.312617727 +0200
 @@ -23,15 +23,12 @@
  #include linux/platform_data/dwc3-exynos.h
  #include linux/dma-mapping.h
  #include linux/clk.h
 -#include linux/usb/otg.h
 -#include linux/usb/usb_phy_generic.h
 +#include linux/pm_runtime.h
  #include linux/of.h
  #include linux/of_platform.h
  #include linux/regulator/consumer.h
 
  struct dwc3_exynos {
 - struct platform_device  *usb2_phy;
 - struct platform_device  *usb3_phy;
   struct device   *dev;
 
   struct clk  *clk;
 @@ -39,61 +36,6 @@ struct dwc3_exynos {
   struct regulator*vdd10;
  };
 
 -static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
 -{
 - struct usb_phy_generic_platform_data pdata;
 - struct platform_device  *pdev;
 - int ret;
 -
 - memset(pdata, 0x00, sizeof(pdata));
 -
 - pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
 - if (!pdev)
 - return -ENOMEM;
 -
 - exynos-usb2_phy = pdev;
 - pdata.type = USB_PHY_TYPE_USB2;
 - pdata.gpio_reset = -1;
 -
 - ret = platform_device_add_data(exynos-usb2_phy, pdata, sizeof(pdata));
 - if (ret)
 - goto err1;
 -
 - pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
 - if (!pdev) {
 - ret = -ENOMEM;
 - goto err1;
 - }
 -
 - exynos-usb3_phy = pdev;
 - pdata.type = USB_PHY_TYPE_USB3;
 -
 - ret = platform_device_add_data(exynos-usb3_phy, pdata, sizeof(pdata));
 - if (ret)
 - goto err2;
 -
 - ret = platform_device_add(exynos-usb2_phy);
 - if (ret)
 - goto err2;
 -
 - ret = platform_device_add(exynos-usb3_phy);
 - if (ret)
 - goto err3;
 -
 - return 0;
 -
 -err3:
 - platform_device_del(exynos-usb2_phy);
 -
 -err2:
 - platform_device_put(exynos-usb3_phy);
 -
 -err1:
 - platform_device_put(exynos-usb2_phy);
 -
 - return ret;
 -}
 -
  static int dwc3_exynos_remove_child(struct device *dev, void *unused)
  {
   struct platform_device *pdev = to_platform_device(dev);
 @@ -127,12 +69,6 @@ static int dwc3_exynos_probe(struct plat
 
   platform_set_drvdata(pdev, exynos);
 
 - ret = dwc3_exynos_register_phys(exynos);
 - if (ret) {
 - dev_err(dev, couldn't register PHYs\n);
 - return ret;
 - }
 -
   clk = devm_clk_get(dev, usbdrd30);
   if (IS_ERR(clk)) {
   dev_err(dev, couldn't get clock\n);
 @@ -194,8 +130,6 @@ static int dwc3_exynos_remove(struct pla
   struct dwc3_exynos  *exynos = platform_get_drvdata(pdev);
 
   device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
 - platform_device_unregister(exynos-usb2_phy);
 - platform_device_unregister(exynos-usb3_phy);
 
   clk_disable_unprepare(exynos-clk);
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord

Re: [PATCH v5 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

2014-08-26 Thread Jingoo Han
))
 + break;
 +
 + udelay(1);
 + } while (usec--  0);
 +
 + if (!usec)
 + dev_err(phy_drd-dev,
 + CRPORT handshake timeout2 (0x%08x)\n, val);
 +}
 +
 +static void crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
 + u32 addr, u32 data)
 +{
 + /* Write Address */
 + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
 +  EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);

According to the guidance from H/W team, before calling crport_handshake(),
write access for EXYNOS5_DRD_PHYREG0 register is necessary.

Please, add the write access as follows.

+   /* Write Address */
+   writel(EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
+   phy_drd-reg_phy + EXYNOS5_DRD_PHYREG0);
+   crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(addr),
+EXYNOS5_DRD_PHYREG0_CR_CAP_ADDR);

Best regards,
Jingoo Han

 +
 + /* Write Data */
 + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
 +  EXYNOS5_DRD_PHYREG0_CR_CAP_DATA);
 + crport_handshake(phy_drd, EXYNOS5_DRD_PHYREG0_CR_DATA_IN(data),
 +  EXYNOS5_DRD_PHYREG0_CR_WRITE);
 +}
 +
 +/*
 + * Override PHY paramaeters using CR_PORT register to calibrate settings
 + * to meet meet SuperSpeed requirements, on Exynos5420 and Exynos5800 
 systems,
 + * which have 28nm USB 3.0 DRD PHY.
 + */
 +static void exynos5420_usbdrd_phy_calibrate(struct exynos5_usbdrd_phy 
 *phy_drd)
 +{
 + u32 temp;
 +
 + /*
 +  * Change los_bias to (0x5) for 28nm PHY from a
 +  * default value (0x0); los_level is set as default
 +  * (0x9) as also reflected in los_level[30:26] bits
 +  * of PHYPARAM0 register.
 +  */
 + temp = LOSLEVEL_OVRD_IN_LOS_BIAS_5420 |
 + LOSLEVEL_OVRD_IN_EN |
 + LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT;
 + crport_ctrl_write(phy_drd,
 +   EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN,
 +   temp);
 +
 + /*
 +  * Set tx_vboost_lvl to (0x5) for 28nm PHY Tuning,
 +  * to raise Tx signal level from its default value of (0x4)
 +  */
 + temp = TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420;
 + crport_ctrl_write(phy_drd,
 +   EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN,
 +   temp);
 +
 + /*
 +  * Set proper time to wait for RxDetect measurement, for
 +  * desired reference clock of PHY, by tuning the CRPORT
 +  * register LANE0.TX_DEBUG which is internal to PHY.
 +  * This fixes issue with few USB 3.0 devices, which are
 +  * not detected (not even generate interrupts on the bus
 +  * on insertion) without this change.
 +  * e.g. Samsung SUM-TSB16S 3.0 USB drive.
 +  */
 + switch (phy_drd-extrefclk) {
 + case EXYNOS5_FSEL_50MHZ:
 + temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M;
 + break;
 + case EXYNOS5_FSEL_20MHZ:
 + case EXYNOS5_FSEL_19MHZ2:
 + temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M;
 + break;
 + case EXYNOS5_FSEL_24MHZ:
 + default:
 + temp = LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M;
 + break;
 + }
 +
 + crport_ctrl_write(phy_drd,
 +   EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG,
 +   temp);
 +}
 +
 +/* Calibrate PIPE3 PHY settings, if any */
 +static int exynos5_usbdrd_pipe3_calibrate(struct phy_usb_instance *inst)
 +{
 + struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
 +
 + /* Call respective phy_calibrate given by certain platform */
 + if (phy_drd-drv_data-calibrate)
 + phy_drd-drv_data-calibrate(phy_drd);
 +
 + return 0;
 +}
 +
 +static int exynos5_usbdrd_phy_calibrate(struct phy *phy)
 +{
 + struct phy_usb_instance *inst = phy_get_drvdata(phy);
 +
 + if (inst-phy_cfg-phy_calibrate)
 + inst-phy_cfg-phy_calibrate(inst);
 +
 + return 0;
 +}
 +
  static struct phy *exynos5_usbdrd_phy_xlate(struct device *dev,
   struct of_phandle_args *args)
  {
 @@ -503,6 +669,7 @@ static struct phy_ops exynos5_usbdrd_phy_ops = {
   .exit   = exynos5_usbdrd_phy_exit,
   .power_on   = exynos5_usbdrd_phy_power_on,
   .power_off  = exynos5_usbdrd_phy_power_off,
 + .calibrate  = exynos5_usbdrd_phy_calibrate,
   .owner  = THIS_MODULE,
  };
 
 @@ -518,6 +685,7 @@ static const struct exynos5_usbdrd_phy_config 
 phy_cfg_exynos5[] = {
   .phy_isol   = exynos5_usbdrd_phy_isol,
   .phy_init   = exynos5_usbdrd_pipe3_init,
   .set_refclk = exynos5_usbdrd_pipe3_set_refclk,
 + .phy_calibrate  = exynos5_usbdrd_pipe3_calibrate,
   },
  };
 
 @@ -525,6 +693,7 @@ static const struct exynos5_usbdrd_phy_drvdata 
 exynos5420_usbdrd_phy = {
   .phy_cfg

Re: [PATCH 3/5] usb: phy: samsung: remove old USB 2.0 PHY driver

2014-08-20 Thread Jingoo Han
On Thursday, August 21, 2014 1:31 PM, Vivek Gautam wrote:
 On Mon, Aug 18, 2014 at 4:52 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
  On 18.08.2014 13:02, Bartlomiej Zolnierkiewicz wrote:
  On Thursday, August 14, 2014 08:07:40 PM Vivek Gautam wrote:
  On Thursday, August 14, 2014 7:55 PM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote
 
  There's one thing that I would want to comment here, since we don't have 
  any
  new usb-phy driver for S3C64XX,
  so we can't simply remove this entire driver.
  I have posted my patch-series [1], which does cleanup while keeping the
  support for S3C64XX.
 
  AFAIK S3C64XX code from drivers/usb/phy/phy-samsung-usb2.c has
  never been used as this platform still uses its own code from
  arch/arm/mach-s3c64xx/setup-usb-phy.c (there are no users in
  the kernel tree of either s3c64xx-usb2phy platform device or
  samsung,s3c64xx-usb2phy DT compatible) .  Therefore I think
  that the entire drivers/usb/phy/phy-samsung-usb2.c driver
  should be removed (somebody with the hardware can as well add
  S3C64XX support to the new drivers/phy/phy-samsung-usb2.c
  driver and port the platform to use it).
 
 
  I agree with removal of this driver. As Bart said, it is not used for
  S3C64xx at all. The platform was supposed to be moved to this driver,
  but that never happened.

Yes, right. As far as I know, you're right.

  In fact, I already have a patch adding support
  for S3C64xx to the new driver.

Good!

 
 Cool then, lets remove this driver completely and use the new generic
 PHY based driver
 once that comes (from Tomasz).

I agree with this opinion.

 
 I shall drop the patches for cleaning up the usb-phy drivers from my series.

Best regards,
Jingoo Han

--
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/5] usb: phy: samsung: remove old USB PHY code

2014-08-20 Thread Jingoo Han
On Thursday, August 21, 2014 1:34 PM, Vivek Gautam wrote:
 On Thu, Aug 14, 2014 at 7:55 PM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:
  Hi,
 
  This patch series removes the old Samsung USB PHY drivers that
  got replaced by the new ones using the generic PHY layer.
 
  Depends on:
  - next-20140813 branch of linux-next kernel
 
  Best regards,
  --
  Bartlomiej Zolnierkiewicz
  Samsung RD Institute Poland
  Samsung Electronics
 
 
  Bartlomiej Zolnierkiewicz (5):
ARM: dts: remove old USB2 PHY node hook for Arndale
ARM: dts: remove old USB2 PHY node for Exynos5250
usb: phy: samsung: remove old USB 2.0 PHY driver
usb: phy: samsung: remove old USB 3.0 PHY driver
usb: phy: samsung: remove old common USB PHY code
 
 Reviewed-by: Vivek Gautam gautam.vi...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

--
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 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

2014-08-11 Thread Jingoo Han
On Sunday, August 10, 2014 6:15 PM, Andreas Farber wrote:
 Am 05.08.2014 13:16, schrieb Jingoo Han:
  On Saturday, August 02, 2014 5:57 AM, Tomasz Figa wrote:
  On 01.08.2014 22:54, Andreas Färber wrote:
  Am 01.08.2014 22:33, schrieb Doug Anderson:
  On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
  Spring uses a different GPIO, so this is not a generic SoC piece.
 
  Suggested-by: Tomasz Figa t.f...@samsung.com
  Signed-off-by: Andreas Färber afaer...@suse.de
  ---
   v5: New (Tomasz Figa)
   Frees dp_hpd for Spring.
 
   arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
   arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
   arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
   3 files changed, 16 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
  b/arch/arm/boot/dts/exynos5250-
 pinctrl.dtsi
  index 886cfca044ac..ed0e5230514b 100644
  --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  @@ -581,13 +581,6 @@
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  -
  -   dp_hpd: dp_hpd {
  -   samsung,pins = gpx0-7;
  -   samsung,pin-function = 3;
  -   samsung,pin-pud = 0;
  -   samsung,pin-drv = 0;
  -   };
  };
 
  pinctrl@1340 {
  diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
  b/arch/arm/boot/dts/exynos5250-
 smdk5250.dts
  index aaa055ac0fe3..5d30fe1dcda4 100644
  --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
  +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
  @@ -414,3 +414,12 @@
  };
  };
   };
  +
  +pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +};
  diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
  b/arch/arm/boot/dts/exynos5250-snow.dts
  index c4b0c73c736d..a9a2f2743794 100644
  --- a/arch/arm/boot/dts/exynos5250-snow.dts
  +++ b/arch/arm/boot/dts/exynos5250-snow.dts
  @@ -547,6 +547,13 @@
   };
 
   pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
 
  NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
  Pin function 3 is special function.  This pin _is_ the hot plug detect
  pin for display port.  When it's set as special function 3 it goes
  straight into the hot plug logic of the display port controller.
 
  Spring may have had its reasons to detect hot plug events on a GPIO
  instead of using this pin, but that doesn't make this pin any less the
  hot plug pin.
 
  Please advise how to handle it then: Should there be two different
  pinctrl entries (if so, how should it be named?),
 
  IMHO this is the right way. Just name the GPIO variant dp_hpd_gpio.
 
  Hi Andreas Färber,
 
  I agree with Tomasz Figa and Doug Anderson.
  Please refer to the following.
 
  1. case: Standard HPD pin is used. (smdk5420)
  arch/arm/boot/dts/exynos5420-pinctrl.dts
  pinctrl@1340 {
  dp_hpd: dp_hpd {
  samsung,pins = gpx0-7;
  samsung,pin-function = 3;
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  arch/arm/boot/dts/exynos5420-smdk5420.dts
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd;
  ...
 
  2. case: non-standard HPD pin such as GPIO is used. (peach pit)
  arch/arm/boot/dts/exynos5420-peach-pit.dts
  pinctrl@1340 {
  dp_hpd_gpio: dp_hpd_gpio {
  samsung,pins = gpx2-6;
  samsung,pin-function = 0;
  samsung,pin-pud = 3;
  samsung,pin-drv = 0;
  };
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd_gpio;
  ...
  samsung,hpd-gpio = gpx2 6 0;
 
  So, you need to follow the second case.
  dp_hpd_gpio can be used for Spring board.
 
 I believe I already did so in v6 [0]? Please take a look there and let
 me know if you still need anything changed. The label name seems
 identical, whereas for the node name I adopted the dashes convention.

OK, I checked v6 patches.
I have no objection. It looks good.
Thank you.

Best regards,
Jingoo Han

 
 Thanks,
 Andreas
 
 [0] https://patchwork.kernel.org/patch/4664691/
 
 --
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body

Re: [PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Jingoo Han
On Tuesday, August 05, 2014 7:39 PM, Vivek Gautam wrote:
 
 Since we want to keep support for both older usb-phys as well as the
 newer generic phys, lets first get the generic PHYs and fallback to
 older USB-PHYs only when we fail to get the former.
 This should fix the issue with ehci-exynos and ohci-exynos, wherein
 in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
 the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
 are not configured properly.
 
 Reported-by: Sachin Kamat sachin.ka...@samsung.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Right, we would get the generic PHYs first, then get the older
usb-phys. Then, the older one will be removed from the kernel.
Thank you.

Best regards,
Jingoo Han

 ---
 
 Based on 'usb-next' branch.
 Resending it after adding 'Reported-by' tag.
 
  drivers/usb/host/ehci-exynos.c |   40 +-
  drivers/usb/host/ohci-exynos.c |   47 
 +++-
  2 files changed, 42 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index cda0a2f..2eed9a4 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -62,18 +62,6 @@ static int exynos_ehci_get_phy(struct device *dev,
   int phy_number;
   int ret = 0;
 
 - 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;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ehci-otg = exynos_ehci-phy-otg;
 - }
 -
   for_each_available_child_of_node(dev-of_node, child) {
   ret = of_property_read_u32(child, reg, phy_number);
   if (ret) {
 @@ -90,15 +78,27 @@ static int exynos_ehci_get_phy(struct device *dev,
 
   phy = devm_of_phy_get(dev, child, NULL);
   of_node_put(child);
 - if (IS_ERR(phy)) {
 - ret = PTR_ERR(phy);
 - if (ret != -ENOSYS  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - }
 + 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;
 + }
 + dev_dbg(dev, Failed to get usb2 phy\n);
 + } else {
 + exynos_ehci-otg = exynos_ehci-phy-otg;
   }
 
   return ret;
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index a72ab8f..7c48e3f 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -51,27 +51,12 @@ static int exynos_ohci_get_phy(struct device *dev,
   int phy_number;
   int ret = 0;
 
 - 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;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ohci-otg = exynos_ohci-phy-otg;
 - }
 -
   /*
* 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.
 -  * If there are existing devices using DTB files built from them,
 -  * to remove the support for old bindings in this driver,
 -  * we need to make sure that such devices have their DTBs
 -  * updated to ones built from new DTS.
 +  * with old DTB too.
 +  * We fallback to older USB-PHYs when we fail to get generic PHYs.
*/
   for_each_available_child_of_node(dev-of_node, child) {
   ret = of_property_read_u32(child, reg, phy_number);
 @@ -89,15 +74,27 @@ static int exynos_ohci_get_phy(struct device *dev,
 
   phy = devm_of_phy_get(dev

Re: [PATCH v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

2014-08-05 Thread Jingoo Han
On Saturday, August 02, 2014 5:57 AM, Tomasz Figa wrote:
 On 01.08.2014 22:54, Andreas Färber wrote:
  Am 01.08.2014 22:33, schrieb Doug Anderson:
  On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
  Spring uses a different GPIO, so this is not a generic SoC piece.
 
  Suggested-by: Tomasz Figa t.f...@samsung.com
  Signed-off-by: Andreas Färber afaer...@suse.de
  ---
   v5: New (Tomasz Figa)
   Frees dp_hpd for Spring.
 
   arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
   arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
   arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
   3 files changed, 16 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
  b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  index 886cfca044ac..ed0e5230514b 100644
  --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  @@ -581,13 +581,6 @@
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  -
  -   dp_hpd: dp_hpd {
  -   samsung,pins = gpx0-7;
  -   samsung,pin-function = 3;
  -   samsung,pin-pud = 0;
  -   samsung,pin-drv = 0;
  -   };
  };
 
  pinctrl@1340 {
  diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
  b/arch/arm/boot/dts/exynos5250-smdk5250.dts
  index aaa055ac0fe3..5d30fe1dcda4 100644
  --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
  +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
  @@ -414,3 +414,12 @@
  };
  };
   };
  +
  +pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +};
  diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
  b/arch/arm/boot/dts/exynos5250-snow.dts
  index c4b0c73c736d..a9a2f2743794 100644
  --- a/arch/arm/boot/dts/exynos5250-snow.dts
  +++ b/arch/arm/boot/dts/exynos5250-snow.dts
  @@ -547,6 +547,13 @@
   };
 
   pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
 
  NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
  Pin function 3 is special function.  This pin _is_ the hot plug detect
  pin for display port.  When it's set as special function 3 it goes
  straight into the hot plug logic of the display port controller.
 
  Spring may have had its reasons to detect hot plug events on a GPIO
  instead of using this pin, but that doesn't make this pin any less the
  hot plug pin.
 
  Please advise how to handle it then: Should there be two different
  pinctrl entries (if so, how should it be named?),
 
 IMHO this is the right way. Just name the GPIO variant dp_hpd_gpio.

Hi Andreas Färber,

I agree with Tomasz Figa and Doug Anderson.
Please refer to the following.

1. case: Standard HPD pin is used. (smdk5420)
arch/arm/boot/dts/exynos5420-pinctrl.dts
pinctrl@1340 {
dp_hpd: dp_hpd {
samsung,pins = gpx0-7;
samsung,pin-function = 3;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
arch/arm/boot/dts/exynos5420-smdk5420.dts
dp-controller@145B {
pinctrl-names = default;
pinctrl-0 = dp_hpd;
...

2. case: non-standard HPD pin such as GPIO is used. (peach pit)
arch/arm/boot/dts/exynos5420-peach-pit.dts
pinctrl@1340 {
dp_hpd_gpio: dp_hpd_gpio {
samsung,pins = gpx2-6;
samsung,pin-function = 0;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
dp-controller@145B {
pinctrl-names = default;
pinctrl-0 = dp_hpd_gpio;
...
samsung,hpd-gpio = gpx2 6 0;

So, you need to follow the second case.
dp_hpd_gpio can be used for Spring board.

Best regards,
Jingoo Han

--
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 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs

2014-07-08 Thread Jingoo Han
On Wednesday, July 09, 2014 12:42 PM, Sachin Kamat wrote:
 On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa t.f...@samsung.com wrote:
  On 30.06.2014 10:56, Sachin Kamat wrote:
  Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers,
 
  That's not true. They are also required for USB gadget controller
  supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the
  change makes sense to me.
 
 Do you propose I amend just the patch description or also add a dependency on
 USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based
 on your input I will re-spin the patch.

I agree with Tomasz Figa's statement. Personally, I think that it would
be good to amend the commit message and add a dependency on USB_DWC2. :-)
Thank you.

Best regards,
Jingoo Han

 
 --
 Regards,
 Sachin.

--
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] clk: samsung: Make of_device_id array const

2014-06-30 Thread Jingoo Han
On Thursday, June 26, 2014 9:00 PM, Krzysztof Kozlowski wrote:
 
 Array of struct of_device_id may be be const as expected by
 of_match_table field and of_find_matching_node_and_match() function.
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/clk/samsung/clk-exynos4.c| 2 +-
  drivers/clk/samsung/clk-exynos5250.c | 2 +-
  drivers/clk/samsung/clk-exynos5420.c | 2 +-
  drivers/clk/samsung/clk-exynos5440.c | 2 +-
  drivers/clk/samsung/clk.c| 2 +-
  drivers/clk/samsung/clk.h| 2 +-
  6 files changed, 6 insertions(+), 6 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


Re: [PATCH 06/17] video: fbdev: s3c-fb: remove s5p64x0 related fimd codes

2014-06-30 Thread Jingoo Han
On Tuesday, July 01, 2014 6:32 AM, Kukjin Kim wrote:
 
 This patch removes fimd codes for s5p6440 and s5p6450 SoCs.
 
 Signed-off-by: Kukjin Kim kgene@samsung.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  .../devicetree/bindings/video/samsung-fimd.txt |1 -
  drivers/video/fbdev/Kconfig|2 +-
  drivers/video/fbdev/s3c-fb.c   |   30 
 
  3 files changed, 1 insertion(+), 32 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
 b/Documentation/devicetree/bindings/video/samsung-fimd.txt
 index 2dad41b..741f4a6 100644
 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
 +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
 @@ -8,7 +8,6 @@ Required properties:
  - compatible: value should be one of the following
   samsung,s3c2443-fimd; /* for S3C24XX SoCs */
   samsung,s3c6400-fimd; /* for S3C64XX SoCs */
 - samsung,s5p6440-fimd; /* for S5P64X0 SoCs */
   samsung,s5pc100-fimd; /* for S5PC100 SoC  */
   samsung,s5pv210-fimd; /* for S5PV210 SoC */
   samsung,exynos4210-fimd; /* for Exynos4 SoCs */
 diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
 index 59c98bfd..11506e5 100644
 --- a/drivers/video/fbdev/Kconfig
 +++ b/drivers/video/fbdev/Kconfig
 @@ -2018,7 +2018,7 @@ config FB_TMIO_ACCELL
 
  config FB_S3C
   tristate Samsung S3C framebuffer support
 - depends on FB  (CPU_S3C2416 || ARCH_S3C64XX || ARCH_S5P64X0 || \
 + depends on FB  (CPU_S3C2416 || ARCH_S3C64XX || \
   ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS)
   select FB_CFB_FILLRECT
   select FB_CFB_COPYAREA
 diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
 index 62acae2..a0cde41 100644
 --- a/drivers/video/fbdev/s3c-fb.c
 +++ b/drivers/video/fbdev/s3c-fb.c
 @@ -1970,33 +1970,6 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
   },
  };
 
 -static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
 - .variant = {
 - .nr_windows = 3,
 - .vidtcon= VIDTCON0,
 - .wincon = WINCON(0),
 - .winmap = WINxMAP(0),
 - .keycon = WKEYCON,
 - .osd= VIDOSD_BASE,
 - .osd_stride = 16,
 - .buf_start  = VIDW_BUF_START(0),
 - .buf_size   = VIDW_BUF_SIZE(0),
 - .buf_end= VIDW_BUF_END(0),
 -
 - .palette = {
 - [0] = 0x2400,
 - [1] = 0x2800,
 - [2] = 0x2c00,
 - },
 -
 - .has_blendcon   = 1,
 - .has_fixvclk= 1,
 - },
 - .win[0] = s3c_fb_data_s5p_wins[0],
 - .win[1] = s3c_fb_data_s5p_wins[1],
 - .win[2] = s3c_fb_data_s5p_wins[2],
 -};
 -
  static struct platform_device_id s3c_fb_driver_ids[] = {
   {
   .name   = s3c-fb,
 @@ -2016,9 +1989,6 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
   }, {
   .name   = s3c2443-fb,
   .driver_data= (unsigned long)s3c_fb_data_s3c2443,
 - }, {
 - .name   = s5p64x0-fb,
 - .driver_data= (unsigned long)s3c_fb_data_s5p64x0,
   },
   {},
  };
 --
 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 V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

2014-06-29 Thread Jingoo Han
On Friday, June 27, 2014 10:03 PM, Ajay kumar wrote:
 On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda a.ha...@samsung.com wrote:
  On 06/27/2014 01:48 PM, Ajay kumar wrote:
  On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda a.ha...@samsung.com wrote:
  +CC DT
 
  On 06/27/2014 12:12 PM, Ajay Kumar wrote:
  Add the missing setting for DP CLKCON register.
 
  This register is present on Exynos5 based FIMD controllers,
  and needs to be set if we are using DP.
 
  Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
  ---
   .../devicetree/bindings/video/samsung-fimd.txt |1 +
   drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
  
   include/video/samsung_fimd.h   |4 
   3 files changed, 28 insertions(+)

[.]

   static const struct of_device_id fimd_driver_dt_match[] = {
  @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager 
  *mgr)
if (clkdiv  1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
 
  + if (ctx-driver_data-has_dp_clkcon 
  + ctx-exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
  + writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
  +
writel(val, ctx-regs + VIDCON0);
 
  New code should not split VIDCON0 related code.It should be moved few
  lines above or few lines below.
 Ok, for better readability.
 
  Anyway this code should be rather placed in power related functions of
  dp encoder, as it enables dp. The only question
  is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
  solution of the whole problem
 I will check this.
 
  seems to be simple:
  - fimd should provide function fimd_set_dp_clk_gate or sth similar,
  - this function should be called in exynos_dp_poweron/exynos_dp_poweroff.
  I hope I have not missed anything this time.
 But, it won't look good to export a FIMD function which sets a FIMD register,
 and call it in DP driver!
 What does Inki/Jingoo have to say about this?

I agree with Ajay Kumar's opinion.
It doesn't look good to export the function to set FIMD register
and call it by DP driver.

Best regards,
Jingoo Han
 
 Regards,
 Ajay
 
[]

--
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] drm/exynos: Support DP CLKCON register in FIMD driver

2014-06-26 Thread Jingoo Han
On Thursday, June 26, 2014 11:37 PM, Ajay Kumar wrote:
 
 Add the missing setting for DP CLKCON register.
 
 This register is present on Exynos5 based FIMD controllers,
 and needs to be used if we are using DP.
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

It looks better than V1 patch.

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 Changes since V1:
  - Remove usage of driver_data to configure DP CLKCON register
  drivers/gpu/drm/exynos/exynos_dp_core.c  | 2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.h  | 8 
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +
  include/video/samsung_fimd.h | 4 
  4 files changed, 19 insertions(+)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 2e77a15..d8868f3 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1336,6 +1336,8 @@ static int exynos_dp_bind(struct device *dev, struct 
 device *master, void *data)
 
   platform_set_drvdata(pdev, exynos_dp_display);
 
 + exynos_fimd_output_type = EXYNOS_FIMD_OUTPUT_DP;
 +
   return exynos_drm_create_enc_conn(drm_dev, exynos_dp_display);
  }
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 36535f3..1089744 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -60,6 +60,12 @@ enum exynos_drm_output_type {
   EXYNOS_DISPLAY_TYPE_VIDI,
  };
 
 +enum exynos_fimd_output_type {
 + EXYNOS_FIMD_OUTPUT_MIPI,
 + EXYNOS_FIMD_OUTPUT_DPI,
 + EXYNOS_FIMD_OUTPUT_DP,
 +};
 +
  /*
   * Exynos drm common overlay structure.
   *
 @@ -380,4 +386,6 @@ extern struct platform_driver fimc_driver;
  extern struct platform_driver rotator_driver;
  extern struct platform_driver gsc_driver;
  extern struct platform_driver ipp_driver;
 +
 +extern enum exynos_fimd_output_type exynos_fimd_output_type;
  #endif
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index bb45ab2..a46a9c4 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -90,6 +90,8 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
   .has_shadowcon = 1,
  };
 
 +enum exynos_fimd_output_type exynos_fimd_output_type;
 +
  struct fimd_win_data {
   unsigned intoffset_x;
   unsigned intoffset_y;
 @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
   if (clkdiv  1)
   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
 
 + if (exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
 + writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
 +
   writel(val, ctx-regs + VIDCON0);
  }
 
 diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
 index b039320..d8f4b0b 100644
 --- a/include/video/samsung_fimd.h
 +++ b/include/video/samsung_fimd.h
 @@ -435,6 +435,10 @@
  #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1  0)
  #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0  0)
 
 +/* Video clock enable for DP */
 +#define DP_CLKCON0x27C
 +#define DP_CLK_ENABLE0x2
 +
  /* Notes on per-window bpp settings
   *
   * Value Win0 Win1 Win2 Win3 Win 4
 --
 1.8.3.2


--
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] drm/exynos: Support DP CLKCON register in FIMD driver

2014-06-24 Thread Jingoo Han
On Tuesday, June 24, 2014 11:15 PM, Andrzej Hajda wrote:
 On 06/24/2014 03:14 PM, Ajay kumar wrote:
  On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda a.ha...@samsung.com wrote:
  Hi Ajay,
 
  On 06/24/2014 01:09 PM, Ajay Kumar wrote:
  Add the missing setting for DP CLKCON register.
 
  This register is present on Exynos5 based FIMD controllers,
  and needs to be used if we are using DP.
 
  Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
  ---
   drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
   include/video/samsung_fimd.h |4 
   2 files changed, 9 insertions(+)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
  b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  index 33161ad..5d3045d 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
  @@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
  + unsigned int has_dp_clkcon:1;
   };
 
   static struct fimd_driver_data s3c64xx_fimd_driver_data = {
  @@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data 
  = {
   static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
  + .has_dp_clkcon = 1,
   };
 
   struct fimd_win_data {
  @@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager 
  *mgr)
if (clkdiv  1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
 
  + if (ctx-driver_data-has_dp_clkcon)
  + writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
  +
  This code always enables the clock on exynos5. As I understand it should
  be enabled only if DP is used.
  Right!
  But, when I searched for the display interface,
  only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
  So, I thought adding this in driver_data for exynos5 should be fine.

No, it should be selectable. Even some exynos5 based boards use MIPI LCD.

 
 Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.
 
 
  Inki/Andrej - Shall I add it as an optional DT property?
 
 No, property is redundant. The simplest solution could be to use
 CONFIG_DRM_EXYNOS_DP
 macro but it is quite ugly.

Right, CONFIG_DRM_EXYNOS_DP is the simplest. But, the macro doesn't
look good.

 I guess extending little bit exynos_drm framework to allow detection of
 DP in fimd would be better.

I agree on Andrzej's opinion.

Best regards,
Jingoo Han

 
 Regards
 Andrzej
 
 
  Ajay
 
writel(val, ctx-regs + VIDCON0);
   }
 
  diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
  index b039320..d8f4b0b 100644
  --- a/include/video/samsung_fimd.h
  +++ b/include/video/samsung_fimd.h
  @@ -435,6 +435,10 @@
   #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1  0)
   #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0  0)
 
  +/* Video clock enable for DP */
  +#define DP_CLKCON0x27C
  +#define DP_CLK_ENABLE0x2
  +
   /* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 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] drm/exynos: dpi: Fix NULL pointer dereference with legacy bindings

2014-06-17 Thread Jingoo Han
On Wednesday, June 11, 2014 5:58 AM, Tomasz Figa wrote:
 
 If there is no panel node in DT and instead display timings are provided
 directly in FIMD node, there is no panel object created and ctx-panel
 becomes NULL. However during Exynos DRM initialization
 drm_helper_hpd_irq_event() is called, which in turns calls
 exynos_dpi_detect(), which dereferences ctx-panel without a check,
 causing a NULL pointer derefrence.
 
 This patch fixes the issue by adding necessary NULL pointer check.
 
 Signed-off-by: Tomasz Figa tomasz.f...@gmail.com

(+cc Inki Dae)

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 index f1b8587..f44bd90 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
 @@ -40,7 +40,7 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
 force)
  {
   struct exynos_dpi *ctx = connector_to_dpi(connector);
 
 - if (!ctx-panel-connector)
 + if (ctx-panel  !ctx-panel-connector)
   drm_panel_attach(ctx-panel, ctx-connector);
 
   return connector_status_connected;
 --

--
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] usb: ehci-exynos: Make provision for vdd regulators

2014-06-11 Thread Jingoo Han
On Thursday, June 12, 2014 12:39 AM, Alan Stern wrote:
 On Fri, 6 Jun 2014, Vivek Gautam wrote:
 
  Facilitate getting required 3.3V and 1.0V VDD supply for
  EHCI controller on Exynos.
 
  With 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,
 
  certain perripherals will now need to ensure that,
  they request VDD regulators in their drivers, and enable
  them so as to make them working.
 
 Certain peripherals?  Don't you mean certain controllers?
 
 Does this mean some controllers don't need to use the VDD regulators?
 
  @@ -193,7 +196,31 @@ 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(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;
  +   }
  +   } else {
  +   dev_warn(pdev-dev, Regulator 3.3V Vdd supply not found\n);
  +   }
 
 What if this is one of the controllers that don't need to use a VDD
 regulator?  Do you really want to print out a warning in that case?
 Should you call devm_regulator_get_optional() instead?

I agree with Alan's suggestion. This warning message is not
proper, when USB controllers that don't need a VDD regulator
are used. The devm_regulator_get_optional() looks better.

Best regards,
Jingoo Han


--
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 1/1] PCI: exynos: Fix section mismatch warning

2014-05-29 Thread Jingoo Han
On Wednesday, May 28, 2014 6:49 PM, Sachin Kamat wrote:
 
 add_pcie_port is called from probe which is annotated with __init.
 add_pcie_port calls dw_pcie_host_init which is also annotated with
 __init. Thus it makes sense to annotate add_pcie_port with __init
 to avoid the following section mismatch warning:
 
 WARNING: drivers/pci/built-in.o(.text.unlikely+0xf8): Section mismatch in 
 reference from the function
 add_pcie_port() to the function .init.text:dw_pcie_host_init()
The function add_pcie_port() references
the function __init dw_pcie_host_init().
This is often because add_pcie_port lacks a __init
annotation or the annotation of dw_pcie_host_init is wrong.
 
 Reported-by: kbuild test robot fengguang...@intel.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/pci/host/pci-exynos.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
 index 3de6bfbbe8e9..3c1ff89829ec 100644
 --- a/drivers/pci/host/pci-exynos.c
 +++ b/drivers/pci/host/pci-exynos.c
 @@ -511,7 +511,8 @@ static struct pcie_host_ops exynos_pcie_host_ops = {
   .host_init = exynos_pcie_host_init,
  };
 
 -static int add_pcie_port(struct pcie_port *pp, struct platform_device *pdev)
 +static int __init add_pcie_port(struct pcie_port *pp,
 + struct platform_device *pdev)
  {
   int ret;
 
 --
 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


Re: [PATCH] drm/exynos: hdmi: remove the i2c drivers and use devtree - continued

2014-05-29 Thread Jingoo Han
On Friday, May 30, 2014 1:42 AM, Tomasz Figa wrote:
 On 29.05.2014 18:36, Lee Jones wrote:
  There appears to have been a merge error on commit:
 
2b76813: drm/exynos: hdmi: remove the i2c drivers and use
 
  The original submission can be found at:
 
https://patchwork.kernel.org/patch/3559541/
 
  It looks like the commit was only half applied.  This patch aims
  to finish what was started by Daniel.

(+cc Inki Dae)

Hi Lee Jones,

A similar patch was already applied to drm-exynos git. [1]
However, 'drivers/gpu/drm/exynos/exynos_hdmi.h' was not
removed yet. Thus, additional patch to remove this
'exynos_hdmi.h' should be submitted. Thank you.


[1]
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-nextid=73c0a75ca9919c12525fd02eb49f9c3a34e0
d2d9

Best regards,
Jingoo Han

 
  Signed-off-by: Lee Jones lee.jo...@linaro.org
  ---
   drivers/gpu/drm/exynos/exynos_ddc.c | 63 
  
   drivers/gpu/drm/exynos/exynos_hdmi.h| 23 
   drivers/gpu/drm/exynos/exynos_hdmiphy.c | 65 
  -
   3 files changed, 151 deletions(-)
   delete mode 100644 drivers/gpu/drm/exynos/exynos_ddc.c
   delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h
   delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c
 
 
 Obviously there is nothing to review, but still:
 
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 
 Thanks for the patch.
 
 Best regards,
 Tomasz

--
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] drm/exynos: remove unnecessary exynos_hdmi.h file

2014-05-29 Thread Jingoo Han
The exynos_hdmi.h has been used for the dedicated i2c drivers
that were already removed. Thus, the unnecessary exynos_hdmi.h
should be removed.

Signed-off-by: Jingoo Han jg1@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.h |   23 ---
 1 file changed, 23 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_hdmi.h
deleted file mode 100644
index 0ddf395..000
--- a/drivers/gpu/drm/exynos/exynos_hdmi.h
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * Authors:
- * Inki Dae inki@samsung.com
- * Seung-Woo Kim sw0312@samsung.com
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#ifndef _EXYNOS_HDMI_H_
-#define _EXYNOS_HDMI_H_
-
-void hdmi_attach_ddc_client(struct i2c_client *ddc);
-void hdmi_attach_hdmiphy_client(struct i2c_client *hdmiphy);
-
-extern struct i2c_driver hdmiphy_driver;
-extern struct i2c_driver ddc_driver;
-
-#endif
-- 
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 5/5] ARM: dts: Update watchdog node name in exynos5440.dtsi

2014-05-23 Thread Jingoo Han
On Friday, May 23, 2014 3:09 PM, Sachin Kamat wrote:
 
 Made it as per DT node naming convention name@reg_addr.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5440.dtsi |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 84f77c2fe4d4..ae3a17c791f6 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -176,7 +176,7 @@
   clock-names = i2c;
   };
 
 - watchdog {
 + watchdog@11 {
   compatible = samsung,s3c2410-wdt;
   reg = 0x11 0x1000;
   interrupts = 0 1 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


Re: [PATCH 1/2] ARM: dts: enable display controller for exynos5800 based peach-pi board

2014-05-12 Thread Jingoo Han
On Monday, May 12, 2014 3:45 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable display controller with timing information for 1080p
 panel in Exynos5800 peach-pi board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5800-peach-pi.dts |   36 
 +
  1 file changed, 36 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
 b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 index 742655b..426705a 100644
 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
 +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 @@ -72,6 +72,13 @@
   samsung,pin-pud = 0;
   samsung,pin-drv = 0;
   };
 +
 + dp_hpd_gpio: dp_hpd_gpio {
 + samsung,pins = gpx2-6;
 + samsung,pin-function = 0;
 + samsung,pin-pud = 3;
 + samsung,pin-drv = 0;
 + };
  };
 
  rtc {
 @@ -121,6 +128,35 @@
   };
  };
 
 +dp {
 + status = okay;
 + pinctrl-names = default;
 + pinctrl-0 = dp_hpd_gpio;
 + samsung,color-space = 0;
 + samsung,dynamic-range = 0;
 + samsung,ycbcr-coeff = 0;
 + samsung,color-depth = 1;
 + samsung,link-rate = 0x0a;
 + samsung,lane-count = 2;
 + samsung,hpd-gpio = gpx2 6 0;
 +
 + display-timings {
 + native-mode = timing1;
 +
 + timing1: timing@1 {
 + clock-frequency = 15066;
 + hactive = 1920;
 + vactive = 1080;
 + hfront-porch = 60;
 + hback-porch = 172;
 + hsync-len = 80;
 + vback-porch = 25;
 + vfront-porch = 10;
 + vsync-len = 10;
 + };
 + };
 +};
 +
  hsi2c_9 {
   status = okay;
   clock-frequency = 40;
 --
 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


Re: [PATCH 2/2] ARM: dts: enable fimd for exynos5800 based peach-pi board

2014-05-12 Thread Jingoo Han
On Monday, May 12, 2014 3:45 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable FIMD for peach-pi board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
 b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 index 426705a..cccacdd 100644
 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
 +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 @@ -157,6 +157,11 @@
   };
  };
 
 +fimd {
 + status = okay;
 + samsung,invert-vclk;
 +};
 +
  hsi2c_9 {
   status = okay;
   clock-frequency = 40;
 --
 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


Re: [PATCH] crypto: s5p-sss: fix multiplatform build

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 8:36 PM, Arnd Bergmann wrote:
 
 As we are preparing to enable multiplatform support on EXYNOS,
 we can no longer include mach/*.h or plat/*.h headers from device
 drivers.
 
 The s5p-sss driver was just enabled for EXYNOS when it used to
 be used only on s5pv210, and it includes two samsung platform
 specific header files for historic reasons. Fortunately, it no
 longer actually needs them, so we can remove the #includes and
 avoid the problem
 
 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
 Cc: Tomasz Figa t.f...@samsung.com
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: Vladimir Zapolskiy v...@mleia.com
 Cc: Herbert Xu herb...@gondor.apana.org.au

I checked that these machine specific headers are
unnecessary. Thanks!

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 Please apply on top of the other s5p-sss patches
 
 diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
 index 47c568e..4197ad9 100644
 --- a/drivers/crypto/s5p-sss.c
 +++ b/drivers/crypto/s5p-sss.c
 @@ -30,9 +30,6 @@
  #include crypto/aes.h
  #include crypto/ctr.h
 
 -#include plat/cpu.h
 -#include mach/dma.h
 -
  #define _SBF(s, v)  ((v)  (s))
  #define _BIT(b) _SBF(b, 1)
 
 
 --

--
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 v3 0/4] ARM: dts: enable display for peach-pit and snow boards

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 7:16 PM, Rahul Sharma wrote:
 
 + Jingoo Han.

If you want to get Acked-by from maintainer, please add the
maintainer to CC list for all patches.

Anyway, I will review this patch. However, if you don't add me
to CC list in the future, I am not sure that I will review
your patches.

Best regards,
Jingoo Han

 
 On 9 May 2014 15:39, Rahul Sharma rahul.sha...@samsung.com wrote:
  From: Rahul Sharma rahul.sha...@samsung.com
 
  Add nodes for fimd and dp controller for exynos5250 based snow
  and exynos5420 based peach-pit board.
 
  This series is based on Kukjin Kims, for-next branch.
 
  V3:
  1) Dropped 1 patch ARM: dts: move dp hpd line to the board file for
   exynos5420.
  2) Extra blank lines for readability.
  3) dp hpd gpio name change (dp_hpd - dp_hpd_gpio)
 
  V2:
  1) Rebase on Peach-pit dependent patches.
 
  It is dependent on
  1) Andrew Bresticker's patch for hpd gpio addition, avilable at
  http://www.spinics.net/lists/linux-samsung-soc/msg28827.html [Patch is 
  'ACK'ed.]
  2) Arun's patch for adding peach-pit board dts file at
  http://www.spinics.net/lists/linux-samsung-soc/msg30103.html. [Patch is 
  'ACK'ed.]
 
  Rahul Sharma (4):
ARM: dts: enable fimd for exynos5250 based snow board
ARM: dts: enable dp-controller for exynos5250 based snow board
ARM: dts: enable fimd for exynos5420 based peach-pit board
ARM: dts: enable dp-controller for exynos5420 based peach-pit board
 
   arch/arm/boot/dts/exynos5250-snow.dts  |   35 
   arch/arm/boot/dts/exynos5420-peach-pit.dts |   41 
  
   2 files changed, 76 insertions(+)
 
  --
  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


Re: [PATCH v3 1/4] ARM: dts: enable fimd for exynos5250 based snow board

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 7:10 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable fimd node for snow board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5250-snow.dts |6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 1ce1088..796954c 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -206,4 +206,10 @@
   clock-frequency = 2400;
   };
   };
 +
 + fimd@1440 {
 + status = okay;
 + samsung,invert-vclk;
 + };
 +
  };
 --
 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


Re: [PATCH v3 3/4] ARM: dts: enable fimd for exynos5420 based peach-pit board

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 7:10 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable fimd for peach-pit board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
 b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 index fae33dd..f75da5b 100644
 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
 +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 @@ -145,3 +145,8 @@
  watchdog {
   timeout-sec = 32;
  };
 +
 +fimd {
 + status = okay;
 + samsung,invert-vclk;
 +};
 --
 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


Re: [PATCH v3 2/4] ARM: dts: enable dp-controller for exynos5250 based snow board

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 7:10 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable dp-controller for snow board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5250-snow.dts |   29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 796954c..7b10e32 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -207,6 +207,35 @@
   };
   };
 
 + dp-controller@145B {
 + status = okay;
 + pinctrl-names = default;
 + pinctrl-0 = dp_hpd;
 + samsung,color-space = 0;
 + samsung,dynamic-range = 0;
 + samsung,ycbcr-coeff = 0;
 + samsung,color-depth = 1;
 + samsung,link-rate = 0x0a;
 + samsung,lane-count = 2;
 + samsung,hpd-gpio = gpx0 7 0;
 +
 + display-timings {
 + native-mode = timing1;
 +
 + timing1: timing@1 {
 + clock-frequency = 70589280;
 + hactive = 1366;
 + vactive = 768;
 + hfront-porch = 40;
 + hback-porch = 40;
 + hsync-len = 32;
 + vback-porch = 10;
 + vfront-porch = 12;
 + vsync-len = 6;
 + };
 + };
 + };
 +
   fimd@1440 {
   status = okay;
   samsung,invert-vclk;
 --
 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


Re: [PATCH v3 4/4] ARM: dts: enable dp-controller for exynos5420 based peach-pit board

2014-05-11 Thread Jingoo Han
On Friday, May 09, 2014 7:10 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable dp-controller for peach-pit board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts |   36 
 
  1 file changed, 36 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
 b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 index f75da5b..0e79479 100644
 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
 +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 @@ -74,6 +74,13 @@
   samsung,pin-pud = 0;
   samsung,pin-drv = 0;
   };
 +
 + dp_hpd_gpio: dp_hpd_gpio {
 + samsung,pins = gpx2-6;
 + samsung,pin-function = 0;
 + samsung,pin-pud = 3;
 + samsung,pin-drv = 0;
 + };
  };
 
  rtc {
 @@ -150,3 +157,32 @@
   status = okay;
   samsung,invert-vclk;
  };
 +
 +dp {
 + status = okay;
 + pinctrl-names = default;
 + pinctrl-0 = dp_hpd_gpio;
 + samsung,color-space = 0;
 + samsung,dynamic-range = 0;
 + samsung,ycbcr-coeff = 0;
 + samsung,color-depth = 1;
 + samsung,link-rate = 0x06;
 + samsung,lane-count = 2;
 + samsung,hpd-gpio = gpx2 6 0;
 +
 + display-timings {
 + native-mode = timing1;
 +
 + timing1: timing@1 {
 + clock-frequency = 70589280;
 + hactive = 1366;
 + vactive = 768;
 + hfront-porch = 40;
 + hback-porch = 40;
 + hsync-len = 32;
 + vback-porch = 10;
 + vfront-porch = 12;
 + vsync-len = 6;
 + };
 + };
 +};
 --
 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


Re: [PATCH 1/5] ARM: dts: move dp hpd line to the board file for exynos5420

2014-05-08 Thread Jingoo Han
On Sunday, April 20, 2014 8:49 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Display controller HPD Gpio line is board specific. This patch
 is moving the pinctrl for hpd gpio line to the respective board
 file.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 ---
  arch/arm/boot/dts/exynos5420-smdk5420.dts |7 +++
  2 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
 b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
 index e62c8eb..5848c42 100644
 --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
 +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
 @@ -59,13 +59,6 @@
   interrupt-controller;
   #interrupt-cells = 2;
   };
 -
 - dp_hpd: dp_hpd {
 - samsung,pins = gpx0-7;
 - samsung,pin-function = 3;
 - samsung,pin-pud = 0;
 - samsung,pin-drv = 0;
 - };
   };

(+cc Doug Anderson, Tomasz Figa)

'gpx0-7' pin is assigned for standard HPD pin. This is chip specific.
So, there should be gpx0-7 part on chip specific dts file such as
'exynos5420-pinctrl.dtsi'.

However, some boards use GPIO as HPD pin, instead of 'gpx0-7' pin.
This is board specific. In my opinion, the following would look
better. In this way, this patch is not necessary.

1. case: Standard HPD pin is used. (smdk5420)
arch/arm/boot/dts/exynos5420-pinctrl.dts
pinctrl@1340 {
dp_hpd: dp_hpd {
samsung,pins = gpx0-7;
samsung,pin-function = 3;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
arch/arm/boot/dts/exynos5420-smdk5420.dts
dp-controller@145B {
pinctrl-names = default;
pinctrl-0 = dp_hpd;
...


2. case: non-standard HPD pin such as GPIO is used. (peach pit)
arch/arm/boot/dts/exynos5420-peach-pit.dts
pinctrl@1340 {
dp_hpd: dp_hpd {
samsung,pins = gpx2-6;
samsung,pin-function = 0;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
dp-controller@145B {
pinctrl-names = default;
pinctrl-0 = dp_hpd;
...
samsung,hpd-gpio = gpx2 6 0;

Even though, there is 'dp_hpd' in exynos5420-pinctrl.dts,
'smdk5420' and 'peach pit' can use gpx0-7 and gpx2-6,
respectively.

A year ago, Doug Anderson and me agreed that standard HPD pin
part should be included to 'exynos5250-pinctrl.dtsi'.
(https://lkml.org/lkml/2013/5/11/134)

Best regards,
Jingoo Han

 
   pinctrl@1341 {
 diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
 b/arch/arm/boot/dts/exynos5420-smdk5420.dts
 index 6910485..62d38c8 100644
 --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
 +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
 @@ -138,6 +138,13 @@
   samsung,pin-pud = 1;
   samsung,pin-drv = 0;
   };
 +
 + dp_hpd: dp_hpd {
 + samsung,pins = gpx0-7;
 + samsung,pin-function = 3;
 + samsung,pin-pud = 0;
 + samsung,pin-drv = 0;
 + };
   };
 
   hdmi@1453 {
 --
 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


Re: [PATCH v2 2/5] ARM: dts: enable fimd for exynos5250 based snow board

2014-05-08 Thread Jingoo Han
On Thursday, May 08, 2014 3:20 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable fimd node for snow board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  arch/arm/boot/dts/exynos5250-snow.dts |6 ++
  1 file changed, 6 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 1ce1088..796954c 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -206,4 +206,10 @@
   clock-frequency = 2400;
   };
   };
 +
 + fimd@1440 {
 + status = okay;

(+cc Sachin Kamat, Tomasz Figa)

For readability, how about moving 'status' to the last entry of
the node? The same comment applies to other patches, too.

Best regards,
Jingoo Han

 + samsung,invert-vclk;
 + };
 +
  };
 --
 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


Re: [PATCH v2 3/5] ARM: dts: enable dp-controller for exynos5250 based snow board

2014-05-08 Thread Jingoo Han
On Thursday, May 08, 2014 3:20 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Enable dp-controller for snow board.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  arch/arm/boot/dts/exynos5250-snow.dts |   27 +++
  1 file changed, 27 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 796954c..28a755f 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -207,6 +207,33 @@
   };
   };
 
 + dp-controller@145B {
 + status = okay;
 + pinctrl-names = default;
 + pinctrl-0 = dp_hpd;
 + samsung,color-space = 0;
 + samsung,dynamic-range = 0;
 + samsung,ycbcr-coeff = 0;
 + samsung,color-depth = 1;
 + samsung,link-rate = 0x0a;
 + samsung,lane-count = 2;
 + samsung,hpd-gpio = gpx0 7 0;
 + display-timings {

For readability, please insert one line as below.

+   samsung,hpd-gpio = gpx0 7 0;
+
+   display-timings {

The same comment applies to the 5th patch.
([PATCH v2 5/5] ARM: dts: enable dp-controller for exynos5420
based peach-pit board)

Best regards,
Jingoo Han

 + native-mode = timing1;
 + timing1: timing@1 {
 + clock-frequency = 70589280;
 + hactive = 1366;
 + vactive = 768;
 + hfront-porch = 40;
 + hback-porch = 40;
 + hsync-len = 32;
 + vback-porch = 10;
 + vfront-porch = 12;
 + vsync-len = 6;
 + };
 + };
 + };
 +
   fimd@1440 {
   status = okay;
   samsung,invert-vclk;
 --
 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


Re: [PATCH 1/5] ARM: dts: move dp hpd line to the board file for exynos5420

2014-05-08 Thread Jingoo Han
On Thursday, May 08, 2014 6:08 PM, Rahul Sharma wrote:
 On 8 May 2014 12:02, Jingoo Han jg1@samsung.com wrote:
  On Sunday, April 20, 2014 8:49 PM, Rahul Sharma wrote:
 
  From: Rahul Sharma rahul.sha...@samsung.com
 
  Display controller HPD Gpio line is board specific. This patch
  is moving the pinctrl for hpd gpio line to the respective board
  file.
 
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
  ---
   arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 ---
   arch/arm/boot/dts/exynos5420-smdk5420.dts |7 +++
   2 files changed, 7 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
  b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  index e62c8eb..5848c42 100644
  --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
  @@ -59,13 +59,6 @@
interrupt-controller;
#interrupt-cells = 2;
};
  -
  - dp_hpd: dp_hpd {
  - samsung,pins = gpx0-7;
  - samsung,pin-function = 3;
  - samsung,pin-pud = 0;
  - samsung,pin-drv = 0;
  - };
};
 
  (+cc Doug Anderson, Tomasz Figa)
 
  'gpx0-7' pin is assigned for standard HPD pin. This is chip specific.
  So, there should be gpx0-7 part on chip specific dts file such as
  'exynos5420-pinctrl.dtsi'.
 
  However, some boards use GPIO as HPD pin, instead of 'gpx0-7' pin.
  This is board specific. In my opinion, the following would look
  better. In this way, this patch is not necessary.
 
  1. case: Standard HPD pin is used. (smdk5420)
  arch/arm/boot/dts/exynos5420-pinctrl.dts
  pinctrl@1340 {
  dp_hpd: dp_hpd {
  samsung,pins = gpx0-7;
  samsung,pin-function = 3;
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  arch/arm/boot/dts/exynos5420-smdk5420.dts
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd;
  ...
 
 
  2. case: non-standard HPD pin such as GPIO is used. (peach pit)
  arch/arm/boot/dts/exynos5420-peach-pit.dts
  pinctrl@1340 {
  dp_hpd: dp_hpd {
  samsung,pins = gpx2-6;
  samsung,pin-function = 0;
  samsung,pin-pud = 3;
  samsung,pin-drv = 0;
  };
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd;
  ...
  samsung,hpd-gpio = gpx2 6 0;
 
  Even though, there is 'dp_hpd' in exynos5420-pinctrl.dts,
  'smdk5420' and 'peach pit' can use gpx0-7 and gpx2-6,
  respectively.
 
  A year ago, Doug Anderson and me agreed that standard HPD pin
  part should be included to 'exynos5250-pinctrl.dtsi'.
  (https://lkml.org/lkml/2013/5/11/134)
 
 
 I wasn't aware of this discussion. It make sense. I will drop this patch.
 I need to choose some other name for this pin, say peach_dp_hpd.
 Let me know if any concern.

In my opinion, dp_hpd_gpio looks better as below.

arch/arm/boot/dts/exynos5420-peach-pit.dts
pinctrl@1340 {
dp_hpd_gpio: dp_hpd_gpio {
samsung,pins = gpx2-6;
samsung,pin-function = 0;
samsung,pin-pud = 3;
samsung,pin-drv = 0;
};
dp-controller@145B {
pinctrl-names = default;
pinctrl-0 = dp_hpd_gpio;
...
samsung,hpd-gpio = gpx2 6 0;

Best regards,
Jingoo Han

 
 Regards,
 Rahul Sharma.
 
  Best regards,
  Jingoo Han
 
 
pinctrl@1341 {
  diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
  b/arch/arm/boot/dts/exynos5420-smdk5420.dts
  index 6910485..62d38c8 100644
  --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
  +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
  @@ -138,6 +138,13 @@
samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
  +
  + dp_hpd: dp_hpd {
  + samsung,pins = gpx0-7;
  + samsung,pin-function = 3;
  + samsung,pin-pud = 0;
  + samsung,pin-drv = 0;
  + };
};
 
hdmi@1453 {
  --
  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


Re: [PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

2014-05-08 Thread Jingoo Han
On Tuesday, April 22, 2014 4:14 PM, Jingoo Han wrote:
 On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
 
  From: Andrew Bresticker abres...@chromium.org
 
  Certain bridge chips use a GPIO to indicate the cable status instead
  of the I_DP_HPD pin.  This adds an optional device-tree property,
  samsung,hpd-gpio, to the exynos-dp controller which indicates that
  the specified GPIO should be used for hotplug detection.
  The GPIO is then set up as an edge-triggered interrupt where the
  rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
 
  Signed-off-by: Andrew Bresticker abres...@chromium.org
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
  Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 
 Acked-by: Jingoo Han jg1@samsung.com

Hi Inki Dae,

Actually, this patch is NOT related to other patches for
bridge chip support. So, would you apply this patch into
your exynos drm git with my Acked-by?

Best regards,
Jingoo Han


 
  ---
  Changes since V1:
  Address reiew comments from Jingoo Han
 
   .../devicetree/bindings/video/exynos_dp.txt|4 ++
   drivers/gpu/drm/exynos/exynos_dp_core.c|   32 --
   drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
   drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 
  ++--
   4 files changed, 66 insertions(+), 15 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


Re: [PATCH 0/5] ARM: dts: enable display for peach-pit and snow boards

2014-05-07 Thread Jingoo Han
On Sunday, April 20, 2014 8:49 PM, Rahul Sharma wrote:
 
 From: Rahul Sharma rahul.sha...@samsung.com
 
 Add nodes for fimd and dp controller for exynos5250 based snow
 and exynos5420 based peach-pit board.
 
 This series is based on Kukjin Kims, for-next branch.
 
 It is dependent on
 1) Andrew Bresticker's patch for hpd gpio addition, avilable at
 http://www.spinics.net/lists/linux-samsung-soc/msg28827.html
 2) Arun's patch for adding peach-pit board dts file at
 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg28846.html.

One more thing. These patches were based against the following patches.

3) Rahul Sharma's patch for hdmi support for exynos5 based dt files.
([PATCH 0/7] ARM: dts: enable hdmi for exynos5 based peach and snow boards)
http://www.spinics.net/lists/linux-samsung-soc/msg29011.html

Please check the dependency.
Anyone does not want to waste the time, due to patch breakage.

Best regards,
Jingoo Han

 
 Rahul Sharma (5):
   ARM: dts: move dp hpd line to the board file for exynos5420
   ARM: dts: enable fimd for exynos5250 based snow board
   ARM: dts: enable dp-controller for exynos5250 based snow board
   ARM: dts: enable fimd for exynos5420 based peach-pit board
   ARM: dts: enable dp-controller for exynos5420 based peach-pit board
 
  arch/arm/boot/dts/exynos5250-snow.dts  |   32 +++
  arch/arm/boot/dts/exynos5420-peach-pit.dts |   39 
 
  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 -
  arch/arm/boot/dts/exynos5420-smdk5420.dts  |7 +
  4 files changed, 78 insertions(+), 7 deletions(-)
 
 --
 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


Re: [PATCH 1/4] usb: ohci-exynos: Use struct device instead of platform_device

2014-04-28 Thread Jingoo Han
On Monday, April 28, 2014 6:25 PM, Vivek Gautam wrote:
 
 Change to use struct device instead of struct platform_device
 for some static functions.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 Cc: Alan Stern st...@rowland.harvard.edu
 ---
  drivers/usb/host/ohci-exynos.c |   20 +---
  1 file changed, 9 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index 9cf80cb..05f00e3 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -39,18 +39,18 @@ struct exynos_ohci_hcd {
   struct usb_otg *otg;
  };
 
 -static void exynos_ohci_phy_enable(struct platform_device *pdev)
 +static void exynos_ohci_phy_enable(struct device *dev)
  {
 - struct usb_hcd *hcd = platform_get_drvdata(pdev);
 + struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
   if (exynos_ohci-phy)
   usb_phy_init(exynos_ohci-phy);
  }
 
 -static void exynos_ohci_phy_disable(struct platform_device *pdev)
 +static void exynos_ohci_phy_disable(struct device *dev)
  {
 - struct usb_hcd *hcd = platform_get_drvdata(pdev);
 + struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 
   if (exynos_ohci-phy)
 @@ -139,7 +139,7 @@ skip_phy:
 
   platform_set_drvdata(pdev, hcd);
 
 - exynos_ohci_phy_enable(pdev);
 + exynos_ohci_phy_enable(pdev-dev);
 
   err = usb_add_hcd(hcd, irq, IRQF_SHARED);
   if (err) {
 @@ -150,7 +150,7 @@ skip_phy:
   return 0;
 
  fail_add_hcd:
 - exynos_ohci_phy_disable(pdev);
 + exynos_ohci_phy_disable(pdev-dev);
  fail_io:
   clk_disable_unprepare(exynos_ohci-clk);
  fail_clk:
 @@ -168,7 +168,7 @@ static int exynos_ohci_remove(struct platform_device 
 *pdev)
   if (exynos_ohci-otg)
   exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
 
 - exynos_ohci_phy_disable(pdev);
 + exynos_ohci_phy_disable(pdev-dev);
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 @@ -190,7 +190,6 @@ static int exynos_ohci_suspend(struct device *dev)
  {
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 - struct platform_device *pdev = to_platform_device(dev);
   bool do_wakeup = device_may_wakeup(dev);
   int rc = ohci_suspend(hcd, do_wakeup);
 
 @@ -200,7 +199,7 @@ static int exynos_ohci_suspend(struct device *dev)
   if (exynos_ohci-otg)
   exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
 
 - exynos_ohci_phy_disable(pdev);
 + exynos_ohci_phy_disable(dev);
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 @@ -211,14 +210,13 @@ static int exynos_ohci_resume(struct device *dev)
  {
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 - struct platform_device *pdev= to_platform_device(dev);
 
   clk_prepare_enable(exynos_ohci-clk);
 
   if (exynos_ohci-otg)
   exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
 
 - exynos_ohci_phy_enable(pdev);
 + exynos_ohci_phy_enable(dev);
 
   ohci_resume(hcd, false);
 
 --
 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/4] usb: ehci-exynos: Use struct device instead of platform_device

2014-04-28 Thread Jingoo Han
On Monday, April 28, 2014 6:26 PM, Vivek Gautam wrote:
 
 Change to use struct device instead of struct platform_device
 for some static functions.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 Cc: Alan Stern st...@rowland.harvard.edu
 ---
  drivers/usb/host/ehci-exynos.c |5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index 7f425ac..4d763dc 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -50,9 +50,8 @@ struct exynos_ehci_hcd {
 
  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
 *)(hcd_to_ehci(hcd)-priv)
 
 -static void exynos_setup_vbus_gpio(struct platform_device *pdev)
 +static void exynos_setup_vbus_gpio(struct device *dev)
  {
 - struct device *dev = pdev-dev;
   int err;
   int gpio;
 
 @@ -88,7 +87,7 @@ static int exynos_ehci_probe(struct platform_device *pdev)
   if (err)
   return err;
 
 - exynos_setup_vbus_gpio(pdev);
 + exynos_setup_vbus_gpio(pdev-dev);
 
   hcd = usb_create_hcd(exynos_ehci_hc_driver,
pdev-dev, dev_name(pdev-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


Re: [PATCH 7/8] PCI: designware: make MSI isr shared irq aware

2014-04-27 Thread Jingoo Han
On Saturday, March 29, 2014 1:53 AM, Lucas Stach wrote:
 
 On i.MX6 the host controller MSI irq is shared
 with PCI legacy INTD. Make sure we don't bail too
 early from the irq handler.
 
 The issue is fairly theoretical as it would require
 a system setup with a PCIe switch where one connected
 device is using legacy INTD and another one using
 MSI, but better fix it now.
 
 Signed-off-by: Lucas Stach l.st...@pengutronix.de

(+cc Mohit KUMAR DCG, Pratyush ANAND)

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/pci/host/pci-exynos.c  | 4 +---
  drivers/pci/host/pcie-designware.c | 6 +-
  drivers/pci/host/pcie-designware.h | 2 +-
  3 files changed, 7 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
 index 3de6bfbbe8e9..b616d34922d8 100644
 --- a/drivers/pci/host/pci-exynos.c
 +++ b/drivers/pci/host/pci-exynos.c
 @@ -415,9 +415,7 @@ static irqreturn_t exynos_pcie_msi_irq_handler(int irq, 
 void *arg)
  {
   struct pcie_port *pp = arg;
 
 - dw_handle_msi_irq(pp);
 -
 - return IRQ_HANDLED;
 + return dw_handle_msi_irq(pp);
  }
 
  static void exynos_pcie_msi_init(struct pcie_port *pp)
 diff --git a/drivers/pci/host/pcie-designware.c 
 b/drivers/pci/host/pcie-designware.c
 index 98c118e04dba..cbce9b04b13d 100644
 --- a/drivers/pci/host/pcie-designware.c
 +++ b/drivers/pci/host/pcie-designware.c
 @@ -156,15 +156,17 @@ static struct irq_chip dw_msi_irq_chip = {
  };
 
  /* MSI int handler */
 -void dw_handle_msi_irq(struct pcie_port *pp)
 +irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
  {
   unsigned long val;
   int i, pos, irq;
 + irqreturn_t ret = IRQ_NONE;
 
   for (i = 0; i  MAX_MSI_CTRLS; i++) {
   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_STATUS + i * 12, 4,
   (u32 *)val);
   if (val) {
 + ret = IRQ_HANDLED;
   pos = 0;
   while ((pos = find_next_bit(val, 32, pos)) != 32) {
   irq = irq_find_mapping(pp-irq_domain,
 @@ -177,6 +179,8 @@ void dw_handle_msi_irq(struct pcie_port *pp)
   }
   }
   }
 +
 + return ret;
  }
 
  void dw_pcie_msi_init(struct pcie_port *pp)
 diff --git a/drivers/pci/host/pcie-designware.h 
 b/drivers/pci/host/pcie-designware.h
 index 3063b3594d88..a169d22d517e 100644
 --- a/drivers/pci/host/pcie-designware.h
 +++ b/drivers/pci/host/pcie-designware.h
 @@ -68,7 +68,7 @@ struct pcie_host_ops {
 
  int dw_pcie_cfg_read(void __iomem *addr, int where, int size, u32 *val);
  int dw_pcie_cfg_write(void __iomem *addr, int where, int size, u32 val);
 -void dw_handle_msi_irq(struct pcie_port *pp);
 +irqreturn_t dw_handle_msi_irq(struct pcie_port *pp);
  void dw_pcie_msi_init(struct pcie_port *pp);
  int dw_pcie_link_up(struct pcie_port *pp);
  void dw_pcie_setup_rc(struct pcie_port *pp);
 --
 1.9.0

--
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 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-24 Thread Jingoo Han
On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
 On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
  On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
  On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
   On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
   
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
   
With 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,
   
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
   
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
   
Based on 'usb-next' branch of Greg's usb tree.
   
 drivers/usb/host/ohci-exynos.c |   47

 1 file changed, 47 insertions(+)
   
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
 
 [snip]
 
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
  exynos_ohci-otg = phy-otg;
  }
   
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
  
   Do we need to skip regulator settings together with PHY configuration
   in case of exynos5440?
 
  Oh, right. In the case of exynos5440, regulator settings is not
  necessary. Vivek, would you fix it in order skip regulator settings
  in exynos5440? It also applies to ehci-exynos.
 
  Sorry, in the case of exynos5440, this patch already skips
  regulator settings.
 
  In the case of exynos5440, there is no need to set PHY setting
  and regulator setting.
 
 Right, in case of exynos5440, we are skipping PHY setting and regulator 
 setting.
 Actually i had missed taking into account 5440, so just curious. Do we
 really not need a regulator
 settings for Exynos5440 ?

To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.

Best regards,
Jingoo Han

  How about making regulator setting optional?
  Then, regulator setting can be done, only when regulator
  is supported.
 
 True, so with Exynos5440 not needing the regulator, we should make the
 regulator settings optional.

[.]

 Thanks for the suggestion.
 I will make the required changes, and post the patchset again.

OK, I see.
Thank you for accepting my suggestion.

Best regards,
Jingoo Han

--
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] usb: dwc3-exynos: Make provision for vdd regulators

2014-04-23 Thread Jingoo Han
On Wednesday, April 23, 2014 8:06 PM, Vivek Gautam wrote:
 On Wednesday, April 23, 2014 7:58 PM, Anton Tikhomirov wrote:
  On Wednesday, April 23, 2014 6:52 PM, Vivek Gautam wrote:
  On Wednesday, April 23, 2014 6:27 PM, Anton Tikhomirov wrote:
   On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
  
   Facilitate getting required 3.3V and 1.0V VDD supply for
   DWC3 controller on Exynos.
  
   With 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,
  
   certain perripherals will now need to ensure that,
   they request VDD regulators in their drivers, and enable
   them so as to make them working.
  
   Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
   Cc: Anton Tikhomirov av.tikhomi...@samsung.com
   ---
  
   Based on 'usb-next' branch of Greg's USB tree.
   Also cleanly applies on 'next' branch of Balbi's USB tree.
  
drivers/usb/dwc3/dwc3-exynos.c |   51
   ++--
1 file changed, 49 insertions(+), 2 deletions(-)
  
   diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
   exynos.c
   index 28c8ad7..c9d9102 100644
   --- a/drivers/usb/dwc3/dwc3-exynos.c
   +++ b/drivers/usb/dwc3/dwc3-exynos.c
   @@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
   +#include linux/regulator/consumer.h
  
struct dwc3_exynos {
 struct platform_device  *usb2_phy;
   @@ -34,6 +35,8 @@ struct dwc3_exynos {
 struct device   *dev;
  
 struct clk  *clk;
   + struct regulator*vdd33;
   + struct regulator*vdd10;
};
  
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
   @@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
   platform_device *pdev)
  
 clk_prepare_enable(exynos-clk);
  
   + exynos-vdd33 = devm_regulator_get(dev, vdd33);
   + if (IS_ERR(exynos-vdd33)) {
   + ret = PTR_ERR(exynos-vdd33);
   + goto err2;
  
   Is regulator property mandatory for dwc3-exynos? If it is not
   and device tree doesn't provide it, dwc3-exynos driver probe
  shouldn't
   fail here.
 
  These are the VDD regulators (from PMIC ldo supplies), in absence of
  which the controller will not be powered up.
  So doesn't it make sense to stop the probe when these are not supplied
  by device tree ?
 
  Agree. Just curious, is there special reason for this change except making
  things right?
 
 Yea, actually after the patch (which got merged in 3.15 rc1)
 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
 
 the USB stops working, and that's because the regulators related to
 usb are not turned on by default (ldo12 and ldo15 to be specific).
 So we need to enable those regulators, which ofcourse the driver
 should be doing, if i am not wrong.
 Similar is the reason for EHCI, and OHCI exynos patches in this series.

Oh, I see. Thank you for your explanation.

 
 I shall be sending the dt patch for this soon.

OK, I will wait for your patch.

Best regards,
Jingoo Han

 
 
 --
 Best Regards
 Vivek Gautam
 Samsung RD 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 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-23 Thread Jingoo Han
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
 
 Facilitate getting required 3.3V and 1.0V VDD supply for
 OHCI controller on Exynos.
 
 With 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,
 
 certain perripherals will now need to ensure that,
 they request VDD regulators in their drivers, and enable
 them so as to make them working.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 
 Based on 'usb-next' branch of Greg's usb tree.
 
  drivers/usb/host/ohci-exynos.c |   47 
 
  1 file changed, 47 insertions(+)
 
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index 68588d8..e2e72a8 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -18,6 +18,7 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/platform_device.h
 +#include linux/regulator/consumer.h
  #include linux/usb/phy.h
  #include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
 @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
   struct clk *clk;
   struct usb_phy *phy;
   struct usb_otg *otg;
 + struct regulator *vdd33;
 + struct regulator *vdd10;
  };
 
  static void exynos_ohci_phy_enable(struct platform_device *pdev)
 @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
   exynos_ohci-otg = phy-otg;
   }
 
 + exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
 + if (IS_ERR(exynos_ohci-vdd33)) {
 + err = PTR_ERR(exynos_ohci-vdd33);
 + goto fail_regulator1;
 + }
 + err = regulator_enable(exynos_ohci-vdd33);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD33 supply\n);
 + goto fail_regulator1;
 + }
 +
 + exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
 + if (IS_ERR(exynos_ohci-vdd10)) {
 + err = PTR_ERR(exynos_ohci-vdd10);
 + goto fail_regulator2;
 + }
 + err = regulator_enable(exynos_ohci-vdd10);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD10 supply\n);
 + goto fail_regulator2;
 + }
 +
  skip_phy:
   exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 
 @@ -154,6 +179,10 @@ fail_add_hcd:
  fail_io:
   clk_disable_unprepare(exynos_ohci-clk);
  fail_clk:
 + regulator_disable(exynos_ohci-vdd10);
 +fail_regulator2:
 + regulator_disable(exynos_ohci-vdd33);
 +fail_regulator1:
   usb_put_hcd(hcd);
   return err;
  }
 @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device 
 *pdev)
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 + regulator_disable(exynos_ohci-vdd10);
 + regulator_disable(exynos_ohci-vdd33);
 +
   usb_put_hcd(hcd);
 
   return 0;
 @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 + regulator_disable(exynos_ohci-vdd10);
 + regulator_disable(exynos_ohci-vdd33);
 +
   spin_unlock_irqrestore(ohci-lock, flags);
 
   return 0;
 @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
   struct platform_device *pdev= to_platform_device(dev);
 + int ret;
 +
 + ret = regulator_enable(exynos_ohci-vdd33);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD33 supply\n);
 + return ret;
 + }
 + ret = regulator_enable(exynos_ohci-vdd10);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD10 supply\n);
 + return ret;
 + }
 
   clk_prepare_enable(exynos_ohci-clk);
 
 --
 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] usb: ehci-exynos: Make provision for vdd regulators

2014-04-23 Thread Jingoo Han
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
 
 Facilitate getting required 3.3V and 1.0V VDD supply for
 EHCI controller on Exynos.
 
 With 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,
 
 certain perripherals will now need to ensure that,
 they request VDD regulators in their drivers, and enable
 them so as to make them working.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 
 Based on 'usb-next' branch of Greg's usb tree.
 
  drivers/usb/host/ehci-exynos.c |   47 
 
  1 file changed, 47 insertions(+)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index d1d8c47..a3ca8cc 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -20,6 +20,7 @@
  #include linux/of.h
  #include linux/of_gpio.h
  #include linux/platform_device.h
 +#include linux/regulator/consumer.h
  #include linux/usb/phy.h
  #include linux/usb/samsung_usb_phy.h
  #include linux/usb.h
 @@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
   struct clk *clk;
   struct usb_phy *phy;
   struct usb_otg *otg;
 + struct regulator *vdd33;
 + struct regulator *vdd10;
  };
 
  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
 *)(hcd_to_ehci(hcd)-priv)
 @@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device 
 *pdev)
   exynos_ehci-otg = phy-otg;
   }
 
 + exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
 + if (IS_ERR(exynos_ehci-vdd33)) {
 + err = PTR_ERR(exynos_ehci-vdd33);
 + goto fail_regulator1;
 + }
 + err = regulator_enable(exynos_ehci-vdd33);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD33 supply\n);
 + goto fail_regulator1;
 + }
 +
 + exynos_ehci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
 + if (IS_ERR(exynos_ehci-vdd10)) {
 + err = PTR_ERR(exynos_ehci-vdd10);
 + goto fail_regulator2;
 + }
 + err = regulator_enable(exynos_ehci-vdd10);
 + if (err) {
 + dev_err(pdev-dev, Failed to enable VDD10 supply\n);
 + goto fail_regulator2;
 + }
 +
  skip_phy:
 
   exynos_ehci-clk = devm_clk_get(pdev-dev, usbhost);
 @@ -178,6 +203,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);
 +fail_regulator1:
   usb_put_hcd(hcd);
   return err;
  }
 @@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device 
 *pdev)
 
   clk_disable_unprepare(exynos_ehci-clk);
 
 + regulator_disable(exynos_ehci-vdd10);
 + regulator_disable(exynos_ehci-vdd33);
 +
   usb_put_hcd(hcd);
 
   return 0;
 @@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
 
   clk_disable_unprepare(exynos_ehci-clk);
 
 + regulator_disable(exynos_ehci-vdd10);
 + regulator_disable(exynos_ehci-vdd33);
 +
   return rc;
  }
 
 @@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
  {
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
 + int ret;
 +
 + ret = regulator_enable(exynos_ehci-vdd33);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD33 supply\n);
 + return ret;
 + }
 + ret = regulator_enable(exynos_ehci-vdd10);
 + if (ret) {
 + dev_err(dev, Failed to enable VDD10 supply\n);
 + return ret;
 + }
 
   clk_prepare_enable(exynos_ehci-clk);
 
 --
 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 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-23 Thread Jingoo Han
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
 On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
 
  Facilitate getting required 3.3V and 1.0V VDD supply for
  OHCI controller on Exynos.
 
  With 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,
 
  certain perripherals will now need to ensure that,
  they request VDD regulators in their drivers, and enable
  them so as to make them working.
 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Cc: Jingoo Han jg1@samsung.com
  ---
 
  Based on 'usb-next' branch of Greg's usb tree.
 
   drivers/usb/host/ohci-exynos.c |   47
  
   1 file changed, 47 insertions(+)
 
  diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
  exynos.c
  index 68588d8..e2e72a8 100644
  --- a/drivers/usb/host/ohci-exynos.c
  +++ b/drivers/usb/host/ohci-exynos.c
  @@ -18,6 +18,7 @@
   #include linux/module.h
   #include linux/of.h
   #include linux/platform_device.h
  +#include linux/regulator/consumer.h
   #include linux/usb/phy.h
   #include linux/usb/samsung_usb_phy.h
   #include linux/usb.h
  @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
  struct clk *clk;
  struct usb_phy *phy;
  struct usb_otg *otg;
  +   struct regulator *vdd33;
  +   struct regulator *vdd10;
   };
 
   static void exynos_ohci_phy_enable(struct platform_device *pdev)
  @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
  *pdev)
  exynos_ohci-otg = phy-otg;
  }
 
  +   exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
  +   if (IS_ERR(exynos_ohci-vdd33)) {
  +   err = PTR_ERR(exynos_ohci-vdd33);
  +   goto fail_regulator1;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd33);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD33 supply\n);
  +   goto fail_regulator1;
  +   }
  +
  +   exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
  +   if (IS_ERR(exynos_ohci-vdd10)) {
  +   err = PTR_ERR(exynos_ohci-vdd10);
  +   goto fail_regulator2;
  +   }
  +   err = regulator_enable(exynos_ohci-vdd10);
  +   if (err) {
  +   dev_err(pdev-dev, Failed to enable VDD10 supply\n);
  +   goto fail_regulator2;
  +   }
  +
 
 Do we need to skip regulator settings together with PHY configuration
 in case of exynos5440?

Oh, right. In the case of exynos5440, regulator settings is not 
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.

Best regards,
Jingoo Han

 
   skip_phy:
  exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
 
  @@ -154,6 +179,10 @@ fail_add_hcd:
   fail_io:
  clk_disable_unprepare(exynos_ohci-clk);
   fail_clk:
  +   regulator_disable(exynos_ohci-vdd10);
  +fail_regulator2:
  +   regulator_disable(exynos_ohci-vdd33);
  +fail_regulator1:
  usb_put_hcd(hcd);
  return err;
   }
  @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
  platform_device *pdev)
 
  clk_disable_unprepare(exynos_ohci-clk);
 
  +   regulator_disable(exynos_ohci-vdd10);
  +   regulator_disable(exynos_ohci-vdd33);
  +
  usb_put_hcd(hcd);
 
  return 0;
  @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
 
  clk_disable_unprepare(exynos_ohci-clk);
 
  +   regulator_disable(exynos_ohci-vdd10);
  +   regulator_disable(exynos_ohci-vdd33);
  +
  spin_unlock_irqrestore(ohci-lock, flags);
 
  return 0;
  @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
  struct usb_hcd *hcd = dev_get_drvdata(dev);
  struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
  struct platform_device *pdev= to_platform_device(dev);
  +   int ret;
  +
  +   ret = regulator_enable(exynos_ohci-vdd33);
  +   if (ret) {
  +   dev_err(dev, Failed to enable VDD33 supply\n);
  +   return ret;
 
 Not sure, but shall we continue resuming and do everything
 we can in case of error? At least it will avoid
 WARN_ON(clk-enable_count == 0) on next system suspend.
 
  +   }
  +   ret = regulator_enable(exynos_ohci-vdd10);
  +   if (ret) {
  +   dev_err(dev, Failed to enable VDD10 supply\n);
  +   return ret;
  +   }
 
  clk_prepare_enable(exynos_ohci-clk);
 
  --
 
 Thanks

--
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 1/3] usb: ohci-exynos: Make provision for vdd regulators

2014-04-23 Thread Jingoo Han
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
 On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
  On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
  
   Facilitate getting required 3.3V and 1.0V VDD supply for
   OHCI controller on Exynos.
  
   With 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,
  
   certain perripherals will now need to ensure that,
   they request VDD regulators in their drivers, and enable
   them so as to make them working.
  
   Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
   Cc: Jingoo Han jg1@samsung.com
   ---
  
   Based on 'usb-next' branch of Greg's usb tree.
  
drivers/usb/host/ohci-exynos.c |   47
   
1 file changed, 47 insertions(+)
  
   diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
   exynos.c
   index 68588d8..e2e72a8 100644
   --- a/drivers/usb/host/ohci-exynos.c
   +++ b/drivers/usb/host/ohci-exynos.c
   @@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
   +#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
   @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
 struct clk *clk;
 struct usb_phy *phy;
 struct usb_otg *otg;
   + struct regulator *vdd33;
   + struct regulator *vdd10;
};
  
static void exynos_ohci_phy_enable(struct platform_device *pdev)
   @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
   *pdev)
 exynos_ohci-otg = phy-otg;
 }
  
   + exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
   + if (IS_ERR(exynos_ohci-vdd33)) {
   + err = PTR_ERR(exynos_ohci-vdd33);
   + goto fail_regulator1;
   + }
   + err = regulator_enable(exynos_ohci-vdd33);
   + if (err) {
   + dev_err(pdev-dev, Failed to enable VDD33 supply\n);
   + goto fail_regulator1;
   + }
   +
   + exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
   + if (IS_ERR(exynos_ohci-vdd10)) {
   + err = PTR_ERR(exynos_ohci-vdd10);
   + goto fail_regulator2;
   + }
   + err = regulator_enable(exynos_ohci-vdd10);
   + if (err) {
   + dev_err(pdev-dev, Failed to enable VDD10 supply\n);
   + goto fail_regulator2;
   + }
   +
 
  Do we need to skip regulator settings together with PHY configuration
  in case of exynos5440?
 
 Oh, right. In the case of exynos5440, regulator settings is not
 necessary. Vivek, would you fix it in order skip regulator settings
 in exynos5440? It also applies to ehci-exynos.

Sorry, in the case of exynos5440, this patch already skips
regulator settings.

In the case of exynos5440, there is no need to set PHY setting
and regulator setting.

How about making regulator setting optional?
Then, regulator setting can be done, only when regulator
is supported.

exynos_ohci_probe()
exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
if (IS_ERR(exynos_ohci-vdd33)) {
dev_err(pdev-dev, Failed to get VDD33 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd33);
if (err) {
dev_err(pdev-dev, Failed to enable VDD33 supply\n);
goto fail_regulator1;
}
}

exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
if (IS_ERR(exynos_ohci-vdd10)) {
dev_err(pdev-dev, Failed to get VDD10 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd10);
if (err) {
dev_err(pdev-dev, Failed to enable VDD10 supply\n);
goto fail_regulator2;
}
}

In this case, suspend/resume can be fixed as below.

exynos_ohci_suspend()
if (exynos_ohci-vdd10)
regulator_disable(exynos_ohci-vdd10);
if (exynos_ohci-vdd33)
regulator_disable(exynos_ohci-vdd33);

exynos_ohci_resume()

if (exynos_ohci-vdd33) {
ret = regulator_enable(exynos_ohci-vdd33);
if (ret) {
dev_err(dev, Failed to enable VDD33 supply\n);
return ret;
}
}
if (exynos_ohci-vdd10) {
ret = regulator_enable(exynos_ohci-vdd10);
if (ret) {
dev_err(dev, Failed to enable VDD10 supply\n);
return ret;
}
}

Best regards,
Jingoo Han

 
 
skip_phy:
 exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
  
   @@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
 clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
   + regulator_disable(exynos_ohci-vdd10);
   +fail_regulator2:
   + regulator_disable(exynos_ohci-vdd33);
   +fail_regulator1

Re: [PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

2014-04-22 Thread Jingoo Han
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
 
 From: Andrew Bresticker abres...@chromium.org
 
 Certain bridge chips use a GPIO to indicate the cable status instead
 of the I_DP_HPD pin.  This adds an optional device-tree property,
 samsung,hpd-gpio, to the exynos-dp controller which indicates that
 the specified GPIO should be used for hotplug detection.
 The GPIO is then set up as an edge-triggered interrupt where the
 rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
 
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 Changes since V1:
   Address reiew comments from Jingoo Han
 
  .../devicetree/bindings/video/exynos_dp.txt|4 ++
  drivers/gpu/drm/exynos/exynos_dp_core.c|   32 --
  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
  drivers/gpu/drm/exynos/exynos_dp_reg.c |   44 
 ++--
  4 files changed, 66 insertions(+), 15 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


Re: [PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

2014-04-22 Thread Jingoo Han
On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote:
 
 This patch adds a simple driver to handle all the LCD and LED
 powerup/down routines needed to support eDP/eDP-LVDS panels
 supported on exynos boards.
 
 The LCD and LED units are usually powered up via regulators,
 and almost on all boards, we will have a BL_EN pin to enable/
 disable the backlight. Sometimes, we can have LCD_EN switches
 as well. The routines in this driver can be used to control
 panel power sequence on such boards.
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
 Changes since V1:
   Added routine for post_disable, removed few unwanted headers.
   Refactored a lot of code.
 
  .../devicetree/bindings/panel/exynos-dp-panel.txt  |   45 
  drivers/gpu/drm/panel/Kconfig  |9 +
  drivers/gpu/drm/panel/Makefile |1 +
  drivers/gpu/drm/panel/panel-exynos-dp.c|  251 
 
  4 files changed, 306 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
  create mode 100644 drivers/gpu/drm/panel/panel-exynos-dp.c
 
 diff --git a/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
 b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
 new file mode 100644
 index 000..3fbca54
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/panel/exynos-dp-panel.txt
 @@ -0,0 +1,45 @@
 +exynos_DP_panel/DP_to_LVDS_panel

Please fix it as below.

+Exynos DP panel/DP to LVDS panel

[]

 diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
 index 4ec874d..ea9d5ac 100644
 --- a/drivers/gpu/drm/panel/Kconfig
 +++ b/drivers/gpu/drm/panel/Kconfig
 @@ -30,4 +30,13 @@ config DRM_PANEL_S6E8AA0
   select DRM_MIPI_DSI
   select VIDEOMODE_HELPERS
 
 +config DRM_PANEL_EXYNOS_DP
 + tristate support for DP panels

It looks very general. Please fix it as below.

+   tristate support for Exynos DP panels

Best regards,
Jingoo Han

 + depends on OF  DRM_PANEL  DRM_EXYNOS_DP
 + help
 +   DRM panel driver for DP panels and LVDS connected via DP bridges
 +   that need at most a regulator for LCD unit, a regulator for LED unit
 +   and/or enable GPIOs for LCD or LED units. Delay values can also be
 +   specified to support powerup and powerdown process.
 +

[.]


--
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 8/9] drm/bridge: Add PS8622 bridge driver

2014-04-22 Thread Jingoo Han
 the
 +  * reset pin.
 +  */
 + usleep_range(PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US,
 +  PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US);
 +
 + if (gpio_is_valid(ps_bridge-gpio_rst_n))
 + gpio_set_value(ps_bridge-gpio_rst_n, 1);
 +
 + ret = ps8622_send_config(ps_bridge);
 + if (ret)
 + DRM_ERROR(Failed to send config to bridge (%d)\n, ret);
 +
 + ps_bridge-enabled = true;
 +
 + mutex_unlock(ps_bridge-enable_mutex);
 + return;
 +
 +out:
 +
 + mutex_unlock(ps_bridge-enable_mutex);
 +}

mutex_unlock() is duplicated. Also, 'return' is unnecessary.
Please fix it as below.

+   ps_bridge-enabled = true;
+
+out:
+   mutex_unlock(ps_bridge-enable_mutex);
+}

 +
 +static void ps8622_enable(struct drm_bridge *bridge)
 +{
 + struct ps8622_bridge *ps_bridge = bridge-driver_private;
 +
 + mutex_lock(ps_bridge-enable_mutex);
 + if (ps_bridge-enabled)
 + drm_panel_enable(ps_bridge-panel);
 + mutex_unlock(ps_bridge-enable_mutex);
 +}
 +
 +static void ps8622_disable(struct drm_bridge *bridge)
 +{
 + struct ps8622_bridge *ps_bridge = bridge-driver_private;
 +
 + mutex_lock(ps_bridge-enable_mutex);
 +
 + if (!ps_bridge-enabled)
 + goto out;
 +
 + ps_bridge-enabled = false;
 +
 + drm_panel_disable(ps_bridge-panel);
 + msleep(PS8622_PWMO_END_T12_MS);
 +
 + /*
 +  * This doesn't matter if the regulators are turned off, but something
 +  * else might keep them on. In that case, we want to assert the slp gpio
 +  * to lower power.
 +  */
 + if (gpio_is_valid(ps_bridge-gpio_slp_n))
 + gpio_set_value(ps_bridge-gpio_slp_n, 0);
 +
 + drm_panel_post_disable(ps_bridge-panel);
 + if (ps_bridge-v12)
 + regulator_disable(ps_bridge-v12);
 +
 + /*
 +  * Sleep for at least the amount of time that it takes the power rail to
 +  * fall to prevent asserting the rst gpio from doing anything.
 +  */
 + usleep_range(PS8622_POWER_FALL_T16_MAX_US,
 +  2 * PS8622_POWER_FALL_T16_MAX_US);
 + if (gpio_is_valid(ps_bridge-gpio_rst_n))
 + gpio_set_value(ps_bridge-gpio_rst_n, 0);
 +
 + msleep(PS8622_POWER_OFF_T17_MS);
 +
 +out:
 + mutex_unlock(ps_bridge-enable_mutex);
 +}
 +
 +static void ps8622_post_disable(struct drm_bridge *bridge)
 +{
 +}

How about just removing this empty function?

[.]

Best regards,
Jingoo Han

--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-21 Thread Jingoo Han
On Wednesday, April 16, 2014 11:49 PM, Vivek Gautam wrote:
 On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa t.f...@samsung.com wrote:
  On 15.04.2014 08:09, Vivek Gautam wrote:
  On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam wrote:
  On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa t.f...@samsung.com wrote:
  On 09.04.2014 13:49, Vivek Gautam wrote:
 
  So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I
  don't see any reference to XXTI in the USB 3.0 DRD controller chapter
  (in both Exynos5250 and 5420)
  In addition to this there's one more point to be noticed here.
  On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30
  for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy
  clock.
  So we should add a similar clk_get() for this clock in the
  phy-exynos5250-usb2 driver too, to support Exynos5420.
 
 
  Is something clear from the above block diagram ? (although the
  diagram looks weird - space and tabs problem :-(  )
  Basically there's the clock USB30_SCLK_100M which is going into the
  USB 3.0 DRD PHY controller.
  And this is the only sclk mentioned in the block diagram for USB 3.0
  DRD controller in Exynos5420.
  Same is not there in the block diagram in Exynos5250 UM.
 
 
  From what I can see in the documentation, there are 4 USB 3.0 related clocks
  generated in CMU:
 
   - sclk_usbphy300,
   - sclk_usbphy301,
   - sclk_usbdrd300,
   - sclk_usbdrd301,
 
  They are all rated to max. 24 MHz and the recommended operating frequency is
  24 MHz, so it looks exactly like USB PHY reference, which is usually a 24
  MHz clock.
 
  To me, this looks like on Exynos5420 a separate special clock path is used
  instead of xusbxti as reference of USB 3.0 PHY and so the sclk should be
  simply passed as the ref clock.
 
 Ok, i will clear on this with the hardware engineer also once.
 May be Jingoo can help me with this.
 
 Jingoo,
 Can you please enquire about the clock path of usbphy30 reference
 clocks on Exynos5420.
 As mentioned by Tomasz above, we have sclk_usbphy300 and
 sclk_usbphy301 as the reference clocks for USB3.0 DRD phy. *Also*
 sclk_usbphy300 is used for Pico phy (which is the USb 2.0 phy used by
 ehci/ohci controller on Exynos5420).
 It will be of great help.

Hi Vevek, Tomasz

Long time no see.

I asked USB S/W engineer and USB H/W engineer.

There are two USB3.0 on Exynos5420; thus there are two sclks
such as 'sclk_usbphy300 and sclk_usbphy301'.

As Tomasz mentioned, 'sclk_usbphy300 and sclk_usbphy301' can
be used instead of 'xusbxti' as reference of USB 3.0 PHY.

However, on Exynos5420, ONLY 'sclk_usbphy300' can be used
for USB2.0 pico phy. (so, '301' CANNOT support USB2.0 pico phy.)

Best regards,
Jingoo Han

--
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 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver

2014-04-20 Thread Jingoo Han
On Saturday, April 19, 2014 4:51 AM, Ajay Kumar wrote:
 On Fri, Apr 18, 2014 at 2:27 PM, Jingoo Han jg1@samsung.com wrote:
  On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote:

[.]

   +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
   + platform_driver_unregister(exynos_dp_panel_driver);
   +err_unregister_dp_panel:
   +#endif
  Please add platform_driver_unregister() to exynos_drm_platform_remove(),
 Right, I have missed adding it in exynos_drm_platform_remove().
  as well as exynos_drm_platform_probe().
 I have already added for this case!

What I wanted to say is that
Please add platform_driver_unregister() to exynos_drm_platform_remove(),
as you added it to exynos_drm_platform_probe().

Best regards,
Jingoo Han

--
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] drm/panel: Add driver for exynos_dp based panels

2014-04-20 Thread Jingoo Han
On Saturday, April 19, 2014 4:43 AM, Ajay kumar wrote:
 On Fri, Apr 18, 2014 at 2:17 PM, Jingoo Han jg1@samsung.com wrote:
  On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote:

[.]

   +struct panel_exynos_dp {
   + struct drm_panelbase;
   + struct regulator*bck_fet;
   + struct regulator*lcd_fet;
  'bck' means 'backlight'? Then, just use 'backlight_fet'.
 backlight_fet is more meaningful. Will change it.
  Also, I cannot understand the meaning of 'fet'.
  What's the meaning of the 'fet'?

 FET is an output from the regulator. On exynos5250-snow board,
 FET1 controls power to the backlight unit.
 See more here: https://lkml.org/lkml/2014/4/15/618 

OK, I see.

PS: Please change your mail from 'html' mode to 'text' mode.

Best regards,
Jingoo Han

--
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 1/7] drm/exynos: dp: support hotplug detection via GPIO

2014-04-18 Thread Jingoo Han
On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote:
 
 From: Andrew Bresticker abres...@chromium.org
 
 Certain bridge chips use a GPIO to indicate the cable status instead
 of the I_DP_HPD pin.  This adds an optional device-tree property,
 samsung,hpd-gpio, to the exynos-dp controller which indicates that
 the specified GPIO should be used for hotplug detection.
 The GPIO is then set up as an edge-triggered interrupt where the
 rising edge indicates hotplug-in and the falling edge indicates hotplug-out.
 
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  .../devicetree/bindings/video/exynos_dp.txt|  4 +++
  drivers/gpu/drm/exynos/exynos_dp_core.c| 32 
 --
  drivers/gpu/drm/exynos/exynos_dp_core.h|  1 +
  drivers/gpu/drm/exynos/exynos_dp_reg.c | 26 --
  4 files changed, 57 insertions(+), 6 deletions(-)
 

[.]

 --- a/drivers/gpu/drm/exynos/exynos_dp_reg.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_reg.c
 @@ -13,6 +13,7 @@
  #include linux/device.h
  #include linux/io.h
  #include linux/delay.h
 +#include linux/gpio.h
 
  #include exynos_dp_core.h
  #include exynos_dp_reg.h
 @@ -326,6 +327,9 @@ void exynos_dp_clear_hotplug_interrupts(struct 
 exynos_dp_device *dp)
  {
   u32 reg;
 
 + if (gpio_is_valid(dp-hpd_gpio))
 + return;
 +
   reg = HOTPLUG_CHG | HPD_LOST | PLUG;
   writel(reg, dp-reg_base + EXYNOS_DP_COMMON_INT_STA_4);
 
 @@ -337,6 +341,9 @@ void exynos_dp_init_hpd(struct exynos_dp_device *dp)
  {
   u32 reg;
 
 + if (gpio_is_valid(dp-hpd_gpio))
 + return;
 +
   exynos_dp_clear_hotplug_interrupts(dp);
 
   reg = readl(dp-reg_base + EXYNOS_DP_SYS_CTL_3);
 @@ -348,6 +355,14 @@ enum dp_irq_type exynos_dp_get_irq_type(struct 
 exynos_dp_device *dp)
  {
   u32 reg;
 
 + if (gpio_is_valid(dp-hpd_gpio)) {
 + reg = gpio_get_value(dp-hpd_gpio);
 + if (reg)
 + return DP_IRQ_TYPE_HP_CABLE_IN;
 + else
 + return DP_IRQ_TYPE_HP_CABLE_OUT;
 + }
 +

Please keep the style. It enhances the readability.

if (gpio_is_valid(dp-hpd_gpio)) {
...
} else {
...
}

Then, it can be as bellows.

+   if (gpio_is_valid(dp-hpd_gpio)) {
+   reg = gpio_get_value(dp-hpd_gpio);
+   if (reg)
+   return DP_IRQ_TYPE_HP_CABLE_IN;
+   else
+   return DP_IRQ_TYPE_HP_CABLE_OUT;
+   } else {
+   /* Parse hotplug interrupt status register */
+   reg = readl(dp-reg_base + EXYNOS_DP_COMMON_INT_STA_4);
+
+   if (reg  PLUG)
+   return DP_IRQ_TYPE_HP_CABLE_IN;
+
+   if (reg  HPD_LOST)
+   return DP_IRQ_TYPE_HP_CABLE_OUT;
+
+   if (reg  HOTPLUG_CHG)
+   return DP_IRQ_TYPE_HP_CHANGE;
+   }

return DP_IRQ_TYPE_UNKNOWN;
}

Best regards,
Jingoo Han

   /* Parse hotplug interrupt status register */
   reg = readl(dp-reg_base + EXYNOS_DP_COMMON_INT_STA_4);
 
 @@ -402,9 +417,14 @@ int exynos_dp_get_plug_in_status(struct exynos_dp_device 
 *dp)
  {
   u32 reg;
 
 - reg = readl(dp-reg_base + EXYNOS_DP_SYS_CTL_3);
 - if (reg  HPD_STATUS)
 - return 0;
 + if (gpio_is_valid(dp-hpd_gpio)) {
 + if (gpio_get_value(dp-hpd_gpio))
 + return 0;
 + } else {
 + reg = readl(dp-reg_base + EXYNOS_DP_SYS_CTL_3);
 + if (reg  HPD_STATUS)
 + return 0;
 + }
 
   return -EINVAL;
  }
 --
 1.8.1.2

--
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] drm/panel: Add driver for exynos_dp based panels

2014-04-18 Thread Jingoo Han
 'backlight_fet'.
Also, I cannot understand the meaning of 'fet'.
What's the meaning of the 'fet'?

 + int led_en_gpio;
 + int lcd_en_gpio;
 + int power_up_delay;
 + int power_down_delay;
 + boolenabled;
 +};
 +
 +static inline struct panel_exynos_dp *to_panel(struct drm_panel *panel)
 +{
 + return container_of(panel, struct panel_exynos_dp, base);
 +}
 +
 +static int panel_exynos_dp_disable(struct drm_panel *panel)
 +{
 + struct panel_exynos_dp *dp_panel = to_panel(panel);
 + bool enable_delay = false;
 +
 + if (!dp_panel-enabled)
 + return 0;
 +
 + if (gpio_is_valid(dp_panel-led_en_gpio))
 + gpio_set_value(dp_panel-led_en_gpio, 0);
 +
 + if (!IS_ERR_OR_NULL(dp_panel-bck_fet))
 + regulator_disable(dp_panel-bck_fet);
 +
 + if (gpio_is_valid(dp_panel-lcd_en_gpio)) {
 + gpio_set_value(dp_panel-lcd_en_gpio, 0);
 + enable_delay = true;
 + }
 +
 + if (!IS_ERR_OR_NULL(dp_panel-lcd_fet)) {
 + regulator_disable(dp_panel-lcd_fet);
 + enable_delay = true;
 + }
 +
 + if (enable_delay)
 + msleep(dp_panel-power_down_delay);
 +
 + dp_panel-enabled = false;
 +
 + return 0;
 +}
 +
 +static int panel_exynos_dp_pre_enable(struct drm_panel *panel)

panel_exynos_dp_pre_enable() always returns '0'.
These are two ways. Either one will be better.
1. Make return values meaningful. In other words, add the case
   returning error values.

2. Change the return type to 'void'

Best regards,
Jingoo Han

 +{
 + struct panel_exynos_dp *dp_panel = to_panel(panel);
 + bool enable_delay = false;
 +
 + if (dp_panel-enabled)
 + return 0;
 +
 + if (!IS_ERR_OR_NULL(dp_panel-lcd_fet)) {
 + if (regulator_enable(dp_panel-lcd_fet))
 + DRM_ERROR(Failed to enable LCD fet\n);
 + enable_delay = true;
 + }
 +
 + if (gpio_is_valid(dp_panel-lcd_en_gpio)) {
 + gpio_set_value(dp_panel-lcd_en_gpio, 1);
 + enable_delay = true;
 + }
 +
 + if (enable_delay)
 + msleep(dp_panel-power_up_delay);
 +
 + return 0;
 +}
 +
 +static int panel_exynos_dp_enable(struct drm_panel *panel)
 +{
 + struct panel_exynos_dp *dp_panel = to_panel(panel);
 +
 + if (dp_panel-enabled)
 + return 0;
 +
 + if (!IS_ERR_OR_NULL(dp_panel-bck_fet))
 + if (regulator_enable(dp_panel-bck_fet))
 + DRM_ERROR(Failed to enable LED fet\n);
 +
 + if (gpio_is_valid(dp_panel-led_en_gpio))
 + gpio_set_value(dp_panel-led_en_gpio, 1);
 +
 + dp_panel-enabled = true;
 +
 + return 0;
 +}
 +
 +static const struct drm_panel_funcs panel_exynos_dp_funcs = {
 + .disable = panel_exynos_dp_disable,
 + .pre_enable = panel_exynos_dp_pre_enable,
 + .enable = panel_exynos_dp_enable,
 +};
 +
 +static int panel_exynos_dp_probe(struct platform_device *pdev)
 +{
 + struct panel_exynos_dp *dp_panel;
 + struct device *dev = pdev-dev;
 + int ret;
 +
 + dp_panel = devm_kzalloc(dev, sizeof(*dp_panel), GFP_KERNEL);
 + if (!dp_panel)
 + return -ENOMEM;
 +
 + dp_panel-enabled = false;
 +
 + dp_panel-lcd_en_gpio = of_get_named_gpio(dev-of_node,
 + samsung,lcd-en-gpio, 0);
 + dp_panel-led_en_gpio = of_get_named_gpio(dev-of_node,
 + samsung,led-en-gpio, 0);
 +
 + of_property_read_u32(dev-of_node, samsung,power-up-delay,
 + dp_panel-power_up_delay);
 + of_property_read_u32(dev-of_node, samsung,power-down-delay,
 + dp_panel-power_down_delay);
 +
 + dp_panel-lcd_fet = devm_regulator_get(dev, lcd_vdd);
 + if (IS_ERR(dp_panel-lcd_fet))
 + return PTR_ERR(dp_panel-lcd_fet);
 +
 + dp_panel-bck_fet = devm_regulator_get(dev, vcd_led);
 + if (IS_ERR(dp_panel-bck_fet))
 + return PTR_ERR(dp_panel-bck_fet);
 +
 + if (gpio_is_valid(dp_panel-lcd_en_gpio)) {
 + ret = devm_gpio_request_one(dev, dp_panel-lcd_en_gpio,
 + GPIOF_OUT_INIT_LOW, lcd_en_gpio);
 + if (ret) {
 + DRM_ERROR(failed to get lcd-en gpio [%d]\n, ret);
 + return ret;
 + }
 + } else {
 + dp_panel-lcd_en_gpio = -ENODEV;
 + }
 +
 + if (gpio_is_valid(dp_panel-led_en_gpio)) {
 + ret = devm_gpio_request_one(dev, dp_panel-led_en_gpio,
 + GPIOF_OUT_INIT_LOW, led_en_gpio);
 + if (ret) {
 + DRM_ERROR(failed to get led-en gpio [%d]\n, ret);
 + return ret;
 + }
 + } else {
 + dp_panel

Re: [PATCH 4/7] drm/exynos: add exynos_dp_panel driver registration to drm driver

2014-04-18 Thread Jingoo Han
On Wednesday, April 16, 2014 11:33 PM, Ajay Kumar wrote:
 
 Register exynos_dp_panel before the list of exynos crtcs and
 connectors are probed.
 
 This is needed because exynos_dp_panel should be registered to
 the drm_panel list via panel-exynos-dp probe, i.e much before
 exynos_dp_bind calls of_drm_find_panel().
 
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 11 +++
  drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 +
  2 files changed, 12 insertions(+)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 1d1c604..47266e7 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -560,12 +560,23 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
   goto err_unregister_ipp;
  #endif
 
 +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
 + ret = platform_driver_register(exynos_dp_panel_driver);
 + if (ret  0)
 + goto err_unregister_dp_panel;
 +#endif
 +
   ret = component_master_add(pdev-dev, exynos_drm_ops);
   if (ret  0)
   DRM_DEBUG_KMS(re-tried by last sub driver probed later.\n);
 
   return 0;
 
 +#ifdef CONFIG_DRM_PANEL_EXYNOS_DP
 + platform_driver_unregister(exynos_dp_panel_driver);
 +err_unregister_dp_panel:
 +#endif

Please add platform_driver_unregister() to exynos_drm_platform_remove(),
as well as exynos_drm_platform_probe().

Best regards,
Jingoo Han

 +
  #ifdef CONFIG_DRM_EXYNOS_IPP
   exynos_platform_device_ipp_unregister();
  err_unregister_ipp:
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 257ce09..f606290 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -368,4 +368,5 @@ extern struct platform_driver fimc_driver;
  extern struct platform_driver rotator_driver;
  extern struct platform_driver gsc_driver;
  extern struct platform_driver ipp_driver;
 +extern struct platform_driver exynos_dp_panel_driver;
  #endif
 --
 1.8.1.2

--
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 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails

2014-04-09 Thread Jingoo Han
On Thursday, April 10, 2014 3:32 AM, Alan Stern wrote:
 On Wed, 9 Apr 2014, Vivek Gautam wrote:
 
  Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
  adds a check for possible race between suspend and wakeup interrupt,
  and thereby it returns -EBUSY as error code if there's a wakeup
  interrupt.
  So the platform host controller should not proceed further with
  its suspend callback, rather should return immediately to avoid
  powering down the essential things, like phy.
 
  Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
  Cc: Alan Stern st...@rowland.harvard.edu
  Cc: Jingoo Han jg1@samsung.com
  ---
 
  Based on 'usb-next' branch of Greg's usb tree.
 
   drivers/usb/host/ehci-exynos.c |4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
  index d1d8c47..a4550eb 100644
  --- a/drivers/usb/host/ehci-exynos.c
  +++ b/drivers/usb/host/ehci-exynos.c
  @@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev)
  int rc;
 
  rc = ehci_suspend(hcd, do_wakeup);
  +   if (rc)
  +   return rc;
 
  if (exynos_ehci-otg)
  exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self);
  @@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev)
 
  clk_disable_unprepare(exynos_ehci-clk);
 
  -   return rc;
  +   return 0;
   }
 
   static int exynos_ehci_resume(struct device *dev)
 
 The first hunk of this patch is correct, but the second hunk isn't
 needed.  A similar remark is true for the ehci-platform patch.

Hi Alan,

Do you mean the following?

1st hunk
 +  if (rc)
 +  return rc;

2nd hunk
 -  return rc;
 +  return 0;

Currently, the 'rc' will be always 'zero'; however, I don't
Have any objection, because the code might be  modified later.

Best regards,
Jingoo Han
 
 Alan Stern

--
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] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback

2014-04-08 Thread Jingoo Han
On Tuesday, April 08, 2014 11:41 PM, Vivek Gautam wrote:
 
 Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend
 has already removed 'ohci_hcd' settings from exynos glue layer
 as a part of streamlining the ohci controller's suspend.
 So we don't need the locks for 'ohci_hcd' anymore.

Right, this spin_lock/unlock is unnecessary, because it is
already used in ohci_suspend().

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Manjunath Goudar csmanjuvi...@gmail.com
 Cc: Alan Stern st...@rowland.harvard.edu
 ---
  drivers/usb/host/ohci-exynos.c |6 --
  1 file changed, 6 deletions(-)
 
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index 68588d8..9cf80cb 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -190,17 +190,13 @@ static int exynos_ohci_suspend(struct device *dev)
  {
   struct usb_hcd *hcd = dev_get_drvdata(dev);
   struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
 - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
   struct platform_device *pdev = to_platform_device(dev);
   bool do_wakeup = device_may_wakeup(dev);
 - unsigned long flags;
   int rc = ohci_suspend(hcd, do_wakeup);
 
   if (rc)
   return rc;
 
 - spin_lock_irqsave(ohci-lock, flags);
 -
   if (exynos_ohci-otg)
   exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
 
 @@ -208,8 +204,6 @@ static int exynos_ohci_suspend(struct device *dev)
 
   clk_disable_unprepare(exynos_ohci-clk);
 
 - spin_unlock_irqrestore(ohci-lock, flags);
 -
   return 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 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails

2014-04-08 Thread Jingoo Han
On Wednesday, April 09, 2014 1:01 PM, Vivek Gautam wrote:
 
 Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
 adds a check for possible race between suspend and wakeup interrupt,
 and thereby it returns -EBUSY as error code if there's a wakeup
 interrupt.
 So the platform host controller should not proceed further with
 its suspend callback, rather should return immediately to avoid
 powering down the essential things, like phy.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
 
 Based on 'usb-next' branch of Greg's usb tree.
 
  drivers/usb/host/ehci-exynos.c |4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index d1d8c47..a4550eb 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev)
   int rc;
 
   rc = ehci_suspend(hcd, do_wakeup);
 + if (rc)
 + return rc;
 
   if (exynos_ehci-otg)
   exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self);
 @@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev)
 
   clk_disable_unprepare(exynos_ehci-clk);
 
 - return rc;
 + return 0;
  }
 
  static int exynos_ehci_resume(struct device *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


Re: [PATCH v2 6/6] PCI: designware: use new OF interrupt mapping when possible

2014-04-07 Thread Jingoo Han
On Monday, April 07, 2014 5:39 PM, Lucas Stach wrote:
 Am Freitag, den 04.04.2014, 11:05 -0600 schrieb Bjorn Helgaas:
  On Fri, Apr 04, 2014 at 11:03:41AM -0600, Bjorn Helgaas wrote:
   On Wed, Mar 05, 2014 at 11:42:19AM -0700, Jason Gunthorpe wrote:
On Wed, Mar 05, 2014 at 02:25:51PM +0100, Lucas Stach wrote:
 - return pp-irq;
 + irq = of_irq_parse_and_map_pci(dev, slot, pin);
 + if (!irq)
 + irq = pp-irq;
   
In light of the two bugs that Tim found, it might be wise to throw a
'dev_warn(FW_BUG Missing DT interrupt mapping)' in the fall back
path, so it doesn't continue to silently cover up errors on the OF/DT
side..
  
   This sounds like a reasonable thing to do, but I didn't see a response to
   this comment.  Should I merge it as-is, or do you want to add the message?
 
  Oh, and I suppose the same question applies to the other host drivers in
  this series (tegra, rcar)?
 
 Please apply as-is. of_irq_parse_and_map_pci() already prints an error
 message if it isn't able to establish the mapping, thus right before we
 fall into the fallback path. So any the warning would be redundant.

+1

I agree with Lucas Stach's opinion. of_irq_parse_and_map_pci() already
prints an error as below. So, additional warning message of host controller
looks superfluous.

ret = of_irq_parse_pci(dev, oirq);
if (ret) {
dev_err(dev-dev, of_irq_parse_pci() failed with rc=%d\n, 
ret);
return 0; /* Proper return code 0 == NO_IRQ */


Best regards,
Jingoo Han

--
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] pata_samsung_cf: fix ata_host_activate() failure handling

2014-03-31 Thread Jingoo Han
On Tuesday, April 01, 2014 2:53 AM, Tejun Heo wrote:
 
 Add missing clk_disable() call to ata_host_activate() failure path.
 
 Cc: Ben Dooks ben-li...@fluff.org
 Cc: Kukjin Kim kgene@samsung.com
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com

Reviewed-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 ---
  drivers/ata/pata_samsung_cf.c |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)
 
 Index: b/drivers/ata/pata_samsung_cf.c
 ===
 --- a/drivers/ata/pata_samsung_cf.c   2014-03-14 16:45:04.344724378 +0100
 +++ b/drivers/ata/pata_samsung_cf.c   2014-03-31 18:31:58.083631437 +0200
 @@ -594,9 +594,13 @@ static int __init pata_s3c_probe(struct
 
   platform_set_drvdata(pdev, host);
 
 - return ata_host_activate(host, info-irq,
 - info-irq ? pata_s3c_irq : NULL,
 - 0, pata_s3c_sht);
 + ret = ata_host_activate(host, info-irq,
 + info-irq ? pata_s3c_irq : NULL,
 + 0, pata_s3c_sht);
 + if (ret)
 + goto stop_clk;
 +
 + return 0;
 
  stop_clk:
   clk_disable(info-clk);
 
 --

--
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] ARM: dts: Increase the size of PCIe configuration space for EXYNOS5440

2014-03-31 Thread Jingoo Han
Increase the size of PCIe configuration space to 8kB from 4kB,
because 4kB for cfg0 and 4kB for cfg1 are required respectively.
If 2kB for cfg0 and 2kB for cfg1 are set, it will make problems
when a PCIe card having multiple EPs below a bridge is used.

Suggested-by: Pratyush Anand pratyush.an...@st.com
Signed-off-by: Jingoo Han jg1@samsung.com
---
 arch/arm/boot/dts/exynos5440.dtsi |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
b/arch/arm/boot/dts/exynos5440.dtsi
index d600733..5d08be8 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -281,9 +281,9 @@
#address-cells = 3;
#size-cells = 2;
device_type = pci;
-   ranges = 0x0800 0 0x4000 0x4000 0 0x1000   /* 
configuration space */
- 0x8100 0 0  0x40001000 0 0x0001   /* 
downstream I/O */
- 0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
non-prefetchable memory */
+   ranges = 0x0800 0 0x4000 0x4000 0 0x2000   /* 
configuration space */
+ 0x8100 0 0  0x40002000 0 0x0001   /* 
downstream I/O */
+ 0x8200 0 0x40012000 0x40012000 0 0x1ffee000; /* 
non-prefetchable memory */
#interrupt-cells = 1;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0x0 0 gic 53;
@@ -302,9 +302,9 @@
#address-cells = 3;
#size-cells = 2;
device_type = pci;
-   ranges = 0x0800 0 0x6000 0x6000 0 0x1000   /* 
configuration space */
- 0x8100 0 0  0x60001000 0 0x0001   /* 
downstream I/O */
- 0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
non-prefetchable memory */
+   ranges = 0x0800 0 0x6000 0x6000 0 0x2000   /* 
configuration space */
+ 0x8100 0 0  0x60002000 0 0x0002   /* 
downstream I/O */
+ 0x8200 0 0x60012000 0x60012000 0 0x1ffee000; /* 
non-prefetchable memory */
#interrupt-cells = 1;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0x0 0 gic 56;
-- 
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] ARM: dts: Increase the size of PCIe configuration space for EXYNOS5440

2014-03-31 Thread Jingoo Han
On Tuesday, April 01, 2014 12:44 PM, Pratyush Anand wrote:
 On Tue, Apr 01, 2014 at 10:54:57AM +0800, Jingoo Han wrote:
  Increase the size of PCIe configuration space to 8kB from 4kB,
  because 4kB for cfg0 and 4kB for cfg1 are required respectively.
  If 2kB for cfg0 and 2kB for cfg1 are set, it will make problems
  when a PCIe card having multiple EPs below a bridge is used.
 
  Suggested-by: Pratyush Anand pratyush.an...@st.com
  Signed-off-by: Jingoo Han jg1@samsung.com
  ---
   arch/arm/boot/dts/exynos5440.dtsi |   12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
  b/arch/arm/boot/dts/exynos5440.dtsi
  index d600733..5d08be8 100644
  --- a/arch/arm/boot/dts/exynos5440.dtsi
  +++ b/arch/arm/boot/dts/exynos5440.dtsi
  @@ -281,9 +281,9 @@
  #address-cells = 3;
  #size-cells = 2;
  device_type = pci;
  -   ranges = 0x0800 0 0x4000 0x4000 0 0x1000   /* 
  configuration space */
  - 0x8100 0 0  0x40001000 0 0x0001   /* 
  downstream I/O */
  - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
  non-prefetchable memory */
  +   ranges = 0x0800 0 0x4000 0x4000 0 0x2000   /* 
  configuration space */
  + 0x8100 0 0  0x40002000 0 0x0001   /* 
  downstream I/O */
  + 0x8200 0 0x40012000 0x40012000 0 0x1ffee000; /* 
  non-prefetchable memory */
  #interrupt-cells = 1;
  interrupt-map-mask = 0 0 0 0;
  interrupt-map = 0x0 0 gic 53;
  @@ -302,9 +302,9 @@
  #address-cells = 3;
  #size-cells = 2;
  device_type = pci;
  -   ranges = 0x0800 0 0x6000 0x6000 0 0x1000   /* 
  configuration space */
  - 0x8100 0 0  0x60001000 0 0x0001   /* 
  downstream I/O */
  - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
  non-prefetchable memory */
  +   ranges = 0x0800 0 0x6000 0x6000 0 0x2000   /* 
  configuration space */
  + 0x8100 0 0  0x60002000 0 0x0002   /* 
  downstream I/O */
 
 is I/O size change intentional?

Hi Pratyush Anand,

No, it is my mistake. I/O size should not be modified.
I really appreciate your review. I will send v2 patch. :-)
Thank you.

Best regards,
Jingoo Han

 
 Regards
 Pratyush
  + 0x8200 0 0x60012000 0x60012000 0 0x1ffee000; /* 
  non-prefetchable memory */
  #interrupt-cells = 1;
  interrupt-map-mask = 0 0 0 0;
  interrupt-map = 0x0 0 gic 56;
  --
  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] ARM: dts: Increase the size of PCIe configuration space for EXYNOS5440

2014-03-31 Thread Jingoo Han
Increase the size of PCIe configuration space to 8kB from 4kB,
because 4kB for cfg0 and 4kB for cfg1 are required respectively.
If 2kB for cfg0 and 2kB for cfg1 are set, it will make problems
when a PCIe card having multiple EPs below a bridge is used.

Suggested-by: Pratyush Anand pratyush.an...@st.com
Signed-off-by: Jingoo Han jg1@samsung.com
---
Changes since v1:
- Fix unintentional modification of I/O size, per Pratyush Anand.

 arch/arm/boot/dts/exynos5440.dtsi |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
b/arch/arm/boot/dts/exynos5440.dtsi
index d600733..94b2cea 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -281,9 +281,9 @@
#address-cells = 3;
#size-cells = 2;
device_type = pci;
-   ranges = 0x0800 0 0x4000 0x4000 0 0x1000   /* 
configuration space */
- 0x8100 0 0  0x40001000 0 0x0001   /* 
downstream I/O */
- 0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
non-prefetchable memory */
+   ranges = 0x0800 0 0x4000 0x4000 0 0x2000   /* 
configuration space */
+ 0x8100 0 0  0x40002000 0 0x0001   /* 
downstream I/O */
+ 0x8200 0 0x40012000 0x40012000 0 0x1ffee000; /* 
non-prefetchable memory */
#interrupt-cells = 1;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0x0 0 gic 53;
@@ -302,9 +302,9 @@
#address-cells = 3;
#size-cells = 2;
device_type = pci;
-   ranges = 0x0800 0 0x6000 0x6000 0 0x1000   /* 
configuration space */
- 0x8100 0 0  0x60001000 0 0x0001   /* 
downstream I/O */
- 0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
non-prefetchable memory */
+   ranges = 0x0800 0 0x6000 0x6000 0 0x2000   /* 
configuration space */
+ 0x8100 0 0  0x60002000 0 0x0001   /* 
downstream I/O */
+ 0x8200 0 0x60012000 0x60012000 0 0x1ffee000; /* 
non-prefetchable memory */
#interrupt-cells = 1;
interrupt-map-mask = 0 0 0 0;
interrupt-map = 0x0 0 gic 56;
-- 
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: [PATCHv3 5/8] devfreq: exynos4: Use SET_SYSTEM_SLEEP_PM_OPS macro

2014-03-16 Thread Jingoo Han
On Friday, March 14, 2014 6:30 PM, Chanwoo Choi wrote:
 
 This patch use SET_SYSTEM_SLEEP_PM_OPS macro instead of legacy method.
 
 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 ---
  drivers/devfreq/exynos/exynos4_bus.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
 b/drivers/devfreq/exynos/exynos4_bus.c
 index 60539e8..e5d2c5a 100644
 --- a/drivers/devfreq/exynos/exynos4_bus.c
 +++ b/drivers/devfreq/exynos/exynos4_bus.c
 @@ -1247,6 +1247,7 @@ static int exynos4_busfreq_remove(struct 
 platform_device *pdev)
   return 0;
  }
 
 +#ifdef CONFIG_PM_SLEEP
  static int exynos4_busfreq_resume(struct device *dev)
  {
   struct busfreq_data *data = dev_get_drvdata(dev);
 @@ -1254,9 +1255,10 @@ static int exynos4_busfreq_resume(struct device *dev)
   busfreq_mon_reset(data);
   return 0;
  }
 +#endif
 
  static const struct dev_pm_ops exynos4_busfreq_pm = {
 - .resume = exynos4_busfreq_resume,
 + SET_SYSTEM_SLEEP_PM_OPS(NULL, exynos4_busfreq_resume)

Hi Chanwoo Choi,

How about using SIMPLE_DEV_PM_OPS instead of SET_SYSTEM_SLEEP_PM_OPS?
SIMPLE_DEV_PM_OPS is simpler as below.

static SIMPLE_DEV_PM_OPS(exynos4_busfreq_pm, NULL, exynos4_busfreq_resume);

However, if runtime pm functions will be added later,
SIMPLE_DEV_PM_OPS is not necessary.

Best regards,
Jingoo Han

  };
 
  static const struct platform_device_id exynos4_busfreq_id[] = {
 --
 1.8.0

--
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/6] PCI: tegra: use new OF interrupt mapping when possible

2014-03-06 Thread Jingoo Han
On Friday, March 07, 2014 9:25 AM, Arnd Bergmann wrote:
 On Thursday 06 March 2014, Lucas Stach wrote:
  Am Donnerstag, den 06.03.2014, 10:36 -0700 schrieb Stephen Warren:
   On 03/05/2014 06:25 AM, Lucas Stach wrote:
This is the recommended method of doing the IRQ
mapping. For old devicetrees we fall back to the
previous practice.
  
   Tested-by: Stephen Warren swar...@nvidia.com
  
   I tested both with and without patch 1/6, and the PCIe-based NIC on
   Beaver worked fine either way. Without patch 1/6, I do see:
  
   pci :00:01.0: of_irq_parse_pci() failed with rc=-22
  
   ... but that seems reasonable given that the DT that of_irq_parse_pci()
   parses is missing, and did correctly trigger the fallback path, so
   everything still worked.
 
  Yes, this should be normal. It spits this error for old DTs, but keeps
  doing the right thing. I'm not sure if we should downgrade this to info
  or dbg.
 
 No, I think printing an error like this is appropriate: it is an incentive
 to update the dts files, but doesn't look too urgent as long as everything
 still works.

+1

I agree with Arnd's opinion. I think that all dts files should be
updated properly. This error message can be the good way to do it.
Thank you.

Best regards,
Jingoo Han

--
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 4/6] ARM: dts: exynos5440: fix PCIe interrupt mapping

2014-03-05 Thread Jingoo Han
On Wednesday, March 05, 2014 10:26 PM, Lucas Stach wrote:
 
 So it actually works.
 
 Signed-off-by: Lucas Stach l.st...@pengutronix.de
 Acked-by: Arnd Bergmann a...@arndb.de

Acked-by: Jingoo Han jg1@samsung.com

It works properly on Exynos platform.
Thank you.

Best regards,
Jingoo Han

 ---
 v2: fix build breakage by including arm-gic.h
 ---
  arch/arm/boot/dts/exynos5440.dtsi | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 02a0a1226cef..7628e2edf1b6 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -9,6 +9,8 @@
   * published by the Free Software Foundation.
  */
 
 +#include dt-bindings/interrupt-controller/arm-gic.h
 +
  #include skeleton.dtsi
 
  / {
 @@ -274,7 +276,7 @@
 0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
 non-prefetchable memory */
   #interrupt-cells = 1;
   interrupt-map-mask = 0 0 0 0;
 - interrupt-map = 0x0 0 gic 53;
 + interrupt-map = 0 0 0 0 gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;
   num-lanes = 4;
   status = disabled;
   };
 @@ -295,7 +297,7 @@
 0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
 non-prefetchable memory */
   #interrupt-cells = 1;
   interrupt-map-mask = 0 0 0 0;
 - interrupt-map = 0x0 0 gic 56;
 + interrupt-map = 0 0 0 0 gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
   num-lanes = 4;
   status = disabled;
   };
 --
 1.9.0

--
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 6/6] PCI: designware: use new OF interrupt mapping when possible

2014-03-05 Thread Jingoo Han
On Wednesday, March 05, 2014 10:26 PM, Lucas Stach wrote:
 
 This is the recommended method of doing the IRQ
 mapping. For old devicetrees we fall back to the
 previous practice.
 
 Signed-off-by: Lucas Stach l.st...@pengutronix.de
 Acked-by: Arnd Bergmann a...@arndb.de

(+cc Mohit KUMAR, Richard Zhu, Pratyush Anand, Marek Vasut,
   Kishon Vijay Abraham I)

Acked-by: Jingoo Han jg1@samsung.com

It works properly on Exynos platform.
Thank you.

Best regards,
Jingoo Han

 ---
 v2: pass in parent dev to relevant functions, to make DT parsing
 work (spotted by Tim Harvey thar...@gateworks.com)
 ---
  drivers/pci/host/pcie-designware.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/pci/host/pcie-designware.c 
 b/drivers/pci/host/pcie-designware.c
 index 17ce88f79d2b..98c118e04dba 100644
 --- a/drivers/pci/host/pcie-designware.c
 +++ b/drivers/pci/host/pcie-designware.c
 @@ -17,6 +17,7 @@
  #include linux/module.h
  #include linux/msi.h
  #include linux/of_address.h
 +#include linux/of_pci.h
  #include linux/pci.h
  #include linux/pci_regs.h
  #include linux/types.h
 @@ -492,7 +493,7 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
   dw_pci.nr_controllers = 1;
   dw_pci.private_data = (void **)pp;
 
 - pci_common_init(dw_pci);
 + pci_common_init_dev(pp-dev, dw_pci);
   pci_assign_unassigned_resources();
  #ifdef CONFIG_PCI_DOMAINS
   dw_pci.domain++;
 @@ -725,7 +726,7 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct 
 pci_sys_data *sys)
 
   if (pp) {
   pp-root_bus_nr = sys-busnr;
 - bus = pci_scan_root_bus(NULL, sys-busnr, dw_pcie_ops,
 + bus = pci_scan_root_bus(pp-dev, sys-busnr, dw_pcie_ops,
   sys, sys-resources);
   } else {
   bus = NULL;
 @@ -738,8 +739,13 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct 
 pci_sys_data *sys)
  static int dw_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
  {
   struct pcie_port *pp = sys_to_pcie(dev-bus-sysdata);
 + int irq;
 
 - return pp-irq;
 + irq = of_irq_parse_and_map_pci(dev, slot, pin);
 + if (!irq)
 + irq = pp-irq;
 +
 + return irq;
  }
 
  static void dw_pcie_add_bus(struct pci_bus *bus)
 --
 1.9.0

--
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/7] PCI irq mapping fixes and cleanups

2014-03-03 Thread Jingoo Han
On Sunday, March 02, 2014 3:31 AM, Jason Gunthorpe wrote:
 On Fri, Feb 28, 2014 at 04:53:33PM -0800, Tim Harvey wrote:
 
  In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()'
  always returns -EINVAL because it can't find a dt node for the host
  bridge:
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60.
 
 There may be some kind of issue in the pcie-designware.c:
 
 static struct pci_bus *dw_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 {
 struct pci_bus *bus;
 struct pcie_port *pp = sys_to_pcie(sys);
 
 if (pp) {
 pp-root_bus_nr = sys-busnr;
 bus = pci_scan_root_bus(NULL, sys-busnr, dw_pcie_ops,
  ^^^
  Shouldn't be null for DT cases.
 
 Perhaps since the driver doesn't pass in a parent pointer, no parent
 device is associated with the struct pci_bus that gets created, so
 pci_bus_to_OF_node will always fail and the DT PCI mechanisms become
 broken.

Jason,
Thank you for your advice. :-)

Tim,
I tested the following as Jason guided.
You can test i.MX PCIe with this.

./drivers/pci/host/pcie-designware.c
@@ -726,7 +727,7 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct 
pci_sys_data *sys)

if (pp) {
pp-root_bus_nr = sys-busnr;
-   bus = pci_scan_root_bus(NULL, sys-busnr, dw_pcie_ops,
+   bus = pci_scan_root_bus(pp-dev, sys-busnr, dw_pcie_ops,
sys, sys-resources);
} else {
bus = NULL;

However, I think that we may need to replace 'pci_common_init()'
with 'pci_common_init_dev()'.

Best regards,
Jingoo Han

--
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 4/7] ARM: dts: exynos5440: fix PCIe interrupt mapping

2014-03-02 Thread Jingoo Han
On Saturday, March 01, 2014 2:29 AM, Lucas Stach wrote:
 
 So it actually works.
 
 Signed-off-by: Lucas Stach l.st...@pengutronix.de
 ---
  arch/arm/boot/dts/exynos5440.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
 b/arch/arm/boot/dts/exynos5440.dtsi
 index 02a0a1226cef..65d425d9ec27 100644
 --- a/arch/arm/boot/dts/exynos5440.dtsi
 +++ b/arch/arm/boot/dts/exynos5440.dtsi
 @@ -274,7 +274,7 @@
 0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
 non-prefetchable memory */
   #interrupt-cells = 1;
   interrupt-map-mask = 0 0 0 0;
 - interrupt-map = 0x0 0 gic 53;
 + interrupt-map = 0 0 0 0 gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;

It makes build errors as below:

DTC arch/arm/boot/dts/exynos5440-ssdk5440.dtb
Error: arch/arm/boot/dts/exynos5440.dtsi:289.33-34 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/arm/boot/dts/exynos5440-ssdk5440.dtb] Error 1
make: *** [exynos5440-ssdk5440.dtb] Error 2

Would you fix it?

Best regards,
Jingoo Han

   num-lanes = 4;
   status = disabled;
   };
 @@ -295,7 +295,7 @@
 0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
 non-prefetchable memory */
   #interrupt-cells = 1;
   interrupt-map-mask = 0 0 0 0;
 - interrupt-map = 0x0 0 gic 56;
 + interrupt-map = 0 0 0 0 gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
   num-lanes = 4;
   status = disabled;
   };
 --
 1.8.5.3

--
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 4/7] ARM: dts: exynos5440: fix PCIe interrupt mapping

2014-03-02 Thread Jingoo Han
On Monday, March 03, 2014 4:41 PM, Jingoo Han wrote:
 On Saturday, March 01, 2014 2:29 AM, Lucas Stach wrote:
 
  So it actually works.
 
  Signed-off-by: Lucas Stach l.st...@pengutronix.de
  ---
   arch/arm/boot/dts/exynos5440.dtsi | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
  b/arch/arm/boot/dts/exynos5440.dtsi
  index 02a0a1226cef..65d425d9ec27 100644
  --- a/arch/arm/boot/dts/exynos5440.dtsi
  +++ b/arch/arm/boot/dts/exynos5440.dtsi
  @@ -274,7 +274,7 @@
0x8200 0 0x40011000 0x40011000 0 0x1ffef000; /* 
  non-prefetchable memory */
  #interrupt-cells = 1;
  interrupt-map-mask = 0 0 0 0;
  -   interrupt-map = 0x0 0 gic 53;
  +   interrupt-map = 0 0 0 0 gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH;
 
 It makes build errors as below:
 
 DTC arch/arm/boot/dts/exynos5440-ssdk5440.dtb
 Error: arch/arm/boot/dts/exynos5440.dtsi:289.33-34 syntax error
 FATAL ERROR: Unable to parse input tree
 make[1]: *** [arch/arm/boot/dts/exynos5440-ssdk5440.dtb] Error 1
 make: *** [exynos5440-ssdk5440.dtb] Error 2
 
 Would you fix it?

I fixed build errors after including 'arm-gic.h' as below:

--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -9,6 +9,8 @@
  * published by the Free Software Foundation.
 */

+#include dt-bindings/interrupt-controller/arm-gic.h
+
 #include skeleton.dtsi

Would you confirm this?

Best regards,
Jingoo Han

 
  num-lanes = 4;
  status = disabled;
  };
  @@ -295,7 +295,7 @@
0x8200 0 0x60011000 0x60011000 0 0x1ffef000; /* 
  non-prefetchable memory */
  #interrupt-cells = 1;
  interrupt-map-mask = 0 0 0 0;
  -   interrupt-map = 0x0 0 gic 56;
  +   interrupt-map = 0 0 0 0 gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
  num-lanes = 4;
  status = disabled;
  };
  --
  1.8.5.3

--
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 v3 2/2] phy: Select PHY_EXYNOS_DP_VIDEO by default for ARCH_EXYNOS

2014-02-23 Thread Jingoo Han
On Saturday, February 22, 2014 1:44 AM, Sylwester Nawrocki wrote:
 
 Instead of requiring user to figure out when PHY_EXYNOS_DP_VIDEO needs
 to be selected select it by default for Exynos SoCs. Also enable it
 when COMPILE_TEST is selected. If required the display port PHY driver
 can be then disabled or compiled in as module.
 
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Best regards,
Jingoo Han

 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
 Changes since v2:
  - s/default y/default ARCH_EXYNOS
 
 Changes since first version:
  - use ARCH_EXYNOS instead of ARCH_EXYNOS4 || ARCH_EXYNOS5
  - add dependency on COMPILE_TEST
 ---
  drivers/phy/Kconfig |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index d71be95..fe1b1f4 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -57,6 +57,8 @@ config TWL4030_USB
  config PHY_EXYNOS_DP_VIDEO
   tristate EXYNOS SoC series Display Port PHY driver
   depends on OF
 + depends on ARCH_EXYNOS || COMPILE_TEST
 + default ARCH_EXYNOS
   select GENERIC_PHY
   help
 Support for Display Port PHY found on Samsung EXYNOS SoCs.
 --
 1.7.9.5

Re: [RFC PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.

2014-02-11 Thread Jingoo Han
On Wednesday, February 12, 2014 2:34 PM, Stephen Warren wrote:
 On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
  From: Dinh Nguyen dingu...@altera.com
 
  This means that the driver can be in host or peripheral mode when the 
  appropriate
  connector is used. When an A-cable is plugged in, the driver behaves in host
  mode, and when a B-cable is used, the driver will be in peripheral mode.
 
 Sorry for the slow response. When building ARCH=arm bcm2835_defconfig, I
 get build errors:
 
  drivers/built-in.o: In function `dwc2_gadget_init':
  drivers/usb/dwc2/s3c-hsotg.c:3335: undefined reference to 
  `usb_add_gadget_udc'
  drivers/built-in.o: In function `s3c_hsotg_remove':
  drivers/usb/dwc2/s3c-hsotg.c:3358: undefined reference to 
  `usb_del_gadget_udc'
  drivers/usb/dwc2/s3c-hsotg.c:3364: undefined reference to 
  `usb_gadget_unregister_driver'

These errors happen when CONFIG_USB_GADGET=n. 's3c-hsotg.c'
supports only gadget mode. In the case of USB_DWC2_HOST mode,
CONFIG_USB_GADGET is NOT enabled. I don't know how to solve it.

Best regards,
Jingoo Han

--
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 PATCHv1] usb: dwc2: Combine the dwc2 and s3c_hsotg into a single USB DRD driver.

2014-02-05 Thread Jingoo Han
On Thursday, February 06, 2014 4:21 AM, Paul Zimmerman wrote:
 On Tuesday, February 04, 2014 10:14 PM, Dinh Nguyen wrote:
  On Wed, 2014-02-05 at 00:42 +, Paul Zimmerman wrote:
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Tuesday, February 04, 2014 1:46 PM
   
From: Dinh Nguyen dingu...@altera.com
   
This means that the driver can be in host or peripheral mode when the 
appropriate
connector is used. When an A-cable is plugged in, the driver behaves in 
host
mode, and when a B-cable is used, the driver will be in peripheral mode.
   
This commit:
- Replaces in the defines used in s3c_hsotg.h with the defines used in 
the dwc2
  hw.h defines.
- Use the dw2_hsotg as the unified data structure for the host/gadget.
- Uses the dwc2 IRQ handler for host/gadget.
- A single spinlock.
  
   Hi Dinh,
  
   Putting all of these changes into a single patch makes them unreviewable
   as far I am concerned. You need to break this into a series of smaller
   patches. I would suggest something like this:
  
   1 of n:  Make the minimum changes to the dwc2 header files needed to
support s3c-hsotg as a standalone driver.
   2 of n:  Make the spelling changes to s3c-hsotg.c needed to use the dwc2
headers, and move it to the dwc2/ directory. Make the Kconfig
and Makefile changes needed for the move. Delete s3c-hsotg.h.
   3 of n:  Move the struct defines etc. from s3c-hsotg.c to the dwc2
header files.
   .. of n: Make the changes required to combine the functionality of
both drivers into one. Preferably this would also be a series
of patches instead of one big one.
  
   At each step of the series, both drivers should still compile and work.
 
  I agree. My original thought was to also split this patch, but I just
  didn't know how to split it. This is why I designated as an RFC. I was
  really looking for feedback as this is the correct way to combine this
  driver. I was also looking for testing purpose to make sure I did not
  break anything for the s3c platform.
 
 The problem is, it's almost impossible to see what the functional
 changes are because of all the noise of the other changes.

Yes, right. I think so, too.

 
  
   Also, please follow the patch style used on the linux lists.
   'git format-patch --cover-letter' should do most of this for you
   automatically.
 
  I did use --cover-letter on this patch series.
 
  
   And you should probably trim the Cc list to something more reasonable.
 
  I looked through all the commits for the dwc2 driver for the cc list. I
  also CC a bunch of the Samsung people as I figured that the biggest
  impact of the work would affect the s3c folks.
 
 I would suggest just CCing the Samsung folks to start with, since s3c-hsotg
 is a driver for their hardware. And the linux-usb and linux-samsung-soc
 lists.

Please keep CCing linux-samsung-soc. Some Samsung folks will test
the patches with Samsung hardware. Thank you.

Best regards,
Jingoo Han

--
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 0/3] exynos: arch: add support for exynos5260 SoC

2014-02-04 Thread Jingoo Han
On Wednesday, February 05, 2014 2:16 PM, Rahul Sharma wrote:
 
 This is re-spin of V2 which add arch-side support for exynos5260 SoC.
 
 V2:
   1) Split up DT patch into SoC and Board patch.
 
 This series is based on Kukjin's for-next branch at
 http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
 
 Pankaj Dubey (1):
   ARM: EXYNOS: initial board support for exynos5260 SoC
 
 Rahul Sharma (2):
   ARM: dts: add dts files for exynos5260 SoC
   ARM: dts: add dts files for xyref5260 board
 
  arch/arm/boot/dts/Makefile  |1 +
  arch/arm/boot/dts/exynos5260-pinctrl.dtsi   |  572 
 +++
  arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts |  105 +
  arch/arm/boot/dts/exynos5260.dtsi   |  317 +
  arch/arm/mach-exynos/Kconfig|9 +
  arch/arm/mach-exynos/common.c   |   18 +
  arch/arm/mach-exynos/include/mach/map.h |1 +
  arch/arm/mach-exynos/mach-exynos5-dt.c  |1 +
  arch/arm/plat-samsung/include/plat/cpu.h|8 +
  arch/arm/plat-samsung/include/plat/map-s5p.h|1 +
  10 files changed, 1033 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
  create mode 100644 arch/arm/boot/dts/exynos5260-xyref5260-evt0.dts
  create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
  mode change 100644 = 100755 arch/arm/mach-exynos/include/mach/map.h
  mode change 100644 = 100755 arch/arm/mach-exynos/mach-exynos5-dt.c
  mode change 100644 = 100755 arch/arm/plat-samsung/include/plat/cpu.h

The mode of these three files should NOT be changed to 100755.
Please fix it.

Best regards,
Jingoo Han

--
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] Documentation: devicetree: mct: Fix counter bit of CPU local timers

2014-01-22 Thread Jingoo Han
On Tuesday, January 21, 2014 6:03 PM, Jingoo Han wrote:
 
 According to the datasheet of Exynos SoCs, the counter bit
 of CPU local timers is 31-bit, not 32-bit; thus, it should
 be fixed.

Please, ignore this patch.
There is a 31-bit counter in CPU local timers; however,
FRC (free running down-counters) of CPU local timers is
32-bit. Thus, there is no need to fix it.
Thank you.

Best regards,
Jingoo Han

 
 Signed-off-by: Jingoo Han jg1@samsung.com
 ---
  Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git 
 a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
 b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
 index 167d5da..8c77791 100644
 --- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
 +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
 @@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
  The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
  global timer and CPU local timers. The global timer is a 64-bit free running
  up-counter and can generate 4 interrupts when the counter reaches one of the
 -four preset counter values. The CPU local timers are 32-bit free running
 +four preset counter values. The CPU local timers are 31-bit free running
  down-counters and generate an interrupt when the counter expires. There is
  one CPU local timer instantiated in MCT for every CPU in the system.
 
 --
 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] Documentation: devicetree: mct: Fix counter bit of CPU local timers

2014-01-21 Thread Jingoo Han
According to the datasheet of Exynos SoCs, the counter bit
of CPU local timers is 31-bit, not 32-bit; thus, it should
be fixed.

Signed-off-by: Jingoo Han jg1@samsung.com
---
 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index 167d5da..8c77791 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -3,7 +3,7 @@ Samsung's Multi Core Timer (MCT)
 The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
 global timer and CPU local timers. The global timer is a 64-bit free running
 up-counter and can generate 4 interrupts when the counter reaches one of the
-four preset counter values. The CPU local timers are 32-bit free running
+four preset counter values. The CPU local timers are 31-bit free running
 down-counters and generate an interrupt when the counter expires. There is
 one CPU local timer instantiated in MCT for every CPU in the system.
 
-- 
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] ARM: exynos_defconfig: Update EHCI config entry

2014-01-16 Thread Jingoo Han
On Thursday, January 16, 2014 5:34 PM, Tushar Behera wrote:
 
 Commit 29824c167bea (USB: host: Rename ehci-s5p to ehci-exynos)
 renamed the config entry of EHCI host driver. Similar change needs
 to be done in exynos_defconfig as well.
 
 Signed-off-by: Tushar Behera tushar.beh...@linaro.org

(+cc Vivek Gautam, Yulgon Kim, Julius Werner)

Reviewed-by: Jingoo Han jg1@samsung.com

Yes, right.
I overlooked 'exynos_defconfig', when I changed the name of
Exynos EHCI driver. Thank you for sending the patch. :-)

Best regards,
Jingoo Han

 ---
  arch/arm/configs/exynos_defconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index dbe1f1c..4ce7b70 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -94,7 +94,7 @@ CONFIG_FONT_7x14=y
  CONFIG_LOGO=y
  CONFIG_USB=y
  CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_EHCI_S5P=y
 +CONFIG_USB_EHCI_EXYNOS=y
  CONFIG_USB_STORAGE=y
  CONFIG_USB_DWC3=y
  CONFIG_USB_PHY=y
 --
 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


  1   2   3   4   5   6   >