Re: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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] usb: dwc3: exynos: remove usb_phy_generic support
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
))
+ 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
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
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
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
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
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
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
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
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
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
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: dpi: Fix NULL pointer dereference with legacy bindings
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
'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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
Re: [PATCH -next] clk: exynos-audss: remove redundant dev_err call in exynos_audss_clk_probe()
On Tuesday, January 14, 2014 11:06 AM, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
It looks good. This error message is redundant; thus it
should be removed.
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/clk/samsung/clk-exynos-audss.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos-audss.c
b/drivers/clk/samsung/clk-exynos-audss.c
index 884187f..01ef381 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -94,10 +94,8 @@ static int exynos_audss_clk_probe(struct platform_device
*pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg_base = devm_ioremap_resource(pdev-dev, res);
- if (IS_ERR(reg_base)) {
- dev_err(pdev-dev, failed to map audss registers\n);
+ if (IS_ERR(reg_base))
return PTR_ERR(reg_base);
- }
clk_table = devm_kzalloc(pdev-dev,
sizeof(struct clk *) * EXYNOS_AUDSS_MAX_CLKS,
--
--
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] exynos4-is: Compile runtime PM callbacks in conditionally
On Wednesday, January 08, 2014 7:09 AM, Sylwester Nawrocki wrote:
Enclose the runtime PM helpers in #ifdef CONFIG_PM_RUNTIME/#endif
to avoid following compile warning when CONFIG_PM_RUNTIME is disabled:
CC drivers/media/platform/exynos4-is/fimc-core.o
drivers/media/platform/exynos4-is/fimc-core.c:1040:12: warning:
‘fimc_runtime_resume’ defined but not
used
drivers/media/platform/exynos4-is/fimc-core.c:1057:12: warning:
‘fimc_runtime_suspend’ defined but not
used
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Right, '#ifdef CONFIG_PM_RUNTIME' should be used in order to
fix the compile warning.
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/media/platform/exynos4-is/fimc-core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-
core.c
index dcbea59..da2fc86 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1037,6 +1037,7 @@ err_sclk:
return ret;
}
+#ifdef CONFIG_PM_RUNTIME
static int fimc_runtime_resume(struct device *dev)
{
struct fimc_dev *fimc = dev_get_drvdata(dev);
@@ -1069,6 +1070,7 @@ static int fimc_runtime_suspend(struct device *dev)
dbg(fimc%d: state: 0x%lx, fimc-id, fimc-state);
return ret;
}
+#endif
#ifdef CONFIG_PM_SLEEP
static int fimc_resume(struct device *dev)
--
1.7.4.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
