Re: [PATCH v2 2/2] ARM: dts: exynos5250: Add clocks to DISP1 domain

2015-10-16 Thread Tomeu Vizoso 
On 10/16/2015 01:44 AM, Krzysztof Kozlowski wrote:
> On 15.10.2015 19:31, Tomeu Vizoso wrote:
>> Adds to the node of the DISP1 power domain the two clocks that need to
>> be reparented while the domain is powered off:
>> CLK_MOUT_ACLK200_DISP1_SUB and CLK_MOUT_ACLK300_DISP1_SUB.
>>
>> Otherwise the state is unknown at power up and the mixer's clocks are
>> all messed up.
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
>> Link: http://lkml.kernel.org/g/561cdc33.7050...@collabora.com
>> ---
>>
>>
>>  arch/arm/boot/dts/exynos5250.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index b24610ea8c2a..88b9cf5f226f 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -130,6 +130,10 @@
>>  compatible = "samsung,exynos4210-pd";
>>  reg = <0x100440A0 0x20>;
>>  #power-domain-cells = <0>;
>> +clocks = < CLK_FIN_PLL>,
>> + < CLK_MOUT_ACLK200_DISP1_SUB>,
>> + < CLK_MOUT_ACLK300_DISP1_SUB>;
>> +clock-names = "oscclk", "clk0", "clk1";
>>  };
>>  
>>  clock: clock-controller@1001 {
>>
> 
> I reviewed it already. Any changes here since v1?

No, I just forgot to add your r-b tag, sorry about that.

Thanks,

Tomeu

--
To unsubscribe from this list: send the line "unsubscribe linux-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: [RFT PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common

2015-10-16 Thread Tomeu Vizoso 
On 15 October 2015 at 18:51, Javier Martinez Canillas
<jav...@osg.samsung.com> wrote:
> The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
> can't neither be removed nor be detected. But the node isn't marked
> as non-removable and instead has the broken-cd DT property.
>
> This causes the device to be removed when the system enters into a
> suspend state and the following warnings is shown after a resume:
>
> [  181.944636] mmc2: error -2 during resume (card was removed?)
>
> Also remove the card-detect-delay property that is not needed with
> non-removable.
>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Tested-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

Thanks,

Tomeu


>
> Changes since v1:
> - Remove card-detect-delay property as well.
> - Use the correct mmc node. Suggested by Tomeu.
>
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> index 0a7f408824d8..1822c502a25a 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -552,10 +552,9 @@
>  _3 {
> status = "okay";
> num-slots = <1>;
> -   broken-cd;
> +   non-removable;
> cap-sdio-irq;
> keep-power-in-suspend;
> -   card-detect-delay = <200>;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <2 3>;
> samsung,dw-mshc-ddr-timing = <1 2>;
> --
> 2.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-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: [RFT PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common

2015-10-16 Thread Tomeu Vizoso 
On 15 October 2015 at 18:51, Javier Martinez Canillas
<jav...@osg.samsung.com> wrote:
> The eMMC is non-removable so mark it using the non-removable DT
> property to avoid having to redetect it after a suspend/resume.
>
> Also remove the card-detect-delay property that is not needed with
> non-removable.
>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Reviewed-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Tested-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

Thanks,

Tomeu

> ---
>
> Changes since v1:
> - None, new patch.
>
>  arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
> b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> index 1822c502a25a..5cb33ba5e296 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -520,8 +520,7 @@
>  _0 {
> status = "okay";
> num-slots = <1>;
> -   broken-cd;
> -   card-detect-delay = <200>;
> +   non-removable;
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <2 3>;
> samsung,dw-mshc-ddr-timing = <1 2>;
> --
> 2.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] ARM: dts: exynos5250: Add clocks to DISP1 domain

2015-10-15 Thread Tomeu Vizoso 
Adds to the node of the DISP1 power domain the two clocks that need to
be reparented while the domain is powered off:
CLK_MOUT_ACLK200_DISP1_SUB and CLK_MOUT_ACLK300_DISP1_SUB.

Otherwise the state is unknown at power up and the mixer's clocks are
all messed up.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Link: http://lkml.kernel.org/g/561cdc33.7050...@collabora.com
---


 arch/arm/boot/dts/exynos5250.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index b24610ea8c2a..88b9cf5f226f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -130,6 +130,10 @@
compatible = "samsung,exynos4210-pd";
reg = <0x100440A0 0x20>;
#power-domain-cells = <0>;
+   clocks = < CLK_FIN_PLL>,
+< CLK_MOUT_ACLK200_DISP1_SUB>,
+< CLK_MOUT_ACLK300_DISP1_SUB>;
+   clock-names = "oscclk", "clk0", "clk1";
};
 
clock: clock-controller@1001 {
-- 
2.5.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

[PATCH v2 0/2] Fix display on second resume on 5250-snow

2015-10-15 Thread Tomeu Vizoso 
Hi,

as discussed in [0], currently on the second resume from memory the
display is broken on Snow boards (ARM Samsung Series 3 Chromebook).

The reason is that on resume the contents of register SRC_TOP3 aren't
what the kernel thinks they are because the HW (or FW) is doing some
clock reparenting beneath our feet.

This series tasks the kernel to do the reparenting itself so that the HW
state always matches the kernel's internal state.

Thanks,

Tomeu

[0] http://lkml.kernel.org/g/561cdc33.7050...@collabora.com

Changes in v2:
- Reuse mout_aclk200_p
- Rename div_aclk300 as div_aclk300_disp

Tomeu Vizoso (2):
  clk: samsung: exynos5250: Add DISP1 clocks
  ARM: dts: exynos5250: Add clocks to DISP1 domain

 arch/arm/boot/dts/exynos5250.dtsi  |  4 
 drivers/clk/samsung/clk-exynos5250.c   | 14 +-
 include/dt-bindings/clock/exynos5250.h |  4 +++-
 3 files changed, 20 insertions(+), 2 deletions(-)

-- 
2.5.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

[PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks

2015-10-15 Thread Tomeu Vizoso 
When the DISP1 power domain is powered off, there's two clocks that need
to be temporarily reparented to OSC, and back to their original parents
when the domain is powered on again.

We expose these two clocks in the DT bindings so that the DT node of the
power domain can reference them.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Acked-by: Stephen Boyd <sb...@codeaurora.org>
---

Changes in v2:
- Reuse mout_aclk200_p
- Rename div_aclk300 as div_aclk300_disp

 drivers/clk/samsung/clk-exynos5250.c   | 14 +-
 include/dt-bindings/clock/exynos5250.h |  4 +++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 55b83c7ef878..5bebf8cb0d70 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -222,9 +222,13 @@ PNAME(mout_mpll_user_p)= { "fin_pll", "mout_mpll" };
 PNAME(mout_bpll_user_p)= { "fin_pll", "mout_bpll" };
 PNAME(mout_aclk166_p)  = { "mout_cpll", "mout_mpll_user" };
 PNAME(mout_aclk200_p)  = { "mout_mpll_user", "mout_bpll_user" };
+PNAME(mout_aclk300_p)  = { "mout_aclk300_disp1_mid",
+   "mout_aclk300_disp1_mid1" };
 PNAME(mout_aclk400_p)  = { "mout_aclk400_g3d_mid", "mout_gpll" };
 PNAME(mout_aclk200_sub_p) = { "fin_pll", "div_aclk200" };
 PNAME(mout_aclk266_sub_p) = { "fin_pll", "div_aclk266" };
+PNAME(mout_aclk300_sub_p) = { "fin_pll", "div_aclk300_disp" };
+PNAME(mout_aclk300_disp1_mid1_p) = { "mout_vpll", "mout_cpll" };
 PNAME(mout_aclk333_sub_p) = { "fin_pll", "div_aclk333" };
 PNAME(mout_aclk400_isp_sub_p) = { "fin_pll", "div_aclk400_isp" };
 PNAME(mout_hdmi_p) = { "div_hdmi_pixel", "sclk_hdmiphy" };
@@ -303,9 +307,13 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
 */
MUX(0, "mout_aclk166", mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(0, "mout_aclk200", mout_aclk200_p, SRC_TOP0, 12, 1),
+   MUX(0, "mout_aclk300_disp1_mid", mout_aclk200_p, SRC_TOP0, 14, 1),
+   MUX(0, "mout_aclk300", mout_aclk300_p, SRC_TOP0, 15, 1),
MUX(0, "mout_aclk333", mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(0, "mout_aclk400_g3d_mid", mout_aclk200_p, SRC_TOP0, 20, 1),
 
+   MUX(0, "mout_aclk300_disp1_mid1", mout_aclk300_disp1_mid1_p, SRC_TOP1,
+   8, 1),
MUX(0, "mout_aclk400_isp", mout_aclk200_p, SRC_TOP1, 24, 1),
MUX(0, "mout_aclk400_g3d", mout_aclk400_p, SRC_TOP1, 28, 1),
 
@@ -316,7 +324,10 @@ static struct samsung_mux_clock exynos5250_mux_clks[] 
__initdata = {
MUX(0, "mout_bpll_user", mout_bpll_user_p, SRC_TOP2, 24, 1),
MUX(CLK_MOUT_GPLL, "mout_gpll", mout_gpll_p, SRC_TOP2, 28, 1),
 
-   MUX(0, "mout_aclk200_disp1_sub", mout_aclk200_sub_p, SRC_TOP3, 4, 1),
+   MUX(CLK_MOUT_ACLK200_DISP1_SUB, "mout_aclk200_disp1_sub",
+   mout_aclk200_sub_p, SRC_TOP3, 4, 1),
+   MUX(CLK_MOUT_ACLK300_DISP1_SUB, "mout_aclk300_disp1_sub",
+   mout_aclk300_sub_p, SRC_TOP3, 6, 1),
MUX(0, "mout_aclk266_gscl_sub", mout_aclk266_sub_p, SRC_TOP3, 8, 1),
MUX(0, "mout_aclk_266_isp_sub", mout_aclk266_sub_p, SRC_TOP3, 16, 1),
MUX(0, "mout_aclk_400_isp_sub", mout_aclk400_isp_sub_p,
@@ -392,6 +403,7 @@ static struct samsung_div_clock exynos5250_div_clks[] 
__initdata = {
DIV(0, "div_aclk333", "mout_aclk333", DIV_TOP0, 20, 3),
DIV(0, "div_aclk400_g3d", "mout_aclk400_g3d", DIV_TOP0,
24, 3),
+   DIV(0, "div_aclk300_disp", "mout_aclk300", DIV_TOP0, 28, 3),
 
DIV(0, "div_aclk400_isp", "mout_aclk400_isp", DIV_TOP1, 20, 3),
DIV(0, "div_aclk66_pre", "mout_mpll_user", DIV_TOP1, 24, 3),
diff --git a/include/dt-bindings/clock/exynos5250.h 
b/include/dt-bindings/clock/exynos5250.h
index 8183d1c237d9..15508adcdfde 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -173,8 +173,10 @@
 /* mux clocks */
 #define CLK_MOUT_HDMI  1024
 #define CLK_MOUT_GPLL  1025
+#define CLK_MOUT_ACLK200_DISP1_SUB 1026
+#define CLK_MOUT_ACLK300_DISP1_SUB 1027
 
 /* must be greater than maximal clock id */
-#define CLK_NR_CLKS1026
+#define CLK_NR_CLKS1028
 
 #endif /* _DT_BINDINGS_CLOCK_EXYNOS_5250_H */
-- 
2.5.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

[PATCH v1 2/2] ARM: dts: exynos5250: Add clocks to DISP1 domain

2015-10-14 Thread Tomeu Vizoso 
Adds to the node of the DISP1 power domain the two clocks that need to
be reparented while the domain is powered off:
CLK_MOUT_ACLK200_DISP1_SUB and CLK_MOUT_ACLK300_DISP1_SUB.

Otherwise the state is unknown at power up and the mixer's clocks are
all messed up.

Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
Link: http://lkml.kernel.org/g/561cdc33.7050...@collabora.com
---

 arch/arm/boot/dts/exynos5250.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index b24610ea8c2a..88b9cf5f226f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -130,6 +130,10 @@
compatible = "samsung,exynos4210-pd";
reg = <0x100440A0 0x20>;
#power-domain-cells = <0>;
+   clocks = < CLK_FIN_PLL>,
+< CLK_MOUT_ACLK200_DISP1_SUB>,
+< CLK_MOUT_ACLK300_DISP1_SUB>;
+   clock-names = "oscclk", "clk0", "clk1";
};
 
clock: clock-controller@1001 {
-- 
2.5.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

[BUG] broken mixer after second resume from mem

2015-10-13 Thread Tomeu Vizoso 
Hi,

have been hunting down a bug on exynos5250-snow which caused both HDMI
and LVDS output to be broken after the second resume (with suspend to
mem, but not to idle).

What I have found is that when powering down the DISP1 power domain
while suspending for the second time, the contents of the SRC_TOP3
register change from 0x1110550 to 0x1110500. IIUIC, this means that
ACLK_200_DISP1 is reparented to XXTI.

When the CPU comes up again, that register contains 0x1110550 again, but
it's set to 0x1110500 by the code that restores clk registers when resuming:

First suspend:

exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after
exynos5250_clk_suspend: SRC_TOP3 1110550
exynos5250_clk_resume: SRC_TOP3 1110550 - before
exynos5250_clk_resume: SRC_TOP3 1110550 - after
exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after


Second suspend:

exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after
exynos5250_clk_suspend: SRC_TOP3 1110500
exynos5250_clk_resume: SRC_TOP3 1110550 - before
exynos5250_clk_resume: SRC_TOP3 1110500 - after
exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - before
exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after


I have no idea of why it happens on the second suspend, and also don't
know why it doesn't happen when suspending to idle.

Any ideas?

Thanks,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-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] ARM: dts: Move display-timings node from fimd to dp

2015-09-28 Thread Tomeu Vizoso 
Hi Kukjin and Krzysztof,

could you take a look at this?

Thanks,

Tomeu

On 17 September 2015 at 14:48, Tomeu Vizoso <tomeu.viz...@collabora.com> wrote:
> From: Sean Paul <seanp...@chromium.org>
>
> This patch moves the display-timings node from fimd to dp to reflect the
> device tree bindings change.
>
> Signed-off-by: Sean Paul <seanp...@chromium.org>
> [tomeu.viz...@collabora.com: Rebased]
> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
>
> ---
>
> Hi,
>
> looks like a long time ago the bindings were changed and the DTs for
> these boards weren't updated.
>
> I have retaken Sean's forgotten patch and rebased it, but I have only
> tested on an Arndale that exynos-drm doesn't complain about missing
> timings.
>
> Regards,
>
> Tomeu
> ---
>  arch/arm/boot/dts/exynos5250-arndale.dts  |  8 
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 
>  arch/arm/boot/dts/exynos5420-smdk5420.dts |  7 ---
>  3 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index db3f65f3eb45..c000532c1444 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -129,10 +129,6 @@
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> -};
> -
> - {
> -   status = "okay";
>
> display-timings {
> native-mode = <>;
> @@ -152,6 +148,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> hpd-gpio = < 7 GPIO_ACTIVE_LOW>;
> vdd_osc-supply = <_reg>;
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index c625e71217aa..0f5dcd418af8 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -89,14 +89,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <_hpd>;
> status = "okay";
> -};
> -
> - {
> -   samsung,vbus-gpio = < 6 GPIO_ACTIVE_HIGH>;
> -};
> -
> - {
> -   status = "okay";
>
> display-timings {
> native-mode = <>;
> @@ -116,6 +108,14 @@
> };
>  };
>
> + {
> +   samsung,vbus-gpio = < 6 GPIO_ACTIVE_HIGH>;
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
>  };
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 98871f972c8a..7520d52f4e22 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -98,10 +98,7 @@
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> status = "okay";
> -};
>
> - {
> -   status = "okay";
> display-timings {
> native-mode = <>;
> timing0: timing@0 {
> @@ -118,6 +115,10 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
> hpd-gpio = < 7 0>;
> --
> 2.4.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

[PATCH RESEND] ARM: dts: Move display-timings node from fimd to dp

2015-09-17 Thread Tomeu Vizoso 
From: Sean Paul <seanp...@chromium.org>

This patch moves the display-timings node from fimd to dp to reflect the
device tree bindings change.

Signed-off-by: Sean Paul <seanp...@chromium.org>
[tomeu.viz...@collabora.com: Rebased]
Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>

---

Hi,

looks like a long time ago the bindings were changed and the DTs for
these boards weren't updated.

I have retaken Sean's forgotten patch and rebased it, but I have only
tested on an Arndale that exynos-drm doesn't complain about missing
timings.

Regards,

Tomeu
---
 arch/arm/boot/dts/exynos5250-arndale.dts  |  8 
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 
 arch/arm/boot/dts/exynos5420-smdk5420.dts |  7 ---
 3 files changed, 16 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index db3f65f3eb45..c000532c1444 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -129,10 +129,6 @@
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
-};
-
- {
-   status = "okay";
 
display-timings {
native-mode = <>;
@@ -152,6 +148,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
hpd-gpio = < 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index c625e71217aa..0f5dcd418af8 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -89,14 +89,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
status = "okay";
-};
-
- {
-   samsung,vbus-gpio = < 6 GPIO_ACTIVE_HIGH>;
-};
-
- {
-   status = "okay";
 
display-timings {
native-mode = <>;
@@ -116,6 +108,14 @@
};
 };
 
+ {
+   samsung,vbus-gpio = < 6 GPIO_ACTIVE_HIGH>;
+};
+
+ {
+   status = "okay";
+};
+
  {
hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
 };
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 98871f972c8a..7520d52f4e22 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -98,10 +98,7 @@
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
status = "okay";
-};
 
- {
-   status = "okay";
display-timings {
native-mode = <>;
timing0: timing@0 {
@@ -118,6 +115,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
hpd-gpio = < 7 0>;
-- 
2.4.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 00/21] On-demand device registration

2015-06-22 Thread Tomeu Vizoso 
On 28 May 2015 at 06:33, Rob Herring robherri...@gmail.com wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like.

Can you elaborate on the reasons why we would like to have devices
registered before built-in drivers finish registering, even if we
don't probe them yet?

 Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

Nod, I haven't looked yet at requesting modules on-demand, but I guess
it should be doable. Modules that have dependencies described in the
firmware should get them probed automatically already though.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

I'm afraid that too much old code depends on that. For example, Rafael
pointed out to the PNP subsystem, which registers a driver that will
probe devices with the EISA ID PNP0c02 to reserve memory regions for
devices that will be probed later.

http://lxr.free-electrons.com/source/drivers/pnp/system.c

My understanding is that probing of PNP0c02 devices must happen before
the actual devices that depend on those regions are probed, so if we
decoupled the probing from the driver/device registration, we would be
breaking that assumption.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

The problem is that some platforms will need fixing because some
initcalls assume that some devices will have been registered already,
or even probed. I think removing those assumptions shouldn't be
problematic because I haven't had much trouble with this on the four
platforms I have tested with, but I cannot test every board that is
supported upstream.

I can ask though the KernelCI folks to boot my branch in all their
boards and make sure that those work when of_platform_populate is
called in late_initcall.

http://kernelci.org/boot/all/job/next/kernel/next-20150619/

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead of 
 2.8s.

 That's certainly compelling.

Have to say that those numbers are with the serial console enabled
(without, it's 0.5s vs 1.5s), but on machines that take longer to boot
we should see bigger gains because we won't be sending devices to the
end of the queue when their probe is deferred.

Regards,

Tomeu

 Rob


 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 Tomeu Vizoso (21):
   regulator: core: Reduce critical area in _regulator_get
   ARM: tegra: Add gpio-ranges property
   ARM: tegra: Register drivers before devices
   ARM: EXYNOS: Register drivers before devices
   ARM i.MX6q: Register drivers before devices
   of/platform: Add of_platform_device_ensure()
   of/platform: Ensure device registration on lookup
   gpio: Probe GPIO drivers on demand
   gpio: Probe pinctrl devices on demand
   regulator: core: Probe regulators on demand
   drm: Probe panels on demand
   drm/tegra: Probe dpaux devices on demand
   i2c: core: Probe i2c master devices on demand
   pwm: Probe PWM chip devices on demand
   backlight: Probe backlight devices on demand
   usb: phy: Probe phy devices on demand
   clk: Probe clk providers on demand
   pinctrl: Probe pinctrl devices on demand
   phy: core: Probe phy providers on demand
   dma: of: Probe DMA controllers on demand
   power-supply: Probe power supplies

Re: [PATCH 00/21] On-demand device registration

2015-06-11 Thread Tomeu Vizoso 
On 06/11/2015 12:17 PM, Alexander Holler wrote:
 Am 11.06.2015 um 10:12 schrieb Linus Walleij:
 On Wed, Jun 10, 2015 at 10:28 AM, Alexander Holler hol...@ahsoftware.de 
 wrote:
 Am 10.06.2015 um 09:30 schrieb Linus Walleij:

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

 You would end up with the same problem of deadlocks as currently, and you
 would still need something ugly like the defered probe brutforce to avoid
 them.

 Sorry I don't get that. Care to elaborate on why?
 
 Because loading/initializing on demand doesn't give you any solved order 
 of drivers to initialize. And it can't because it has no idea about the 
 requirements of other drivers.

So, this is only about ordering device probing. All built-in drivers
have already registered themselves by when we start probing.

 The reason why it might work better in 
 the case of the tegra is that it might give you another initialization 
 order than the one which is currently choosen, which, by luck, might be 
 a better one.

Note that this series was also tested on iMX.6, Exynos and OMAP4.

 But maybe I missed something, I haven't looked at the patches at all. 

It's a really small patchset :)

  19 files changed, 130 insertions(+), 45 deletions(-)

Thanks,

Tomeu

 But just loading on demand, can't magically give you a working order of 
 drivers to initialize. E.g. how do you choose the first driver to 
 initialize?
 
 Regards,
 
 Alexander Holler
 

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

Re: [PATCH 00/21] On-demand device registration

2015-06-10 Thread Tomeu Vizoso 
On 10 June 2015 at 09:30, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:
 On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

 I understood above that you propose probing devices in order, but now
 you mention that resource getters would block until the dependency is
 fulfilled which confuses me because if we are probing in order then
 all dependencies would be fulfilled before the device in question gets
 probed.

 Sorry, the problem space is a bit convoluted so the answers
 get a bit convoluted. Maybe I'm thinking aloud and altering the course
 of my thoughts as I type...

 I guess there can be explicit dependencies for resources like this
 patch does, but another way would be for all resource fetch functions
 to be instrumented, so that you do not block until you try to take
 a resource that is not yet there, e.g.:

 regulator_get(...) - not available, so:
 - identify target regulator provider - this will need instrumentation
 - probe it

 It then turns out the regulator driver is on the i2c bus, so we
 need to probe the i2c driver:
 - identify target i2c host for the regulator driver - this will need
   instrumentation
 - probe the i2c host driver

 i2c host comes out, probes the regulator driver, regulator driver
 probes and then the regulator_get() call returns.

Hmm, if I understand correctly what you say, this is exactly what this
particular series does:

regulator_get - of_platform_device_ensure - probe() on the platform
device that encloses the requested device node (i2c host) - i2c slave
gets probed and the regulator registered - regulator_get returns the
requested resource

The downside I'm currently looking at is that an explicit dependency
graph would be useful to have for other purposes. For example to print
a neat warning when a dependency cannot be fulfilled. Or to refuse to
unbind a device which other devices depend on, or to automatically
unbind the devices that depend on it, or to print a warning if a
device is hotplugged off and other devices depend on it.

 This requires instrumentation on anything providing a resource
 to another driver like those I mentioned and a lot of overhead
 infrastructure, but I think it's the right approach. However I don't
 know if I would ever be able to pull that off myself, I know talk
 is cheap and I should show the code instead.

Yeah, if you can give it a second look and say if it matches what you
wrote above, it would be very much appreciated.

 Deepest respect for your efforts!

Thanks!

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/21] On-demand device registration

2015-06-04 Thread Tomeu Vizoso 
On 3 June 2015 at 21:57, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
 Hi Tomeu,

 On 05/28/2015 07:33 AM, Rob Herring wrote:
 On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com 
 wrote:
 I have a problem with the panel on my Tegra Chromebook taking longer than
 expected to be ready during boot (Stéphane Marchesin reported what is
 basically the same issue in [0]), and have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing 
 with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series 
 to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 I like the concept and novel approach.

 This basically reuses the information that is already implicit in the 
 probe()
 implementations, saving us from refactoring existing drivers or adding
 information to DTBs.

 Something I'm not completely happy with is that I have had to move the call 
 to
 of_platform_populate after all platform drivers have been registered.
 Otherwise I don't see how I could register drivers on demand as we don't 
 have
 yet each driver's compatible strings.

 Yeah, this is the opposite of what we'd really like. Ideally, we would
 have a solution that works for modules too. However, we're no worse
 off. We pretty much build-in dependencies to avoid module ordering
 problems.

 Perhaps we need to make the probing on-demand rather than simply on
 device-driver match occurring.

 For machs that don't move of_platform_populate() to a later point, these
 patches shouldn't cause any problems but it's not guaranteed that we'll 
 avoid
 all the deferred probes as some drivers may not be registered yet.

 Ideally, of_platform_populate is not explicitly called by each
 platform. So I think we need to make this work for the default case.

 I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
 patches were enough to eliminate all the deferred probes.

 With this series I get the kernel to output to the panel in 0.5s, instead 
 of 2.8s.

 That's certainly compelling.

 I've found your idea about moving device registration later during System boot
 very interesting so I've decided to try it on dra7-evem (TI) :).
 It's good to know time during Kernel boot when we can assume that all drivers 
 are
 ready for probing, so there are more ways to control probing order.

Thanks, though right now I'm following Rob's suggestion and only delay
probing, not registration. The patch is really simple (applies on
linux-next, with async probing):

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 8da8e07..7e6b1e1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -407,6 +407,11 @@ int driver_probe_device(struct device_driver
*drv, struct device *dev)
if (!device_is_registered(dev))
return -ENODEV;

+   if (!driver_deferred_probe_enable) {
+   driver_deferred_probe_add(dev);
+   return 0;
+   }
+
pr_debug(bus: '%s': %s: matched device %s with driver %s\n,
 drv-bus-name, __func__, dev_name(dev), drv-name);

@@ -585,7 +590,7 @@ EXPORT_SYMBOL_GPL(device_attach);

 void device_initial_probe(struct device *dev)
 {
-   __device_attach(dev, true);
+   __device_attach(dev, driver_deferred_probe_enable);
 }

 static int __driver_attach(struct device *dev, void *data)

 Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of
 DT and not DT devices/drivers.

 Ok. So What was done...

 LKML Linux 4.1-rc3 (a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 Boot time reduction ~0.4 sec

I'm a bit surprised at such a big improvement. May I ask how you are
measuring it?

 TI Android Kernel 3.14 (NOT a simple case)
 1) use your patches 3/4 as reference (only these two patches :)
 2) move of_platform_populate later at device_initcall_sync time
 3) make it to boot (not sure I've fixed all issues, but those which
break the System boot):
  - split non-DT and DT devices registration in platform code;
  - keep non-DT devices registration from .init_machine() [arch_initcall]
  - move DT-devices registration at device_initcall_sync time
  - fix drivers which use platform_driver_probe().
Note. Now there are at about ~190 occurrences of this macro in Kernel.
  - re-order few devices in DT (4 devices)
  - fix one driver which uses of_find_device_by_node() wrongly
Note. This API is used some times with assumption that
requested dev has been probed already.
 Boot time reduction ~0.3 sec. Probing of some devices are still deferred.

I got no deferred probes on a pandaboard with just these changes:

https://git.collabora.com/cgit/user/tomeu/linux.git/commit/?id=1586c6f50b3d3c65dc219a3cdc3327d798cabca6

Re: [PATCH 00/21] On-demand device registration

2015-06-02 Thread Tomeu Vizoso 
On 2 June 2015 at 10:48, Linus Walleij linus.wall...@linaro.org wrote:
 On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso
 tomeu.viz...@collabora.com wrote:

 have looked into ordered probing as a
 better way of solving this than moving nodes around in the DT or playing with
 initcall levels.

 While reading the thread [1] that Alexander Holler started with his series to
 make probing order deterministic, it occurred to me that it should be 
 possible
 to achieve the same by registering devices as they are referenced by other
 devices.

 This is pretty cool, but a too local solution to a global problem.

 Deferred probe and initcall reordering, silly as they may seem,
 does not require you to use device tree.

 The real solution, which I think I pointed out already when we
 added deferred probe, is to put dependency graphs in the drivers

By this you mean something like what Thierry suggested here?

http://article.gmane.org/gmane.linux.kernel/1774623

 and have the kernel device driver core percolate dependecies by
 walking the graph on probing driver, removing driver (usually the
 inverse use case), [runtime] suspend and [runtime] resumeing
 a driver. Possibly the dependencies will even be different
 depending on use case.

 This is what systemd is doing in userspace for starting services:
 ask for your dependencies and wait for them if they are not
 there. So drivers ask for resources and wait for them. It also
 needs to be abstract, so for example we need to be able to
 hang on regulator_get() until the driver is up and providing that
 regulator, and as long as everything is in slowpath it should
 be OK. (And vice versa mutatis mutandis for clk, gpio, pin
 control, interrupts (!) and DMA channels for example.)

I understood above that you propose probing devices in order, but now
you mention that resource getters would block until the dependency is
fulfilled which confuses me because if we are probing in order then
all dependencies would be fulfilled before the device in question gets
probed.

 So if this should be solved it should be solved in an abstract way
 in the device driver core available for all, then have calls calling
 out to DT, ACPI, possibly even PCI or USB (as these
 enumerate devices themselves) to obtain a certain
 dependency.

Yeah, I was planning looking into this now that I got it working with
async probing.

Thanks,

Tomeu

 Yours,
 Linus Walleij
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/21] On-demand device registration

2015-05-25 Thread Tomeu Vizoso 
Hello,

I have a problem with the panel on my Tegra Chromebook taking longer than
expected to be ready during boot (Stéphane Marchesin reported what is
basically the same issue in [0]), and have looked into ordered probing as a
better way of solving this than moving nodes around in the DT or playing with
initcall levels.

While reading the thread [1] that Alexander Holler started with his series to
make probing order deterministic, it occurred to me that it should be possible
to achieve the same by registering devices as they are referenced by other
devices.

This basically reuses the information that is already implicit in the probe()
implementations, saving us from refactoring existing drivers or adding
information to DTBs.

Something I'm not completely happy with is that I have had to move the call to
of_platform_populate after all platform drivers have been registered.
Otherwise I don't see how I could register drivers on demand as we don't have
yet each driver's compatible strings.

For machs that don't move of_platform_populate() to a later point, these
patches shouldn't cause any problems but it's not guaranteed that we'll avoid
all the deferred probes as some drivers may not be registered yet.

I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these
patches were enough to eliminate all the deferred probes.

With this series I get the kernel to output to the panel in 0.5s, instead of 
2.8s.

Regards,

Tomeu

[0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

[1] https://lkml.org/lkml/2014/5/12/452

Tomeu Vizoso (21):
  regulator: core: Reduce critical area in _regulator_get
  ARM: tegra: Add gpio-ranges property
  ARM: tegra: Register drivers before devices
  ARM: EXYNOS: Register drivers before devices
  ARM i.MX6q: Register drivers before devices
  of/platform: Add of_platform_device_ensure()
  of/platform: Ensure device registration on lookup
  gpio: Probe GPIO drivers on demand
  gpio: Probe pinctrl devices on demand
  regulator: core: Probe regulators on demand
  drm: Probe panels on demand
  drm/tegra: Probe dpaux devices on demand
  i2c: core: Probe i2c master devices on demand
  pwm: Probe PWM chip devices on demand
  backlight: Probe backlight devices on demand
  usb: phy: Probe phy devices on demand
  clk: Probe clk providers on demand
  pinctrl: Probe pinctrl devices on demand
  phy: core: Probe phy providers on demand
  dma: of: Probe DMA controllers on demand
  power-supply: Probe power supplies on demand

 arch/arm/boot/dts/tegra124.dtsi |  1 +
 arch/arm/mach-exynos/exynos.c   |  4 +--
 arch/arm/mach-imx/mach-imx6q.c  | 12 -
 arch/arm/mach-tegra/tegra.c | 21 ++-
 drivers/clk/clk.c   |  3 +++
 drivers/dma/of-dma.c|  3 +++
 drivers/gpio/gpiolib-of.c   |  5 
 drivers/gpu/drm/drm_panel.c |  3 +++
 drivers/gpu/drm/tegra/dpaux.c   |  3 +++
 drivers/i2c/i2c-core.c  |  3 +++
 drivers/of/platform.c   | 53 +
 drivers/phy/phy-core.c  |  3 +++
 drivers/pinctrl/devicetree.c|  2 ++
 drivers/power/power_supply_core.c   |  3 +++
 drivers/pwm/core.c  |  3 +++
 drivers/regulator/core.c| 45 +++
 drivers/usb/phy/phy.c   |  3 +++
 drivers/video/backlight/backlight.c |  3 +++
 include/linux/of_platform.h |  2 ++
 19 files changed, 130 insertions(+), 45 deletions(-)

-- 
2.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

[PATCH 04/21] ARM: EXYNOS: Register drivers before devices

2015-05-25 Thread Tomeu Vizoso 
So devices can be probed on demand, we need to have the drivers already
registered as we don't have enough information to register a driver on
demand.

Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
 arch/arm/mach-exynos/exynos.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 5917a30..3c98c92 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -110,6 +110,8 @@ void __init exynos_sysram_init(void)
 
 static void __init exynos_init_late(void)
 {
+   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+
if (of_machine_is_compatible(samsung,exynos5440))
/* to be supported later */
return;
@@ -246,8 +248,6 @@ static void __init exynos_dt_machine_init(void)
platform_device_register(exynos_cpuidle);
 
platform_device_register_simple(exynos-cpufreq, -1, NULL, 0);
-
-   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
 static char const *const exynos_dt_compat[] __initconst = {
-- 
2.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

Re: [RFC 0/3] mmc: Add dynamic frequency scaling

2015-01-15 Thread Tomeu Vizoso 
On 12 January 2015 at 10:23, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
 Hi,


 I would like to hear some comments about idea of scaling MMC clock
 frequency. The basic idea is to lower the clock when device is
 completely idle or not busy enough.

 The patchset adds MMC card as a devfreq device and uses simple_ondemand
 as governor. In idle this gave benefits (less energy consumed during
 idle):
 1. Trats2 (Exynos4412): 2.6%
 2. Rinato (Exynos3250): 1%

 but (especially on Rinato) it had impact on performance (probably
 because ondemand triggering a little to late). What is interesting
 manually changing the clock (without this patchset) gave slightly
 bigger benefits. Maybe the devfreq introduces noticeable overhead?

Could it be because of the polling interval being too long thus it
being too slow to ramp up?

That's a problem with all polling devfreq drivers, it has been
proposed before using pm_qos to to reduce the polling interval when
some event indicates that the utilization may grow abruptly in the
near future.

I don't think pm_qos is the best mechanism for that, maybe something
new needs to be devised.

Regards,

Tomeu


 Comments are welcomed. Maybe on other platforms this has bigger impact?

 Best regards,
 Krzysztof


 Krzysztof Kozlowski (3):
   mmc: Add dynamic frequency scaling
   ARM: dts: Specify MSHC realistic clocks and use frequency scaling
   ARM: dts: Use frequency scaling for MSHC

  Documentation/devicetree/bindings/mmc/mmc.txt |   2 +
  arch/arm/boot/dts/exynos3250-rinato.dts   |   1 +
  arch/arm/boot/dts/exynos4412-trats2.dts   |   4 +-
  drivers/mmc/card/block.c  | 247 
 ++
  drivers/mmc/core/Kconfig  |  16 ++
  drivers/mmc/core/core.h   |   1 -
  drivers/mmc/core/host.c   |   2 +
  include/linux/mmc/card.h  |   8 +
  include/linux/mmc/host.h  |   3 +
  9 files changed, 282 insertions(+), 2 deletions(-)

 --
 1.9.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-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] Exynos4: enable HDMI support for Odroid and UniversalC210

2014-08-12 Thread Tomeu Vizoso 
On 1 July 2014 10:10, Marek Szyprowski m.szyprow...@samsung.com wrote:
 This is a long awaited patch series enabling support for HDMI output
 available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
 Exynos4210 Universal C210 board.

Hello,

have tested a few of these patches on an Odroid-U2 on top of
linux/master (c8d6637):

1a8edf8 clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
bb2561d drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled
afe0bff Exynos: add support for 'domain-always-on' property
be421b7 ARM: dts: exynos4: add hdmi related nodes
1206d41 ARM: dts: exynos4412-odroid: enable hdmi support

Tested-by: Tomeu Vizoso to...@tomeuvizoso.net

I also needed these two patches from Daniel Drake:

64489ec ARM: dts: Enable PMIC interrupts on ODROID
ef009d7 ARM: dts: ODROID i2c improvements

HDMI worked just fine in the testing I did, I have pushed a branch here:

http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=odroid-hdmi

Marek, Daniel: would you like me to send a series with all the needed
patches together?

Thanks,

Tomeu
--
To unsubscribe from this list: send the line unsubscribe linux-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 PMIC interrupts on ODROID

2014-08-12 Thread Tomeu Vizoso 
Tested on an Odroid-U2:

Tested-by: Tomeu Vizoso to...@tomeuvizoso.net

Thanks,

Tomeu


On 16 July 2014 10:50, Daniel Drake dr...@endlessm.com wrote:
 The ODROID kernel shows that the PMIC interrupt line is hooked up
 to pin GPX3-2.

 This is needed for the max77686-irq driver to create the PMIC IRQ
 domain, which is needed by max77686-rtc.

 Signed-off-by: Daniel Drake dr...@endlessm.com
 ---
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 11 +++
  1 file changed, 11 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index 6d6d23c..cb6f55f 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -148,6 +148,10 @@

 max77686: pmic@09 {
 compatible = maxim,max77686;
 +   interrupt-parent = gpx3;
 +   interrupts = 2 0;
 +   pinctrl-names = default;
 +   pinctrl-0 = max77686_irq;
 reg = 0x09;
 #clock-cells = 1;

 @@ -368,4 +372,11 @@
 samsung,pins = gpx1-3;
 samsung,pin-pud = 0;
 };
 +
 +   max77686_irq: max77686-irq {
 +   samsung,pins = gpx3-2;
 +   samsung,pin-function = 0;
 +   samsung,pin-pud = 0;
 +   samsung,pin-drv = 0;
 +   };
  };
 --
 1.9.1


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-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: ODROID i2c improvements

2014-08-12 Thread Tomeu Vizoso 
Tested on an Odroid-U2:

Tested-by: Tomeu Vizoso tomeu.viz...@collabora.com

Thanks,

Tomeu

On 16 July 2014 10:50, Daniel Drake dr...@endlessm.com wrote:
 Increase max i2c bus frequency beyond the default for faster
 data transfers. According to the manual, these faster speeds are
 only available when the board is wired up the right way. In this case,
 the vendor kernel has run at this speed for a long time.

 sda-delay is needed for talking to RTC on PMIC, otherwise the i2c
 controller never sees an ACK. Strangely the other PMIC i2c slave (the
 main one) works fine even without this delay. I Chose value 100 to
 match the vendor kernel.

 Signed-off-by: Daniel Drake dr...@endlessm.com
 ---
  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
 b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 index cb6f55f..adadaf9 100644
 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
 @@ -134,6 +134,8 @@
 i2c@1386 {
 pinctrl-0 = i2c0_bus;
 pinctrl-names = default;
 +   samsung,i2c-sda-delay = 100;
 +   samsung,i2c-max-bus-freq = 40;
 status = okay;

 usb3503: usb3503@08 {
 --
 1.9.1


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-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/2] Firmware-assisted suspend/resume of Exynos SoCs

2014-08-11 Thread Tomeu Vizoso 
For both patches, on the Odroid U2:

Tested-by: Tomeu Vizoso tomeu.viz...@collabora.com

Thanks,

Tomeu

On 17 July 2014 17:56, Tomasz Figa t.f...@samsung.com wrote:
 On Exynos-based boards running secure firmware the sequence of low level
 operations to enter and leave system-wide sleep mode is different than
 on those without the firmware. Namely:
  - CP15 power control and diagnostic registers cannot be written directly,
  - the way of setting boot address and boot flag is different,
  - different resume handler needs to be used,
  - dedicated SMC call needs to be performed instead of letting the CPU enter
WFI.

 This series introduces .suspend() and .resume() firmware operations to
 perform low level firmware-specific suspend and resume and then leverages
 them to provide suspend-resume path meeting the above requirements.

 The series is based on Kgene's for-next branch and tested on:
  - Exynos4412-based Trats2 board running in non-secure mode (under secure
firmware) with few board-specific fixes that will be sent separately soon,
  - Exynos4210-based Trats board running in secure mode,
  - Exynos4412-based ODROID-U3 board running in non-secure mode with one minor
board-specific fix which will be send shortly.

 Depends on:
  - [PATCH v3] ARM: save/restore Cortex-A9 CP15 registers on suspend/resume
(http://www.spinics.net/lists/arm-kernel/msg346212.html)
  - [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences
(https://lkml.org/lkml/2014/7/15/319)
  - [PATCH] ARM: make it easier to check the CPU part number correctly
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/335126
 already in linux-next)

 Changes since v1:
  - dropped outer_resume() - will be handled in assembly in further patches,
as support for L2C in non-secure mode gets added,
  - moved CP15 resume to assembly as it needs to be done before MMU is enabled,
  - surrounded CP15 save with a check for cpuid part, because it is valid only
on Cortex A9,
  - rebased on next-20140717 tag of linux-next tree.

 Tomasz Figa (2):
   ARM: firmware: Introduce suspend and resume operations
   ARM: EXYNOS: Add support for firmware-assisted suspend/resume

  Documentation/arm/firmware.txt  | 28 +
  arch/arm/include/asm/firmware.h |  8 
  arch/arm/mach-exynos/Makefile   |  1 +
  arch/arm/mach-exynos/common.h   |  4 
  arch/arm/mach-exynos/firmware.c | 45 
 +
  arch/arm/mach-exynos/pm.c   | 16 ++-
  arch/arm/mach-exynos/sleep.S| 28 +
  arch/arm/mach-exynos/smc.h  |  4 
  8 files changed, 106 insertions(+), 28 deletions(-)

 --
 1.9.3

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-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: Re: [PATCHv2 0/8] devfreq: exynos4: Support dt and use common ppmu driver

2014-07-09 Thread Tomeu Vizoso 

On 03/17/2014 02:58 AM, Chanwoo Choi wrote:

Hi Tomasz,

On 03/15/2014 02:58 AM, Tomasz Figa wrote:


However, this driver, even after applying your series, is still far
from a state that would allow it to be enabled. The most important
issue is direct access to CMU registers, based on static mapping,
which is not allowed on multiplatform kernels and
multiplatform-awareness for drivers is currently a must.

To allow this driver to be enabled, it needs to be converted to use
common clock framework functions to configure all clocks, e.g.
clk_set_rate(), clk_set_parent(), etc., without accessing CMU
registers directly.

Of course as long as the driver is effectively unusable, to keep
development, we can proceed with refactoring it step-by-step and
your series would be basically the first step, after addressing the
review comments.



I agree your opinion. When setting frequency of memory bus, this
driver access directly to CMU registers. I know it should be modified
by using common clk framework as your comment.

I'll send patch set about using common clk framework instead of CMU
register based on static mapping after finished the review and apply
of this patch set as next step.


Hi Chanwoo,

any news on this?

I would love to test this devfreq driver with the clk_set_floor_rate API 
I'm adding to the common clk framework.


Regards,

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