[PATCH 0/3] Fix boot-hang on Peach-pit and Enable audio

[PATCH 0/3] Fix boot-hang on Peach-pit and Enable audio

[Tushar Behera]

With next-20140610, Peach-pit/Peach-pi board hangs during boot if we
run 'sound init' during u-boot. The issue is fixed in following patches.
While at it, also enable audio support for Peach-pi board.

How to test audio on Peach-pi:
* On top of exynos_defconfig, enable SND_SOC_SNOW and PL330_DMA.
* Run 'sound init' at u-boot prompt.

Tushar Behera (3):
  clk: exynos-audss: Keep the parent of mout_audss always enabled
  ARM: dts: Update the parent for Audss clocks in Exynos5420
  ARM: dts: Enable audio support for Peach-pi board

 arch/arm/boot/dts/exynos5420.dtsi         |    2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-exynos-audss.c    |   17 +++++++++++++---
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
1.7.9.5

[PATCH 0/3] Fix boot-hang on Peach-pit and Enable audio

[Tushar Behera]

With next-20140610, Peach-pit/Peach-pi board hangs during boot if we
run 'sound init' during u-boot. The issue is fixed in following patches.
While at it, also enable audio support for Peach-pi board.

How to test audio on Peach-pi:
* On top of exynos_defconfig, enable SND_SOC_SNOW and PL330_DMA.
* Run 'sound init' at u-boot prompt.

Tushar Behera (3):
  clk: exynos-audss: Keep the parent of mout_audss always enabled
  ARM: dts: Update the parent for Audss clocks in Exynos5420
  ARM: dts: Enable audio support for Peach-pi board

 arch/arm/boot/dts/exynos5420.dtsi         |    2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
 drivers/clk/samsung/clk-exynos-audss.c    |   17 +++++++++++++---
 3 files changed, 46 insertions(+), 4 deletions(-)

-- 
1.7.9.5

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

When the output clock of AUDSS mux is disabled, we are getting kernel
oops while doing a clk_get() on other clocks provided by AUDSS. Though
user manual doesn't specify this dependency, we came across this issue
while disabling the parent of AUDSS mux clocks.

Keeping the parents of AUDSS mux always enabled fixes this issue.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
---
 drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 13eae14c..1542f30 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -30,6 +30,8 @@ static struct clk **clk_table;
 static void __iomem *reg_base;
 static struct clk_onecell_data clk_data;
 
+static struct clk *pll_ref, *pll_in;
+
 #define ASS_CLK_SRC 0x0
 #define ASS_CLK_DIV 0x4
 #define ASS_CLK_GATE 0x8
@@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
 	const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
 	const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
 	const char *sclk_pcm_p = "sclk_pcm0";
-	struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
+	struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
 	const struct of_device_id *match;
 	enum exynos_audss_clk_type variant;
 
@@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
 
 	pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
 	pll_in = devm_clk_get(&pdev->dev, "pll_in");
-	if (!IS_ERR(pll_ref))
+	if (!IS_ERR(pll_ref)) {
 		mout_audss_p[0] = __clk_get_name(pll_ref);
-	if (!IS_ERR(pll_in))
+		clk_prepare_enable(pll_ref);
+	}
+	if (!IS_ERR(pll_in)) {
 		mout_audss_p[1] = __clk_get_name(pll_in);
+		clk_prepare_enable(pll_in);
+	}
 	clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
 				mout_audss_p, ARRAY_SIZE(mout_audss_p),
 				CLK_SET_RATE_NO_REPARENT,
@@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
 			clk_unregister(clk_table[i]);
 	}
 
+	if (!IS_ERR(pll_in))
+		clk_disable_unprepare(pll_in);
+	if (!IS_ERR(pll_ref))
+		clk_disable_unprepare(pll_ref);
+
 	return 0;
 }
 
-- 
1.7.9.5

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

When the output clock of AUDSS mux is disabled, we are getting kernel
oops while doing a clk_get() on other clocks provided by AUDSS. Though
user manual doesn't specify this dependency, we came across this issue
while disabling the parent of AUDSS mux clocks.

Keeping the parents of AUDSS mux always enabled fixes this issue.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
---
 drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
index 13eae14c..1542f30 100644
--- a/drivers/clk/samsung/clk-exynos-audss.c
+++ b/drivers/clk/samsung/clk-exynos-audss.c
@@ -30,6 +30,8 @@ static struct clk **clk_table;
 static void __iomem *reg_base;
 static struct clk_onecell_data clk_data;
 
+static struct clk *pll_ref, *pll_in;
+
 #define ASS_CLK_SRC 0x0
 #define ASS_CLK_DIV 0x4
 #define ASS_CLK_GATE 0x8
@@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
 	const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
 	const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
 	const char *sclk_pcm_p = "sclk_pcm0";
-	struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
+	struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
 	const struct of_device_id *match;
 	enum exynos_audss_clk_type variant;
 
@@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
 
 	pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
 	pll_in = devm_clk_get(&pdev->dev, "pll_in");
-	if (!IS_ERR(pll_ref))
+	if (!IS_ERR(pll_ref)) {
 		mout_audss_p[0] = __clk_get_name(pll_ref);
-	if (!IS_ERR(pll_in))
+		clk_prepare_enable(pll_ref);
+	}
+	if (!IS_ERR(pll_in)) {
 		mout_audss_p[1] = __clk_get_name(pll_in);
+		clk_prepare_enable(pll_in);
+	}
 	clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
 				mout_audss_p, ARRAY_SIZE(mout_audss_p),
 				CLK_SET_RATE_NO_REPARENT,
@@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
 			clk_unregister(clk_table[i]);
 	}
 
+	if (!IS_ERR(pll_in))
+		clk_disable_unprepare(pll_in);
+	if (!IS_ERR(pll_ref))
+		clk_disable_unprepare(pll_ref);
+
 	return 0;
 }
 
-- 
1.7.9.5

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
As per the user manual, it should be CLK_MAU_EPLL.

The problem surfaced when the bootloader in Peach-pit board set
the EPLL clock as the parent of AUDSS mux. While booting the kernel,
we used to get a system hang during late boot if CLK_MAU_EPLL was
disabled.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Reported-by: Kevin Hilman <khilman@linaro.org>
---
 arch/arm/boot/dts/exynos5420.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..79e9119 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -167,7 +167,7 @@
 		compatible = "samsung,exynos5420-audss-clock";
 		reg = <0x03810000 0x0C>;
 		#clock-cells = <1>;
-		clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
+		clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
 			 <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
 		clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
 	};
-- 
1.7.9.5

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
As per the user manual, it should be CLK_MAU_EPLL.

The problem surfaced when the bootloader in Peach-pit board set
the EPLL clock as the parent of AUDSS mux. While booting the kernel,
we used to get a system hang during late boot if CLK_MAU_EPLL was
disabled.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Reported-by: Kevin Hilman <khilman@linaro.org>
---
 arch/arm/boot/dts/exynos5420.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..79e9119 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -167,7 +167,7 @@
 		compatible = "samsung,exynos5420-audss-clock";
 		reg = <0x03810000 0x0C>;
 		#clock-cells = <1>;
-		clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
+		clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
 			 <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
 		clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
 	};
-- 
1.7.9.5

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3af207..76f5966 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -78,9 +78,27 @@
 		pinctrl-0 = <&usb301_vbus_en>;
 		enable-active-high;
 	};
+
+	sound {
+		compatible = "google,snow-audio-max98090";
+
+		samsung,i2s-controller = <&i2s0>;
+		samsung,audio-codec = <&max98090>;
+	};
+};
+
+&i2s0 {
+	status = "okay";
 };
 
 &pinctrl_0 {
+	max98090_irq: max98090-irq {
+		samsung,pins = "gpx0-2";
+		samsung,pin-function = <0>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+
 	tpm_irq: tpm-irq {
 		samsung,pins = "gpx1-0";
 		samsung,pin-function = <0>;
@@ -207,6 +225,19 @@
 	samsung,invert-vclk;
 };
 
+&hsi2c_7 {
+	status = "okay";
+
+	max98090: codec@10 {
+		compatible = "maxim,max98090";
+		reg = <0x10>;
+		interrupts = <2 0>;
+		interrupt-parent = <&gpx0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&max98090_irq>;
+	};
+};
+
 &hsi2c_9 {
 	status = "okay";
 	clock-frequency = <400000>;
-- 
1.7.9.5

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

Signed-off-by: Tushar Behera <tushar.b-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3af207..76f5966 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -78,9 +78,27 @@
 		pinctrl-0 = <&usb301_vbus_en>;
 		enable-active-high;
 	};
+
+	sound {
+		compatible = "google,snow-audio-max98090";
+
+		samsung,i2s-controller = <&i2s0>;
+		samsung,audio-codec = <&max98090>;
+	};
+};
+
+&i2s0 {
+	status = "okay";
 };
 
 &pinctrl_0 {
+	max98090_irq: max98090-irq {
+		samsung,pins = "gpx0-2";
+		samsung,pin-function = <0>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+
 	tpm_irq: tpm-irq {
 		samsung,pins = "gpx1-0";
 		samsung,pin-function = <0>;
@@ -207,6 +225,19 @@
 	samsung,invert-vclk;
 };
 
+&hsi2c_7 {
+	status = "okay";
+
+	max98090: codec@10 {
+		compatible = "maxim,max98090";
+		reg = <0x10>;
+		interrupts = <2 0>;
+		interrupt-parent = <&gpx0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&max98090_irq>;
+	};
+};
+
 &hsi2c_9 {
 	status = "okay";
 	clock-frequency = <400000>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

Signed-off-by: Tushar Behera <tushar.b@samsung.com>
---
 arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3af207..76f5966 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -78,9 +78,27 @@
 		pinctrl-0 = <&usb301_vbus_en>;
 		enable-active-high;
 	};
+
+	sound {
+		compatible = "google,snow-audio-max98090";
+
+		samsung,i2s-controller = <&i2s0>;
+		samsung,audio-codec = <&max98090>;
+	};
+};
+
+&i2s0 {
+	status = "okay";
 };
 
 &pinctrl_0 {
+	max98090_irq: max98090-irq {
+		samsung,pins = "gpx0-2";
+		samsung,pin-function = <0>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+
 	tpm_irq: tpm-irq {
 		samsung,pins = "gpx1-0";
 		samsung,pin-function = <0>;
@@ -207,6 +225,19 @@
 	samsung,invert-vclk;
 };
 
+&hsi2c_7 {
+	status = "okay";
+
+	max98090: codec at 10 {
+		compatible = "maxim,max98090";
+		reg = <0x10>;
+		interrupts = <2 0>;
+		interrupt-parent = <&gpx0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&max98090_irq>;
+	};
+};
+
 &hsi2c_9 {
 	status = "okay";
 	clock-frequency = <400000>;
-- 
1.7.9.5

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>
> --
> 1.7.9.5
>

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>
> --
> 1.7.9.5
>

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>
> --
> 1.7.9.5
>

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index e385322..79e9119 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -167,7 +167,7 @@
>                 compatible = "samsung,exynos5420-audss-clock";
>                 reg = <0x03810000 0x0C>;
>                 #clock-cells = <1>;
> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>         };
> --
> 1.7.9.5
>
> --

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index e385322..79e9119 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -167,7 +167,7 @@
>                 compatible = "samsung,exynos5420-audss-clock";
>                 reg = <0x03810000 0x0C>;
>                 #clock-cells = <1>;
> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>         };
> --
> 1.7.9.5
>
> --

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index e385322..79e9119 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -167,7 +167,7 @@
>                 compatible = "samsung,exynos5420-audss-clock";
>                 reg = <0x03810000 0x0C>;
>                 #clock-cells = <1>;
> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>         };
> --
> 1.7.9.5
>
> --

Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-06-10 22:32:17)
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.

Hi Tushar,

Can you help me understand better what the actual problem is? What is
the root cause of the kernel oops?

You mention calling clk_get on child clocks of the AUDSS mux fails, but
I cannot imagine why. How can the enable/disable state of a clock affect
the ability to clk_get other clocks?

Regards,
Mike

> 
> Keeping the parents of AUDSS mux always enabled fixes this issue.
> 
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>  
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>  
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>  
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>  
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>  
> -- 
> 1.7.9.5
> 

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-06-10 22:32:17)
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.

Hi Tushar,

Can you help me understand better what the actual problem is? What is
the root cause of the kernel oops?

You mention calling clk_get on child clocks of the AUDSS mux fails, but
I cannot imagine why. How can the enable/disable state of a clock affect
the ability to clk_get other clocks?

Regards,
Mike

> 
> Keeping the parents of AUDSS mux always enabled fixes this issue.
> 
> Signed-off-by: Tushar Behera <tushar.b-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>  
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>  
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>  
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>  
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>  
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-06-10 22:32:17)
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.

Hi Tushar,

Can you help me understand better what the actual problem is? What is
the root cause of the kernel oops?

You mention calling clk_get on child clocks of the AUDSS mux fails, but
I cannot imagine why. How can the enable/disable state of a clock affect
the ability to clk_get other clocks?

Regards,
Mike

> 
> Keeping the parents of AUDSS mux always enabled fixes this issue.
> 
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> ---
>  drivers/clk/samsung/clk-exynos-audss.c |   17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos-audss.c b/drivers/clk/samsung/clk-exynos-audss.c
> index 13eae14c..1542f30 100644
> --- a/drivers/clk/samsung/clk-exynos-audss.c
> +++ b/drivers/clk/samsung/clk-exynos-audss.c
> @@ -30,6 +30,8 @@ static struct clk **clk_table;
>  static void __iomem *reg_base;
>  static struct clk_onecell_data clk_data;
>  
> +static struct clk *pll_ref, *pll_in;
> +
>  #define ASS_CLK_SRC 0x0
>  #define ASS_CLK_DIV 0x4
>  #define ASS_CLK_GATE 0x8
> @@ -83,7 +85,7 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>         const char *mout_audss_p[] = {"fin_pll", "fout_epll"};
>         const char *mout_i2s_p[] = {"mout_audss", "cdclk0", "sclk_audio0"};
>         const char *sclk_pcm_p = "sclk_pcm0";
> -       struct clk *pll_ref, *pll_in, *cdclk, *sclk_audio, *sclk_pcm_in;
> +       struct clk *cdclk, *sclk_audio, *sclk_pcm_in;
>         const struct of_device_id *match;
>         enum exynos_audss_clk_type variant;
>  
> @@ -113,10 +115,14 @@ static int exynos_audss_clk_probe(struct platform_device *pdev)
>  
>         pll_ref = devm_clk_get(&pdev->dev, "pll_ref");
>         pll_in = devm_clk_get(&pdev->dev, "pll_in");
> -       if (!IS_ERR(pll_ref))
> +       if (!IS_ERR(pll_ref)) {
>                 mout_audss_p[0] = __clk_get_name(pll_ref);
> -       if (!IS_ERR(pll_in))
> +               clk_prepare_enable(pll_ref);
> +       }
> +       if (!IS_ERR(pll_in)) {
>                 mout_audss_p[1] = __clk_get_name(pll_in);
> +               clk_prepare_enable(pll_in);
> +       }
>         clk_table[EXYNOS_MOUT_AUDSS] = clk_register_mux(NULL, "mout_audss",
>                                 mout_audss_p, ARRAY_SIZE(mout_audss_p),
>                                 CLK_SET_RATE_NO_REPARENT,
> @@ -217,6 +223,11 @@ static int exynos_audss_clk_remove(struct platform_device *pdev)
>                         clk_unregister(clk_table[i]);
>         }
>  
> +       if (!IS_ERR(pll_in))
> +               clk_disable_unprepare(pll_in);
> +       if (!IS_ERR(pll_ref))
> +               clk_disable_unprepare(pll_ref);
> +
>         return 0;
>  }
>  
> -- 
> 1.7.9.5
> 

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Kevin Hilman]

Tushar Behera <tushar.b@samsung.com> writes:

> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. 
>
> Though user manual doesn't specify this dependency, we came across
> this issue while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.

While this patch works (and fixes the boot problem for me), it seems
like it's papering over the real problem.

Seems like the right fix is actually modelling the clocks properly so
that enabling a child clock ensures that the parent is also enabled.

Kevin

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Kevin Hilman]

Tushar Behera <tushar.b@samsung.com> writes:

> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. 
>
> Though user manual doesn't specify this dependency, we came across
> this issue while disabling the parent of AUDSS mux clocks.
>
> Keeping the parents of AUDSS mux always enabled fixes this issue.

While this patch works (and fixes the boot problem for me), it seems
like it's papering over the real problem.

Seems like the right fix is actually modelling the clocks properly so
that enabling a child clock ensures that the parent is also enabled.

Kevin

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tomasz Figa]

Hi Tushar,

On 11.06.2014 07:32, Tushar Behera wrote:
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.

Could you provide more data about this oops? E.g. kernel log, platforms
it affects (just peach-pit or also others), test case, extra patches
applied on top of mainline (if any).

I don't like this solution, because keeping a clock always enabled is
usually not desirable and this driver is also used on other platforms
than peach-pit, so this change will affect all of them.

Best regards,
Tomasz

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tomasz Figa]

Hi Tushar,

On 11.06.2014 07:32, Tushar Behera wrote:
> When the output clock of AUDSS mux is disabled, we are getting kernel
> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> user manual doesn't specify this dependency, we came across this issue
> while disabling the parent of AUDSS mux clocks.

Could you provide more data about this oops? E.g. kernel log, platforms
it affects (just peach-pit or also others), test case, extra patches
applied on top of mainline (if any).

I don't like this solution, because keeping a clock always enabled is
usually not desirable and this driver is also used on other platforms
than peach-pit, so this change will affect all of them.

Best regards,
Tomasz

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Tushar Behera (2014-06-10 22:32:17)
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>> user manual doesn't specify this dependency, we came across this issue
>> while disabling the parent of AUDSS mux clocks.
>
> Hi Tushar,
>
> Can you help me understand better what the actual problem is? What is
> the root cause of the kernel oops?

Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
As per observation, when the output of AUDSS mux is gated, we are not
able to do any operation on the clocks provided by MAU block (mostly
the clocks used by ADMA and audio blocks).

>
> You mention calling clk_get on child clocks of the AUDSS mux fails, but
> I cannot imagine why. How can the enable/disable state of a clock affect
> the ability to clk_get other clocks?
>

I might have a little vogue while updating the commit message
(mentioning about clk_get which surely is only a s/w operation), but
there is definitely some issue with handling those clocks under given
scenario.

I am on leave till end of this week, so I will update you more with
the logs on Monday.

Thanks,
--
Tushar

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Tushar Behera (2014-06-10 22:32:17)
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>> user manual doesn't specify this dependency, we came across this issue
>> while disabling the parent of AUDSS mux clocks.
>
> Hi Tushar,
>
> Can you help me understand better what the actual problem is? What is
> the root cause of the kernel oops?

Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
As per observation, when the output of AUDSS mux is gated, we are not
able to do any operation on the clocks provided by MAU block (mostly
the clocks used by ADMA and audio blocks).

>
> You mention calling clk_get on child clocks of the AUDSS mux fails, but
> I cannot imagine why. How can the enable/disable state of a clock affect
> the ability to clk_get other clocks?
>

I might have a little vogue while updating the commit message
(mentioning about clk_get which surely is only a s/w operation), but
there is definitely some issue with handling those clocks under given
scenario.

I am on leave till end of this week, so I will update you more with
the logs on Monday.

Thanks,
--
Tushar

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:58 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Tushar,
>
> On 11.06.2014 07:32, Tushar Behera wrote:
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>> user manual doesn't specify this dependency, we came across this issue
>> while disabling the parent of AUDSS mux clocks.
>
> Could you provide more data about this oops? E.g. kernel log, platforms
> it affects (just peach-pit or also others), test case, extra patches
> applied on top of mainline (if any).
>
> I don't like this solution, because keeping a clock always enabled is
> usually not desirable and this driver is also used on other platforms
> than peach-pit, so this change will affect all of them.
>

I will update later after doing similar tests on other platforms.

> Best regards,
> Tomasz

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:58 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Hi Tushar,
>
> On 11.06.2014 07:32, Tushar Behera wrote:
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>> user manual doesn't specify this dependency, we came across this issue
>> while disabling the parent of AUDSS mux clocks.
>
> Could you provide more data about this oops? E.g. kernel log, platforms
> it affects (just peach-pit or also others), test case, extra patches
> applied on top of mainline (if any).
>
> I don't like this solution, because keeping a clock always enabled is
> usually not desirable and this driver is also used on other platforms
> than peach-pit, so this change will affect all of them.
>

I will update later after doing similar tests on other platforms.

> Best regards,
> Tomasz

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Tushar Behera <tushar.b@samsung.com> writes:
>
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>
>> Though user manual doesn't specify this dependency, we came across
>> this issue while disabling the parent of AUDSS mux clocks.
>>
>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>
> While this patch works (and fixes the boot problem for me), it seems
> like it's papering over the real problem.
>

Thanks for testing.

> Seems like the right fix is actually modelling the clocks properly so
> that enabling a child clock ensures that the parent is also enabled.
>

Patch 2/3 was to ensure we have proper clock tree defined for
Exynos5420. While testing with audio disabled, that patch alone fixed
the issue. But when audio was enabled (and hence I2S0 was trying to
access the clocks), we got some kernel oops during late booting, hence
I came up this solution.

The solution might be a little half-baked because of the urgency to
push the fix, but will try to dig more into the issue on Monday when I
resume office.

> Kevin

Thanks,
--
Tushar

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
> Tushar Behera <tushar.b@samsung.com> writes:
>
>> When the output clock of AUDSS mux is disabled, we are getting kernel
>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>
>> Though user manual doesn't specify this dependency, we came across
>> this issue while disabling the parent of AUDSS mux clocks.
>>
>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>
> While this patch works (and fixes the boot problem for me), it seems
> like it's papering over the real problem.
>

Thanks for testing.

> Seems like the right fix is actually modelling the clocks properly so
> that enabling a child clock ensures that the parent is also enabled.
>

Patch 2/3 was to ensure we have proper clock tree defined for
Exynos5420. While testing with audio disabled, that patch alone fixed
the issue. But when audio was enabled (and hence I2S0 was trying to
access the clocks), we got some kernel oops during late booting, hence
I came up this solution.

The solution might be a little half-baked because of the urgency to
push the fix, but will try to dig more into the issue on Monday when I
resume office.

> Kevin

Thanks,
--
Tushar

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-06-12 00:29:23)
> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Tushar Behera (2014-06-10 22:32:17)
> >> When the output clock of AUDSS mux is disabled, we are getting kernel
> >> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> >> user manual doesn't specify this dependency, we came across this issue
> >> while disabling the parent of AUDSS mux clocks.
> >
> > Hi Tushar,
> >
> > Can you help me understand better what the actual problem is? What is
> > the root cause of the kernel oops?
> 
> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
> As per observation, when the output of AUDSS mux is gated, we are not
> able to do any operation on the clocks provided by MAU block (mostly
> the clocks used by ADMA and audio blocks).

I tried to get a datasheet for Exynos 54xx but could not find it. I even
looked at the public 5250 data sheet, but it is completely missing
Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
"Clock names and clock tree diagram of MAUDIO_BLK".

So without any clue about your hardware (not for lack of trying) I would
guess that somewhere in the parent hierarchy you have an interface clock
which must be enabled in order for you to touch the registers pertaining
to the downstream audio clocks.

The right way to handle this requires two steps:

1) model your interface clock in the Linux clock framework if you
haven't already (I assume it is a gate clock, or the child of a gate
clock)

2) the clk_ops callbacks for the affected audio clocks should wrap their
operations (i.e. critical secion) with a clk_enable/clk_disable pair,
where the clock being enables/disable is the interface clock mentioned
above in #1

The CCF is reentrant, so you can do this by simply using the top-level
clk.h API from within your clk_ops callbacks.

I might be totally wrong about the cause of the hang, but that's my best
guess based on everyone's bug reports.

Regards,
Mike

> 
> >
> > You mention calling clk_get on child clocks of the AUDSS mux fails, but
> > I cannot imagine why. How can the enable/disable state of a clock affect
> > the ability to clk_get other clocks?
> >
> 
> I might have a little vogue while updating the commit message
> (mentioning about clk_get which surely is only a s/w operation), but
> there is definitely some issue with handling those clocks under given
> scenario.
> 
> I am on leave till end of this week, so I will update you more with
> the logs on Monday.
> 
> Thanks,
> --
> Tushar

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-06-12 00:29:23)
> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> > Quoting Tushar Behera (2014-06-10 22:32:17)
> >> When the output clock of AUDSS mux is disabled, we are getting kernel
> >> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> >> user manual doesn't specify this dependency, we came across this issue
> >> while disabling the parent of AUDSS mux clocks.
> >
> > Hi Tushar,
> >
> > Can you help me understand better what the actual problem is? What is
> > the root cause of the kernel oops?
> 
> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
> As per observation, when the output of AUDSS mux is gated, we are not
> able to do any operation on the clocks provided by MAU block (mostly
> the clocks used by ADMA and audio blocks).

I tried to get a datasheet for Exynos 54xx but could not find it. I even
looked at the public 5250 data sheet, but it is completely missing
Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
"Clock names and clock tree diagram of MAUDIO_BLK".

So without any clue about your hardware (not for lack of trying) I would
guess that somewhere in the parent hierarchy you have an interface clock
which must be enabled in order for you to touch the registers pertaining
to the downstream audio clocks.

The right way to handle this requires two steps:

1) model your interface clock in the Linux clock framework if you
haven't already (I assume it is a gate clock, or the child of a gate
clock)

2) the clk_ops callbacks for the affected audio clocks should wrap their
operations (i.e. critical secion) with a clk_enable/clk_disable pair,
where the clock being enables/disable is the interface clock mentioned
above in #1

The CCF is reentrant, so you can do this by simply using the top-level
clk.h API from within your clk_ops callbacks.

I might be totally wrong about the cause of the hang, but that's my best
guess based on everyone's bug reports.

Regards,
Mike

> 
> >
> > You mention calling clk_get on child clocks of the AUDSS mux fails, but
> > I cannot imagine why. How can the enable/disable state of a clock affect
> > the ability to clk_get other clocks?
> >
> 
> I might have a little vogue while updating the commit message
> (mentioning about clk_get which surely is only a s/w operation), but
> there is definitely some issue with handling those clocks under given
> scenario.
> 
> I am on leave till end of this week, so I will update you more with
> the logs on Monday.
> 
> Thanks,
> --
> Tushar

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

If you want to be a stickler about it, peach-pi actually has a
max98091.  That requires code changes to the i2c driver, though.
...and unfortunately listing two compatible strings for i2c devices is
broken.  :(


> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..76f5966 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -78,9 +78,27 @@
>                 pinctrl-0 = <&usb301_vbus_en>;
>                 enable-active-high;
>         };
> +
> +       sound {
> +               compatible = "google,snow-audio-max98090";
> +
> +               samsung,i2s-controller = <&i2s0>;
> +               samsung,audio-codec = <&max98090>;
> +       };
> +};
> +
> +&i2s0 {
> +       status = "okay";

It would be awfully nice to keep diffs between exynos5420-peach-pit
and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
already gotten messed up with DP/HDMI were added, but there's no need
to make it worse.

Could you add these nodes in the same place within the dts they were
added in exynos5420-peach-pit?

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

If you want to be a stickler about it, peach-pi actually has a
max98091.  That requires code changes to the i2c driver, though.
...and unfortunately listing two compatible strings for i2c devices is
broken.  :(


> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..76f5966 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -78,9 +78,27 @@
>                 pinctrl-0 = <&usb301_vbus_en>;
>                 enable-active-high;
>         };
> +
> +       sound {
> +               compatible = "google,snow-audio-max98090";
> +
> +               samsung,i2s-controller = <&i2s0>;
> +               samsung,audio-codec = <&max98090>;
> +       };
> +};
> +
> +&i2s0 {
> +       status = "okay";

It would be awfully nice to keep diffs between exynos5420-peach-pit
and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
already gotten messed up with DP/HDMI were added, but there's no need
to make it worse.

Could you add these nodes in the same place within the dts they were
added in exynos5420-peach-pit?

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

If you want to be a stickler about it, peach-pi actually has a
max98091.  That requires code changes to the i2c driver, though.
...and unfortunately listing two compatible strings for i2c devices is
broken.  :(


> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index f3af207..76f5966 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -78,9 +78,27 @@
>                 pinctrl-0 = <&usb301_vbus_en>;
>                 enable-active-high;
>         };
> +
> +       sound {
> +               compatible = "google,snow-audio-max98090";
> +
> +               samsung,i2s-controller = <&i2s0>;
> +               samsung,audio-codec = <&max98090>;
> +       };
> +};
> +
> +&i2s0 {
> +       status = "okay";

It would be awfully nice to keep diffs between exynos5420-peach-pit
and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
already gotten messed up with DP/HDMI were added, but there's no need
to make it worse.

Could you add these nodes in the same place within the dts they were
added in exynos5420-peach-pit?

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:

> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(

It is?  We should fix that if it's the case...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:

> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(

It is?  We should fix that if it's the case...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:

> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(

It is?  We should fix that if it's the case...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140613/4f707c80/attachment.sig>

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>
>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>
> It is?  We should fix that if it's the case...

Yah, I mentioned it to Mark Rutland at the last ELC and he said he
might take a look at it, but I probably should have posted something
up to the i2c list.

I made a half-assed attempt to fix it locally in the ChromeOS but
quickly found that it was going to be a much bigger job than I had
time for...

https://chromium-review.googlesource.com/#/c/184406/

IIRC i2c_new_device didn't return an error like I thought it would,
probably trying to deal with the fact that devices might show up at a
later point in time.


Hrm, now that I think about it I wonder if the right answer is just to
call i2c_new_device for all the compatible strings even if it doesn't
return an error.  I'd have to go back and try that and re-explore this
code...

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>
>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>
> It is?  We should fix that if it's the case...

Yah, I mentioned it to Mark Rutland at the last ELC and he said he
might take a look at it, but I probably should have posted something
up to the i2c list.

I made a half-assed attempt to fix it locally in the ChromeOS but
quickly found that it was going to be a much bigger job than I had
time for...

https://chromium-review.googlesource.com/#/c/184406/

IIRC i2c_new_device didn't return an error like I thought it would,
probably trying to deal with the fact that devices might show up at a
later point in time.


Hrm, now that I think about it I wonder if the right answer is just to
call i2c_new_device for all the compatible strings even if it doesn't
return an error.  I'd have to go back and try that and re-explore this
code...

-Doug

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>
>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>
> It is?  We should fix that if it's the case...

Yah, I mentioned it to Mark Rutland at the last ELC and he said he
might take a look at it, but I probably should have posted something
up to the i2c list.

I made a half-assed attempt to fix it locally in the ChromeOS but
quickly found that it was going to be a much bigger job than I had
time for...

https://chromium-review.googlesource.com/#/c/184406/

IIRC i2c_new_device didn't return an error like I thought it would,
probably trying to deal with the fact that devices might show up at a
later point in time.


Hrm, now that I think about it I wonder if the right answer is just to
call i2c_new_device for all the compatible strings even if it doesn't
return an error.  I'd have to go back and try that and re-explore this
code...

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:13 AM, Doug Anderson <dianders@google.com> wrote:
> Mark,
>
> On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>
>>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>
>> It is?  We should fix that if it's the case...
>
> Yah, I mentioned it to Mark Rutland at the last ELC and he said he
> might take a look at it, but I probably should have posted something
> up to the i2c list.
>
> I made a half-assed attempt to fix it locally in the ChromeOS but
> quickly found that it was going to be a much bigger job than I had
> time for...
>
> https://chromium-review.googlesource.com/#/c/184406/
>
> IIRC i2c_new_device didn't return an error like I thought it would,
> probably trying to deal with the fact that devices might show up at a
> later point in time.
>
>
> Hrm, now that I think about it I wonder if the right answer is just to
> call i2c_new_device for all the compatible strings even if it doesn't
> return an error.  I'd have to go back and try that and re-explore this
> code...

Nope, that didn't work either.  Now I remember trying that before,
too.  It doesn't like you registering two different devices with the
same address:

[    2.582539] DOUG: /i2c@12CD0000/codec@10 (0) max98091
[    2.587360] DOUG: /i2c@12CD0000/codec@10 (0) max98091
[    2.591160] DOUG: /i2c@12CD0000/codec@10 (1) max98090
[    2.596686] i2c i2c-7: Failed to register i2c client max98090 at 0x10 (-16)

If you hack out the check for address business:

sysfs: cannot create duplicate filename '/devices/12cd0000.i2c/i2c-7/7-0010'

Anyway, suffice to say that the i2c core needs to be extended to
handle the idea that a single device has more than one "compatible"
string.  I'll leave it to an eager reader of this thread to implement
this since we can also fix our own problem by just listing "max98091"
in "sound/soc/codecs/max98090.c" like has always been done in the
past.


-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:13 AM, Doug Anderson <dianders-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> Mark,
>
> On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>
>>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>
>> It is?  We should fix that if it's the case...
>
> Yah, I mentioned it to Mark Rutland at the last ELC and he said he
> might take a look at it, but I probably should have posted something
> up to the i2c list.
>
> I made a half-assed attempt to fix it locally in the ChromeOS but
> quickly found that it was going to be a much bigger job than I had
> time for...
>
> https://chromium-review.googlesource.com/#/c/184406/
>
> IIRC i2c_new_device didn't return an error like I thought it would,
> probably trying to deal with the fact that devices might show up at a
> later point in time.
>
>
> Hrm, now that I think about it I wonder if the right answer is just to
> call i2c_new_device for all the compatible strings even if it doesn't
> return an error.  I'd have to go back and try that and re-explore this
> code...

Nope, that didn't work either.  Now I remember trying that before,
too.  It doesn't like you registering two different devices with the
same address:

[    2.582539] DOUG: /i2c@12CD0000/codec@10 (0) max98091
[    2.587360] DOUG: /i2c@12CD0000/codec@10 (0) max98091
[    2.591160] DOUG: /i2c@12CD0000/codec@10 (1) max98090
[    2.596686] i2c i2c-7: Failed to register i2c client max98090 at 0x10 (-16)

If you hack out the check for address business:

sysfs: cannot create duplicate filename '/devices/12cd0000.i2c/i2c-7/7-0010'

Anyway, suffice to say that the i2c core needs to be extended to
handle the idea that a single device has more than one "compatible"
string.  I'll leave it to an eager reader of this thread to implement
this since we can also fix our own problem by just listing "max98091"
in "sound/soc/codecs/max98090.c" like has always been done in the
past.


-Doug

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 10:13 AM, Doug Anderson <dianders@google.com> wrote:
> Mark,
>
> On Fri, Jun 13, 2014 at 10:05 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Fri, Jun 13, 2014 at 10:03:50AM -0700, Doug Anderson wrote:
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>
>>> > Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>
>> It is?  We should fix that if it's the case...
>
> Yah, I mentioned it to Mark Rutland at the last ELC and he said he
> might take a look at it, but I probably should have posted something
> up to the i2c list.
>
> I made a half-assed attempt to fix it locally in the ChromeOS but
> quickly found that it was going to be a much bigger job than I had
> time for...
>
> https://chromium-review.googlesource.com/#/c/184406/
>
> IIRC i2c_new_device didn't return an error like I thought it would,
> probably trying to deal with the fact that devices might show up at a
> later point in time.
>
>
> Hrm, now that I think about it I wonder if the right answer is just to
> call i2c_new_device for all the compatible strings even if it doesn't
> return an error.  I'd have to go back and try that and re-explore this
> code...

Nope, that didn't work either.  Now I remember trying that before,
too.  It doesn't like you registering two different devices with the
same address:

[    2.582539] DOUG: /i2c at 12CD0000/codec at 10 (0) max98091
[    2.587360] DOUG: /i2c at 12CD0000/codec at 10 (0) max98091
[    2.591160] DOUG: /i2c at 12CD0000/codec at 10 (1) max98090
[    2.596686] i2c i2c-7: Failed to register i2c client max98090 at 0x10 (-16)

If you hack out the check for address business:

sysfs: cannot create duplicate filename '/devices/12cd0000.i2c/i2c-7/7-0010'

Anyway, suffice to say that the i2c core needs to be extended to
handle the idea that a single device has more than one "compatible"
string.  I'll leave it to an eager reader of this thread to implement
this since we can also fix our own problem by just listing "max98091"
in "sound/soc/codecs/max98090.c" like has always been done in the
past.


-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:

> Anyway, suffice to say that the i2c core needs to be extended to
> handle the idea that a single device has more than one "compatible"
> string.  I'll leave it to an eager reader of this thread to implement
> this since we can also fix our own problem by just listing "max98091"
> in "sound/soc/codecs/max98090.c" like has always been done in the
> past.

Why do you need to register multiple compatible strings (I guess for
fallback purposes?).  A quick fix that is about as good is to take the
first compatible only.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 585 bytes --]

On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:

> Anyway, suffice to say that the i2c core needs to be extended to
> handle the idea that a single device has more than one "compatible"
> string.  I'll leave it to an eager reader of this thread to implement
> this since we can also fix our own problem by just listing "max98091"
> in "sound/soc/codecs/max98090.c" like has always been done in the
> past.

Why do you need to register multiple compatible strings (I guess for
fallback purposes?).  A quick fix that is about as good is to take the
first compatible only.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:

> Anyway, suffice to say that the i2c core needs to be extended to
> handle the idea that a single device has more than one "compatible"
> string.  I'll leave it to an eager reader of this thread to implement
> this since we can also fix our own problem by just listing "max98091"
> in "sound/soc/codecs/max98090.c" like has always been done in the
> past.

Why do you need to register multiple compatible strings (I guess for
fallback purposes?).  A quick fix that is about as good is to take the
first compatible only.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140613/49590638/attachment.sig>

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 3:04 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:
>
>> Anyway, suffice to say that the i2c core needs to be extended to
>> handle the idea that a single device has more than one "compatible"
>> string.  I'll leave it to an eager reader of this thread to implement
>> this since we can also fix our own problem by just listing "max98091"
>> in "sound/soc/codecs/max98090.c" like has always been done in the
>> past.
>
> Why do you need to register multiple compatible strings (I guess for
> fallback purposes?).

I'm no expert, but I think that's part of device tree isn't it?

In the case of max98090 and max98091, they are incredibly similar
pieces of hardware (I think the max98091 simply has more microphones).
If you've got a driver for a max98090 it will work just fine for a
max98091 but you just won't get the extra microphones.

In cases like this then device tree theory says that you should list
both compatible strings: max98091 and max98090, right?  If your OS has
a driver for max98091 it will use it.  ...if it doesn't but it has a
max98090 driver it will try that one.

As far as I understand we _shouldn't_ lie and just say that we have a
max98090 when we really have a max98091.  The device tree is supposed
to describe the hardware and isn't support to care that the OS has a
driver for max98090 but not max98091.

Ironically in our case we have a driver that supports both the 98090
and the 98091 via autodetect.  However, it doesn't know about the
98091 compatible string so if you list yourself as compatible with
98091 then it won't find the driver.

> A quick fix that is about as good is to take the
> first compatible only.

That's how the code works today, actually.  ...but as per above the
current 98090 driver doesn't know about the 98091 compatible string,
so:

compatible = "maxim,max98091", "maxim,max98090";

...won't find the right driver.

--

The quick fix is to add max98091 to the max98090 driver and is what
I'd suggest in this case.  ...but I still think that the above logic
is valid and eventually the i2c core should be fixed.  Please correct
me if I'm wrong.

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 3:04 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:
>
>> Anyway, suffice to say that the i2c core needs to be extended to
>> handle the idea that a single device has more than one "compatible"
>> string.  I'll leave it to an eager reader of this thread to implement
>> this since we can also fix our own problem by just listing "max98091"
>> in "sound/soc/codecs/max98090.c" like has always been done in the
>> past.
>
> Why do you need to register multiple compatible strings (I guess for
> fallback purposes?).

I'm no expert, but I think that's part of device tree isn't it?

In the case of max98090 and max98091, they are incredibly similar
pieces of hardware (I think the max98091 simply has more microphones).
If you've got a driver for a max98090 it will work just fine for a
max98091 but you just won't get the extra microphones.

In cases like this then device tree theory says that you should list
both compatible strings: max98091 and max98090, right?  If your OS has
a driver for max98091 it will use it.  ...if it doesn't but it has a
max98090 driver it will try that one.

As far as I understand we _shouldn't_ lie and just say that we have a
max98090 when we really have a max98091.  The device tree is supposed
to describe the hardware and isn't support to care that the OS has a
driver for max98090 but not max98091.

Ironically in our case we have a driver that supports both the 98090
and the 98091 via autodetect.  However, it doesn't know about the
98091 compatible string so if you list yourself as compatible with
98091 then it won't find the driver.

> A quick fix that is about as good is to take the
> first compatible only.

That's how the code works today, actually.  ...but as per above the
current 98090 driver doesn't know about the 98091 compatible string,
so:

compatible = "maxim,max98091", "maxim,max98090";

...won't find the right driver.

--

The quick fix is to add max98091 to the max98090 driver and is what
I'd suggest in this case.  ...but I still think that the above logic
is valid and eventually the i2c core should be fixed.  Please correct
me if I'm wrong.

-Doug

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Fri, Jun 13, 2014 at 3:04 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:
>
>> Anyway, suffice to say that the i2c core needs to be extended to
>> handle the idea that a single device has more than one "compatible"
>> string.  I'll leave it to an eager reader of this thread to implement
>> this since we can also fix our own problem by just listing "max98091"
>> in "sound/soc/codecs/max98090.c" like has always been done in the
>> past.
>
> Why do you need to register multiple compatible strings (I guess for
> fallback purposes?).

I'm no expert, but I think that's part of device tree isn't it?

In the case of max98090 and max98091, they are incredibly similar
pieces of hardware (I think the max98091 simply has more microphones).
If you've got a driver for a max98090 it will work just fine for a
max98091 but you just won't get the extra microphones.

In cases like this then device tree theory says that you should list
both compatible strings: max98091 and max98090, right?  If your OS has
a driver for max98091 it will use it.  ...if it doesn't but it has a
max98090 driver it will try that one.

As far as I understand we _shouldn't_ lie and just say that we have a
max98090 when we really have a max98091.  The device tree is supposed
to describe the hardware and isn't support to care that the OS has a
driver for max98090 but not max98091.

Ironically in our case we have a driver that supports both the 98090
and the 98091 via autodetect.  However, it doesn't know about the
98091 compatible string so if you list yourself as compatible with
98091 then it won't find the driver.

> A quick fix that is about as good is to take the
> first compatible only.

That's how the code works today, actually.  ...but as per above the
current 98090 driver doesn't know about the 98091 compatible string,
so:

compatible = "maxim,max98091", "maxim,max98090";

...won't find the right driver.

--

The quick fix is to add max98091 to the max98090 driver and is what
I'd suggest in this case.  ...but I still think that the above logic
is valid and eventually the i2c core should be fixed.  Please correct
me if I'm wrong.

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On 06/13/2014 10:33 PM, Doug Anderson wrote:
> Tushar,
> 
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
> 
> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(
> 
Hi Doug,

You are right. I checked the boot logs, the detected codec type is
MAX98091. Since both these CODECs are supported through a single driver
and the detection of chip is done during runtime, I would suggest we go
ahead with "max98090" compatible string. I will update the commit
message accordingly.

Does that sound okay to you?

> 
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index f3af207..76f5966 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -78,9 +78,27 @@
>>                 pinctrl-0 = <&usb301_vbus_en>;
>>                 enable-active-high;
>>         };
>> +
>> +       sound {
>> +               compatible = "google,snow-audio-max98090";
>> +
>> +               samsung,i2s-controller = <&i2s0>;
>> +               samsung,audio-codec = <&max98090>;
>> +       };
>> +};
>> +
>> +&i2s0 {
>> +       status = "okay";
> 
> It would be awfully nice to keep diffs between exynos5420-peach-pit
> and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
> already gotten messed up with DP/HDMI were added, but there's no need
> to make it worse.
> 

If you so desire, I will submit a patch to sort peach-pi device-tree
nodes (w.r.t. peach-pit dts file).

> Could you add these nodes in the same place within the dts they were
> added in exynos5420-peach-pit?
> 

Okay, I will add it after watchdog node.

-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On 06/13/2014 10:33 PM, Doug Anderson wrote:
> Tushar,
> 
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
> 
> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(
> 
Hi Doug,

You are right. I checked the boot logs, the detected codec type is
MAX98091. Since both these CODECs are supported through a single driver
and the detection of chip is done during runtime, I would suggest we go
ahead with "max98090" compatible string. I will update the commit
message accordingly.

Does that sound okay to you?

> 
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index f3af207..76f5966 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -78,9 +78,27 @@
>>                 pinctrl-0 = <&usb301_vbus_en>;
>>                 enable-active-high;
>>         };
>> +
>> +       sound {
>> +               compatible = "google,snow-audio-max98090";
>> +
>> +               samsung,i2s-controller = <&i2s0>;
>> +               samsung,audio-codec = <&max98090>;
>> +       };
>> +};
>> +
>> +&i2s0 {
>> +       status = "okay";
> 
> It would be awfully nice to keep diffs between exynos5420-peach-pit
> and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
> already gotten messed up with DP/HDMI were added, but there's no need
> to make it worse.
> 

If you so desire, I will submit a patch to sort peach-pi device-tree
nodes (w.r.t. peach-pit dts file).

> Could you add these nodes in the same place within the dts they were
> added in exynos5420-peach-pit?
> 

Okay, I will add it after watchdog node.

-- 
Tushar Behera

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On 06/13/2014 10:33 PM, Doug Anderson wrote:
> Tushar,
> 
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
> 
> If you want to be a stickler about it, peach-pi actually has a
> max98091.  That requires code changes to the i2c driver, though.
> ...and unfortunately listing two compatible strings for i2c devices is
> broken.  :(
> 
Hi Doug,

You are right. I checked the boot logs, the detected codec type is
MAX98091. Since both these CODECs are supported through a single driver
and the detection of chip is done during runtime, I would suggest we go
ahead with "max98090" compatible string. I will update the commit
message accordingly.

Does that sound okay to you?

> 
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts |   31 +++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index f3af207..76f5966 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -78,9 +78,27 @@
>>                 pinctrl-0 = <&usb301_vbus_en>;
>>                 enable-active-high;
>>         };
>> +
>> +       sound {
>> +               compatible = "google,snow-audio-max98090";
>> +
>> +               samsung,i2s-controller = <&i2s0>;
>> +               samsung,audio-codec = <&max98090>;
>> +       };
>> +};
>> +
>> +&i2s0 {
>> +       status = "okay";
> 
> It would be awfully nice to keep diffs between exynos5420-peach-pit
> and exynos5800-peach-pi clean.  They're 99% the same.  I know this has
> already gotten messed up with DP/HDMI were added, but there's no need
> to make it worse.
> 

If you so desire, I will submit a patch to sort peach-pi device-tree
nodes (w.r.t. peach-pit dts file).

> Could you add these nodes in the same place within the dts they were
> added in exynos5420-peach-pit?
> 

Okay, I will add it after watchdog node.

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index e385322..79e9119 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -167,7 +167,7 @@
>>                 compatible = "samsung,exynos5420-audss-clock";
>>                 reg = <0x03810000 0x0C>;
>>                 #clock-cells = <1>;
>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>         };
>> --
>> 1.7.9.5
>>
>> --
> 
> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 

Kukjin,

Would you please take this patch as a fix for 3.16?

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index e385322..79e9119 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -167,7 +167,7 @@
>>                 compatible = "samsung,exynos5420-audss-clock";
>>                 reg = <0x03810000 0x0C>;
>>                 #clock-cells = <1>;
>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>         };
>> --
>> 1.7.9.5
>>
>> --
> 
> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 

Kukjin,

Would you please take this patch as a fix for 3.16?

-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>> index e385322..79e9119 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -167,7 +167,7 @@
>>                 compatible = "samsung,exynos5420-audss-clock";
>>                 reg = <0x03810000 0x0C>;
>>                 #clock-cells = <1>;
>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>         };
>> --
>> 1.7.9.5
>>
>> --
> 
> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> 

Kukjin,

Would you please take this patch as a fix for 3.16?

-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>>
> Hi Doug,
>
> You are right. I checked the boot logs, the detected codec type is
> MAX98091. Since both these CODECs are supported through a single driver
> and the detection of chip is done during runtime, I would suggest we go
> ahead with "max98090" compatible string. I will update the commit
> message accordingly.
>
> Does that sound okay to you?

As per my understanding you shouldn't do this.  You should have two patches:

1. Add "max98091".  You could simply post Wonjoon's patch from
<https://chromium-review.googlesource.com/184091>

2. Change the device tree to refer to "max98091"

The argument that the "current kernel driver has a single driver" is
an argument that you're not supposed to make for device tree.  The
same device tree is supposed to work for U-Boot, BSD, or any other
platform.  On those platforms it might not be a shared driver.


> If you so desire, I will submit a patch to sort peach-pi device-tree
> nodes (w.r.t. peach-pit dts file).

Yes please.  I think there's supposed to be some official ordering of
things.  If anyone reading this has a pointer to the official sort
order of things in the device tree I'd love to see it!  ;)

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>>
> Hi Doug,
>
> You are right. I checked the boot logs, the detected codec type is
> MAX98091. Since both these CODECs are supported through a single driver
> and the detection of chip is done during runtime, I would suggest we go
> ahead with "max98090" compatible string. I will update the commit
> message accordingly.
>
> Does that sound okay to you?

As per my understanding you shouldn't do this.  You should have two patches:

1. Add "max98091".  You could simply post Wonjoon's patch from
<https://chromium-review.googlesource.com/184091>

2. Change the device tree to refer to "max98091"

The argument that the "current kernel driver has a single driver" is
an argument that you're not supposed to make for device tree.  The
same device tree is supposed to work for U-Boot, BSD, or any other
platform.  On those platforms it might not be a shared driver.


> If you so desire, I will submit a patch to sort peach-pi device-tree
> nodes (w.r.t. peach-pit dts file).

Yes please.  I think there's supposed to be some official ordering of
things.  If anyone reading this has a pointer to the official sort
order of things in the device tree I'd love to see it!  ;)

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>
>> If you want to be a stickler about it, peach-pi actually has a
>> max98091.  That requires code changes to the i2c driver, though.
>> ...and unfortunately listing two compatible strings for i2c devices is
>> broken.  :(
>>
> Hi Doug,
>
> You are right. I checked the boot logs, the detected codec type is
> MAX98091. Since both these CODECs are supported through a single driver
> and the detection of chip is done during runtime, I would suggest we go
> ahead with "max98090" compatible string. I will update the commit
> message accordingly.
>
> Does that sound okay to you?

As per my understanding you shouldn't do this.  You should have two patches:

1. Add "max98091".  You could simply post Wonjoon's patch from
<https://chromium-review.googlesource.com/184091>

2. Change the device tree to refer to "max98091"

The argument that the "current kernel driver has a single driver" is
an argument that you're not supposed to make for device tree.  The
same device tree is supposed to work for U-Boot, BSD, or any other
platform.  On those platforms it might not be a shared driver.


> If you so desire, I will submit a patch to sort peach-pi device-tree
> nodes (w.r.t. peach-pit dts file).

Yes please.  I think there's supposed to be some official ordering of
things.  If anyone reading this has a pointer to the official sort
order of things in the device tree I'd love to see it!  ;)

-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:

> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)

Most exact first I believe?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:

> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)

Most exact first I believe?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Mark Brown]

On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:

> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)

Most exact first I believe?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140616/2589c554/attachment.sig>

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>
>> Yes please.  I think there's supposed to be some official ordering of
>> things.  If anyone reading this has a pointer to the official sort
>> order of things in the device tree I'd love to see it!  ;)
>
> Most exact first I believe?

More specifically I'm looking for the ordering between nodes and
between properties in a node.  For instance:

1. It appears to be convention to sort children of the "pinctrl" nodes
by the first pin number in that group.  That is:

ec_spi_cs: ec-spi-cs {
  samsung,pins = "gpb1-2";
  ...
};

...comes before:
usb300_vbus_en: usb300-vbus-en {
  samsung,pins = "gph0-0";
  ...
};

...that's one really good and well-defined ordering.


2. I have no idea how general properties should be sorted.  I tend to
see "compatible" first but that's above the only rule I've seen.
Sometimes I've seen "status" first, sometimes last, sometimes
alphabetically sorted, and sometimes in a random place.  Examples:

usb301_vbus_reg: regulator-usb301 {
  compatible = "regulator-fixed";
  regulator-name = "P5.0V_USB3CON1";
  regulator-min-microvolt = <5000000>;
  regulator-max-microvolt = <5000000>;
  gpio = <&gph0 1 0>;
  pinctrl-names = "default";
  pinctrl-0 = <&usb301_vbus_en>;
  enable-active-high;
};

&hdmi {
  status = "okay";
  hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
  pinctrl-names = "default";
  pinctrl-0 = <&hdmi_hpd_irq>;
  ddc = <&i2c_2>;
};


3. I have no idea how to sort nodes.  In theory you could say that
they should be sorted by base address:

i2s0: i2s@03830000 {
  ...
};

hsi2c_7: i2c@12CD0000 {
  ...
};

i2s1: i2s@12D60000 {
  ...
};

...that works until someone argues that all of the "i2s" nodes should
be together.  It also doesn't work so well with the board convention
of using aliases to refer to things in the SoC, like:

&i2s0 {
  status = "okay";
};

&hsi2c_7 {
  status = "okay";
};

...it's not at all obvious in the board file what the base address in
the SoC was.

---

Anyway, none of this is earth shattering and it doesn't matter all
that much.  It's just nice to have an official order to make diffing
easier and also to avoid merge conflicts (unlikely someone changing
different properties will both add them in the same place in the
ordering).


-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>
>> Yes please.  I think there's supposed to be some official ordering of
>> things.  If anyone reading this has a pointer to the official sort
>> order of things in the device tree I'd love to see it!  ;)
>
> Most exact first I believe?

More specifically I'm looking for the ordering between nodes and
between properties in a node.  For instance:

1. It appears to be convention to sort children of the "pinctrl" nodes
by the first pin number in that group.  That is:

ec_spi_cs: ec-spi-cs {
  samsung,pins = "gpb1-2";
  ...
};

...comes before:
usb300_vbus_en: usb300-vbus-en {
  samsung,pins = "gph0-0";
  ...
};

...that's one really good and well-defined ordering.


2. I have no idea how general properties should be sorted.  I tend to
see "compatible" first but that's above the only rule I've seen.
Sometimes I've seen "status" first, sometimes last, sometimes
alphabetically sorted, and sometimes in a random place.  Examples:

usb301_vbus_reg: regulator-usb301 {
  compatible = "regulator-fixed";
  regulator-name = "P5.0V_USB3CON1";
  regulator-min-microvolt = <5000000>;
  regulator-max-microvolt = <5000000>;
  gpio = <&gph0 1 0>;
  pinctrl-names = "default";
  pinctrl-0 = <&usb301_vbus_en>;
  enable-active-high;
};

&hdmi {
  status = "okay";
  hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
  pinctrl-names = "default";
  pinctrl-0 = <&hdmi_hpd_irq>;
  ddc = <&i2c_2>;
};


3. I have no idea how to sort nodes.  In theory you could say that
they should be sorted by base address:

i2s0: i2s@03830000 {
  ...
};

hsi2c_7: i2c@12CD0000 {
  ...
};

i2s1: i2s@12D60000 {
  ...
};

...that works until someone argues that all of the "i2s" nodes should
be together.  It also doesn't work so well with the board convention
of using aliases to refer to things in the SoC, like:

&i2s0 {
  status = "okay";
};

&hsi2c_7 {
  status = "okay";
};

...it's not at all obvious in the board file what the base address in
the SoC was.

---

Anyway, none of this is earth shattering and it doesn't matter all
that much.  It's just nice to have an official order to make diffing
easier and also to avoid merge conflicts (unlikely someone changing
different properties will both add them in the same place in the
ordering).


-Doug

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Mark,

On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>
>> Yes please.  I think there's supposed to be some official ordering of
>> things.  If anyone reading this has a pointer to the official sort
>> order of things in the device tree I'd love to see it!  ;)
>
> Most exact first I believe?

More specifically I'm looking for the ordering between nodes and
between properties in a node.  For instance:

1. It appears to be convention to sort children of the "pinctrl" nodes
by the first pin number in that group.  That is:

ec_spi_cs: ec-spi-cs {
  samsung,pins = "gpb1-2";
  ...
};

...comes before:
usb300_vbus_en: usb300-vbus-en {
  samsung,pins = "gph0-0";
  ...
};

...that's one really good and well-defined ordering.


2. I have no idea how general properties should be sorted.  I tend to
see "compatible" first but that's above the only rule I've seen.
Sometimes I've seen "status" first, sometimes last, sometimes
alphabetically sorted, and sometimes in a random place.  Examples:

usb301_vbus_reg: regulator-usb301 {
  compatible = "regulator-fixed";
  regulator-name = "P5.0V_USB3CON1";
  regulator-min-microvolt = <5000000>;
  regulator-max-microvolt = <5000000>;
  gpio = <&gph0 1 0>;
  pinctrl-names = "default";
  pinctrl-0 = <&usb301_vbus_en>;
  enable-active-high;
};

&hdmi {
  status = "okay";
  hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
  pinctrl-names = "default";
  pinctrl-0 = <&hdmi_hpd_irq>;
  ddc = <&i2c_2>;
};


3. I have no idea how to sort nodes.  In theory you could say that
they should be sorted by base address:

i2s0: i2s at 03830000 {
  ...
};

hsi2c_7: i2c at 12CD0000 {
  ...
};

i2s1: i2s at 12D60000 {
  ...
};

...that works until someone argues that all of the "i2s" nodes should
be together.  It also doesn't work so well with the board convention
of using aliases to refer to things in the SoC, like:

&i2s0 {
  status = "okay";
};

&hsi2c_7 {
  status = "okay";
};

...it's not at all obvious in the board file what the base address in
the SoC was.

---

Anyway, none of this is earth shattering and it doesn't matter all
that much.  It's just nice to have an official order to make diffing
easier and also to avoid merge conflicts (unlikely someone changing
different properties will both add them in the same place in the
ordering).


-Doug

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
> Tushar,
>
> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>>
>> Hi Doug,
>>
>> You are right. I checked the boot logs, the detected codec type is
>> MAX98091. Since both these CODECs are supported through a single driver
>> and the detection of chip is done during runtime, I would suggest we go
>> ahead with "max98090" compatible string. I will update the commit
>> message accordingly.
>>
>> Does that sound okay to you?
>
> As per my understanding you shouldn't do this.  You should have two patches:
>
> 1. Add "max98091".  You could simply post Wonjoon's patch from
> <https://chromium-review.googlesource.com/184091>
>
> 2. Change the device tree to refer to "max98091"
>
> The argument that the "current kernel driver has a single driver" is
> an argument that you're not supposed to make for device tree.  The
> same device tree is supposed to work for U-Boot, BSD, or any other
> platform.  On those platforms it might not be a shared driver.
>

My argument is that the device type is getting detected during
runtime, hence there is no need to differentiate between these two.

But if you prefer that way, I will repost.

>
>> If you so desire, I will submit a patch to sort peach-pi device-tree
>> nodes (w.r.t. peach-pit dts file).
>
> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)
>
> -Doug

-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
> Tushar,
>
> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>>
>> Hi Doug,
>>
>> You are right. I checked the boot logs, the detected codec type is
>> MAX98091. Since both these CODECs are supported through a single driver
>> and the detection of chip is done during runtime, I would suggest we go
>> ahead with "max98090" compatible string. I will update the commit
>> message accordingly.
>>
>> Does that sound okay to you?
>
> As per my understanding you shouldn't do this.  You should have two patches:
>
> 1. Add "max98091".  You could simply post Wonjoon's patch from
> <https://chromium-review.googlesource.com/184091>
>
> 2. Change the device tree to refer to "max98091"
>
> The argument that the "current kernel driver has a single driver" is
> an argument that you're not supposed to make for device tree.  The
> same device tree is supposed to work for U-Boot, BSD, or any other
> platform.  On those platforms it might not be a shared driver.
>

My argument is that the device type is getting detected during
runtime, hence there is no need to differentiate between these two.

But if you prefer that way, I will repost.

>
>> If you so desire, I will submit a patch to sort peach-pi device-tree
>> nodes (w.r.t. peach-pit dts file).
>
> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)
>
> -Doug

-- 
Tushar Behera

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
> Tushar,
>
> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>>
>> Hi Doug,
>>
>> You are right. I checked the boot logs, the detected codec type is
>> MAX98091. Since both these CODECs are supported through a single driver
>> and the detection of chip is done during runtime, I would suggest we go
>> ahead with "max98090" compatible string. I will update the commit
>> message accordingly.
>>
>> Does that sound okay to you?
>
> As per my understanding you shouldn't do this.  You should have two patches:
>
> 1. Add "max98091".  You could simply post Wonjoon's patch from
> <https://chromium-review.googlesource.com/184091>
>
> 2. Change the device tree to refer to "max98091"
>
> The argument that the "current kernel driver has a single driver" is
> an argument that you're not supposed to make for device tree.  The
> same device tree is supposed to work for U-Boot, BSD, or any other
> platform.  On those platforms it might not be a shared driver.
>

My argument is that the device type is getting detected during
runtime, hence there is no need to differentiate between these two.

But if you prefer that way, I will repost.

>
>> If you so desire, I will submit a patch to sort peach-pi device-tree
>> nodes (w.r.t. peach-pit dts file).
>
> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)
>
> -Doug

-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:32 PM, Doug Anderson <dianders@google.com> wrote:
> Mark,
>
> On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>>
>>> Yes please.  I think there's supposed to be some official ordering of
>>> things.  If anyone reading this has a pointer to the official sort
>>> order of things in the device tree I'd love to see it!  ;)
>>
>> Most exact first I believe?
>
> More specifically I'm looking for the ordering between nodes and
> between properties in a node.  For instance:
>
> 1. It appears to be convention to sort children of the "pinctrl" nodes
> by the first pin number in that group.  That is:
>
> ec_spi_cs: ec-spi-cs {
>   samsung,pins = "gpb1-2";
>   ...
> };
>
> ...comes before:
> usb300_vbus_en: usb300-vbus-en {
>   samsung,pins = "gph0-0";
>   ...
> };
>
> ...that's one really good and well-defined ordering.
>
>
> 2. I have no idea how general properties should be sorted.  I tend to
> see "compatible" first but that's above the only rule I've seen.
> Sometimes I've seen "status" first, sometimes last, sometimes
> alphabetically sorted, and sometimes in a random place.  Examples:
>
> usb301_vbus_reg: regulator-usb301 {
>   compatible = "regulator-fixed";
>   regulator-name = "P5.0V_USB3CON1";
>   regulator-min-microvolt = <5000000>;
>   regulator-max-microvolt = <5000000>;
>   gpio = <&gph0 1 0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&usb301_vbus_en>;
>   enable-active-high;
> };
>
> &hdmi {
>   status = "okay";
>   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&hdmi_hpd_irq>;
>   ddc = <&i2c_2>;
> };
>
>
> 3. I have no idea how to sort nodes.  In theory you could say that
> they should be sorted by base address:
>
> i2s0: i2s@03830000 {
>   ...
> };
>
> hsi2c_7: i2c@12CD0000 {
>   ...
> };
>
> i2s1: i2s@12D60000 {
>   ...
> };
>
> ...that works until someone argues that all of the "i2s" nodes should
> be together.  It also doesn't work so well with the board convention
> of using aliases to refer to things in the SoC, like:
>
> &i2s0 {
>   status = "okay";
> };
>
> &hsi2c_7 {
>   status = "okay";
> };
>
> ...it's not at all obvious in the board file what the base address in
> the SoC was.
>

In case where we are using only aliases in board file, sorting them
alphabetically would be reasonable. This rule would be easy to
reinforce.

> ---
>
> Anyway, none of this is earth shattering and it doesn't matter all
> that much.  It's just nice to have an official order to make diffing
> easier and also to avoid merge conflicts (unlikely someone changing
> different properties will both add them in the same place in the
> ordering).
>
>
> -Doug



-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:32 PM, Doug Anderson <dianders@google.com> wrote:
> Mark,
>
> On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>>
>>> Yes please.  I think there's supposed to be some official ordering of
>>> things.  If anyone reading this has a pointer to the official sort
>>> order of things in the device tree I'd love to see it!  ;)
>>
>> Most exact first I believe?
>
> More specifically I'm looking for the ordering between nodes and
> between properties in a node.  For instance:
>
> 1. It appears to be convention to sort children of the "pinctrl" nodes
> by the first pin number in that group.  That is:
>
> ec_spi_cs: ec-spi-cs {
>   samsung,pins = "gpb1-2";
>   ...
> };
>
> ...comes before:
> usb300_vbus_en: usb300-vbus-en {
>   samsung,pins = "gph0-0";
>   ...
> };
>
> ...that's one really good and well-defined ordering.
>
>
> 2. I have no idea how general properties should be sorted.  I tend to
> see "compatible" first but that's above the only rule I've seen.
> Sometimes I've seen "status" first, sometimes last, sometimes
> alphabetically sorted, and sometimes in a random place.  Examples:
>
> usb301_vbus_reg: regulator-usb301 {
>   compatible = "regulator-fixed";
>   regulator-name = "P5.0V_USB3CON1";
>   regulator-min-microvolt = <5000000>;
>   regulator-max-microvolt = <5000000>;
>   gpio = <&gph0 1 0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&usb301_vbus_en>;
>   enable-active-high;
> };
>
> &hdmi {
>   status = "okay";
>   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&hdmi_hpd_irq>;
>   ddc = <&i2c_2>;
> };
>
>
> 3. I have no idea how to sort nodes.  In theory you could say that
> they should be sorted by base address:
>
> i2s0: i2s@03830000 {
>   ...
> };
>
> hsi2c_7: i2c@12CD0000 {
>   ...
> };
>
> i2s1: i2s@12D60000 {
>   ...
> };
>
> ...that works until someone argues that all of the "i2s" nodes should
> be together.  It also doesn't work so well with the board convention
> of using aliases to refer to things in the SoC, like:
>
> &i2s0 {
>   status = "okay";
> };
>
> &hsi2c_7 {
>   status = "okay";
> };
>
> ...it's not at all obvious in the board file what the base address in
> the SoC was.
>

In case where we are using only aliases in board file, sorting them
alphabetically would be reasonable. This rule would be easy to
reinforce.

> ---
>
> Anyway, none of this is earth shattering and it doesn't matter all
> that much.  It's just nice to have an official order to make diffing
> easier and also to avoid merge conflicts (unlikely someone changing
> different properties will both add them in the same place in the
> ordering).
>
>
> -Doug



-- 
Tushar Behera

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:32 PM, Doug Anderson <dianders@google.com> wrote:
> Mark,
>
> On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>>
>>> Yes please.  I think there's supposed to be some official ordering of
>>> things.  If anyone reading this has a pointer to the official sort
>>> order of things in the device tree I'd love to see it!  ;)
>>
>> Most exact first I believe?
>
> More specifically I'm looking for the ordering between nodes and
> between properties in a node.  For instance:
>
> 1. It appears to be convention to sort children of the "pinctrl" nodes
> by the first pin number in that group.  That is:
>
> ec_spi_cs: ec-spi-cs {
>   samsung,pins = "gpb1-2";
>   ...
> };
>
> ...comes before:
> usb300_vbus_en: usb300-vbus-en {
>   samsung,pins = "gph0-0";
>   ...
> };
>
> ...that's one really good and well-defined ordering.
>
>
> 2. I have no idea how general properties should be sorted.  I tend to
> see "compatible" first but that's above the only rule I've seen.
> Sometimes I've seen "status" first, sometimes last, sometimes
> alphabetically sorted, and sometimes in a random place.  Examples:
>
> usb301_vbus_reg: regulator-usb301 {
>   compatible = "regulator-fixed";
>   regulator-name = "P5.0V_USB3CON1";
>   regulator-min-microvolt = <5000000>;
>   regulator-max-microvolt = <5000000>;
>   gpio = <&gph0 1 0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&usb301_vbus_en>;
>   enable-active-high;
> };
>
> &hdmi {
>   status = "okay";
>   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&hdmi_hpd_irq>;
>   ddc = <&i2c_2>;
> };
>
>
> 3. I have no idea how to sort nodes.  In theory you could say that
> they should be sorted by base address:
>
> i2s0: i2s at 03830000 {
>   ...
> };
>
> hsi2c_7: i2c at 12CD0000 {
>   ...
> };
>
> i2s1: i2s at 12D60000 {
>   ...
> };
>
> ...that works until someone argues that all of the "i2s" nodes should
> be together.  It also doesn't work so well with the board convention
> of using aliases to refer to things in the SoC, like:
>
> &i2s0 {
>   status = "okay";
> };
>
> &hsi2c_7 {
>   status = "okay";
> };
>
> ...it's not at all obvious in the board file what the base address in
> the SoC was.
>

In case where we are using only aliases in board file, sorting them
alphabetically would be reasonable. This rule would be easy to
reinforce.

> ---
>
> Anyway, none of this is earth shattering and it doesn't matter all
> that much.  It's just nice to have an official order to make diffing
> easier and also to avoid merge conflicts (unlikely someone changing
> different properties will both add them in the same place in the
> ordering).
>
>
> -Doug



-- 
Tushar Behera

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 8:36 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
>> Tushar,
>>
>> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>>
>>>> If you want to be a stickler about it, peach-pi actually has a
>>>> max98091.  That requires code changes to the i2c driver, though.
>>>> ...and unfortunately listing two compatible strings for i2c devices is
>>>> broken.  :(
>>>>
>>> Hi Doug,
>>>
>>> You are right. I checked the boot logs, the detected codec type is
>>> MAX98091. Since both these CODECs are supported through a single driver
>>> and the detection of chip is done during runtime, I would suggest we go
>>> ahead with "max98090" compatible string. I will update the commit
>>> message accordingly.
>>>
>>> Does that sound okay to you?
>>
>> As per my understanding you shouldn't do this.  You should have two patches:
>>
>> 1. Add "max98091".  You could simply post Wonjoon's patch from
>> <https://chromium-review.googlesource.com/184091>
>>
>> 2. Change the device tree to refer to "max98091"
>>
>> The argument that the "current kernel driver has a single driver" is
>> an argument that you're not supposed to make for device tree.  The
>> same device tree is supposed to work for U-Boot, BSD, or any other
>> platform.  On those platforms it might not be a shared driver.
>>
>
> My argument is that the device type is getting detected during
> runtime, hence there is no need to differentiate between these two.
>
> But if you prefer that way, I will repost.

Yes please.

True that it is possible to detect 98090 vs. 98091.  ...but it's also
possible to detect exynos5250 vs. exynos5420 vs. exynos5800.  ...yet
they have different compatible strings.

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 8:36 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
>> Tushar,
>>
>> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>>
>>>> If you want to be a stickler about it, peach-pi actually has a
>>>> max98091.  That requires code changes to the i2c driver, though.
>>>> ...and unfortunately listing two compatible strings for i2c devices is
>>>> broken.  :(
>>>>
>>> Hi Doug,
>>>
>>> You are right. I checked the boot logs, the detected codec type is
>>> MAX98091. Since both these CODECs are supported through a single driver
>>> and the detection of chip is done during runtime, I would suggest we go
>>> ahead with "max98090" compatible string. I will update the commit
>>> message accordingly.
>>>
>>> Does that sound okay to you?
>>
>> As per my understanding you shouldn't do this.  You should have two patches:
>>
>> 1. Add "max98091".  You could simply post Wonjoon's patch from
>> <https://chromium-review.googlesource.com/184091>
>>
>> 2. Change the device tree to refer to "max98091"
>>
>> The argument that the "current kernel driver has a single driver" is
>> an argument that you're not supposed to make for device tree.  The
>> same device tree is supposed to work for U-Boot, BSD, or any other
>> platform.  On those platforms it might not be a shared driver.
>>
>
> My argument is that the device type is getting detected during
> runtime, hence there is no need to differentiate between these two.
>
> But if you prefer that way, I will repost.

Yes please.

True that it is possible to detect 98090 vs. 98091.  ...but it's also
possible to detect exynos5250 vs. exynos5420 vs. exynos5800.  ...yet
they have different compatible strings.

[PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 8:36 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson <dianders@google.com> wrote:
>> Tushar,
>>
>> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>>
>>>> If you want to be a stickler about it, peach-pi actually has a
>>>> max98091.  That requires code changes to the i2c driver, though.
>>>> ...and unfortunately listing two compatible strings for i2c devices is
>>>> broken.  :(
>>>>
>>> Hi Doug,
>>>
>>> You are right. I checked the boot logs, the detected codec type is
>>> MAX98091. Since both these CODECs are supported through a single driver
>>> and the detection of chip is done during runtime, I would suggest we go
>>> ahead with "max98090" compatible string. I will update the commit
>>> message accordingly.
>>>
>>> Does that sound okay to you?
>>
>> As per my understanding you shouldn't do this.  You should have two patches:
>>
>> 1. Add "max98091".  You could simply post Wonjoon's patch from
>> <https://chromium-review.googlesource.com/184091>
>>
>> 2. Change the device tree to refer to "max98091"
>>
>> The argument that the "current kernel driver has a single driver" is
>> an argument that you're not supposed to make for device tree.  The
>> same device tree is supposed to work for U-Boot, BSD, or any other
>> platform.  On those platforms it might not be a shared driver.
>>
>
> My argument is that the device type is getting detected during
> runtime, hence there is no need to differentiate between these two.
>
> But if you prefer that way, I will repost.

Yes please.

True that it is possible to detect 98090 vs. 98091.  ...but it's also
possible to detect exynos5250 vs. exynos5420 vs. exynos5800.  ...yet
they have different compatible strings.

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Mon, Jun 16, 2014 at 4:56 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
>> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>> index e385322..79e9119 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -167,7 +167,7 @@
>>>                 compatible = "samsung,exynos5420-audss-clock";
>>>                 reg = <0x03810000 0x0C>;
>>>                 #clock-cells = <1>;
>>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>>         };
>>> --
>>> 1.7.9.5
>>>
>>> --
>>
>> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>
> Kukjin,
>
> Would you please take this patch as a fix for 3.16?
>
> --
> Tushar Behera

Kukjin,

Please pick this patch for 3.16. This is an essential fix required for
Peach-pit/Peach-pi board.

--
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Mon, Jun 16, 2014 at 4:56 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
>> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>> index e385322..79e9119 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -167,7 +167,7 @@
>>>                 compatible = "samsung,exynos5420-audss-clock";
>>>                 reg = <0x03810000 0x0C>;
>>>                 #clock-cells = <1>;
>>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>>         };
>>> --
>>> 1.7.9.5
>>>
>>> --
>>
>> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>
> Kukjin,
>
> Would you please take this patch as a fix for 3.16?
>
> --
> Tushar Behera

Kukjin,

Please pick this patch for 3.16. This is an essential fix required for
Peach-pit/Peach-pi board.

--
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Mon, Jun 16, 2014 at 4:56 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/11/2014 09:28 PM, Javier Martinez Canillas wrote:
>> On Wed, Jun 11, 2014 at 7:32 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
>>> index e385322..79e9119 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -167,7 +167,7 @@
>>>                 compatible = "samsung,exynos5420-audss-clock";
>>>                 reg = <0x03810000 0x0C>;
>>>                 #clock-cells = <1>;
>>> -               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
>>> +               clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MAU_EPLL>,
>>>                          <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
>>>                 clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
>>>         };
>>> --
>>> 1.7.9.5
>>>
>>> --
>>
>> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>>
>
> Kukjin,
>
> Would you please take this patch as a fix for 3.16?
>
> --
> Tushar Behera

Kukjin,

Please pick this patch for 3.16. This is an essential fix required for
Peach-pit/Peach-pi board.

--
Tushar Behera

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>> Tushar Behera <tushar.b@samsung.com> writes:
>>
>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>
>>> Though user manual doesn't specify this dependency, we came across
>>> this issue while disabling the parent of AUDSS mux clocks.
>>>
>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>
>> While this patch works (and fixes the boot problem for me), it seems
>> like it's papering over the real problem.
>>
>
> Thanks for testing.
>
>> Seems like the right fix is actually modelling the clocks properly so
>> that enabling a child clock ensures that the parent is also enabled.
>>
>
> Patch 2/3 was to ensure we have proper clock tree defined for
> Exynos5420. While testing with audio disabled, that patch alone fixed
> the issue. But when audio was enabled (and hence I2S0 was trying to
> access the clocks), we got some kernel oops during late booting, hence
> I came up this solution.
>
> The solution might be a little half-baked because of the urgency to
> push the fix, but will try to dig more into the issue on Monday when I
> resume office.

Which Monday were you referring to?  ;)

...but in all seriousness do you have an official status update on
this patch?  It seems as if it's not needed and all you need is
<https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
get an official confirmation.

Thanks!

-Doug

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>> Tushar Behera <tushar.b@samsung.com> writes:
>>
>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>
>>> Though user manual doesn't specify this dependency, we came across
>>> this issue while disabling the parent of AUDSS mux clocks.
>>>
>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>
>> While this patch works (and fixes the boot problem for me), it seems
>> like it's papering over the real problem.
>>
>
> Thanks for testing.
>
>> Seems like the right fix is actually modelling the clocks properly so
>> that enabling a child clock ensures that the parent is also enabled.
>>
>
> Patch 2/3 was to ensure we have proper clock tree defined for
> Exynos5420. While testing with audio disabled, that patch alone fixed
> the issue. But when audio was enabled (and hence I2S0 was trying to
> access the clocks), we got some kernel oops during late booting, hence
> I came up this solution.
>
> The solution might be a little half-baked because of the urgency to
> push the fix, but will try to dig more into the issue on Monday when I
> resume office.

Which Monday were you referring to?  ;)

...but in all seriousness do you have an official status update on
this patch?  It seems as if it's not needed and all you need is
<https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
get an official confirmation.

Thanks!

-Doug

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've tested this myself now as well.

Tested-by: Doug Anderson <dianders@chromium.org>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've tested this myself now as well.

Tested-by: Doug Anderson <dianders@chromium.org>

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Tushar,

On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
> As per the user manual, it should be CLK_MAU_EPLL.
>
> The problem surfaced when the bootloader in Peach-pit board set
> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
> we used to get a system hang during late boot if CLK_MAU_EPLL was
> disabled.
>
> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I've tested this myself now as well.

Tested-by: Doug Anderson <dianders@chromium.org>

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/25/2014 04:29 AM, Doug Anderson wrote:
> Tushar,
> 
> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Tushar Behera <tushar.b@samsung.com> writes:
>>>
>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>>
>>>> Though user manual doesn't specify this dependency, we came across
>>>> this issue while disabling the parent of AUDSS mux clocks.
>>>>
>>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>
>>> While this patch works (and fixes the boot problem for me), it seems
>>> like it's papering over the real problem.
>>>
>>
>> Thanks for testing.
>>
>>> Seems like the right fix is actually modelling the clocks properly so
>>> that enabling a child clock ensures that the parent is also enabled.
>>>
>>
>> Patch 2/3 was to ensure we have proper clock tree defined for
>> Exynos5420. While testing with audio disabled, that patch alone fixed
>> the issue. But when audio was enabled (and hence I2S0 was trying to
>> access the clocks), we got some kernel oops during late booting, hence
>> I came up this solution.
>>
>> The solution might be a little half-baked because of the urgency to
>> push the fix, but will try to dig more into the issue on Monday when I
>> resume office.
> 
> Which Monday were you referring to?  ;)
> 

Sorry that I couldn't get deeper into this issue. Thanks for reminding
though.

> ...but in all seriousness do you have an official status update on
> this patch?  It seems as if it's not needed and all you need is
> <https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
> get an official confirmation.

I have tested various scenarios with only patch 2/3, which seems to be
sufficient for the time being. I have not encountered the older issue
till now. I was thinking of testing a bit further, but given that you
have already asked for, we can go ahead with only patch 2/3 right now.

In case any further issue comes up, I will post patch 1/3 as per the
review comments that I have got.

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


-- 
Tushar Behera

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/25/2014 04:29 AM, Doug Anderson wrote:
> Tushar,
> 
> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Tushar Behera <tushar.b@samsung.com> writes:
>>>
>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>>
>>>> Though user manual doesn't specify this dependency, we came across
>>>> this issue while disabling the parent of AUDSS mux clocks.
>>>>
>>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>
>>> While this patch works (and fixes the boot problem for me), it seems
>>> like it's papering over the real problem.
>>>
>>
>> Thanks for testing.
>>
>>> Seems like the right fix is actually modelling the clocks properly so
>>> that enabling a child clock ensures that the parent is also enabled.
>>>
>>
>> Patch 2/3 was to ensure we have proper clock tree defined for
>> Exynos5420. While testing with audio disabled, that patch alone fixed
>> the issue. But when audio was enabled (and hence I2S0 was trying to
>> access the clocks), we got some kernel oops during late booting, hence
>> I came up this solution.
>>
>> The solution might be a little half-baked because of the urgency to
>> push the fix, but will try to dig more into the issue on Monday when I
>> resume office.
> 
> Which Monday were you referring to?  ;)
> 

Sorry that I couldn't get deeper into this issue. Thanks for reminding
though.

> ...but in all seriousness do you have an official status update on
> this patch?  It seems as if it's not needed and all you need is
> <https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
> get an official confirmation.

I have tested various scenarios with only patch 2/3, which seems to be
sufficient for the time being. I have not encountered the older issue
till now. I was thinking of testing a bit further, but given that you
have already asked for, we can go ahead with only patch 2/3 right now.

In case any further issue comes up, I will post patch 1/3 as per the
review comments that I have got.

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


-- 
Tushar Behera

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Tue, Jun 24, 2014 at 8:09 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/25/2014 04:29 AM, Doug Anderson wrote:
>> Tushar,
>>
>> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>>> Tushar Behera <tushar.b@samsung.com> writes:
>>>>
>>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>>>
>>>>> Though user manual doesn't specify this dependency, we came across
>>>>> this issue while disabling the parent of AUDSS mux clocks.
>>>>>
>>>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>>
>>>> While this patch works (and fixes the boot problem for me), it seems
>>>> like it's papering over the real problem.
>>>>
>>>
>>> Thanks for testing.
>>>
>>>> Seems like the right fix is actually modelling the clocks properly so
>>>> that enabling a child clock ensures that the parent is also enabled.
>>>>
>>>
>>> Patch 2/3 was to ensure we have proper clock tree defined for
>>> Exynos5420. While testing with audio disabled, that patch alone fixed
>>> the issue. But when audio was enabled (and hence I2S0 was trying to
>>> access the clocks), we got some kernel oops during late booting, hence
>>> I came up this solution.
>>>
>>> The solution might be a little half-baked because of the urgency to
>>> push the fix, but will try to dig more into the issue on Monday when I
>>> resume office.
>>
>> Which Monday were you referring to?  ;)
>>
>
> Sorry that I couldn't get deeper into this issue. Thanks for reminding
> though.

No problem.  I know how it is.  I was trying to be funny though
sometimes that doesn't come through very well over email.


>> ...but in all seriousness do you have an official status update on
>> this patch?  It seems as if it's not needed and all you need is
>> <https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
>> get an official confirmation.
>
> I have tested various scenarios with only patch 2/3, which seems to be
> sufficient for the time being. I have not encountered the older issue
> till now. I was thinking of testing a bit further, but given that you
> have already asked for, we can go ahead with only patch 2/3 right now.
>
> In case any further issue comes up, I will post patch 1/3 as per the
> review comments that I have got.

Sounds like a plan.  Thanks for getting the original patch sent out so
quickly after I reported it.

Hopefully Kukjin will apply pack 2/3 soon (today?)

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Doug Anderson]

Tushar,

On Tue, Jun 24, 2014 at 8:09 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 06/25/2014 04:29 AM, Doug Anderson wrote:
>> Tushar,
>>
>> On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>>> Tushar Behera <tushar.b@samsung.com> writes:
>>>>
>>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>>> oops while doing a clk_get() on other clocks provided by AUDSS.
>>>>>
>>>>> Though user manual doesn't specify this dependency, we came across
>>>>> this issue while disabling the parent of AUDSS mux clocks.
>>>>>
>>>>> Keeping the parents of AUDSS mux always enabled fixes this issue.
>>>>
>>>> While this patch works (and fixes the boot problem for me), it seems
>>>> like it's papering over the real problem.
>>>>
>>>
>>> Thanks for testing.
>>>
>>>> Seems like the right fix is actually modelling the clocks properly so
>>>> that enabling a child clock ensures that the parent is also enabled.
>>>>
>>>
>>> Patch 2/3 was to ensure we have proper clock tree defined for
>>> Exynos5420. While testing with audio disabled, that patch alone fixed
>>> the issue. But when audio was enabled (and hence I2S0 was trying to
>>> access the clocks), we got some kernel oops during late booting, hence
>>> I came up this solution.
>>>
>>> The solution might be a little half-baked because of the urgency to
>>> push the fix, but will try to dig more into the issue on Monday when I
>>> resume office.
>>
>> Which Monday were you referring to?  ;)
>>
>
> Sorry that I couldn't get deeper into this issue. Thanks for reminding
> though.

No problem.  I know how it is.  I was trying to be funny though
sometimes that doesn't come through very well over email.


>> ...but in all seriousness do you have an official status update on
>> this patch?  It seems as if it's not needed and all you need is
>> <https://patchwork.kernel.org/patch/4333581/>, but it would be nice to
>> get an official confirmation.
>
> I have tested various scenarios with only patch 2/3, which seems to be
> sufficient for the time being. I have not encountered the older issue
> till now. I was thinking of testing a bit further, but given that you
> have already asked for, we can go ahead with only patch 2/3 right now.
>
> In case any further issue comes up, I will post patch 1/3 as per the
> review comments that I have got.

Sounds like a plan.  Thanks for getting the original patch sent out so
quickly after I reported it.

Hopefully Kukjin will apply pack 2/3 soon (today?)

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Doug Anderson <dianders@google.com> writes:

> Tushar,
>
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I've tested this myself now as well.
>
> Tested-by: Doug Anderson <dianders@chromium.org>

For me, this patch alone (on top of -next) doesn't solve the boot hang.
I still need clk_ignore_unused for a successful boot.

So, this patch might be correct, but it doesn't prevent a boot hang
using a chain-loaded nv_uboot on peach-pi.  There's still another clock
being disabled that causes a hang.

Kevin

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Doug Anderson <dianders@google.com> writes:

> Tushar,
>
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I've tested this myself now as well.
>
> Tested-by: Doug Anderson <dianders@chromium.org>

For me, this patch alone (on top of -next) doesn't solve the boot hang.
I still need clk_ignore_unused for a successful boot.

So, this patch might be correct, but it doesn't prevent a boot hang
using a chain-loaded nv_uboot on peach-pi.  There's still another clock
being disabled that causes a hang.

Kevin

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Doug Anderson <dianders@google.com> writes:

> Tushar,
>
> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>> As per the user manual, it should be CLK_MAU_EPLL.
>>
>> The problem surfaced when the bootloader in Peach-pit board set
>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>> disabled.
>>
>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>> Reported-by: Kevin Hilman <khilman@linaro.org>
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I've tested this myself now as well.
>
> Tested-by: Doug Anderson <dianders@chromium.org>

For me, this patch alone (on top of -next) doesn't solve the boot hang.
I still need clk_ignore_unused for a successful boot.

So, this patch might be correct, but it doesn't prevent a boot hang
using a chain-loaded nv_uboot on peach-pi.  There's still another clock
being disabled that causes a hang.

Kevin

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
> Doug Anderson <dianders@google.com> writes:
>
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I've tested this myself now as well.
>>
>> Tested-by: Doug Anderson <dianders@chromium.org>
>
> For me, this patch alone (on top of -next) doesn't solve the boot hang.
> I still need clk_ignore_unused for a successful boot.
>
> So, this patch might be correct, but it doesn't prevent a boot hang
> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
> being disabled that causes a hang.
>
> Kevin

Kevin,

Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
issue for you?

Also can you please confirm that setting CLK_IGNORE_UNUSED flag
CLK_MAU_EPLL alone fixes the issue, without any need for
clk_ignore_unused in u-boot bootargs?

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
> Doug Anderson <dianders@google.com> writes:
>
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I've tested this myself now as well.
>>
>> Tested-by: Doug Anderson <dianders@chromium.org>
>
> For me, this patch alone (on top of -next) doesn't solve the boot hang.
> I still need clk_ignore_unused for a successful boot.
>
> So, this patch might be correct, but it doesn't prevent a boot hang
> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
> being disabled that causes a hang.
>
> Kevin

Kevin,

Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
issue for you?

Also can you please confirm that setting CLK_IGNORE_UNUSED flag
CLK_MAU_EPLL alone fixes the issue, without any need for
clk_ignore_unused in u-boot bootargs?

-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
> Doug Anderson <dianders@google.com> writes:
>
>> Tushar,
>>
>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>
>>> The problem surfaced when the bootloader in Peach-pit board set
>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>> disabled.
>>>
>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>> ---
>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I've tested this myself now as well.
>>
>> Tested-by: Doug Anderson <dianders@chromium.org>
>
> For me, this patch alone (on top of -next) doesn't solve the boot hang.
> I still need clk_ignore_unused for a successful boot.
>
> So, this patch might be correct, but it doesn't prevent a boot hang
> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
> being disabled that causes a hang.
>
> Kevin

Kevin,

Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
issue for you?

Also can you please confirm that setting CLK_IGNORE_UNUSED flag
CLK_MAU_EPLL alone fixes the issue, without any need for
clk_ignore_unused in u-boot bootargs?

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Tushar Behera <trblinux@gmail.com> writes:

> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> Doug Anderson <dianders@google.com> writes:
>>
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>
>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>> disabled.
>>>>
>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>> ---
>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> I've tested this myself now as well.
>>>
>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>
>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>> I still need clk_ignore_unused for a successful boot.
>>
>> So, this patch might be correct, but it doesn't prevent a boot hang
>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>> being disabled that causes a hang.
>>
>> Kevin
>
> Kevin,
>
> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
> issue for you?

Yes, using patch 1/3 along with 2/3 fixes the issue.

> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
> CLK_MAU_EPLL alone fixes the issue, without any need for
> clk_ignore_unused in u-boot bootargs?

Yes, I have this patch[1] in my local branch which fixes the issue
alone, without clk_ignore_unused on the command line.

Kevin


[1]
>From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Thu, 5 Jun 2014 17:12:28 -0700
Subject: [PATCH] KJH: leave mau_epll enabled

---
 drivers/clk/samsung/clk-exynos5420.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 61eccf0dd72f..ed175088ee7e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
 			SRC_MASK_TOP2, 24, 0, 0),
 
 	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
-			SRC_MASK_TOP7, 20, 0, 0),
+			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
 
 	/* sclk */
 	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
-- 
1.9.2

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Tushar Behera <trblinux@gmail.com> writes:

> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> Doug Anderson <dianders@google.com> writes:
>>
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>
>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>> disabled.
>>>>
>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>> ---
>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> I've tested this myself now as well.
>>>
>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>
>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>> I still need clk_ignore_unused for a successful boot.
>>
>> So, this patch might be correct, but it doesn't prevent a boot hang
>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>> being disabled that causes a hang.
>>
>> Kevin
>
> Kevin,
>
> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
> issue for you?

Yes, using patch 1/3 along with 2/3 fixes the issue.

> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
> CLK_MAU_EPLL alone fixes the issue, without any need for
> clk_ignore_unused in u-boot bootargs?

Yes, I have this patch[1] in my local branch which fixes the issue
alone, without clk_ignore_unused on the command line.

Kevin


[1]
>From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Thu, 5 Jun 2014 17:12:28 -0700
Subject: [PATCH] KJH: leave mau_epll enabled

---
 drivers/clk/samsung/clk-exynos5420.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 61eccf0dd72f..ed175088ee7e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
 			SRC_MASK_TOP2, 24, 0, 0),
 
 	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
-			SRC_MASK_TOP7, 20, 0, 0),
+			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
 
 	/* sclk */
 	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
-- 
1.9.2

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

Tushar Behera <trblinux@gmail.com> writes:

> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> Doug Anderson <dianders@google.com> writes:
>>
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>
>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>> disabled.
>>>>
>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>> ---
>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> I've tested this myself now as well.
>>>
>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>
>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>> I still need clk_ignore_unused for a successful boot.
>>
>> So, this patch might be correct, but it doesn't prevent a boot hang
>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>> being disabled that causes a hang.
>>
>> Kevin
>
> Kevin,
>
> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
> issue for you?

Yes, using patch 1/3 along with 2/3 fixes the issue.

> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
> CLK_MAU_EPLL alone fixes the issue, without any need for
> clk_ignore_unused in u-boot bootargs?

Yes, I have this patch[1] in my local branch which fixes the issue
alone, without clk_ignore_unused on the command line.

Kevin


[1]
>From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Thu, 5 Jun 2014 17:12:28 -0700
Subject: [PATCH] KJH: leave mau_epll enabled

---
 drivers/clk/samsung/clk-exynos5420.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
index 61eccf0dd72f..ed175088ee7e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
 			SRC_MASK_TOP2, 24, 0, 0),
 
 	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
-			SRC_MASK_TOP7, 20, 0, 0),
+			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
 
 	/* sclk */
 	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
-- 
1.9.2

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/26/2014 09:38 PM, Kevin Hilman wrote:
> Tushar Behera <trblinux@gmail.com> writes:
> 
>> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Doug Anderson <dianders@google.com> writes:
>>>
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>>
>>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>>> disabled.
>>>>>
>>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> I've tested this myself now as well.
>>>>
>>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>>
>>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>>> I still need clk_ignore_unused for a successful boot.
>>>
>>> So, this patch might be correct, but it doesn't prevent a boot hang
>>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>>> being disabled that causes a hang.
>>>
>>> Kevin
>>
>> Kevin,
>>
>> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
>> issue for you?
> 
> Yes, using patch 1/3 along with 2/3 fixes the issue.
> 

Okay, that adds some more reason to re-investigate patch 1/3.

Kevin,

Would you please provide me the environment setting of your u-boot?
U-boot environment on my board has been over-written, I would like to
set it same as yours and try to reproduce the issue at my end. With only
'sound init', I don't seem to hit this issue anymore.

>> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
>> CLK_MAU_EPLL alone fixes the issue, without any need for
>> clk_ignore_unused in u-boot bootargs?
> 
> Yes, I have this patch[1] in my local branch which fixes the issue
> alone, without clk_ignore_unused on the command line.
> 
> Kevin
> 
> 
> [1]
> From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@linaro.org>
> Date: Thu, 5 Jun 2014 17:12:28 -0700
> Subject: [PATCH] KJH: leave mau_epll enabled
> 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 61eccf0dd72f..ed175088ee7e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
>  			SRC_MASK_TOP2, 24, 0, 0),
>  
>  	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
> -			SRC_MASK_TOP7, 20, 0, 0),
> +			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>  
>  	/* sclk */
>  	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
> 


-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/26/2014 09:38 PM, Kevin Hilman wrote:
> Tushar Behera <trblinux@gmail.com> writes:
> 
>> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Doug Anderson <dianders@google.com> writes:
>>>
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>>
>>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>>> disabled.
>>>>>
>>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> I've tested this myself now as well.
>>>>
>>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>>
>>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>>> I still need clk_ignore_unused for a successful boot.
>>>
>>> So, this patch might be correct, but it doesn't prevent a boot hang
>>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>>> being disabled that causes a hang.
>>>
>>> Kevin
>>
>> Kevin,
>>
>> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
>> issue for you?
> 
> Yes, using patch 1/3 along with 2/3 fixes the issue.
> 

Okay, that adds some more reason to re-investigate patch 1/3.

Kevin,

Would you please provide me the environment setting of your u-boot?
U-boot environment on my board has been over-written, I would like to
set it same as yours and try to reproduce the issue at my end. With only
'sound init', I don't seem to hit this issue anymore.

>> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
>> CLK_MAU_EPLL alone fixes the issue, without any need for
>> clk_ignore_unused in u-boot bootargs?
> 
> Yes, I have this patch[1] in my local branch which fixes the issue
> alone, without clk_ignore_unused on the command line.
> 
> Kevin
> 
> 
> [1]
> From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@linaro.org>
> Date: Thu, 5 Jun 2014 17:12:28 -0700
> Subject: [PATCH] KJH: leave mau_epll enabled
> 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 61eccf0dd72f..ed175088ee7e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
>  			SRC_MASK_TOP2, 24, 0, 0),
>  
>  	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
> -			SRC_MASK_TOP7, 20, 0, 0),
> +			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>  
>  	/* sclk */
>  	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
> 


-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/26/2014 09:38 PM, Kevin Hilman wrote:
> Tushar Behera <trblinux@gmail.com> writes:
> 
>> On Thu, Jun 26, 2014 at 4:51 AM, Kevin Hilman <khilman@linaro.org> wrote:
>>> Doug Anderson <dianders@google.com> writes:
>>>
>>>> Tushar,
>>>>
>>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera <tushar.b@samsung.com> wrote:
>>>>> Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux.
>>>>> As per the user manual, it should be CLK_MAU_EPLL.
>>>>>
>>>>> The problem surfaced when the bootloader in Peach-pit board set
>>>>> the EPLL clock as the parent of AUDSS mux. While booting the kernel,
>>>>> we used to get a system hang during late boot if CLK_MAU_EPLL was
>>>>> disabled.
>>>>>
>>>>> Signed-off-by: Tushar Behera <tushar.b@samsung.com>
>>>>> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
>>>>> Reported-by: Kevin Hilman <khilman@linaro.org>
>>>>> ---
>>>>>  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> I've tested this myself now as well.
>>>>
>>>> Tested-by: Doug Anderson <dianders@chromium.org>
>>>
>>> For me, this patch alone (on top of -next) doesn't solve the boot hang.
>>> I still need clk_ignore_unused for a successful boot.
>>>
>>> So, this patch might be correct, but it doesn't prevent a boot hang
>>> using a chain-loaded nv_uboot on peach-pi.  There's still another clock
>>> being disabled that causes a hang.
>>>
>>> Kevin
>>
>> Kevin,
>>
>> Can you please check if adding patch 1/3 alongwith patch 2/3 fixes the
>> issue for you?
> 
> Yes, using patch 1/3 along with 2/3 fixes the issue.
> 

Okay, that adds some more reason to re-investigate patch 1/3.

Kevin,

Would you please provide me the environment setting of your u-boot?
U-boot environment on my board has been over-written, I would like to
set it same as yours and try to reproduce the issue at my end. With only
'sound init', I don't seem to hit this issue anymore.

>> Also can you please confirm that setting CLK_IGNORE_UNUSED flag
>> CLK_MAU_EPLL alone fixes the issue, without any need for
>> clk_ignore_unused in u-boot bootargs?
> 
> Yes, I have this patch[1] in my local branch which fixes the issue
> alone, without clk_ignore_unused on the command line.
> 
> Kevin
> 
> 
> [1]
> From ab1627127730ef4507ce96cbf95047d626bbb53f Mon Sep 17 00:00:00 2001
> From: Kevin Hilman <khilman@linaro.org>
> Date: Thu, 5 Jun 2014 17:12:28 -0700
> Subject: [PATCH] KJH: leave mau_epll enabled
> 
> ---
>  drivers/clk/samsung/clk-exynos5420.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos5420.c b/drivers/clk/samsung/clk-exynos5420.c
> index 61eccf0dd72f..ed175088ee7e 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -911,7 +911,7 @@ static struct samsung_gate_clock exynos5x_gate_clks[] __initdata = {
>  			SRC_MASK_TOP2, 24, 0, 0),
>  
>  	GATE(CLK_MAU_EPLL, "mau_epll", "mout_mau_epll_clk",
> -			SRC_MASK_TOP7, 20, 0, 0),
> +			SRC_MASK_TOP7, 20, CLK_IGNORE_UNUSED, 0),
>  
>  	/* sclk */
>  	GATE(CLK_SCLK_UART0, "sclk_uart0", "dout_uart0",
> 


-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:

> Would you please provide me the environment setting of your u-boot?
> U-boot environment on my board has been over-written, I would like to
> set it same as yours and try to reproduce the issue at my end. With only
> 'sound init', I don't seem to hit this issue anymore.

Attached is a full boot log using v3.16-rc2 with my patch adding
CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
boot log, you'll see the output of 'printenv' inside u-boot where the
environment is dumped.

Hope that helps,

Kevin

[-- Attachment #2: boot-octa.log.gz --]
[-- Type: application/x-gzip, Size: 7519 bytes --]

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:

> Would you please provide me the environment setting of your u-boot?
> U-boot environment on my board has been over-written, I would like to
> set it same as yours and try to reproduce the issue at my end. With only
> 'sound init', I don't seem to hit this issue anymore.

Attached is a full boot log using v3.16-rc2 with my patch adding
CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
boot log, you'll see the output of 'printenv' inside u-boot where the
environment is dumped.

Hope that helps,

Kevin

[-- Attachment #2: boot-octa.log.gz --]
[-- Type: application/x-gzip, Size: 7519 bytes --]

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:

> Would you please provide me the environment setting of your u-boot?
> U-boot environment on my board has been over-written, I would like to
> set it same as yours and try to reproduce the issue at my end. With only
> 'sound init', I don't seem to hit this issue anymore.

Attached is a full boot log using v3.16-rc2 with my patch adding
CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
boot log, you'll see the output of 'printenv' inside u-boot where the
environment is dumped.

Hope that helps,

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot-octa.log.gz
Type: application/x-gzip
Size: 7519 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140627/e2a51df0/attachment.bin>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>
>> Would you please provide me the environment setting of your u-boot?
>> U-boot environment on my board has been over-written, I would like to
>> set it same as yours and try to reproduce the issue at my end. With only
>> 'sound init', I don't seem to hit this issue anymore.
>
> Attached is a full boot log using v3.16-rc2 with my patch adding
> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
> boot log, you'll see the output of 'printenv' inside u-boot where the
> environment is dumped.

Oops, I sent you a boot log for the octa board.  Here's the one for
peach-pi with the same kernel (built with upstream exynos_defconfig)

Kevin

[-- Attachment #2: boot-chromebook2.log.gz --]
[-- Type: application/x-gzip, Size: 8850 bytes --]

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>
>> Would you please provide me the environment setting of your u-boot?
>> U-boot environment on my board has been over-written, I would like to
>> set it same as yours and try to reproduce the issue at my end. With only
>> 'sound init', I don't seem to hit this issue anymore.
>
> Attached is a full boot log using v3.16-rc2 with my patch adding
> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
> boot log, you'll see the output of 'printenv' inside u-boot where the
> environment is dumped.

Oops, I sent you a boot log for the octa board.  Here's the one for
peach-pi with the same kernel (built with upstream exynos_defconfig)

Kevin

[-- Attachment #2: boot-chromebook2.log.gz --]
[-- Type: application/x-gzip, Size: 8850 bytes --]

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kevin Hilman]

On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>
>> Would you please provide me the environment setting of your u-boot?
>> U-boot environment on my board has been over-written, I would like to
>> set it same as yours and try to reproduce the issue at my end. With only
>> 'sound init', I don't seem to hit this issue anymore.
>
> Attached is a full boot log using v3.16-rc2 with my patch adding
> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
> boot log, you'll see the output of 'printenv' inside u-boot where the
> environment is dumped.

Oops, I sent you a boot log for the octa board.  Here's the one for
peach-pi with the same kernel (built with upstream exynos_defconfig)

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot-chromebook2.log.gz
Type: application/x-gzip
Size: 8850 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140627/a95b6b32/attachment.bin>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/27/2014 08:18 PM, Kevin Hilman wrote:
> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>
>>> Would you please provide me the environment setting of your u-boot?
>>> U-boot environment on my board has been over-written, I would like to
>>> set it same as yours and try to reproduce the issue at my end. With only
>>> 'sound init', I don't seem to hit this issue anymore.
>>
>> Attached is a full boot log using v3.16-rc2 with my patch adding
>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>> boot log, you'll see the output of 'printenv' inside u-boot where the
>> environment is dumped.
> 
> Oops, I sent you a boot log for the octa board.  Here's the one for
> peach-pi with the same kernel (built with upstream exynos_defconfig)
> 
> Kevin
> 

The u-boot version is a little different on my Peach-Pi as compared to
the market release version. Not sure if that is making any difference.

Peach # version

U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
4.8.x-google 20130905 (prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/27/2014 08:18 PM, Kevin Hilman wrote:
> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>
>>> Would you please provide me the environment setting of your u-boot?
>>> U-boot environment on my board has been over-written, I would like to
>>> set it same as yours and try to reproduce the issue at my end. With only
>>> 'sound init', I don't seem to hit this issue anymore.
>>
>> Attached is a full boot log using v3.16-rc2 with my patch adding
>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>> boot log, you'll see the output of 'printenv' inside u-boot where the
>> environment is dumped.
> 
> Oops, I sent you a boot log for the octa board.  Here's the one for
> peach-pi with the same kernel (built with upstream exynos_defconfig)
> 
> Kevin
> 

The u-boot version is a little different on my Peach-Pi as compared to
the market release version. Not sure if that is making any difference.

Peach # version

U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
4.8.x-google 20130905 (prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22

-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 06/27/2014 08:18 PM, Kevin Hilman wrote:
> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman <khilman@linaro.org> wrote:
>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>
>>> Would you please provide me the environment setting of your u-boot?
>>> U-boot environment on my board has been over-written, I would like to
>>> set it same as yours and try to reproduce the issue at my end. With only
>>> 'sound init', I don't seem to hit this issue anymore.
>>
>> Attached is a full boot log using v3.16-rc2 with my patch adding
>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>> boot log, you'll see the output of 'printenv' inside u-boot where the
>> environment is dumped.
> 
> Oops, I sent you a boot log for the octa board.  Here's the one for
> peach-pi with the same kernel (built with upstream exynos_defconfig)
> 
> Kevin
> 

The u-boot version is a little different on my Peach-Pi as compared to
the market release version. Not sure if that is making any difference.

Peach # version

U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
4.8.x-google 20130905 (prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kukjin Kim]

On 07/01/14 20:59, Tushar Behera wrote:
> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org>  wrote:
>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com>  wrote:
>>>
>>>> Would you please provide me the environment setting of your u-boot?
>>>> U-boot environment on my board has been over-written, I would like to
>>>> set it same as yours and try to reproduce the issue at my end. With only
>>>> 'sound init', I don't seem to hit this issue anymore.
>>>
>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>> environment is dumped.
>>
>> Oops, I sent you a boot log for the octa board.  Here's the one for
>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>
>> Kevin
>>
>
> The u-boot version is a little different on my Peach-Pi as compared to
> the market release version. Not sure if that is making any difference.
>
> Peach # version
>
> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
> 4.8.x-google 20130905 (prerelease)
> GNU ld (binutils-2.22_cos_gg_2) 2.22
>

Note that I've applied this only from this series so I'm not sure how 
much the problem can be solved...any updates for 1/3 and 3/3?

- Kukjin

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kukjin Kim]

On 07/01/14 20:59, Tushar Behera wrote:
> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org>  wrote:
>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com>  wrote:
>>>
>>>> Would you please provide me the environment setting of your u-boot?
>>>> U-boot environment on my board has been over-written, I would like to
>>>> set it same as yours and try to reproduce the issue at my end. With only
>>>> 'sound init', I don't seem to hit this issue anymore.
>>>
>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>> environment is dumped.
>>
>> Oops, I sent you a boot log for the octa board.  Here's the one for
>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>
>> Kevin
>>
>
> The u-boot version is a little different on my Peach-Pi as compared to
> the market release version. Not sure if that is making any difference.
>
> Peach # version
>
> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
> 4.8.x-google 20130905 (prerelease)
> GNU ld (binutils-2.22_cos_gg_2) 2.22
>

Note that I've applied this only from this series so I'm not sure how 
much the problem can be solved...any updates for 1/3 and 3/3?

- Kukjin

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kukjin Kim]

On 07/01/14 20:59, Tushar Behera wrote:
> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org>  wrote:
>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com>  wrote:
>>>
>>>> Would you please provide me the environment setting of your u-boot?
>>>> U-boot environment on my board has been over-written, I would like to
>>>> set it same as yours and try to reproduce the issue at my end. With only
>>>> 'sound init', I don't seem to hit this issue anymore.
>>>
>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>> environment is dumped.
>>
>> Oops, I sent you a boot log for the octa board.  Here's the one for
>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>
>> Kevin
>>
>
> The u-boot version is a little different on my Peach-Pi as compared to
> the market release version. Not sure if that is making any difference.
>
> Peach # version
>
> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
> 4.8.x-google 20130905 (prerelease)
> GNU ld (binutils-2.22_cos_gg_2) 2.22
>

Note that I've applied this only from this series so I'm not sure how 
much the problem can be solved...any updates for 1/3 and 3/3?

- Kukjin

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/08/2014 05:04 AM, Kukjin Kim wrote:
> On 07/01/14 20:59, Tushar Behera wrote:
>> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org> 
>>> wrote:
>>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com> 
>>>> wrote:
>>>>
>>>>> Would you please provide me the environment setting of your u-boot?
>>>>> U-boot environment on my board has been over-written, I would like to
>>>>> set it same as yours and try to reproduce the issue at my end. With
>>>>> only
>>>>> 'sound init', I don't seem to hit this issue anymore.
>>>>
>>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>>> environment is dumped.
>>>
>>> Oops, I sent you a boot log for the octa board.  Here's the one for
>>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>>
>>> Kevin
>>>
>>
>> The u-boot version is a little different on my Peach-Pi as compared to
>> the market release version. Not sure if that is making any difference.
>>
>> Peach # version
>>
>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>> 4.8.x-google 20130905 (prerelease)
>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>
> 
> Note that I've applied this only from this series so I'm not sure how
> much the problem can be solved...any updates for 1/3 and 3/3?
> 
> - Kukjin

Thanks for applying 2/3. I am working on 1/3 to see if we are following
the right approach to fix Kevin's issue (unfortunately, I am not hitting
the bug on my board ATM). 3/3 has already been merged through a
different patchset.

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/08/2014 05:04 AM, Kukjin Kim wrote:
> On 07/01/14 20:59, Tushar Behera wrote:
>> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org> 
>>> wrote:
>>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com> 
>>>> wrote:
>>>>
>>>>> Would you please provide me the environment setting of your u-boot?
>>>>> U-boot environment on my board has been over-written, I would like to
>>>>> set it same as yours and try to reproduce the issue at my end. With
>>>>> only
>>>>> 'sound init', I don't seem to hit this issue anymore.
>>>>
>>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>>> environment is dumped.
>>>
>>> Oops, I sent you a boot log for the octa board.  Here's the one for
>>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>>
>>> Kevin
>>>
>>
>> The u-boot version is a little different on my Peach-Pi as compared to
>> the market release version. Not sure if that is making any difference.
>>
>> Peach # version
>>
>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>> 4.8.x-google 20130905 (prerelease)
>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>
> 
> Note that I've applied this only from this series so I'm not sure how
> much the problem can be solved...any updates for 1/3 and 3/3?
> 
> - Kukjin

Thanks for applying 2/3. I am working on 1/3 to see if we are following
the right approach to fix Kevin's issue (unfortunately, I am not hitting
the bug on my board ATM). 3/3 has already been merged through a
different patchset.

-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/08/2014 05:04 AM, Kukjin Kim wrote:
> On 07/01/14 20:59, Tushar Behera wrote:
>> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman<khilman@linaro.org> 
>>> wrote:
>>>> On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera<trblinux@gmail.com> 
>>>> wrote:
>>>>
>>>>> Would you please provide me the environment setting of your u-boot?
>>>>> U-boot environment on my board has been over-written, I would like to
>>>>> set it same as yours and try to reproduce the issue at my end. With
>>>>> only
>>>>> 'sound init', I don't seem to hit this issue anymore.
>>>>
>>>> Attached is a full boot log using v3.16-rc2 with my patch adding
>>>> CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
>>>> boot log, you'll see the output of 'printenv' inside u-boot where the
>>>> environment is dumped.
>>>
>>> Oops, I sent you a boot log for the octa board.  Here's the one for
>>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>>
>>> Kevin
>>>
>>
>> The u-boot version is a little different on my Peach-Pi as compared to
>> the market release version. Not sure if that is making any difference.
>>
>> Peach # version
>>
>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>> 4.8.x-google 20130905 (prerelease)
>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>
> 
> Note that I've applied this only from this series so I'm not sure how
> much the problem can be solved...any updates for 1/3 and 3/3?
> 
> - Kukjin

Thanks for applying 2/3. I am working on 1/3 to see if we are following
the right approach to fix Kevin's issue (unfortunately, I am not hitting
the bug on my board ATM). 3/3 has already been merged through a
different patchset.

-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hello Tushar,

On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>
>>> The u-boot version is a little different on my Peach-Pi as compared to
>>> the market release version. Not sure if that is making any difference.
>>>
>>> Peach # version
>>>
>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>> 4.8.x-google 20130905 (prerelease)
>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>
>>

I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
and on my setup using chained nv-uboot I also need patch 1/3 along
with 2/3 to fix the issue.

>> Note that I've applied this only from this series so I'm not sure how
>> much the problem can be solved...any updates for 1/3 and 3/3?
>>
>> - Kukjin
>
> Thanks for applying 2/3. I am working on 1/3 to see if we are following
> the right approach to fix Kevin's issue (unfortunately, I am not hitting
> the bug on my board ATM). 3/3 has already been merged through a
> different patchset.
>

I'm sending as an attachment my complete boot log when booting today's
next (20140709) until it hangs and my u-boot env vars. I hope that
helps.

> --
> Tushar Behera
> --

Best regards,
Javier

[-- Attachment #2: boot_log --]
[-- Type: application/octet-stream, Size: 16442 bytes --]

U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach

CPU:    Exynos5420@1800MHz

Board: Google Peach Pit, rev 9.0
I2C:   ready
DRAM:  2 GiB
PMIC max77802-pmic initialized
CPU:    Exynos5420@1800MHz
TPS65090 PMIC EC init
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:    cros-ec-keyb
Out:   lcd
Err:   lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net:   No ethernet found.
Hit any key to stop autoboot:  0
reading uImage
2922012 bytes read in 143 ms (19.5 MiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux
   Created:      2014-07-09   9:55:47 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2921948 Bytes = 2.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

Timer summary in microseconds:
       Mark    Elapsed  Stage
          0          0  reset
  3,453,084  3,453,084  board_init_f
  3,549,299     96,215  board_init_r
  3,693,404    144,105  id=64
  3,696,125      2,721  main_loop
  4,018,144    322,019  bootm_start
  4,018,146          2  id=1
  4,023,850      5,704  id=2
  4,023,852          2  id=3
  4,075,433     51,581  id=4
  4,075,434          1  id=5
  4,075,436          2  id=6
  4,075,437          1  id=14
  4,164,987     89,550  id=7
  4,164,996          9  id=15
  4,169,050      4,054  start_kernel

Accumulated time:
                 6,939  SPI read
cleanup_before_linux_select: Console recording failed (1)


U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach

CPU:    Exynos5420@1800MHz

Board: Google Peach Pit, rev 9.0
I2C:   ready
DRAM:  2 GiB
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.16.0-rc4-next-20140709ccu (javier@minerva) (gcc version 4.6.3 (Debian 4.6.3-14) ) #360 SMP PREEMPT Wed Jul 9 11:50:52 CEST 2014
[    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Ignoring memory range 0x20000000 - 0x40000000
[    0.000000] Machine model: Google Peach Pit Rev 6+
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 393216
[    0.000000] free_area_init_node: node 0, pgdat c05744c0, node_mem_map eebf4000
[    0.000000]   Normal zone: 1520 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 194560 pages, LIFO batch:31
[    0.000000]   HighMem zone: 1552 pages used for memmap
[    0.000000]   HighMem zone: 198656 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 7 pages/cpu @eeb8d000 s7104 r8192 d13376 u32768
[    0.000000] pcpu-alloc: s7104 r8192 d13376 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 391696
[    0.000000] Kernel command line: console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1553488K/1572864K available (3857K kernel code, 244K rwdata, 1196K rodata, 254K init, 273K bss, 19376K reserved, 794624K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc04f78f0   (5055 kB)
[    0.000000]       .init : 0xc04f8000 - 0xc0537bc0   ( 255 kB)
[    0.000000]       .data : 0xc0538000 - 0xc0575060   ( 245 kB)
[    0.000000]        .bss : 0xc057506c - 0xc05b9480   ( 274 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C: failed to init: -19
[    0.000000] Switching to timer-based delay loop, resolution 41ns
[    0.000003] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[    0.000157] Console: colour dummy device 80x30
[    0.000173] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[    0.000183] pid_max: default: 32768 minimum: 301
[    0.000284] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000291] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000677] CPU: Testing write buffer coherency: ok
[    0.000875] CPU0: update cpu_capacity 1535
[    0.000883] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.000973] Setting up static identity map for 0x403a92a0 - 0x403a92f8
[    1.030018] CPU1: failed to boot: -38
[    2.040035] CPU2: failed to boot: -38
[    3.050051] CPU3: failed to boot: -38
[    4.060068] CPU4: failed to boot: -38
[    5.070085] CPU5: failed to boot: -38
[    6.080103] CPU6: failed to boot: -38
[    7.090119] CPU7: failed to boot: -38
[    7.090136] Brought up 1 CPUs
[    7.090142] SMP: Total of 1 processors activated.
[    7.090148] CPU: All CPU(s) started in SVC mode.
[    7.090469] devtmpfs: initialized
[    7.095819] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    7.096216] pinctrl core: initialized pinctrl subsystem
[    7.096388] regulator-dummy: no parameters
[    7.106177] NET: Registered protocol family 16
[    7.106313] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    7.108847] gpiochip_add: registered GPIOs 0 to 7 on device: gpy7
[    7.108856] gpiochip_add: registered GPIOs 8 to 15 on device: gpx0
[    7.108864] gpiochip_add: registered GPIOs 16 to 23 on device: gpx1
[    7.108872] gpiochip_add: registered GPIOs 24 to 31 on device: gpx2
[    7.108879] gpiochip_add: registered GPIOs 32 to 39 on device: gpx3
[    7.109495] gpiochip_add: registered GPIOs 40 to 47 on device: gpc0
[    7.109504] gpiochip_add: registered GPIOs 48 to 55 on device: gpc1
[    7.109511] gpiochip_add: registered GPIOs 56 to 62 on device: gpc2
[    7.109518] gpiochip_add: registered GPIOs 63 to 66 on device: gpc3
[    7.109525] gpiochip_add: registered GPIOs 67 to 68 on device: gpc4
[    7.109532] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1
[    7.109539] gpiochip_add: registered GPIOs 77 to 82 on device: gpy0
[    7.109546] gpiochip_add: registered GPIOs 83 to 86 on device: gpy1
[    7.109553] gpiochip_add: registered GPIOs 87 to 92 on device: gpy2
[    7.109560] gpiochip_add: registered GPIOs 93 to 100 on device: gpy3
[    7.109567] gpiochip_add: registered GPIOs 101 to 108 on device: gpy4
[    7.109574] gpiochip_add: registered GPIOs 109 to 116 on device: gpy5
[    7.109581] gpiochip_add: registered GPIOs 117 to 124 on device: gpy6
[    7.109971] gpiochip_add: registered GPIOs 125 to 132 on device: gpe0
[    7.109979] gpiochip_add: registered GPIOs 133 to 134 on device: gpe1
[    7.109986] gpiochip_add: registered GPIOs 135 to 140 on device: gpf0
[    7.109994] gpiochip_add: registered GPIOs 141 to 148 on device: gpf1
[    7.110000] gpiochip_add: registered GPIOs 149 to 156 on device: gpg0
[    7.110007] gpiochip_add: registered GPIOs 157 to 164 on device: gpg1
[    7.110014] gpiochip_add: registered GPIOs 165 to 166 on device: gpg2
[    7.110021] gpiochip_add: registered GPIOs 167 to 170 on device: gpj4
[    7.110384] gpiochip_add: registered GPIOs 171 to 178 on device: gpa0
[    7.110392] gpiochip_add: registered GPIOs 179 to 184 on device: gpa1
[    7.110399] gpiochip_add: registered GPIOs 185 to 192 on device: gpa2
[    7.110406] gpiochip_add: registered GPIOs 193 to 197 on device: gpb0
[    7.110413] gpiochip_add: registered GPIOs 198 to 202 on device: gpb1
[    7.110421] gpiochip_add: registered GPIOs 203 to 206 on device: gpb2
[    7.110428] gpiochip_add: registered GPIOs 207 to 214 on device: gpb3
[    7.110435] gpiochip_add: registered GPIOs 215 to 216 on device: gpb4
[    7.110442] gpiochip_add: registered GPIOs 217 to 224 on device: gph0
[    7.110964] gpiochip_add: registered GPIOs 225 to 231 on device: gpz
[    7.111834] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[    7.117332] EXYNOS: PMU not supported
[    7.131601] of_get_named_gpiod_flags exited with status 0
[    7.131701] P5.0V_USB3CON0: 5000 mV
[    7.131790] of_get_named_gpiod_flags exited with status 0
[    7.131891] P5.0V_USB3CON1: 5000 mV
[    7.132749] SCSI subsystem initialized
[    7.132972] usbcore: registered new interface driver usbfs
[    7.133030] usbcore: registered new interface driver hub
[    7.133185] usbcore: registered new device driver usb
[    7.133451] s3c-i2c 12c80000.i2c: slave address 0x50
[    7.133462] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[    7.133578] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[    7.134377] Switched to clocksource mct-frc
[    7.142076] NET: Registered protocol family 2
[    7.142404] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    7.142456] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[    7.142547] TCP: Hash tables configured (established 8192 bind 8192)
[    7.142584] TCP: reno registered
[    7.142595] UDP hash table entries: 512 (order: 2, 24576 bytes)
[    7.142617] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[    7.142761] NET: Registered protocol family 1
[    7.144092] futex hash table entries: 2048 (order: 5, 131072 bytes)
[    7.154291] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[    7.154563] msgmni has been set to 1482
[    7.155284] bounce: pool size: 64 pages
[    7.155294] io scheduler noop registered
[    7.155303] io scheduler deadline registered
[    7.155634] io scheduler cfq registered (default)
[    7.200083] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    7.201178] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 83, base_baud = 0) is a S3C6400/10
[    7.201522] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 84, base_baud = 0) is a S3C6400/10
[    7.201791] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 85, base_baud = 0) is a S3C6400/10
[    7.202063] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 86, base_baud = 0) is a S3C6400/10
[    7.985873] console [ttySAC3] enabled
[    7.996120] brd: module loaded
[    8.000814] loop: module loaded
[    8.002944] usbcore: registered new interface driver cdc_ether
[    8.008661] usbcore: registered new interface driver smsc75xx
[    8.014319] usbcore: registered new interface driver smsc95xx
[    8.020093] usbcore: registered new interface driver net1080
[    8.025671] usbcore: registered new interface driver cdc_subset
[    8.031628] usbcore: registered new interface driver zaurus
[    8.037149] usbcore: registered new interface driver cdc_ncm
[    8.043210] usb@12000000 supply vdd33 not found, using dummy regulator
[    8.049289] usb@12000000 supply vdd10 not found, using dummy regulator
[    8.256625] usb@12400000 supply vdd33 not found, using dummy regulator
[    8.261988] usb@12400000 supply vdd10 not found, using dummy regulator
[    8.469286] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    8.474586] ehci-exynos: EHCI EXYNOS driver
[    8.478620] of_get_named_gpiod_flags: can't parse gpios property of node '/usb@12110000[0]'
[    8.487511] exynos-ehci 12110000.usb: EHCI Host Controller
[    8.492585] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 1
[    8.500365] exynos-ehci 12110000.usb: irq 103, io mem 0x12110000
[    8.514407] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[    8.519799] hub 1-0:1.0: USB hub found
[    8.522741] hub 1-0:1.0: 3 ports detected
[    8.527175] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.532892] ohci-exynos: OHCI EXYNOS driver
[    8.537172] exynos-ohci 12120000.usb: USB Host Controller
[    8.542402] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 2
[    8.550039] exynos-ohci 12120000.usb: irq 103, io mem 0x12120000
[    8.614032] hub 2-0:1.0: USB hub found
[    8.616410] hub 2-0:1.0: 3 ports detected
[    8.620870] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    8.625925] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[    8.633558] xhci-hcd xhci-hcd.2.auto: irq 104, io mem 0x12000000
[    8.639997] hub 3-0:1.0: USB hub found
[    8.643182] hub 3-0:1.0: 1 port detected
[    8.647307] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    8.652513] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[    8.660783] hub 4-0:1.0: USB hub found
[    8.663914] hub 4-0:1.0: 1 port detected
[    8.668083] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[    8.673251] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 5
[    8.681010] xhci-hcd xhci-hcd.5.auto: irq 105, io mem 0x12400000
[    8.687452] hub 5-0:1.0: USB hub found
[    8.690667] hub 5-0:1.0: 1 port detected
[    8.694741] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[    8.699964] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 6
[    8.708223] hub 6-0:1.0: USB hub found
[    8.711405] hub 6-0:1.0: 1 port detected
[    8.715650] usbcore: registered new interface driver usb-storage
[    8.721932] mousedev: PS/2 mouse device common for all mice
[    8.727375] s3c-rtc 101e0000.rtc: rtc disabled, re-enabling
[    8.732713] s3c-rtc 101e0000.rtc: rtc core: registered s3c as rtc0
[    8.738695] s3c-rtc 101e0000.rtc: warning: invalid RTC value so initializing it
[    8.747966] tpm_i2c_infineon 9-0020: 1.2 TPM (device-id 0x1A)
[    8.850417] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[    8.857686] sdhci: Secure Digital Host Controller Interface driver
[    8.863657] sdhci: Copyright(c) Pierre Ossman
[    8.868062] Synopsys Designware Multimedia Card Interface Driver
[    8.874365] dwmmc_exynos 12200000.mmc: no vmmc regulator found: -19
[    8.880181] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[    8.886555] dwmmc_exynos 12200000.mmc: Version ID is 250a
[    8.892062] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 107, 64 bit host data width, 64 deep fifo
[    8.901541] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12200000[0]'
[    8.939393] dwmmc_exynos 12200000.mmc: 1 slots initialized
[    8.943577] dwmmc_exynos 12220000.mmc: no vmmc regulator found: -19
[    8.949691] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[    8.957123] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[    8.964611] dwmmc_exynos 12220000.mmc: Version ID is 250a
[    8.968697] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 109, 64 bit host data width, 64 deep fifo
[    8.978165] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12220000[0]'
[    8.986435] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12220000[0]'
[    9.024394] dwmmc_exynos 12220000.mmc: 1 slots initialized
[    9.028422] mmc0: BKOPS_EN bit is not set
[    9.033244] usbcore: registered new interface driver usbhid
[    9.038139] usbhid: USB HID core driver
[    9.042109] TCP: cubic registered
[    9.045225] NET: Registered protocol family 17
[    9.049744] NET: Registered protocol family 15
[    9.054079] Registering SWP/SWPB emulation handler
[    9.058707] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[    9.069179] of_get_named_gpiod_flags exited with status 0
[    9.074135] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[    9.083665] gpio-18: gpiod_set_debounce: missing set() or set_debounce() operations
[    9.091662] mmc0: new DDR MMC card at address 0001
[    9.096007] input: gpio-keys as /devices/gpio-keys/input/input0
[    9.102183] mmcblk0: mmc0:0001 MAG2GC 14.5 GiB
[    9.106746] s3c-rtc 101e0000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    9.115114] mmcblk0boot0: mmc0:0001 MAG2GC partition 1 4.00 MiB


[-- Attachment #3: uboot_env --]
[-- Type: application/octet-stream, Size: 3614 bytes --]

Peach # printenv
baudrate=115200
bootargs=console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
bootcmd=fatload mmc 1:1 0x42000000 uImage; bootm 0x42000000
bootdelay=0
bootdev_bootargs=root=PARTUUID=747e4fa4-9273-4747-adf8-fbdbdeaa9561 rootwait ro
common_bootargs=cros_legacy console=ttySAC3,115200 debug earlyprintk
cros_bootfile=/boot/vmlinux.uimg
devname=PARTUUID=747e4fa4-9273-4747-adf8-fbdbdeaa9561
devnum=0
devtype=mmc
ethact=asx0
ext2_boot=run regen_ext2_bootargs; if ext2load ${devtype} ${devnum}:${rootpart} ${loadaddr} ${cros_bootfile}; then if test ${kernaddr} != ""; then echo "Using bundled kernel"; bootm ${kernaddr};fi; bootm ${loadaddr};fi
filesize=8e
has_initrd=0
initramfs_boot=run tftp_setup; run regen_initramfs_install_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
initrd_high=0xffffffff
initrdroot_boot=run tftp_setup; run regen_initrdroot_bootargs; bootp; if tftpboot ${rootaddr} ${tftpserverip}:${tftprootpath} &&    tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr} ${rootaddr}; else echo 'ERROR: Could not load root/kernel from TFTP'; exit; fi
mmc0_boot=setenv devnum 0; run mmc_boot
mmc0_tftpboot=setenv devnum 0; run mmc_setup; run tftp_ext2_boot
mmc1_boot=setenv devnum 1; run mmc_boot
mmc_boot=run mmc_setup; run run_disk_boot_script;run set_devname; run ext2_boot
mmc_setup=mmc dev ${devnum}; mmc rescan; setenv devtype mmc
net_boot=if test ${ethact} != ""; then if test ${tftpserverip} != "0.0.0.0"; then if test ${nfsserverip} != "0.0.0.0"; then run nfsroot_boot; fi; if test ${has_initrd} != "0"; then run initrdroot_boot; else run initramfs_boot; fi; fi; fi
nfsroot_boot=run tftp_setup; run regen_nfsroot_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
nfsserverip=0.0.0.0
non_verified_boot=usb start; run net_boot; run usb_boot; run mmc1_boot; run mmc0_boot
regen_all=setenv bootargs ${common_bootargs} ${dev_extras} ${extra_bootargs} ${bootdev_bootargs}
regen_ext2_bootargs=setenv bootdev_bootargs root=${devname} rootwait ro; run regen_all
regen_initramfs_install_bootargs=setenv bootdev_bootargs lsm.module_locking=0 cros_netboot_ramfs cros_factory_install cros_secure; run regen_all
regen_initrdroot_bootargs=setenv bootdev_bootargs rw root=/dev/ram0 ramdisk_size=512000 cros_netboot; run regen_all
regen_nfsroot_bootargs=setenv bootdev_bootargs dev=/dev/nfs4 rw nfsroot=${nfsserverip}:${rootpath} ip=dhcp noinitrd; run regen_all
rootaddr=CONFIG_INITRD_ADDRESS
rootpart=3
rootuuid=747e4fa4-9273-4747-adf8-fbdbdeaa9561
run_disk_boot_script=if fatload ${devtype} ${devnum}:${script_part} ${loadaddr} ${script_img}; then source ${loadaddr}; fi
script_img=/u-boot/boot.scr.uimg
script_part=c
set_devname=part uuid ${devtype} ${devnum}:${rootpart} rootuuid; setenv devname PARTUUID=${rootuuid}
stderr=serial,lcd
stdin=serial,cros-ec-keyb
stdout=serial,lcd
tftp_ext2_boot=run tftp_setup; run regen_ext2_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
tftp_setup=setenv tftpkernelpath /tftpboot/vmlinux.uimg; setenv tftprootpath /tftpboot/initrd.uimg; setenv rootpath /export/nfsroot; setenv autoload n
tftpserverip=0.0.0.0
usb_boot=setenv devtype usb; setenv devnum 0; run run_disk_boot_script;run set_devname; run ext2_boot
usbethaddr=00:50:b6:63:d6:2e

Environment size: 3653/16380 bytes

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Hello Tushar,

On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>
>>> The u-boot version is a little different on my Peach-Pi as compared to
>>> the market release version. Not sure if that is making any difference.
>>>
>>> Peach # version
>>>
>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>> 4.8.x-google 20130905 (prerelease)
>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>
>>

I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
and on my setup using chained nv-uboot I also need patch 1/3 along
with 2/3 to fix the issue.

>> Note that I've applied this only from this series so I'm not sure how
>> much the problem can be solved...any updates for 1/3 and 3/3?
>>
>> - Kukjin
>
> Thanks for applying 2/3. I am working on 1/3 to see if we are following
> the right approach to fix Kevin's issue (unfortunately, I am not hitting
> the bug on my board ATM). 3/3 has already been merged through a
> different patchset.
>

I'm sending as an attachment my complete boot log when booting today's
next (20140709) until it hangs and my u-boot env vars. I hope that
helps.

> --
> Tushar Behera
> --

Best regards,
Javier

[-- Attachment #2: boot_log --]
[-- Type: application/octet-stream, Size: 16442 bytes --]

U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach

CPU:    Exynos5420@1800MHz

Board: Google Peach Pit, rev 9.0
I2C:   ready
DRAM:  2 GiB
PMIC max77802-pmic initialized
CPU:    Exynos5420@1800MHz
TPS65090 PMIC EC init
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:    cros-ec-keyb
Out:   lcd
Err:   lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net:   No ethernet found.
Hit any key to stop autoboot:  0
reading uImage
2922012 bytes read in 143 ms (19.5 MiB/s)
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux
   Created:      2014-07-09   9:55:47 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2921948 Bytes = 2.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK

Starting kernel ...

Timer summary in microseconds:
       Mark    Elapsed  Stage
          0          0  reset
  3,453,084  3,453,084  board_init_f
  3,549,299     96,215  board_init_r
  3,693,404    144,105  id=64
  3,696,125      2,721  main_loop
  4,018,144    322,019  bootm_start
  4,018,146          2  id=1
  4,023,850      5,704  id=2
  4,023,852          2  id=3
  4,075,433     51,581  id=4
  4,075,434          1  id=5
  4,075,436          2  id=6
  4,075,437          1  id=14
  4,164,987     89,550  id=7
  4,164,996          9  id=15
  4,169,050      4,054  start_kernel

Accumulated time:
                 6,939  SPI read
cleanup_before_linux_select: Console recording failed (1)


U-Boot 2013.04-gb98ed09 (Mar 07 2014 - 12:25:37) for Peach

CPU:    Exynos5420@1800MHz

Board: Google Peach Pit, rev 9.0
I2C:   ready
DRAM:  2 GiB
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.16.0-rc4-next-20140709ccu (javier@minerva) (gcc version 4.6.3 (Debian 4.6.3-14) ) #360 SMP PREEMPT Wed Jul 9 11:50:52 CEST 2014
[    0.000000] CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Ignoring memory range 0x20000000 - 0x40000000
[    0.000000] Machine model: Google Peach Pit Rev 6+
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 393216
[    0.000000] free_area_init_node: node 0, pgdat c05744c0, node_mem_map eebf4000
[    0.000000]   Normal zone: 1520 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 194560 pages, LIFO batch:31
[    0.000000]   HighMem zone: 1552 pages used for memmap
[    0.000000]   HighMem zone: 198656 pages, LIFO batch:31
[    0.000000] PERCPU: Embedded 7 pages/cpu @eeb8d000 s7104 r8192 d13376 u32768
[    0.000000] pcpu-alloc: s7104 r8192 d13376 u32768 alloc=8*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 391696
[    0.000000] Kernel command line: console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1553488K/1572864K available (3857K kernel code, 244K rwdata, 1196K rodata, 254K init, 273K bss, 19376K reserved, 794624K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc04f78f0   (5055 kB)
[    0.000000]       .init : 0xc04f8000 - 0xc0537bc0   ( 255 kB)
[    0.000000]       .data : 0xc0538000 - 0xc0575060   ( 245 kB)
[    0.000000]        .bss : 0xc057506c - 0xc05b9480   ( 274 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C: failed to init: -19
[    0.000000] Switching to timer-based delay loop, resolution 41ns
[    0.000003] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns
[    0.000157] Console: colour dummy device 80x30
[    0.000173] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000)
[    0.000183] pid_max: default: 32768 minimum: 301
[    0.000284] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000291] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000677] CPU: Testing write buffer coherency: ok
[    0.000875] CPU0: update cpu_capacity 1535
[    0.000883] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.000973] Setting up static identity map for 0x403a92a0 - 0x403a92f8
[    1.030018] CPU1: failed to boot: -38
[    2.040035] CPU2: failed to boot: -38
[    3.050051] CPU3: failed to boot: -38
[    4.060068] CPU4: failed to boot: -38
[    5.070085] CPU5: failed to boot: -38
[    6.080103] CPU6: failed to boot: -38
[    7.090119] CPU7: failed to boot: -38
[    7.090136] Brought up 1 CPUs
[    7.090142] SMP: Total of 1 processors activated.
[    7.090148] CPU: All CPU(s) started in SVC mode.
[    7.090469] devtmpfs: initialized
[    7.095819] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
[    7.096216] pinctrl core: initialized pinctrl subsystem
[    7.096388] regulator-dummy: no parameters
[    7.106177] NET: Registered protocol family 16
[    7.106313] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    7.108847] gpiochip_add: registered GPIOs 0 to 7 on device: gpy7
[    7.108856] gpiochip_add: registered GPIOs 8 to 15 on device: gpx0
[    7.108864] gpiochip_add: registered GPIOs 16 to 23 on device: gpx1
[    7.108872] gpiochip_add: registered GPIOs 24 to 31 on device: gpx2
[    7.108879] gpiochip_add: registered GPIOs 32 to 39 on device: gpx3
[    7.109495] gpiochip_add: registered GPIOs 40 to 47 on device: gpc0
[    7.109504] gpiochip_add: registered GPIOs 48 to 55 on device: gpc1
[    7.109511] gpiochip_add: registered GPIOs 56 to 62 on device: gpc2
[    7.109518] gpiochip_add: registered GPIOs 63 to 66 on device: gpc3
[    7.109525] gpiochip_add: registered GPIOs 67 to 68 on device: gpc4
[    7.109532] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1
[    7.109539] gpiochip_add: registered GPIOs 77 to 82 on device: gpy0
[    7.109546] gpiochip_add: registered GPIOs 83 to 86 on device: gpy1
[    7.109553] gpiochip_add: registered GPIOs 87 to 92 on device: gpy2
[    7.109560] gpiochip_add: registered GPIOs 93 to 100 on device: gpy3
[    7.109567] gpiochip_add: registered GPIOs 101 to 108 on device: gpy4
[    7.109574] gpiochip_add: registered GPIOs 109 to 116 on device: gpy5
[    7.109581] gpiochip_add: registered GPIOs 117 to 124 on device: gpy6
[    7.109971] gpiochip_add: registered GPIOs 125 to 132 on device: gpe0
[    7.109979] gpiochip_add: registered GPIOs 133 to 134 on device: gpe1
[    7.109986] gpiochip_add: registered GPIOs 135 to 140 on device: gpf0
[    7.109994] gpiochip_add: registered GPIOs 141 to 148 on device: gpf1
[    7.110000] gpiochip_add: registered GPIOs 149 to 156 on device: gpg0
[    7.110007] gpiochip_add: registered GPIOs 157 to 164 on device: gpg1
[    7.110014] gpiochip_add: registered GPIOs 165 to 166 on device: gpg2
[    7.110021] gpiochip_add: registered GPIOs 167 to 170 on device: gpj4
[    7.110384] gpiochip_add: registered GPIOs 171 to 178 on device: gpa0
[    7.110392] gpiochip_add: registered GPIOs 179 to 184 on device: gpa1
[    7.110399] gpiochip_add: registered GPIOs 185 to 192 on device: gpa2
[    7.110406] gpiochip_add: registered GPIOs 193 to 197 on device: gpb0
[    7.110413] gpiochip_add: registered GPIOs 198 to 202 on device: gpb1
[    7.110421] gpiochip_add: registered GPIOs 203 to 206 on device: gpb2
[    7.110428] gpiochip_add: registered GPIOs 207 to 214 on device: gpb3
[    7.110435] gpiochip_add: registered GPIOs 215 to 216 on device: gpb4
[    7.110442] gpiochip_add: registered GPIOs 217 to 224 on device: gph0
[    7.110964] gpiochip_add: registered GPIOs 225 to 231 on device: gpz
[    7.111834] exynos-audss-clk 3810000.audss-clock-controller: setup completed
[    7.117332] EXYNOS: PMU not supported
[    7.131601] of_get_named_gpiod_flags exited with status 0
[    7.131701] P5.0V_USB3CON0: 5000 mV
[    7.131790] of_get_named_gpiod_flags exited with status 0
[    7.131891] P5.0V_USB3CON1: 5000 mV
[    7.132749] SCSI subsystem initialized
[    7.132972] usbcore: registered new interface driver usbfs
[    7.133030] usbcore: registered new interface driver hub
[    7.133185] usbcore: registered new device driver usb
[    7.133451] s3c-i2c 12c80000.i2c: slave address 0x50
[    7.133462] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz
[    7.133578] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter
[    7.134377] Switched to clocksource mct-frc
[    7.142076] NET: Registered protocol family 2
[    7.142404] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    7.142456] TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
[    7.142547] TCP: Hash tables configured (established 8192 bind 8192)
[    7.142584] TCP: reno registered
[    7.142595] UDP hash table entries: 512 (order: 2, 24576 bytes)
[    7.142617] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes)
[    7.142761] NET: Registered protocol family 1
[    7.144092] futex hash table entries: 2048 (order: 5, 131072 bytes)
[    7.154291] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[    7.154563] msgmni has been set to 1482
[    7.155284] bounce: pool size: 64 pages
[    7.155294] io scheduler noop registered
[    7.155303] io scheduler deadline registered
[    7.155634] io scheduler cfq registered (default)
[    7.200083] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    7.201178] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 83, base_baud = 0) is a S3C6400/10
[    7.201522] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 84, base_baud = 0) is a S3C6400/10
[    7.201791] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 85, base_baud = 0) is a S3C6400/10
[    7.202063] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 86, base_baud = 0) is a S3C6400/10
[    7.985873] console [ttySAC3] enabled
[    7.996120] brd: module loaded
[    8.000814] loop: module loaded
[    8.002944] usbcore: registered new interface driver cdc_ether
[    8.008661] usbcore: registered new interface driver smsc75xx
[    8.014319] usbcore: registered new interface driver smsc95xx
[    8.020093] usbcore: registered new interface driver net1080
[    8.025671] usbcore: registered new interface driver cdc_subset
[    8.031628] usbcore: registered new interface driver zaurus
[    8.037149] usbcore: registered new interface driver cdc_ncm
[    8.043210] usb@12000000 supply vdd33 not found, using dummy regulator
[    8.049289] usb@12000000 supply vdd10 not found, using dummy regulator
[    8.256625] usb@12400000 supply vdd33 not found, using dummy regulator
[    8.261988] usb@12400000 supply vdd10 not found, using dummy regulator
[    8.469286] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    8.474586] ehci-exynos: EHCI EXYNOS driver
[    8.478620] of_get_named_gpiod_flags: can't parse gpios property of node '/usb@12110000[0]'
[    8.487511] exynos-ehci 12110000.usb: EHCI Host Controller
[    8.492585] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 1
[    8.500365] exynos-ehci 12110000.usb: irq 103, io mem 0x12110000
[    8.514407] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00
[    8.519799] hub 1-0:1.0: USB hub found
[    8.522741] hub 1-0:1.0: 3 ports detected
[    8.527175] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    8.532892] ohci-exynos: OHCI EXYNOS driver
[    8.537172] exynos-ohci 12120000.usb: USB Host Controller
[    8.542402] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 2
[    8.550039] exynos-ohci 12120000.usb: irq 103, io mem 0x12120000
[    8.614032] hub 2-0:1.0: USB hub found
[    8.616410] hub 2-0:1.0: 3 ports detected
[    8.620870] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    8.625925] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 3
[    8.633558] xhci-hcd xhci-hcd.2.auto: irq 104, io mem 0x12000000
[    8.639997] hub 3-0:1.0: USB hub found
[    8.643182] hub 3-0:1.0: 1 port detected
[    8.647307] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[    8.652513] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 4
[    8.660783] hub 4-0:1.0: USB hub found
[    8.663914] hub 4-0:1.0: 1 port detected
[    8.668083] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[    8.673251] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 5
[    8.681010] xhci-hcd xhci-hcd.5.auto: irq 105, io mem 0x12400000
[    8.687452] hub 5-0:1.0: USB hub found
[    8.690667] hub 5-0:1.0: 1 port detected
[    8.694741] xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
[    8.699964] xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 6
[    8.708223] hub 6-0:1.0: USB hub found
[    8.711405] hub 6-0:1.0: 1 port detected
[    8.715650] usbcore: registered new interface driver usb-storage
[    8.721932] mousedev: PS/2 mouse device common for all mice
[    8.727375] s3c-rtc 101e0000.rtc: rtc disabled, re-enabling
[    8.732713] s3c-rtc 101e0000.rtc: rtc core: registered s3c as rtc0
[    8.738695] s3c-rtc 101e0000.rtc: warning: invalid RTC value so initializing it
[    8.747966] tpm_i2c_infineon 9-0020: 1.2 TPM (device-id 0x1A)
[    8.850417] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[    8.857686] sdhci: Secure Digital Host Controller Interface driver
[    8.863657] sdhci: Copyright(c) Pierre Ossman
[    8.868062] Synopsys Designware Multimedia Card Interface Driver
[    8.874365] dwmmc_exynos 12200000.mmc: no vmmc regulator found: -19
[    8.880181] dwmmc_exynos 12200000.mmc: Using internal DMA controller.
[    8.886555] dwmmc_exynos 12200000.mmc: Version ID is 250a
[    8.892062] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 107, 64 bit host data width, 64 deep fifo
[    8.901541] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12200000[0]'
[    8.939393] dwmmc_exynos 12200000.mmc: 1 slots initialized
[    8.943577] dwmmc_exynos 12220000.mmc: no vmmc regulator found: -19
[    8.949691] dwmmc_exynos 12220000.mmc: Using internal DMA controller.
[    8.957123] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[    8.964611] dwmmc_exynos 12220000.mmc: Version ID is 250a
[    8.968697] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 109, 64 bit host data width, 64 deep fifo
[    8.978165] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12220000[0]'
[    8.986435] of_get_named_gpiod_flags: can't parse gpios property of node '/mmc@12220000[0]'
[    9.024394] dwmmc_exynos 12220000.mmc: 1 slots initialized
[    9.028422] mmc0: BKOPS_EN bit is not set
[    9.033244] usbcore: registered new interface driver usbhid
[    9.038139] usbhid: USB HID core driver
[    9.042109] TCP: cubic registered
[    9.045225] NET: Registered protocol family 17
[    9.049744] NET: Registered protocol family 15
[    9.054079] Registering SWP/SWPB emulation handler
[    9.058707] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[    9.069179] of_get_named_gpiod_flags exited with status 0
[    9.074135] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1)
[    9.083665] gpio-18: gpiod_set_debounce: missing set() or set_debounce() operations
[    9.091662] mmc0: new DDR MMC card at address 0001
[    9.096007] input: gpio-keys as /devices/gpio-keys/input/input0
[    9.102183] mmcblk0: mmc0:0001 MAG2GC 14.5 GiB
[    9.106746] s3c-rtc 101e0000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[    9.115114] mmcblk0boot0: mmc0:0001 MAG2GC partition 1 4.00 MiB


[-- Attachment #3: uboot_env --]
[-- Type: application/octet-stream, Size: 3614 bytes --]

Peach # printenv
baudrate=115200
bootargs=console=ttySAC3,115200 debug earlyprintk root=/dev/mmcblk1p2 rootwait rw
bootcmd=fatload mmc 1:1 0x42000000 uImage; bootm 0x42000000
bootdelay=0
bootdev_bootargs=root=PARTUUID=747e4fa4-9273-4747-adf8-fbdbdeaa9561 rootwait ro
common_bootargs=cros_legacy console=ttySAC3,115200 debug earlyprintk
cros_bootfile=/boot/vmlinux.uimg
devname=PARTUUID=747e4fa4-9273-4747-adf8-fbdbdeaa9561
devnum=0
devtype=mmc
ethact=asx0
ext2_boot=run regen_ext2_bootargs; if ext2load ${devtype} ${devnum}:${rootpart} ${loadaddr} ${cros_bootfile}; then if test ${kernaddr} != ""; then echo "Using bundled kernel"; bootm ${kernaddr};fi; bootm ${loadaddr};fi
filesize=8e
has_initrd=0
initramfs_boot=run tftp_setup; run regen_initramfs_install_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
initrd_high=0xffffffff
initrdroot_boot=run tftp_setup; run regen_initrdroot_bootargs; bootp; if tftpboot ${rootaddr} ${tftpserverip}:${tftprootpath} &&    tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr} ${rootaddr}; else echo 'ERROR: Could not load root/kernel from TFTP'; exit; fi
mmc0_boot=setenv devnum 0; run mmc_boot
mmc0_tftpboot=setenv devnum 0; run mmc_setup; run tftp_ext2_boot
mmc1_boot=setenv devnum 1; run mmc_boot
mmc_boot=run mmc_setup; run run_disk_boot_script;run set_devname; run ext2_boot
mmc_setup=mmc dev ${devnum}; mmc rescan; setenv devtype mmc
net_boot=if test ${ethact} != ""; then if test ${tftpserverip} != "0.0.0.0"; then if test ${nfsserverip} != "0.0.0.0"; then run nfsroot_boot; fi; if test ${has_initrd} != "0"; then run initrdroot_boot; else run initramfs_boot; fi; fi; fi
nfsroot_boot=run tftp_setup; run regen_nfsroot_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
nfsserverip=0.0.0.0
non_verified_boot=usb start; run net_boot; run usb_boot; run mmc1_boot; run mmc0_boot
regen_all=setenv bootargs ${common_bootargs} ${dev_extras} ${extra_bootargs} ${bootdev_bootargs}
regen_ext2_bootargs=setenv bootdev_bootargs root=${devname} rootwait ro; run regen_all
regen_initramfs_install_bootargs=setenv bootdev_bootargs lsm.module_locking=0 cros_netboot_ramfs cros_factory_install cros_secure; run regen_all
regen_initrdroot_bootargs=setenv bootdev_bootargs rw root=/dev/ram0 ramdisk_size=512000 cros_netboot; run regen_all
regen_nfsroot_bootargs=setenv bootdev_bootargs dev=/dev/nfs4 rw nfsroot=${nfsserverip}:${rootpath} ip=dhcp noinitrd; run regen_all
rootaddr=CONFIG_INITRD_ADDRESS
rootpart=3
rootuuid=747e4fa4-9273-4747-adf8-fbdbdeaa9561
run_disk_boot_script=if fatload ${devtype} ${devnum}:${script_part} ${loadaddr} ${script_img}; then source ${loadaddr}; fi
script_img=/u-boot/boot.scr.uimg
script_part=c
set_devname=part uuid ${devtype} ${devnum}:${rootpart} rootuuid; setenv devname PARTUUID=${rootuuid}
stderr=serial,lcd
stdin=serial,cros-ec-keyb
stdout=serial,lcd
tftp_ext2_boot=run tftp_setup; run regen_ext2_bootargs; bootp; if tftpboot ${loadaddr} ${tftpserverip}:${tftpkernelpath}; then bootm ${loadaddr}; else echo 'ERROR: Could not load kernel from TFTP'; exit; fi
tftp_setup=setenv tftpkernelpath /tftpboot/vmlinux.uimg; setenv tftprootpath /tftpboot/initrd.uimg; setenv rootpath /export/nfsroot; setenv autoload n
tftpserverip=0.0.0.0
usb_boot=setenv devtype usb; setenv devnum 0; run run_disk_boot_script;run set_devname; run ext2_boot
usbethaddr=00:50:b6:63:d6:2e

Environment size: 3653/16380 bytes

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Tushar,

On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>
>>> The u-boot version is a little different on my Peach-Pi as compared to
>>> the market release version. Not sure if that is making any difference.
>>>
>>> Peach # version
>>>
>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>> 4.8.x-google 20130905 (prerelease)
>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>
>>

I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
and on my setup using chained nv-uboot I also need patch 1/3 along
with 2/3 to fix the issue.

>> Note that I've applied this only from this series so I'm not sure how
>> much the problem can be solved...any updates for 1/3 and 3/3?
>>
>> - Kukjin
>
> Thanks for applying 2/3. I am working on 1/3 to see if we are following
> the right approach to fix Kevin's issue (unfortunately, I am not hitting
> the bug on my board ATM). 3/3 has already been merged through a
> different patchset.
>

I'm sending as an attachment my complete boot log when booting today's
next (20140709) until it hangs and my u-boot env vars. I hope that
helps.

> --
> Tushar Behera
> --

Best regards,
Javier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot_log
Type: application/octet-stream
Size: 16442 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140709/8d6422b3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uboot_env
Type: application/octet-stream
Size: 3614 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140709/8d6422b3/attachment-0003.obj>

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
> Hello Tushar,
> 
> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>
>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>> the market release version. Not sure if that is making any difference.
>>>>
>>>> Peach # version
>>>>
>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>> 4.8.x-google 20130905 (prerelease)
>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>
>>>
> 
> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
> and on my setup using chained nv-uboot I also need patch 1/3 along
> with 2/3 to fix the issue.
> 
>>> Note that I've applied this only from this series so I'm not sure how
>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>
>>> - Kukjin
>>
>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>> the bug on my board ATM). 3/3 has already been merged through a
>> different patchset.
>>
> 
> I'm sending as an attachment my complete boot log when booting today's
> next (20140709) until it hangs and my u-boot env vars. I hope that
> helps.
> 

Would you please check the behaviour after enabling following config
options?

diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index e07a227..d6056ab 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
 CONFIG_LOGO=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_SNOW=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_EXYNOS=y
@@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_S3C=y
+CONFIG_DMADEVICES=y
+CONFIG_PL330_DMA=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y


>> --
>> Tushar Behera
>> --
> 
> Best regards,
> Javier
> 


-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
> Hello Tushar,
> 
> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>
>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>> the market release version. Not sure if that is making any difference.
>>>>
>>>> Peach # version
>>>>
>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>> 4.8.x-google 20130905 (prerelease)
>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>
>>>
> 
> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
> and on my setup using chained nv-uboot I also need patch 1/3 along
> with 2/3 to fix the issue.
> 
>>> Note that I've applied this only from this series so I'm not sure how
>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>
>>> - Kukjin
>>
>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>> the bug on my board ATM). 3/3 has already been merged through a
>> different patchset.
>>
> 
> I'm sending as an attachment my complete boot log when booting today's
> next (20140709) until it hangs and my u-boot env vars. I hope that
> helps.
> 

Would you please check the behaviour after enabling following config
options?

diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index e07a227..d6056ab 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
 CONFIG_LOGO=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_SNOW=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_EXYNOS=y
@@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_S3C=y
+CONFIG_DMADEVICES=y
+CONFIG_PL330_DMA=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y


>> --
>> Tushar Behera
>> --
> 
> Best regards,
> Javier
> 


-- 
Tushar Behera

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
> Hello Tushar,
> 
> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>
>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>> the market release version. Not sure if that is making any difference.
>>>>
>>>> Peach # version
>>>>
>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>> 4.8.x-google 20130905 (prerelease)
>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>
>>>
> 
> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
> and on my setup using chained nv-uboot I also need patch 1/3 along
> with 2/3 to fix the issue.
> 
>>> Note that I've applied this only from this series so I'm not sure how
>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>
>>> - Kukjin
>>
>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>> the bug on my board ATM). 3/3 has already been merged through a
>> different patchset.
>>
> 
> I'm sending as an attachment my complete boot log when booting today's
> next (20140709) until it hangs and my u-boot env vars. I hope that
> helps.
> 

Would you please check the behaviour after enabling following config
options?

diff --git a/arch/arm/configs/exynos_defconfig
b/arch/arm/configs/exynos_defconfig
index e07a227..d6056ab 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FONTS=y
 CONFIG_FONT_7x14=y
 CONFIG_LOGO=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_SNOW=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_EXYNOS=y
@@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_EXYNOS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_S3C=y
+CONFIG_DMADEVICES=y
+CONFIG_PL330_DMA=y
 CONFIG_COMMON_CLK_MAX77686=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y


>> --
>> Tushar Behera
>> --
> 
> Best regards,
> Javier
> 


-- 
Tushar Behera

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Tushar,

On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>> Hello Tushar,
>>
>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>
>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>> the market release version. Not sure if that is making any difference.
>>>>>
>>>>> Peach # version
>>>>>
>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>> 4.8.x-google 20130905 (prerelease)
>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>
>>>>
>>
>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>> and on my setup using chained nv-uboot I also need patch 1/3 along
>> with 2/3 to fix the issue.
>>
>>>> Note that I've applied this only from this series so I'm not sure how
>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>
>>>> - Kukjin
>>>
>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>> the bug on my board ATM). 3/3 has already been merged through a
>>> different patchset.
>>>
>>
>> I'm sending as an attachment my complete boot log when booting today's
>> next (20140709) until it hangs and my u-boot env vars. I hope that
>> helps.
>>
>
> Would you please check the behaviour after enabling following config
> options?
>
> diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> index e07a227..d6056ab 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>  CONFIG_FONTS=y
>  CONFIG_FONT_7x14=y
>  CONFIG_LOGO=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_SOC_SAMSUNG=y
> +CONFIG_SND_SOC_SNOW=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_EXYNOS=y
> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_EXYNOS=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_S3C=y
> +CONFIG_DMADEVICES=y
> +CONFIG_PL330_DMA=y
>  CONFIG_COMMON_CLK_MAX77686=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>
>

With those Kconfig options enabled the kernel does not hang anymore so
patch 1/3 is not needed in that case.

Best regards,
Javier

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Tushar,

On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>> Hello Tushar,
>>
>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>
>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>> the market release version. Not sure if that is making any difference.
>>>>>
>>>>> Peach # version
>>>>>
>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>> 4.8.x-google 20130905 (prerelease)
>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>
>>>>
>>
>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>> and on my setup using chained nv-uboot I also need patch 1/3 along
>> with 2/3 to fix the issue.
>>
>>>> Note that I've applied this only from this series so I'm not sure how
>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>
>>>> - Kukjin
>>>
>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>> the bug on my board ATM). 3/3 has already been merged through a
>>> different patchset.
>>>
>>
>> I'm sending as an attachment my complete boot log when booting today's
>> next (20140709) until it hangs and my u-boot env vars. I hope that
>> helps.
>>
>
> Would you please check the behaviour after enabling following config
> options?
>
> diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> index e07a227..d6056ab 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>  CONFIG_FONTS=y
>  CONFIG_FONT_7x14=y
>  CONFIG_LOGO=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_SOC_SAMSUNG=y
> +CONFIG_SND_SOC_SNOW=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_EXYNOS=y
> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_EXYNOS=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_S3C=y
> +CONFIG_DMADEVICES=y
> +CONFIG_PL330_DMA=y
>  CONFIG_COMMON_CLK_MAX77686=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>
>

With those Kconfig options enabled the kernel does not hang anymore so
patch 1/3 is not needed in that case.

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Tushar,

On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>> Hello Tushar,
>>
>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>
>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>> the market release version. Not sure if that is making any difference.
>>>>>
>>>>> Peach # version
>>>>>
>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>> 4.8.x-google 20130905 (prerelease)
>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>
>>>>
>>
>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>> and on my setup using chained nv-uboot I also need patch 1/3 along
>> with 2/3 to fix the issue.
>>
>>>> Note that I've applied this only from this series so I'm not sure how
>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>
>>>> - Kukjin
>>>
>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>> the bug on my board ATM). 3/3 has already been merged through a
>>> different patchset.
>>>
>>
>> I'm sending as an attachment my complete boot log when booting today's
>> next (20140709) until it hangs and my u-boot env vars. I hope that
>> helps.
>>
>
> Would you please check the behaviour after enabling following config
> options?
>
> diff --git a/arch/arm/configs/exynos_defconfig
> b/arch/arm/configs/exynos_defconfig
> index e07a227..d6056ab 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>  CONFIG_FONTS=y
>  CONFIG_FONT_7x14=y
>  CONFIG_LOGO=y
> +CONFIG_SOUND=y
> +CONFIG_SND=y
> +CONFIG_SND_SOC=y
> +CONFIG_SND_SOC_SAMSUNG=y
> +CONFIG_SND_SOC_SNOW=y
>  CONFIG_USB=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_EXYNOS=y
> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_EXYNOS=y
>  CONFIG_RTC_CLASS=y
>  CONFIG_RTC_DRV_S3C=y
> +CONFIG_DMADEVICES=y
> +CONFIG_PL330_DMA=y
>  CONFIG_COMMON_CLK_MAX77686=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT3_FS=y
>
>

With those Kconfig options enabled the kernel does not hang anymore so
patch 1/3 is not needed in that case.

Best regards,
Javier

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Tushar,
>
> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>> Hello Tushar,
>>>
>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>
>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>
>>>>>> Peach # version
>>>>>>
>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>
>>>>>
>>>
>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>> with 2/3 to fix the issue.
>>>
>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>
>>>>> - Kukjin
>>>>
>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>> different patchset.
>>>>
>>>
>>> I'm sending as an attachment my complete boot log when booting today's
>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>> helps.
>>>
>>
>> Would you please check the behaviour after enabling following config
>> options?
>>
>> diff --git a/arch/arm/configs/exynos_defconfig
>> b/arch/arm/configs/exynos_defconfig
>> index e07a227..d6056ab 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>  CONFIG_FONTS=y
>>  CONFIG_FONT_7x14=y
>>  CONFIG_LOGO=y
>> +CONFIG_SOUND=y
>> +CONFIG_SND=y
>> +CONFIG_SND_SOC=y
>> +CONFIG_SND_SOC_SAMSUNG=y
>> +CONFIG_SND_SOC_SNOW=y
>>  CONFIG_USB=y
>>  CONFIG_USB_EHCI_HCD=y
>>  CONFIG_USB_EHCI_EXYNOS=y
>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>  CONFIG_MMC_DW_EXYNOS=y
>>  CONFIG_RTC_CLASS=y
>>  CONFIG_RTC_DRV_S3C=y
>> +CONFIG_DMADEVICES=y
>> +CONFIG_PL330_DMA=y
>>  CONFIG_COMMON_CLK_MAX77686=y
>>  CONFIG_EXT2_FS=y
>>  CONFIG_EXT3_FS=y
>>
>>
>
> With those Kconfig options enabled the kernel does not hang anymore so
> patch 1/3 is not needed in that case.

Just checking: did you happen to confirm whether it's the PL330 /
DMADEVICES that fixes things or do you actually need the sound stuff?

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Tushar,
>
> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>> Hello Tushar,
>>>
>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>
>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>
>>>>>> Peach # version
>>>>>>
>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>
>>>>>
>>>
>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>> with 2/3 to fix the issue.
>>>
>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>
>>>>> - Kukjin
>>>>
>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>> different patchset.
>>>>
>>>
>>> I'm sending as an attachment my complete boot log when booting today's
>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>> helps.
>>>
>>
>> Would you please check the behaviour after enabling following config
>> options?
>>
>> diff --git a/arch/arm/configs/exynos_defconfig
>> b/arch/arm/configs/exynos_defconfig
>> index e07a227..d6056ab 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>  CONFIG_FONTS=y
>>  CONFIG_FONT_7x14=y
>>  CONFIG_LOGO=y
>> +CONFIG_SOUND=y
>> +CONFIG_SND=y
>> +CONFIG_SND_SOC=y
>> +CONFIG_SND_SOC_SAMSUNG=y
>> +CONFIG_SND_SOC_SNOW=y
>>  CONFIG_USB=y
>>  CONFIG_USB_EHCI_HCD=y
>>  CONFIG_USB_EHCI_EXYNOS=y
>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>  CONFIG_MMC_DW_EXYNOS=y
>>  CONFIG_RTC_CLASS=y
>>  CONFIG_RTC_DRV_S3C=y
>> +CONFIG_DMADEVICES=y
>> +CONFIG_PL330_DMA=y
>>  CONFIG_COMMON_CLK_MAX77686=y
>>  CONFIG_EXT2_FS=y
>>  CONFIG_EXT3_FS=y
>>
>>
>
> With those Kconfig options enabled the kernel does not hang anymore so
> patch 1/3 is not needed in that case.

Just checking: did you happen to confirm whether it's the PL330 /
DMADEVICES that fixes things or do you actually need the sound stuff?

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Tushar,
>
> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>> Hello Tushar,
>>>
>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>
>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>
>>>>>> Peach # version
>>>>>>
>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>
>>>>>
>>>
>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>> with 2/3 to fix the issue.
>>>
>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>
>>>>> - Kukjin
>>>>
>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>> different patchset.
>>>>
>>>
>>> I'm sending as an attachment my complete boot log when booting today's
>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>> helps.
>>>
>>
>> Would you please check the behaviour after enabling following config
>> options?
>>
>> diff --git a/arch/arm/configs/exynos_defconfig
>> b/arch/arm/configs/exynos_defconfig
>> index e07a227..d6056ab 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>  CONFIG_FONTS=y
>>  CONFIG_FONT_7x14=y
>>  CONFIG_LOGO=y
>> +CONFIG_SOUND=y
>> +CONFIG_SND=y
>> +CONFIG_SND_SOC=y
>> +CONFIG_SND_SOC_SAMSUNG=y
>> +CONFIG_SND_SOC_SNOW=y
>>  CONFIG_USB=y
>>  CONFIG_USB_EHCI_HCD=y
>>  CONFIG_USB_EHCI_EXYNOS=y
>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>  CONFIG_MMC_DW_EXYNOS=y
>>  CONFIG_RTC_CLASS=y
>>  CONFIG_RTC_DRV_S3C=y
>> +CONFIG_DMADEVICES=y
>> +CONFIG_PL330_DMA=y
>>  CONFIG_COMMON_CLK_MAX77686=y
>>  CONFIG_EXT2_FS=y
>>  CONFIG_EXT3_FS=y
>>
>>
>
> With those Kconfig options enabled the kernel does not hang anymore so
> patch 1/3 is not needed in that case.

Just checking: did you happen to confirm whether it's the PL330 /
DMADEVICES that fixes things or do you actually need the sound stuff?

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Doug,

On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders@google.com> wrote:
> Javier,
>
> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> Hello Tushar,
>>
>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>> Hello Tushar,
>>>>
>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>>
>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>
>>>>>>> Peach # version
>>>>>>>
>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>
>>>>>>
>>>>
>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>> with 2/3 to fix the issue.
>>>>
>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>
>>>>>> - Kukjin
>>>>>
>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>> different patchset.
>>>>>
>>>>
>>>> I'm sending as an attachment my complete boot log when booting today's
>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>> helps.
>>>>
>>>
>>> Would you please check the behaviour after enabling following config
>>> options?
>>>
>>> diff --git a/arch/arm/configs/exynos_defconfig
>>> b/arch/arm/configs/exynos_defconfig
>>> index e07a227..d6056ab 100644
>>> --- a/arch/arm/configs/exynos_defconfig
>>> +++ b/arch/arm/configs/exynos_defconfig
>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>  CONFIG_FONTS=y
>>>  CONFIG_FONT_7x14=y
>>>  CONFIG_LOGO=y
>>> +CONFIG_SOUND=y
>>> +CONFIG_SND=y
>>> +CONFIG_SND_SOC=y
>>> +CONFIG_SND_SOC_SAMSUNG=y
>>> +CONFIG_SND_SOC_SNOW=y
>>>  CONFIG_USB=y
>>>  CONFIG_USB_EHCI_HCD=y
>>>  CONFIG_USB_EHCI_EXYNOS=y
>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>  CONFIG_MMC_DW_EXYNOS=y
>>>  CONFIG_RTC_CLASS=y
>>>  CONFIG_RTC_DRV_S3C=y
>>> +CONFIG_DMADEVICES=y
>>> +CONFIG_PL330_DMA=y
>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>  CONFIG_EXT2_FS=y
>>>  CONFIG_EXT3_FS=y
>>>
>>>
>>
>> With those Kconfig options enabled the kernel does not hang anymore so
>> patch 1/3 is not needed in that case.
>
> Just checking: did you happen to confirm whether it's the PL330 /
> DMADEVICES that fixes things or do you actually need the sound stuff?

Sorry I should had mentioned this before. The DMADEVICES and PL330
Kconfig are enough to avoid the kernel to hang, the sound config
options are not actually required.

Best regards,
Javier

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Doug,

On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders@google.com> wrote:
> Javier,
>
> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> Hello Tushar,
>>
>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>> Hello Tushar,
>>>>
>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>>
>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>
>>>>>>> Peach # version
>>>>>>>
>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>
>>>>>>
>>>>
>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>> with 2/3 to fix the issue.
>>>>
>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>
>>>>>> - Kukjin
>>>>>
>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>> different patchset.
>>>>>
>>>>
>>>> I'm sending as an attachment my complete boot log when booting today's
>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>> helps.
>>>>
>>>
>>> Would you please check the behaviour after enabling following config
>>> options?
>>>
>>> diff --git a/arch/arm/configs/exynos_defconfig
>>> b/arch/arm/configs/exynos_defconfig
>>> index e07a227..d6056ab 100644
>>> --- a/arch/arm/configs/exynos_defconfig
>>> +++ b/arch/arm/configs/exynos_defconfig
>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>  CONFIG_FONTS=y
>>>  CONFIG_FONT_7x14=y
>>>  CONFIG_LOGO=y
>>> +CONFIG_SOUND=y
>>> +CONFIG_SND=y
>>> +CONFIG_SND_SOC=y
>>> +CONFIG_SND_SOC_SAMSUNG=y
>>> +CONFIG_SND_SOC_SNOW=y
>>>  CONFIG_USB=y
>>>  CONFIG_USB_EHCI_HCD=y
>>>  CONFIG_USB_EHCI_EXYNOS=y
>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>  CONFIG_MMC_DW_EXYNOS=y
>>>  CONFIG_RTC_CLASS=y
>>>  CONFIG_RTC_DRV_S3C=y
>>> +CONFIG_DMADEVICES=y
>>> +CONFIG_PL330_DMA=y
>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>  CONFIG_EXT2_FS=y
>>>  CONFIG_EXT3_FS=y
>>>
>>>
>>
>> With those Kconfig options enabled the kernel does not hang anymore so
>> patch 1/3 is not needed in that case.
>
> Just checking: did you happen to confirm whether it's the PL330 /
> DMADEVICES that fixes things or do you actually need the sound stuff?

Sorry I should had mentioned this before. The DMADEVICES and PL330
Kconfig are enough to avoid the kernel to hang, the sound config
options are not actually required.

Best regards,
Javier

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Javier Martinez Canillas]

Hello Doug,

On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders@google.com> wrote:
> Javier,
>
> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
>> Hello Tushar,
>>
>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>> Hello Tushar,
>>>>
>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>>
>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>
>>>>>>> Peach # version
>>>>>>>
>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>
>>>>>>
>>>>
>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>> with 2/3 to fix the issue.
>>>>
>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>
>>>>>> - Kukjin
>>>>>
>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>> different patchset.
>>>>>
>>>>
>>>> I'm sending as an attachment my complete boot log when booting today's
>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>> helps.
>>>>
>>>
>>> Would you please check the behaviour after enabling following config
>>> options?
>>>
>>> diff --git a/arch/arm/configs/exynos_defconfig
>>> b/arch/arm/configs/exynos_defconfig
>>> index e07a227..d6056ab 100644
>>> --- a/arch/arm/configs/exynos_defconfig
>>> +++ b/arch/arm/configs/exynos_defconfig
>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>  CONFIG_FONTS=y
>>>  CONFIG_FONT_7x14=y
>>>  CONFIG_LOGO=y
>>> +CONFIG_SOUND=y
>>> +CONFIG_SND=y
>>> +CONFIG_SND_SOC=y
>>> +CONFIG_SND_SOC_SAMSUNG=y
>>> +CONFIG_SND_SOC_SNOW=y
>>>  CONFIG_USB=y
>>>  CONFIG_USB_EHCI_HCD=y
>>>  CONFIG_USB_EHCI_EXYNOS=y
>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>  CONFIG_MMC_DW_EXYNOS=y
>>>  CONFIG_RTC_CLASS=y
>>>  CONFIG_RTC_DRV_S3C=y
>>> +CONFIG_DMADEVICES=y
>>> +CONFIG_PL330_DMA=y
>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>  CONFIG_EXT2_FS=y
>>>  CONFIG_EXT3_FS=y
>>>
>>>
>>
>> With those Kconfig options enabled the kernel does not hang anymore so
>> patch 1/3 is not needed in that case.
>
> Just checking: did you happen to confirm whether it's the PL330 /
> DMADEVICES that fixes things or do you actually need the sound stuff?

Sorry I should had mentioned this before. The DMADEVICES and PL330
Kconfig are enough to avoid the kernel to hang, the sound config
options are not actually required.

Best regards,
Javier

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 10:46 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Doug,
>
> On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders@google.com> wrote:
>> Javier,
>>
>> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> Hello Tushar,
>>>
>>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>>> Hello Tushar,
>>>>>
>>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>>>
>>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>>
>>>>>>>> Peach # version
>>>>>>>>
>>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>>
>>>>>>>
>>>>>
>>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>>> with 2/3 to fix the issue.
>>>>>
>>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>>
>>>>>>> - Kukjin
>>>>>>
>>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>>> different patchset.
>>>>>>
>>>>>
>>>>> I'm sending as an attachment my complete boot log when booting today's
>>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>>> helps.
>>>>>
>>>>
>>>> Would you please check the behaviour after enabling following config
>>>> options?
>>>>
>>>> diff --git a/arch/arm/configs/exynos_defconfig
>>>> b/arch/arm/configs/exynos_defconfig
>>>> index e07a227..d6056ab 100644
>>>> --- a/arch/arm/configs/exynos_defconfig
>>>> +++ b/arch/arm/configs/exynos_defconfig
>>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>>  CONFIG_FONTS=y
>>>>  CONFIG_FONT_7x14=y
>>>>  CONFIG_LOGO=y
>>>> +CONFIG_SOUND=y
>>>> +CONFIG_SND=y
>>>> +CONFIG_SND_SOC=y
>>>> +CONFIG_SND_SOC_SAMSUNG=y
>>>> +CONFIG_SND_SOC_SNOW=y
>>>>  CONFIG_USB=y
>>>>  CONFIG_USB_EHCI_HCD=y
>>>>  CONFIG_USB_EHCI_EXYNOS=y
>>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>>  CONFIG_MMC_DW_EXYNOS=y
>>>>  CONFIG_RTC_CLASS=y
>>>>  CONFIG_RTC_DRV_S3C=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_PL330_DMA=y
>>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>>  CONFIG_EXT2_FS=y
>>>>  CONFIG_EXT3_FS=y
>>>>
>>>>
>>>
>>> With those Kconfig options enabled the kernel does not hang anymore so
>>> patch 1/3 is not needed in that case.
>>
>> Just checking: did you happen to confirm whether it's the PL330 /
>> DMADEVICES that fixes things or do you actually need the sound stuff?
>
> Sorry I should had mentioned this before. The DMADEVICES and PL330
> Kconfig are enough to avoid the kernel to hang, the sound config
> options are not actually required.

OK, makes sense.  Possibly the correct fix is just a Kconfig change
that somehow enforces that we have these two configs on.

-Doug

Re: [PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 10:46 AM, Javier Martinez Canillas
<javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org> wrote:
> Hello Doug,
>
> On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>> Javier,
>>
>> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
>> <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org> wrote:
>>> Hello Tushar,
>>>
>>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>>> Hello Tushar,
>>>>>
>>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>>
>>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>>
>>>>>>>> Peach # version
>>>>>>>>
>>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>>
>>>>>>>
>>>>>
>>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>>> with 2/3 to fix the issue.
>>>>>
>>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>>
>>>>>>> - Kukjin
>>>>>>
>>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>>> different patchset.
>>>>>>
>>>>>
>>>>> I'm sending as an attachment my complete boot log when booting today's
>>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>>> helps.
>>>>>
>>>>
>>>> Would you please check the behaviour after enabling following config
>>>> options?
>>>>
>>>> diff --git a/arch/arm/configs/exynos_defconfig
>>>> b/arch/arm/configs/exynos_defconfig
>>>> index e07a227..d6056ab 100644
>>>> --- a/arch/arm/configs/exynos_defconfig
>>>> +++ b/arch/arm/configs/exynos_defconfig
>>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>>  CONFIG_FONTS=y
>>>>  CONFIG_FONT_7x14=y
>>>>  CONFIG_LOGO=y
>>>> +CONFIG_SOUND=y
>>>> +CONFIG_SND=y
>>>> +CONFIG_SND_SOC=y
>>>> +CONFIG_SND_SOC_SAMSUNG=y
>>>> +CONFIG_SND_SOC_SNOW=y
>>>>  CONFIG_USB=y
>>>>  CONFIG_USB_EHCI_HCD=y
>>>>  CONFIG_USB_EHCI_EXYNOS=y
>>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>>  CONFIG_MMC_DW_EXYNOS=y
>>>>  CONFIG_RTC_CLASS=y
>>>>  CONFIG_RTC_DRV_S3C=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_PL330_DMA=y
>>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>>  CONFIG_EXT2_FS=y
>>>>  CONFIG_EXT3_FS=y
>>>>
>>>>
>>>
>>> With those Kconfig options enabled the kernel does not hang anymore so
>>> patch 1/3 is not needed in that case.
>>
>> Just checking: did you happen to confirm whether it's the PL330 /
>> DMADEVICES that fixes things or do you actually need the sound stuff?
>
> Sorry I should had mentioned this before. The DMADEVICES and PL330
> Kconfig are enough to avoid the kernel to hang, the sound config
> options are not actually required.

OK, makes sense.  Possibly the correct fix is just a Kconfig change
that somehow enforces that we have these two configs on.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Doug Anderson]

Javier,

On Wed, Jul 9, 2014 at 10:46 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Doug,
>
> On Wed, Jul 9, 2014 at 6:01 PM, Doug Anderson <dianders@google.com> wrote:
>> Javier,
>>
>> On Wed, Jul 9, 2014 at 6:03 AM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>>> Hello Tushar,
>>>
>>> On Wed, Jul 9, 2014 at 2:11 PM, Tushar Behera <trblinux@gmail.com> wrote:
>>>> On 07/09/2014 03:44 PM, Javier Martinez Canillas wrote:
>>>>> Hello Tushar,
>>>>>
>>>>> On Tue, Jul 8, 2014 at 5:00 AM, Tushar Behera <trblinux@gmail.com> wrote:
>>>>>>>>
>>>>>>>> The u-boot version is a little different on my Peach-Pi as compared to
>>>>>>>> the market release version. Not sure if that is making any difference.
>>>>>>>>
>>>>>>>> Peach # version
>>>>>>>>
>>>>>>>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>>>>>>>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>>>>>>>> 4.8.x-google 20130905 (prerelease)
>>>>>>>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>>>>>>>
>>>>>>>
>>>>>
>>>>> I'm using the same U-Boot version than Kevin (U-Boot 2013.04-gb98ed09)
>>>>> and on my setup using chained nv-uboot I also need patch 1/3 along
>>>>> with 2/3 to fix the issue.
>>>>>
>>>>>>> Note that I've applied this only from this series so I'm not sure how
>>>>>>> much the problem can be solved...any updates for 1/3 and 3/3?
>>>>>>>
>>>>>>> - Kukjin
>>>>>>
>>>>>> Thanks for applying 2/3. I am working on 1/3 to see if we are following
>>>>>> the right approach to fix Kevin's issue (unfortunately, I am not hitting
>>>>>> the bug on my board ATM). 3/3 has already been merged through a
>>>>>> different patchset.
>>>>>>
>>>>>
>>>>> I'm sending as an attachment my complete boot log when booting today's
>>>>> next (20140709) until it hangs and my u-boot env vars. I hope that
>>>>> helps.
>>>>>
>>>>
>>>> Would you please check the behaviour after enabling following config
>>>> options?
>>>>
>>>> diff --git a/arch/arm/configs/exynos_defconfig
>>>> b/arch/arm/configs/exynos_defconfig
>>>> index e07a227..d6056ab 100644
>>>> --- a/arch/arm/configs/exynos_defconfig
>>>> +++ b/arch/arm/configs/exynos_defconfig
>>>> @@ -93,6 +93,11 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
>>>>  CONFIG_FONTS=y
>>>>  CONFIG_FONT_7x14=y
>>>>  CONFIG_LOGO=y
>>>> +CONFIG_SOUND=y
>>>> +CONFIG_SND=y
>>>> +CONFIG_SND_SOC=y
>>>> +CONFIG_SND_SOC_SAMSUNG=y
>>>> +CONFIG_SND_SOC_SNOW=y
>>>>  CONFIG_USB=y
>>>>  CONFIG_USB_EHCI_HCD=y
>>>>  CONFIG_USB_EHCI_EXYNOS=y
>>>> @@ -109,6 +114,8 @@ CONFIG_MMC_DW_IDMAC=y
>>>>  CONFIG_MMC_DW_EXYNOS=y
>>>>  CONFIG_RTC_CLASS=y
>>>>  CONFIG_RTC_DRV_S3C=y
>>>> +CONFIG_DMADEVICES=y
>>>> +CONFIG_PL330_DMA=y
>>>>  CONFIG_COMMON_CLK_MAX77686=y
>>>>  CONFIG_EXT2_FS=y
>>>>  CONFIG_EXT3_FS=y
>>>>
>>>>
>>>
>>> With those Kconfig options enabled the kernel does not hang anymore so
>>> patch 1/3 is not needed in that case.
>>
>> Just checking: did you happen to confirm whether it's the PL330 /
>> DMADEVICES that fixes things or do you actually need the sound stuff?
>
> Sorry I should had mentioned this before. The DMADEVICES and PL330
> Kconfig are enough to avoid the kernel to hang, the sound config
> options are not actually required.

OK, makes sense.  Possibly the correct fix is just a Kconfig change
that somehow enforces that we have these two configs on.

-Doug

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/13/2014 02:39 AM, Mike Turquette wrote:
> Quoting Tushar Behera (2014-06-12 00:29:23)
>> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
>>> Quoting Tushar Behera (2014-06-10 22:32:17)
>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>>>> user manual doesn't specify this dependency, we came across this issue
>>>> while disabling the parent of AUDSS mux clocks.
>>>
>>> Hi Tushar,
>>>
>>> Can you help me understand better what the actual problem is? What is
>>> the root cause of the kernel oops?
>>
>> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
>> As per observation, when the output of AUDSS mux is gated, we are not
>> able to do any operation on the clocks provided by MAU block (mostly
>> the clocks used by ADMA and audio blocks).
> 
> I tried to get a datasheet for Exynos 54xx but could not find it. I even
> looked at the public 5250 data sheet, but it is completely missing
> Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
> "Clock names and clock tree diagram of MAUDIO_BLK".
> 
> So without any clue about your hardware (not for lack of trying) I would
> guess that somewhere in the parent hierarchy you have an interface clock
> which must be enabled in order for you to touch the registers pertaining
> to the downstream audio clocks.
> 

Yes, right. As per observation, we need to keep the output of AUDSS mux
enabled to access the registers present in MAU block.

> The right way to handle this requires two steps:
> 
> 1) model your interface clock in the Linux clock framework if you
> haven't already (I assume it is a gate clock, or the child of a gate
> clock)
> 

The interface clock is already part of the clock framework.

> 2) the clk_ops callbacks for the affected audio clocks should wrap their
> operations (i.e. critical secion) with a clk_enable/clk_disable pair,
> where the clock being enables/disable is the interface clock mentioned
> above in #1
> 
> The CCF is reentrant, so you can do this by simply using the top-level
> clk.h API from within your clk_ops callbacks.
> 

Right now, the clocks are registered with clk_register_mux,
clk_register_div and clk_register_gate calls which in turn set
appropriate clk_ops callbacks. If I need to wrap the register access
during these clk_ops callbacks with clk_enable/clk_disable of interface
lock, I would have to reimplement the clk_ops callbacks in
clk-exynos-audss driver.

Is that the approach that you are suggesting?

> I might be totally wrong about the cause of the hang, but that's my best
> guess based on everyone's bug reports.
> 

There are 5 gate clocks within MAU block. While disabling the unused
clocks, if CLK_MAU_EPLL is disabled first, then we are getting this
system hang.


> Regards,
> Mike
> 
>>
>>>
>>> You mention calling clk_get on child clocks of the AUDSS mux fails, but
>>> I cannot imagine why. How can the enable/disable state of a clock affect
>>> the ability to clk_get other clocks?
>>>
>>
>> I might have a little vogue while updating the commit message
>> (mentioning about clk_get which surely is only a s/w operation), but
>> there is definitely some issue with handling those clocks under given
>> scenario.
>>
>> I am on leave till end of this week, so I will update you more with
>> the logs on Monday.
>>
>> Thanks,
>> --
>> Tushar
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Tushar Behera

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Tushar Behera]

On 06/13/2014 02:39 AM, Mike Turquette wrote:
> Quoting Tushar Behera (2014-06-12 00:29:23)
>> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
>>> Quoting Tushar Behera (2014-06-10 22:32:17)
>>>> When the output clock of AUDSS mux is disabled, we are getting kernel
>>>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
>>>> user manual doesn't specify this dependency, we came across this issue
>>>> while disabling the parent of AUDSS mux clocks.
>>>
>>> Hi Tushar,
>>>
>>> Can you help me understand better what the actual problem is? What is
>>> the root cause of the kernel oops?
>>
>> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
>> As per observation, when the output of AUDSS mux is gated, we are not
>> able to do any operation on the clocks provided by MAU block (mostly
>> the clocks used by ADMA and audio blocks).
> 
> I tried to get a datasheet for Exynos 54xx but could not find it. I even
> looked at the public 5250 data sheet, but it is completely missing
> Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
> "Clock names and clock tree diagram of MAUDIO_BLK".
> 
> So without any clue about your hardware (not for lack of trying) I would
> guess that somewhere in the parent hierarchy you have an interface clock
> which must be enabled in order for you to touch the registers pertaining
> to the downstream audio clocks.
> 

Yes, right. As per observation, we need to keep the output of AUDSS mux
enabled to access the registers present in MAU block.

> The right way to handle this requires two steps:
> 
> 1) model your interface clock in the Linux clock framework if you
> haven't already (I assume it is a gate clock, or the child of a gate
> clock)
> 

The interface clock is already part of the clock framework.

> 2) the clk_ops callbacks for the affected audio clocks should wrap their
> operations (i.e. critical secion) with a clk_enable/clk_disable pair,
> where the clock being enables/disable is the interface clock mentioned
> above in #1
> 
> The CCF is reentrant, so you can do this by simply using the top-level
> clk.h API from within your clk_ops callbacks.
> 

Right now, the clocks are registered with clk_register_mux,
clk_register_div and clk_register_gate calls which in turn set
appropriate clk_ops callbacks. If I need to wrap the register access
during these clk_ops callbacks with clk_enable/clk_disable of interface
lock, I would have to reimplement the clk_ops callbacks in
clk-exynos-audss driver.

Is that the approach that you are suggesting?

> I might be totally wrong about the cause of the hang, but that's my best
> guess based on everyone's bug reports.
> 

There are 5 gate clocks within MAU block. While disabling the unused
clocks, if CLK_MAU_EPLL is disabled first, then we are getting this
system hang.


> Regards,
> Mike
> 
>>
>>>
>>> You mention calling clk_get on child clocks of the AUDSS mux fails, but
>>> I cannot imagine why. How can the enable/disable state of a clock affect
>>> the ability to clk_get other clocks?
>>>
>>
>> I might have a little vogue while updating the commit message
>> (mentioning about clk_get which surely is only a s/w operation), but
>> there is definitely some issue with handling those clocks under given
>> scenario.
>>
>> I am on leave till end of this week, so I will update you more with
>> the logs on Monday.
>>
>> Thanks,
>> --
>> Tushar
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


-- 
Tushar Behera

Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-07-10 23:18:54)
> On 06/13/2014 02:39 AM, Mike Turquette wrote:
> > Quoting Tushar Behera (2014-06-12 00:29:23)
> >> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> >>> Quoting Tushar Behera (2014-06-10 22:32:17)
> >>>> When the output clock of AUDSS mux is disabled, we are getting kernel
> >>>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> >>>> user manual doesn't specify this dependency, we came across this issue
> >>>> while disabling the parent of AUDSS mux clocks.
> >>>
> >>> Hi Tushar,
> >>>
> >>> Can you help me understand better what the actual problem is? What is
> >>> the root cause of the kernel oops?
> >>
> >> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
> >> As per observation, when the output of AUDSS mux is gated, we are not
> >> able to do any operation on the clocks provided by MAU block (mostly
> >> the clocks used by ADMA and audio blocks).
> > 
> > I tried to get a datasheet for Exynos 54xx but could not find it. I even
> > looked at the public 5250 data sheet, but it is completely missing
> > Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
> > "Clock names and clock tree diagram of MAUDIO_BLK".
> > 
> > So without any clue about your hardware (not for lack of trying) I would
> > guess that somewhere in the parent hierarchy you have an interface clock
> > which must be enabled in order for you to touch the registers pertaining
> > to the downstream audio clocks.
> > 
> 
> Yes, right. As per observation, we need to keep the output of AUDSS mux
> enabled to access the registers present in MAU block.
> 
> > The right way to handle this requires two steps:
> > 
> > 1) model your interface clock in the Linux clock framework if you
> > haven't already (I assume it is a gate clock, or the child of a gate
> > clock)
> > 
> 
> The interface clock is already part of the clock framework.

Great!

> 
> > 2) the clk_ops callbacks for the affected audio clocks should wrap their
> > operations (i.e. critical secion) with a clk_enable/clk_disable pair,
> > where the clock being enables/disable is the interface clock mentioned
> > above in #1
> > 
> > The CCF is reentrant, so you can do this by simply using the top-level
> > clk.h API from within your clk_ops callbacks.
> > 
> 
> Right now, the clocks are registered with clk_register_mux,
> clk_register_div and clk_register_gate calls which in turn set
> appropriate clk_ops callbacks. If I need to wrap the register access
> during these clk_ops callbacks with clk_enable/clk_disable of interface
> lock, I would have to reimplement the clk_ops callbacks in
> clk-exynos-audss driver.
> 
> Is that the approach that you are suggesting?

Is there another way? This is one of the reasons why I don't like the
basic clock types being subclassed by clock drivers. It's a brittle
design that tends to fall over as soon as the basic clock types don't do
what you need. And don't even get me started on how ugly clk-composite.c
is! ;-)

One hack you can do is to subclass the clk_ops for each of the basic
clock types you use and add .prepare and .unprepare callbacks to them
which enable/disable the interface clock. Some examples of this are
merged and it may be what your clock driver does already. However this
may not be very optimal if your consumer driver simply calls
clk_prepare_enable at probe-time and never turns the interface clock off
again...

> 
> > I might be totally wrong about the cause of the hang, but that's my best
> > guess based on everyone's bug reports.
> > 
> 
> There are 5 gate clocks within MAU block. While disabling the unused
> clocks, if CLK_MAU_EPLL is disabled first, then we are getting this
> system hang.

Right. Then your accesses to the clock control register need to be
protected by a clk_enable/clk_disable critical section.

Regards,
Mike

> 
> 
> > Regards,
> > Mike
> > 
> >>
> >>>
> >>> You mention calling clk_get on child clocks of the AUDSS mux fails, but
> >>> I cannot imagine why. How can the enable/disable state of a clock affect
> >>> the ability to clk_get other clocks?
> >>>
> >>
> >> I might have a little vogue while updating the commit message
> >> (mentioning about clk_get which surely is only a s/w operation), but
> >> there is definitely some issue with handling those clocks under given
> >> scenario.
> >>
> >> I am on leave till end of this week, so I will update you more with
> >> the logs on Monday.
> >>
> >> Thanks,
> >> --
> >> Tushar
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 
> 
> -- 
> Tushar Behera

[PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled

[Mike Turquette]

Quoting Tushar Behera (2014-07-10 23:18:54)
> On 06/13/2014 02:39 AM, Mike Turquette wrote:
> > Quoting Tushar Behera (2014-06-12 00:29:23)
> >> On Wed, Jun 11, 2014 at 10:20 PM, Mike Turquette <mturquette@linaro.org> wrote:
> >>> Quoting Tushar Behera (2014-06-10 22:32:17)
> >>>> When the output clock of AUDSS mux is disabled, we are getting kernel
> >>>> oops while doing a clk_get() on other clocks provided by AUDSS. Though
> >>>> user manual doesn't specify this dependency, we came across this issue
> >>>> while disabling the parent of AUDSS mux clocks.
> >>>
> >>> Hi Tushar,
> >>>
> >>> Can you help me understand better what the actual problem is? What is
> >>> the root cause of the kernel oops?
> >>
> >> Currently AUDSS mux has two parents, XXTI crystal and MAU_EPLL clock.
> >> As per observation, when the output of AUDSS mux is gated, we are not
> >> able to do any operation on the clocks provided by MAU block (mostly
> >> the clocks used by ADMA and audio blocks).
> > 
> > I tried to get a datasheet for Exynos 54xx but could not find it. I even
> > looked at the public 5250 data sheet, but it is completely missing
> > Chapter 34, "Audio Subsystem", which apparently contains Figure 34-3,
> > "Clock names and clock tree diagram of MAUDIO_BLK".
> > 
> > So without any clue about your hardware (not for lack of trying) I would
> > guess that somewhere in the parent hierarchy you have an interface clock
> > which must be enabled in order for you to touch the registers pertaining
> > to the downstream audio clocks.
> > 
> 
> Yes, right. As per observation, we need to keep the output of AUDSS mux
> enabled to access the registers present in MAU block.
> 
> > The right way to handle this requires two steps:
> > 
> > 1) model your interface clock in the Linux clock framework if you
> > haven't already (I assume it is a gate clock, or the child of a gate
> > clock)
> > 
> 
> The interface clock is already part of the clock framework.

Great!

> 
> > 2) the clk_ops callbacks for the affected audio clocks should wrap their
> > operations (i.e. critical secion) with a clk_enable/clk_disable pair,
> > where the clock being enables/disable is the interface clock mentioned
> > above in #1
> > 
> > The CCF is reentrant, so you can do this by simply using the top-level
> > clk.h API from within your clk_ops callbacks.
> > 
> 
> Right now, the clocks are registered with clk_register_mux,
> clk_register_div and clk_register_gate calls which in turn set
> appropriate clk_ops callbacks. If I need to wrap the register access
> during these clk_ops callbacks with clk_enable/clk_disable of interface
> lock, I would have to reimplement the clk_ops callbacks in
> clk-exynos-audss driver.
> 
> Is that the approach that you are suggesting?

Is there another way? This is one of the reasons why I don't like the
basic clock types being subclassed by clock drivers. It's a brittle
design that tends to fall over as soon as the basic clock types don't do
what you need. And don't even get me started on how ugly clk-composite.c
is! ;-)

One hack you can do is to subclass the clk_ops for each of the basic
clock types you use and add .prepare and .unprepare callbacks to them
which enable/disable the interface clock. Some examples of this are
merged and it may be what your clock driver does already. However this
may not be very optimal if your consumer driver simply calls
clk_prepare_enable at probe-time and never turns the interface clock off
again...

> 
> > I might be totally wrong about the cause of the hang, but that's my best
> > guess based on everyone's bug reports.
> > 
> 
> There are 5 gate clocks within MAU block. While disabling the unused
> clocks, if CLK_MAU_EPLL is disabled first, then we are getting this
> system hang.

Right. Then your accesses to the clock control register need to be
protected by a clk_enable/clk_disable critical section.

Regards,
Mike

> 
> 
> > Regards,
> > Mike
> > 
> >>
> >>>
> >>> You mention calling clk_get on child clocks of the AUDSS mux fails, but
> >>> I cannot imagine why. How can the enable/disable state of a clock affect
> >>> the ability to clk_get other clocks?
> >>>
> >>
> >> I might have a little vogue while updating the commit message
> >> (mentioning about clk_get which surely is only a s/w operation), but
> >> there is definitely some issue with handling those clocks under given
> >> scenario.
> >>
> >> I am on leave till end of this week, so I will update you more with
> >> the logs on Monday.
> >>
> >> Thanks,
> >> --
> >> Tushar
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 
> 
> -- 
> Tushar Behera