[PATCH v2 0/6] Enable HDMI support on Exynos platforms

[PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Marek Szyprowski]

Hi all,

This is yet another approach to submit patches, which enables HDMI
support for two Exynos based platforms: UniversalC210 and Odroid X2/U3.

Beside DTS changes, this patchset adds parent domain support for Exynos
PM domains. This was the most controversial patch in the previous
attempts, but I hope I fixes all reported issues and made it really
generic. For more details see individual patches.

The patchset is based on my previous patch:
'ARM: DTS: Exynos: convert to generic power domain bindings'
(http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
and requires 2 patches that have been merged to v3.19-rc4:
'clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi'
(commit df019a5c0f7083001cb694f44821ca506425bda2) and
'PM / Domains: Export of_genpd_get_from_provider function'
(commit 7496fcbe8a643097efc061160e1c3b65ee2fa350).

Regards
Marek Szyprowski

Change log:

v2:
- rewrote subdomains patch according to suggestions from Geert
  Uytterhoeven and Amit Daniel Kachhap.

v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html)
- added handling of generic 'power-domains' binding in subdomains

v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html)
- resolved power domain on/off issue with 'clk: samsung: exynos4: set
  parent of mixer gate clock to hdmi' patch

v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html)
- first attempt, used 'always on' power domains hack


Andrzej Hajda (1):
  ARM: dts: exynos5250: add display power domain

Marek Szyprowski (4):
  ARM: Exynos: add support for sub-power domains
  ARM: dts: exynos4: add hdmi related nodes
  ARM: dts: exynos4: add dependency between TV and LCD0 power domains
  ARM: dts: exynos4412-odroid: enable hdmi support

Tomasz Stanislawski (1):
  ARM: dts: exynos4210-universal_c210: enable hdmi support

 .../bindings/arm/exynos/power_domain.txt           |  2 +
 arch/arm/boot/dts/exynos4.dtsi                     | 41 ++++++++++++++++
 arch/arm/boot/dts/exynos4210-universal_c210.dts    | 57 ++++++++++++++++++++++
 arch/arm/boot/dts/exynos4210.dtsi                  |  8 +++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi    | 44 +++++++++++++++++
 arch/arm/boot/dts/exynos4x12.dtsi                  | 11 +++++
 arch/arm/boot/dts/exynos5250.dtsi                  | 10 ++++
 arch/arm/mach-exynos/pm_domains.c                  | 28 +++++++++++
 8 files changed, 201 insertions(+)

-- 
1.9.2

[PATCH v2 1/6] ARM: Exynos: add support for sub-power domains

[Marek Szyprowski]

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences for devices
like TV Mixer or Camera ISP, which needs to have more than one power
domain enabled to be operational.

Based on previous work by Amit Daniel Kachhap <amit.daniel@samsung.com>.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 .../bindings/arm/exynos/power_domain.txt           |  2 ++
 arch/arm/mach-exynos/pm_domains.c                  | 28 ++++++++++++++++++++++
 2 files changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index f4445e5..28918a9 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,8 @@ Optional Properties:
 	- pclkN, clkN: Pairs of parent of input clock and input clock to the
 		devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
 		are supported currently.
+- power-domains: generic power domain binding pointing to a master power domain
+		 that the given domain is a part of
 
 Node of a device using power domains must have a power-domains property
 defined with a phandle to respective power domain.
diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..37266a8 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -161,6 +161,34 @@ no_clk:
 		of_genpd_add_provider_simple(np, &pd->pd);
 	}
 
+	/* Assign the child power domains to their parents */
+	for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
+		struct generic_pm_domain *child_domain, *parent_domain;
+		struct of_phandle_args args;
+
+		args.np = np;
+		args.args_count = 0;
+		child_domain = of_genpd_get_from_provider(&args);
+		if (!child_domain)
+			continue;
+
+		if (of_parse_phandle_with_args(np, "power-domains",
+					 "#power-domain-cells", 0, &args) != 0)
+			continue;
+
+		parent_domain = of_genpd_get_from_provider(&args);
+		if (!parent_domain)
+			continue;
+
+		if (pm_genpd_add_subdomain(parent_domain, child_domain))
+			pr_warn("%s failed to add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+		else
+			pr_info("%s has as child subdomain: %s.\n",
+				parent_domain->name, child_domain->name);
+		of_node_put(np);
+	}
+
 	return 0;
 }
 arch_initcall(exynos4_pm_init_power_domain);
-- 
1.9.2

Re: [PATCH v2 1/6] ARM: Exynos: add support for sub-power domains

[Ulf Hansson]

On 13 January 2015 at 10:39, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences for devices
> like TV Mixer or Camera ISP, which needs to have more than one power
> domain enabled to be operational.
>
> Based on previous work by Amit Daniel Kachhap <amit.daniel@samsung.com>.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  .../bindings/arm/exynos/power_domain.txt           |  2 ++
>  arch/arm/mach-exynos/pm_domains.c                  | 28 ++++++++++++++++++++++
>  2 files changed, 30 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index f4445e5..28918a9 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -22,6 +22,8 @@ Optional Properties:
>         - pclkN, clkN: Pairs of parent of input clock and input clock to the
>                 devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>                 are supported currently.
> +- power-domains: generic power domain binding pointing to a master power domain
> +                that the given domain is a part of

I would prefer this to be documented as a generic way to configure
power domain parents, in
Documentation/devicetree/bindings/power/power_domain.txt.

>
>  Node of a device using power domains must have a power-domains property
>  defined with a phandle to respective power domain.
> diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
> index 20f2671..37266a8 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -161,6 +161,34 @@ no_clk:
>                 of_genpd_add_provider_simple(np, &pd->pd);
>         }
>
> +       /* Assign the child power domains to their parents */
> +       for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
> +               struct generic_pm_domain *child_domain, *parent_domain;
> +               struct of_phandle_args args;
> +
> +               args.np = np;
> +               args.args_count = 0;
> +               child_domain = of_genpd_get_from_provider(&args);
> +               if (!child_domain)
> +                       continue;
> +
> +               if (of_parse_phandle_with_args(np, "power-domains",
> +                                        "#power-domain-cells", 0, &args) != 0)
> +                       continue;
> +
> +               parent_domain = of_genpd_get_from_provider(&args);
> +               if (!parent_domain)
> +                       continue;
> +
> +               if (pm_genpd_add_subdomain(parent_domain, child_domain))
> +                       pr_warn("%s failed to add subdomain: %s\n",
> +                               parent_domain->name, child_domain->name);
> +               else
> +                       pr_info("%s has as child subdomain: %s.\n",
> +                               parent_domain->name, child_domain->name);
> +               of_node_put(np);
> +       }

How do you maintain the order of how domains are being initialized?
For example, don't you need to initialize all "parents" prior their
children?

> +
>         return 0;
>  }
>  arch_initcall(exynos4_pm_init_power_domain);
> --
> 1.9.2
>

I noticed this patch wasn't sent to linux-arm, I guess it should?

Kind regards
Uffe

Re: [PATCH v2 1/6] ARM: Exynos: add support for sub-power domains

[Marek Szyprowski]

Hello,

On 2015-01-13 11:44, Ulf Hansson wrote:
> On 13 January 2015 at 10:39, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> This patch adds support for making one power domain a sub-domain of
>> other domain. This is useful for modeling power dependences for devices
>> like TV Mixer or Camera ISP, which needs to have more than one power
>> domain enabled to be operational.
>>
>> Based on previous work by Amit Daniel Kachhap <amit.daniel@samsung.com>.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>>   .../bindings/arm/exynos/power_domain.txt           |  2 ++
>>   arch/arm/mach-exynos/pm_domains.c                  | 28 ++++++++++++++++++++++
>>   2 files changed, 30 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> index f4445e5..28918a9 100644
>> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>> @@ -22,6 +22,8 @@ Optional Properties:
>>          - pclkN, clkN: Pairs of parent of input clock and input clock to the
>>                  devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
>>                  are supported currently.
>> +- power-domains: generic power domain binding pointing to a master power domain
>> +                that the given domain is a part of
> I would prefer this to be documented as a generic way to configure
> power domain parents, in
> Documentation/devicetree/bindings/power/power_domain.txt.

Well, right now it is a specific feature of exynos power domains, 
however if you
want I can add a note in 
Documentation/devicetree/bindings/power/power_domain.txt
on defining child-parent relation. However it will be still up to the 
power domain
providers to implement support for it.

>>   Node of a device using power domains must have a power-domains property
>>   defined with a phandle to respective power domain.
>> diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
>> index 20f2671..37266a8 100644
>> --- a/arch/arm/mach-exynos/pm_domains.c
>> +++ b/arch/arm/mach-exynos/pm_domains.c
>> @@ -161,6 +161,34 @@ no_clk:
>>                  of_genpd_add_provider_simple(np, &pd->pd);
>>          }
>>
>> +       /* Assign the child power domains to their parents */
>> +       for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
>> +               struct generic_pm_domain *child_domain, *parent_domain;
>> +               struct of_phandle_args args;
>> +
>> +               args.np = np;
>> +               args.args_count = 0;
>> +               child_domain = of_genpd_get_from_provider(&args);
>> +               if (!child_domain)
>> +                       continue;
>> +
>> +               if (of_parse_phandle_with_args(np, "power-domains",
>> +                                        "#power-domain-cells", 0, &args) != 0)
>> +                       continue;
>> +
>> +               parent_domain = of_genpd_get_from_provider(&args);
>> +               if (!parent_domain)
>> +                       continue;
>> +
>> +               if (pm_genpd_add_subdomain(parent_domain, child_domain))
>> +                       pr_warn("%s failed to add subdomain: %s\n",
>> +                               parent_domain->name, child_domain->name);
>> +               else
>> +                       pr_info("%s has as child subdomain: %s.\n",
>> +                               parent_domain->name, child_domain->name);
>> +               of_node_put(np);
>> +       }
> How do you maintain the order of how domains are being initialized?
> For example, don't you need to initialize all "parents" prior their
> children?

All power domains, which have been added to the system were already 
initialized in
the previous loop (executed before the added code). Once all 
'exynos4210-pd' gets
initialized, they are scanned for child-parent relation.

>
>> +
>>          return 0;
>>   }
>>   arch_initcall(exynos4_pm_init_power_domain);
>> --
>> 1.9.2
>>
> I noticed this patch wasn't sent to linux-arm, I guess it should?

Yes, I forgot about that. I will add it in the next version.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 1/6] ARM: Exynos: add support for sub-power domains

[Ulf Hansson]

On 13 January 2015 at 11:53, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Hello,
>
>
> On 2015-01-13 11:44, Ulf Hansson wrote:
>>
>> On 13 January 2015 at 10:39, Marek Szyprowski <m.szyprowski@samsung.com>
>> wrote:
>>>
>>> This patch adds support for making one power domain a sub-domain of
>>> other domain. This is useful for modeling power dependences for devices
>>> like TV Mixer or Camera ISP, which needs to have more than one power
>>> domain enabled to be operational.
>>>
>>> Based on previous work by Amit Daniel Kachhap <amit.daniel@samsung.com>.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>> ---
>>>   .../bindings/arm/exynos/power_domain.txt           |  2 ++
>>>   arch/arm/mach-exynos/pm_domains.c                  | 28
>>> ++++++++++++++++++++++
>>>   2 files changed, 30 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> index f4445e5..28918a9 100644
>>> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
>>> @@ -22,6 +22,8 @@ Optional Properties:
>>>          - pclkN, clkN: Pairs of parent of input clock and input clock to
>>> the
>>>                  devices in this power domain. Maximum of 4 pairs (N = 0
>>> to 3)
>>>                  are supported currently.
>>> +- power-domains: generic power domain binding pointing to a master power
>>> domain
>>> +                that the given domain is a part of
>>
>> I would prefer this to be documented as a generic way to configure
>> power domain parents, in
>> Documentation/devicetree/bindings/power/power_domain.txt.
>
>
> Well, right now it is a specific feature of exynos power domains, however if
> you
> want I can add a note in
> Documentation/devicetree/bindings/power/power_domain.txt
> on defining child-parent relation. However it will be still up to the power
> domain
> providers to implement support for it.

We don't want one solution per provider to describe child-parent
relations of PM domains in DT, that why I think it's important that we
document this in
Documentation/devicetree/bindings/power/power_domain.txt

Kind regards
Uffe

[PATCH v2 2/6] ARM: dts: exynos4: add hdmi related nodes

[Marek Szyprowski]

This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi    | 40 +++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos4210.dtsi |  8 ++++++++
 arch/arm/boot/dts/exynos4x12.dtsi | 11 +++++++++++
 3 files changed, 59 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c5dc2ef..d951647 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,7 @@
 		i2c5 = &i2c_5;
 		i2c6 = &i2c_6;
 		i2c7 = &i2c_7;
+		i2c8 = &i2c_8;
 		csis0 = &csis_0;
 		csis1 = &csis_1;
 		fimc0 = &fimc_0;
@@ -544,6 +545,22 @@
 		status = "disabled";
 	};
 
+	i2c_8: i2c@138E0000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "samsung,s3c2440-hdmiphy-i2c";
+		reg = <0x138E0000 0x100>;
+		interrupts = <0 93 0>;
+		clocks = <&clock CLK_I2C_HDMI>;
+		clock-names = "i2c";
+		status = "disabled";
+
+		hdmi_i2c_phy: hdmiphy@38 {
+			compatible = "exynos4210-hdmiphy";
+			reg = <0x38>;
+		};
+	};
+
 	spi_0: spi@13920000 {
 		compatible = "samsung,exynos4210-spi";
 		reg = <0x13920000 0x100>;
@@ -652,4 +669,27 @@
 		samsung,sysreg = <&sys_reg>;
 		status = "disabled";
 	};
+
+	hdmi: hdmi@12D00000 {
+		compatible = "samsung,exynos4210-hdmi";
+		reg = <0x12D00000 0x70000>;
+		interrupts = <0 92 0>;
+		clock-names = "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy",
+			"mout_hdmi";
+		clocks = <&clock CLK_HDMI>, <&clock CLK_SCLK_HDMI>,
+			<&clock CLK_SCLK_PIXEL>, <&clock CLK_SCLK_HDMIPHY>,
+			<&clock CLK_MOUT_HDMI>;
+		phy = <&hdmi_i2c_phy>;
+		power-domains = <&pd_tv>;
+		samsung,syscon-phandle = <&pmu_system_controller>;
+		status = "disabled";
+	};
+
+	mixer: mixer@12C10000 {
+		compatible = "samsung,exynos4210-mixer";
+		interrupts = <0 91 0>;
+		reg = <0x12C10000 0x2100>, <0x12c00000 0x300>;
+		power-domains = <&pd_tv>;
+		status = "disabled";
+	};
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 6728aaa..fc17cdf 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -193,4 +193,12 @@
 			samsung,lcd-wb;
 		};
 	};
+
+	mixer: mixer@12C10000 {
+		clock-names = "mixer", "sclk_hdmi", "vp", "mout_mixer",
+			"sclk_mixer";
+		clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>,
+			<&clock CLK_VP>, <&clock CLK_MOUT_MIXER>,
+			<&clock CLK_SCLK_MIXER>;
+	};
 };
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index da8734e..e577bd0 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -283,4 +283,15 @@
 		clock-names = "tmu_apbif";
 		status = "disabled";
 	};
+
+	hdmi: hdmi@12D00000 {
+		compatible = "samsung,exynos4212-hdmi";
+	};
+
+	mixer: mixer@12C10000 {
+		compatible = "samsung,exynos4212-mixer";
+		clock-names = "mixer", "sclk_hdmi", "vp";
+		clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>,
+			<&clock CLK_VP>;
+	};
 };
-- 
1.9.2

[PATCH v2 3/6] ARM: dts: exynos4: add dependency between TV and LCD0 power domains

[Marek Szyprowski]

TV Mixer needs both TV and LCD0 domains enabled to be fully operational.
This dependency is modelled by making TV power domains a sub-domain of
LCD0 power domain.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos4.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d951647..a59b3fae 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -101,6 +101,7 @@
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10023C20 0x20>;
 		#power-domain-cells = <0>;
+		power-domains = <&pd_lcd0>;
 	};
 
 	pd_cam: cam-power-domain@10023C00 {
-- 
1.9.2

[PATCH v2 4/6] ARM: dts: exynos4412-odroid: enable hdmi support

[Marek Szyprowski]

This patch adds nodes specific to Exynos4412 based Odroid X/X2/U2/U3
boards required for enabling HDMI display.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 44 +++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 3fbf588..e10efa8 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -231,6 +231,20 @@
 					regulator-always-on;
 				};
 
+				ldo8_reg: ldo@8 {
+					regulator-compatible = "LDO8";
+					regulator-name = "VDD10_HDMI_1.0V";
+					regulator-min-microvolt = <1000000>;
+					regulator-max-microvolt = <1000000>;
+				};
+
+				ldo10_reg: ldo@10 {
+					regulator-compatible = "LDO10";
+					regulator-name = "VDDQ_MIPIHSI_1.8V";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <1800000>;
+				};
+
 				ldo11_reg: LDO11 {
 					regulator-name = "VDD18_ABB1_1.8V";
 					regulator-min-microvolt = <1800000>;
@@ -389,6 +403,31 @@
 	ehci: ehci@12580000 {
 		status = "okay";
 	};
+
+	mixer: mixer@12C10000 {
+		status = "okay";
+	};
+
+	hdmi@12D00000 {
+		hpd-gpio = <&gpx3 7 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmi_hpd>;
+		vdd-supply = <&ldo8_reg>;
+		vdd_osc-supply = <&ldo10_reg>;
+		vdd_pll-supply = <&ldo8_reg>;
+		ddc = <&hdmi_ddc>;
+		status = "okay";
+	};
+
+	hdmi_ddc: i2c@13880000 {
+		status = "okay";
+		pinctrl-names = "default";
+		pinctrl-0 = <&i2c2_bus>;
+	};
+
+	i2c@138E0000 {
+		status = "okay";
+	};
 };
 
 &pinctrl_1 {
@@ -403,4 +442,9 @@
 		samsung,pin-pud = <0>;
 		samsung,pin-drv = <0>;
 	};
+
+	hdmi_hpd: hdmi-hpd {
+		samsung,pins = "gpx3-7";
+		samsung,pin-pud = <1>;
+	};
 };
-- 
1.9.2

[PATCH v2 5/6] ARM: dts: exynos4210-universal_c210: enable hdmi support

[Marek Szyprowski]

From: Tomasz Stanislawski <t.stanislaws@samsung.com>

This patch adds configuration of hw modules required to enable HDMI
support on Universal C210 board.

Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 57 +++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index aaf0cae..01f7d3c 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -503,6 +503,63 @@
 			assigned-clock-rates = <0>, <160000000>;
 		};
 	};
+
+	hdmi_en: voltage-regulator-hdmi-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "HDMI_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpe0 1 0>;
+		enable-active-high;
+	};
+
+	hdmi_ddc: i2c-ddc {
+		compatible = "i2c-gpio";
+		gpios = <&gpe4 2 0 &gpe4 3 0>;
+		i2c-gpio,delay-us = <100>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		pinctrl-0 = <&i2c_ddc_bus>;
+		pinctrl-names = "default";
+		status = "okay";
+	};
+
+	mixer@12C10000 {
+		status = "okay";
+	};
+
+	hdmi@12D00000 {
+		hpd-gpio = <&gpx3 7 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmi_hpd>;
+		hdmi-en-supply = <&hdmi_en>;
+		vdd-supply = <&ldo3_reg>;
+		vdd_osc-supply = <&ldo4_reg>;
+		vdd_pll-supply = <&ldo3_reg>;
+		ddc = <&hdmi_ddc>;
+		status = "okay";
+	};
+
+	i2c@138E0000 {
+		status = "okay";
+	};
+};
+
+&pinctrl_1 {
+	hdmi_hpd: hdmi-hpd {
+		samsung,pins = "gpx3-7";
+		samsung,pin-pud = <0>;
+	};
+};
+
+&pinctrl_0 {
+	i2c_ddc_bus: i2c-ddc-bus {
+		samsung,pins = "gpe4-2", "gpe4-3";
+		samsung,pin-function = <2>;
+		samsung,pin-pud = <3>;
+		samsung,pin-drv = <0>;
+	};
 };
 
 &mdma1 {
-- 
1.9.2

[PATCH v2 6/6] ARM: dts: exynos5250: add display power domain

[Marek Szyprowski]

From: Andrzej Hajda <a.hajda@samsung.com>

The patch adds domain definition and references to it in appropriate devices.

Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
[mszyprow: rebased onto generic power domains dt bindings]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 2b5a62c..cf4a6ec 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -102,6 +102,12 @@
 		#power-domain-cells = <0>;
 	};
 
+	pd_disp1: disp1-power-domain@100440A0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x100440A0 0x20>;
+		#power-domain-cells = <0>;
+	};
+
 	clock: clock-controller@10010000 {
 		compatible = "samsung,exynos5250-clock";
 		reg = <0x10010000 0x30000>;
@@ -719,6 +725,7 @@
 	hdmi: hdmi {
 		compatible = "samsung,exynos4212-hdmi";
 		reg = <0x14530000 0x70000>;
+		power-domains = <&pd_disp1>;
 		interrupts = <0 95 0>;
 		clocks = <&clock CLK_HDMI>, <&clock CLK_SCLK_HDMI>,
 			 <&clock CLK_SCLK_PIXEL>, <&clock CLK_SCLK_HDMIPHY>,
@@ -731,6 +738,7 @@
 	mixer {
 		compatible = "samsung,exynos5250-mixer";
 		reg = <0x14450000 0x10000>;
+		power-domains = <&pd_disp1>;
 		interrupts = <0 94 0>;
 		clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
 		clock-names = "mixer", "sclk_hdmi";
@@ -743,6 +751,7 @@
 	};
 
 	dp: dp-controller@145B0000 {
+		power-domains = <&pd_disp1>;
 		clocks = <&clock CLK_DP>;
 		clock-names = "dp";
 		phys = <&dp_phy>;
@@ -750,6 +759,7 @@
 	};
 
 	fimd: fimd@14400000 {
+		power-domains = <&pd_disp1>;
 		clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
 		clock-names = "sclk_fimd", "fimd";
 	};
-- 
1.9.2

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Hello,

I've applied v6 of the HDMI patchset (together with the patches the set
depends on) onto torvalds/master, but I'm seeing a lot of warnings
(coming from __clk_{unprepare,disable}) that seem to originate from the
fimc subsystem.

Since the patchset also changes PM domain handling (which shows up in
the log as well), I was wondering if this is related?

Full boot log here:
http://www.math.uni-bielefeld.de/~tjakobi/archive/clk_warnings.txt

That's the tree I'm currently using:
https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.19.y
(maybe I'm missing something here?)


With best wishes,
Tobias

PS: This is on a ODROID-X2.


Marek Szyprowski wrote:
> Hi all,
> 
> This is yet another approach to submit patches, which enables HDMI
> support for two Exynos based platforms: UniversalC210 and Odroid X2/U3.
> 
> Beside DTS changes, this patchset adds parent domain support for Exynos
> PM domains. This was the most controversial patch in the previous
> attempts, but I hope I fixes all reported issues and made it really
> generic. For more details see individual patches.
> 
> The patchset is based on my previous patch:
> 'ARM: DTS: Exynos: convert to generic power domain bindings'
> (http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
> and requires 2 patches that have been merged to v3.19-rc4:
> 'clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi'
> (commit df019a5c0f7083001cb694f44821ca506425bda2) and
> 'PM / Domains: Export of_genpd_get_from_provider function'
> (commit 7496fcbe8a643097efc061160e1c3b65ee2fa350).
> 
> Regards
> Marek Szyprowski
> 
> Change log:
> 
> v2:
> - rewrote subdomains patch according to suggestions from Geert
>   Uytterhoeven and Amit Daniel Kachhap.
> 
> v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html)
> - added handling of generic 'power-domains' binding in subdomains
> 
> v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html)
> - resolved power domain on/off issue with 'clk: samsung: exynos4: set
>   parent of mixer gate clock to hdmi' patch
> 
> v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html)
> - first attempt, used 'always on' power domains hack
> 
> 
> Andrzej Hajda (1):
>   ARM: dts: exynos5250: add display power domain
> 
> Marek Szyprowski (4):
>   ARM: Exynos: add support for sub-power domains
>   ARM: dts: exynos4: add hdmi related nodes
>   ARM: dts: exynos4: add dependency between TV and LCD0 power domains
>   ARM: dts: exynos4412-odroid: enable hdmi support
> 
> Tomasz Stanislawski (1):
>   ARM: dts: exynos4210-universal_c210: enable hdmi support
> 
>  .../bindings/arm/exynos/power_domain.txt           |  2 +
>  arch/arm/boot/dts/exynos4.dtsi                     | 41 ++++++++++++++++
>  arch/arm/boot/dts/exynos4210-universal_c210.dts    | 57 ++++++++++++++++++++++
>  arch/arm/boot/dts/exynos4210.dtsi                  |  8 +++
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi    | 44 +++++++++++++++++
>  arch/arm/boot/dts/exynos4x12.dtsi                  | 11 +++++
>  arch/arm/boot/dts/exynos5250.dtsi                  | 10 ++++
>  arch/arm/mach-exynos/pm_domains.c                  | 28 +++++++++++
>  8 files changed, 201 insertions(+)
> 

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Marek Szyprowski]

Hello,

On 2015-01-14 16:25, Tobias Jakobi wrote:
> Hello,
>
> I've applied v6 of the HDMI patchset (together with the patches the set
> depends on) onto torvalds/master, but I'm seeing a lot of warnings
> (coming from __clk_{unprepare,disable}) that seem to originate from the
> fimc subsystem.
>
> Since the patchset also changes PM domain handling (which shows up in
> the log as well), I was wondering if this is related?
>
> Full boot log here:
> http://www.math.uni-bielefeld.de/~tjakobi/archive/clk_warnings.txt
>
> That's the tree I'm currently using:
> https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.19.y
> (maybe I'm missing something here?)
>
>
> With best wishes,
> Tobias
>
> PS: This is on a ODROID-X2.

The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
be handled separately. For the time being simply please disable Exynos IPP
(or Exynos DRM FIMC) feature in your kernel configuration.

I hope that HDMI display works fine for you.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Marek Szyprowski wrote: This is on a ODROID-X2.
> 
> The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
> be handled separately. For the time being simply please disable Exynos IPP
> (or Exynos DRM FIMC) feature in your kernel configuration.
> 
> I hope that HDMI display works fine for you.
> 
> Best regards

OK, I'll check without FIMC again later this day, but what about the
warning (?) from the mixer:
exynos-mixer 12c10000.mixer: Unbalanced pm_runtime_enable!

Should this go away as well, when I disable the FIMC?

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Marek Szyprowski]

Hello,

On 2015-01-15 11:10, Tobias Jakobi wrote:
> Marek Szyprowski wrote: This is on a ODROID-X2.
>> The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
>> be handled separately. For the time being simply please disable Exynos IPP
>> (or Exynos DRM FIMC) feature in your kernel configuration.
>>
>> I hope that HDMI display works fine for you.
> OK, I'll check without FIMC again later this day, but what about the
> warning (?) from the mixer:
> exynos-mixer 12c10000.mixer: Unbalanced pm_runtime_enable!
>
> Should this go away as well, when I disable the FIMC?

Well, I also got this warning. It looks that pm_runtime in Exynos DRM 
got changed
recently and the bug is somewhere there. We will also check this issue.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Joonyoung Shim]

+Cc Inki Dae.

Hi,

On 01/15/2015 07:26 PM, Marek Szyprowski wrote:
> Hello,
> 
> On 2015-01-15 11:10, Tobias Jakobi wrote:
>> Marek Szyprowski wrote: This is on a ODROID-X2.
>>> The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
>>> be handled separately. For the time being simply please disable Exynos IPP
>>> (or Exynos DRM FIMC) feature in your kernel configuration.
>>>
>>> I hope that HDMI display works fine for you.
>> OK, I'll check without FIMC again later this day, but what about the
>> warning (?) from the mixer:
>> exynos-mixer 12c10000.mixer: Unbalanced pm_runtime_enable!
>>
>> Should this go away as well, when I disable the FIMC?
> 
> Well, I also got this warning. It looks that pm_runtime in Exynos DRM got changed
> recently and the bug is somewhere there. We will also check this issue.
> 

I posted a patch to fix it already.

http://www.spinics.net/lists/dri-devel/msg75039.html

Thanks.

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

On 2015-01-15 11:41, Joonyoung Shim wrote:
> I posted a patch to fix it already.
> 
> http://www.spinics.net/lists/dri-devel/msg75039.html
> 
> Thanks.

Thanks for heads up, I can confirm that applying the patch removes the 
warning from the mixer.

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Hello!

On 2015-01-15 11:06, Marek Szyprowski wrote:
> The issues with FIMC / DRM FIMC are not related to HDMI patches. They 
> will
> be handled separately. For the time being simply please disable Exynos 
> IPP
> (or Exynos DRM FIMC) feature in your kernel configuration.
Confirming that disabling the IPP removes the __clk_{unprepare,disable} 
warnings.

> I hope that HDMI display works fine for you.
I haven't got a HDMI display here atm, testing later!

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Hello!

Marek Szyprowski wrote:
> I hope that HDMI display works fine for you.
I checked with my panel just now and played around a bit with the DRM
(opening, vsync, etc.). However on deinitialization the entire system
locked up. I currently haven't hooked the board up to the serial
console, otherwise I would've tried to extract some more meaningful
information.

Going to check again more thoroughly on the weekend what exactly
triggers the lockup.

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Hello,

so OK, this doesn't look too good.

Tobias Jakobi wrote:
> I checked with my panel just now and played around a bit with the DRM
> (opening, vsync, etc.). However on deinitialization the entire system
> locked up. I currently haven't hooked the board up to the serial
> console, otherwise I would've tried to extract some more meaningful
> information.
> 
> Going to check again more thoroughly on the weekend what exactly
> triggers the lockup.

So, first of all I did my initial test with the exynos video backend of
RetroArch. But it turns out that there's no fancy application needed. I
now tested this with the 'modetest' application from libdrm, and did this:

./modetest -M exynos -s 16@13:1920x1080
setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480
setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
^C
./modetest -M exynos -s 16@13:640x480

The board instantly died then. No kernel log output from the serial
console, the heartbeat just stops and the board is dead. Need to
power-cycle to get it running again.

I'm unsure how to triage this at all.

@Marek: Could you check if this also happens for you?

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Tobias Jakobi wrote:
> Hello,
> 
> so OK, this doesn't look too good.
> 
> Tobias Jakobi wrote:
>> I checked with my panel just now and played around a bit with the DRM
>> (opening, vsync, etc.). However on deinitialization the entire system
>> locked up. I currently haven't hooked the board up to the serial
>> console, otherwise I would've tried to extract some more meaningful
>> information.
>>
>> Going to check again more thoroughly on the weekend what exactly
>> triggers the lockup.
> 
> So, first of all I did my initial test with the exynos video backend of
> RetroArch. But it turns out that there's no fancy application needed. I
> now tested this with the 'modetest' application from libdrm, and did this:
> 
> ./modetest -M exynos -s 16@13:1920x1080
> setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
> 
> The board instantly died then. No kernel log output from the serial
> console, the heartbeat just stops and the board is dead. Need to
> power-cycle to get it running again.
> 
> I'm unsure how to triage this at all.
> 
> @Marek: Could you check if this also happens for you?

In addition to the simple 'set mode' test, I also tried the 'vsync page
flip' one:

./modetest -M exynos -v -s 16@13:1280x720

While I haven't managed to lock up the system that way (I didn't try to
repeatedly kill and start this test), I managed to produce kernel
warnings that way.

Relevant parts here:
[  108.173644] lcd0-power-domain: Power-on latency exceeded, new value
364958 ns
[  108.174010] tv-power-domain: Power-on latency exceeded, new value
350083 ns
[  192.632246] lcd0-power-domain: Power-on latency exceeded, new value
419499 ns
[  192.632695] tv-power-domain: Power-on latency exceeded, new value
408167 ns
[  195.257343] ------------[ cut here ]------------
[  195.257379] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072
drm_vblank_put+0xd8/0xf0()
[  195.257385] Modules linked in: bridge stp llc bnep btrfs xor xor_neon
zlib_inflate zlib_deflate raid6_pq ecb btusb bluetooth usb_storage
[  195.257429] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc4+ #3
[  195.257435] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[  195.257440] Backtrace:
[  195.257462] [<c001212c>] (dump_backtrace) from [<c0012344>]
(show_stack+0x18/0x1c)
[  195.257468]  r6:c0595c30 r5:00000000 r4:c063ba90 r3:00000000
[  195.257494] [<c001232c>] (show_stack) from [<c048f8f8>]
(dump_stack+0x98/0xd8)
[  195.257507] [<c048f860>] (dump_stack) from [<c0028f9c>]
(warn_slowpath_common+0x88/0xb8)
[  195.257512]  r5:00000430 r4:00000000
[  195.257525] [<c0028f14>] (warn_slowpath_common) from [<c0029070>]
(warn_slowpath_null+0x24/0x2c)
[  195.257530]  r8:00200200 r7:ee3a9c00 r6:00000000 r5:ed89e380 r4:ed89e380
[  195.257552] [<c002904c>] (warn_slowpath_null) from [<c0268fac>]
(drm_vblank_put+0xd8/0xf0)
[  195.257570] [<c0268ed4>] (drm_vblank_put) from [<c028156c>]
(exynos_drm_crtc_finish_pageflip+0xc0/0xf0)
[  195.257586] [<c02814ac>] (exynos_drm_crtc_finish_pageflip) from
[<c0290358>] (mixer_irq_handler+0xdc/0x104)
[  195.257591]  r10:c06527ee r9:ee1e26c0 r8:00000041 r7:00000801
r6:ed804e68 r5:00000801
[  195.257607]  r4:ed804e10
[  195.257622] [<c029027c>] (mixer_irq_handler) from [<c00610b0>]
(handle_irq_event_percpu+0x3c/0x138)
[  195.257627]  r7:00000000 r6:00000000 r5:ee1e2720 r4:ed89e9c0
[  195.257644] [<c0061074>] (handle_irq_event_percpu) from [<c00611f0>]
(handle_irq_event+0x44/0x64)
[  195.257649]  r10:00000000 r9:f0020000 r8:ee008000 r7:00000001
r6:ed89e9c0 r5:ee1e2720
[  195.257664]  r4:ee1e26c0
[  195.257677] [<c00611ac>] (handle_irq_event) from [<c0063d84>]
(handle_fasteoi_irq+0xb8/0x188)
[  195.257683]  r6:c063be14 r5:ee1e2720 r4:ee1e26c0 r3:00000000
[  195.257701] [<c0063ccc>] (handle_fasteoi_irq) from [<c0060748>]
(generic_handle_irq+0x34/0x44)
[  195.257706]  r6:00000000 r5:00000000 r4:00000041 r3:c0063ccc
[  195.257723] [<c0060714>] (generic_handle_irq) from [<c0060a28>]
(__handle_domain_irq+0x64/0xb8)
[  195.257728]  r4:c0620a38 r3:00000062
[  195.257741] [<c00609c4>] (__handle_domain_irq) from [<c0008604>]
(gic_handle_irq+0x38/0x70)
[  195.257746]  r8:c0625f08 r7:c062c944 r6:0000006b r5:0000007b
r4:f002000c r3:c0625f08
[  195.257769] [<c00085cc>] (gic_handle_irq) from [<c0012ec0>]
(__irq_svc+0x40/0x74)
[  195.257775] Exception stack(0xc0625f08 to 0xc0625f50)
[  195.257785] 5f00:                   ffffffed 00000000 00000000
c001fa80 c062c510 c062c4c4
[  195.257794] 5f20: 00000000 00000000 c0625f60 c0624000 00000000
c0625f5c c0625f60 c0625f50
[  195.257801] 5f40: c000f780 c000f784 600f0053 ffffffff
[  195.257806]  r9:c0624000 r8:c0625f60 r7:c0625f3c r6:ffffffff
r5:600f0053 r4:c000f784
[  195.257832] [<c000f744>] (arch_cpu_idle) from [<c0057ccc>]
(cpu_startup_entry+0x19c/0x264)
[  195.257845] [<c0057b30>] (cpu_startup_entry) from [<c048bba8>]
(rest_init+0x8c/0x90)
[  195.257850]  r7:ffffffff
[  195.257863] [<c048bb1c>] (rest_init) from [<c05f0cd8>]
(start_kernel+0x37c/0x388)
[  195.257868]  r4:c062c5d8 r3:c0624000
[  195.257882] [<c05f095c>] (start_kernel) from [<40008070>] (0x40008070)
[  195.257888] ---[ end trace 540e9ba1a4f64db4 ]---
[  204.079572] lcd0-power-domain: Power-on latency exceeded, new value
470417 ns
[  204.080079] tv-power-domain: Power-on latency exceeded, new value
449208 ns


So something is fishy...

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Joonyoung Shim]

Hi Tobias,

On 01/17/2015 07:44 AM, Tobias Jakobi wrote:
> Tobias Jakobi wrote:
>> Hello,
>>
>> so OK, this doesn't look too good.
>>
>> Tobias Jakobi wrote:
>>> I checked with my panel just now and played around a bit with the DRM
>>> (opening, vsync, etc.). However on deinitialization the entire system
>>> locked up. I currently haven't hooked the board up to the serial
>>> console, otherwise I would've tried to extract some more meaningful
>>> information.
>>>
>>> Going to check again more thoroughly on the weekend what exactly
>>> triggers the lockup.
>>
>> So, first of all I did my initial test with the exynos video backend of
>> RetroArch. But it turns out that there's no fancy application needed. I
>> now tested this with the 'modetest' application from libdrm, and did this:
>>
>> ./modetest -M exynos -s 16@13:1920x1080
>> setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
>> ^C
>> ./modetest -M exynos -s 16@13:640x480
>> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
>> ^C
>> ./modetest -M exynos -s 16@13:640x480
>> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
>> ^C
>> ./modetest -M exynos -s 16@13:640x480
>>
>> The board instantly died then. No kernel log output from the serial
>> console, the heartbeat just stops and the board is dead. Need to
>> power-cycle to get it running again.
>>
>> I'm unsure how to triage this at all.
>>
>> @Marek: Could you check if this also happens for you?
> 

Could you test after apply IOMMU v4 patchset of Marek and enable with
CONFIG_DRM_EXYNOS_IOMMU?

> In addition to the simple 'set mode' test, I also tried the 'vsync page
> flip' one:
> 
> ./modetest -M exynos -v -s 16@13:1280x720
> 
> While I haven't managed to lock up the system that way (I didn't try to
> repeatedly kill and start this test), I managed to produce kernel
> warnings that way.
> 

Hmm please refer below posted patch, same issue?

http://www.spinics.net/lists/dri-devel/msg75181.html

Thanks.

> Relevant parts here:
> [  108.173644] lcd0-power-domain: Power-on latency exceeded, new value
> 364958 ns
> [  108.174010] tv-power-domain: Power-on latency exceeded, new value
> 350083 ns
> [  192.632246] lcd0-power-domain: Power-on latency exceeded, new value
> 419499 ns
> [  192.632695] tv-power-domain: Power-on latency exceeded, new value
> 408167 ns
> [  195.257343] ------------[ cut here ]------------
> [  195.257379] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072
> drm_vblank_put+0xd8/0xf0()
> [  195.257385] Modules linked in: bridge stp llc bnep btrfs xor xor_neon
> zlib_inflate zlib_deflate raid6_pq ecb btusb bluetooth usb_storage
> [  195.257429] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc4+ #3
> [  195.257435] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [  195.257440] Backtrace:
> [  195.257462] [<c001212c>] (dump_backtrace) from [<c0012344>]
> (show_stack+0x18/0x1c)
> [  195.257468]  r6:c0595c30 r5:00000000 r4:c063ba90 r3:00000000
> [  195.257494] [<c001232c>] (show_stack) from [<c048f8f8>]
> (dump_stack+0x98/0xd8)
> [  195.257507] [<c048f860>] (dump_stack) from [<c0028f9c>]
> (warn_slowpath_common+0x88/0xb8)
> [  195.257512]  r5:00000430 r4:00000000
> [  195.257525] [<c0028f14>] (warn_slowpath_common) from [<c0029070>]
> (warn_slowpath_null+0x24/0x2c)
> [  195.257530]  r8:00200200 r7:ee3a9c00 r6:00000000 r5:ed89e380 r4:ed89e380
> [  195.257552] [<c002904c>] (warn_slowpath_null) from [<c0268fac>]
> (drm_vblank_put+0xd8/0xf0)
> [  195.257570] [<c0268ed4>] (drm_vblank_put) from [<c028156c>]
> (exynos_drm_crtc_finish_pageflip+0xc0/0xf0)
> [  195.257586] [<c02814ac>] (exynos_drm_crtc_finish_pageflip) from
> [<c0290358>] (mixer_irq_handler+0xdc/0x104)
> [  195.257591]  r10:c06527ee r9:ee1e26c0 r8:00000041 r7:00000801
> r6:ed804e68 r5:00000801
> [  195.257607]  r4:ed804e10
> [  195.257622] [<c029027c>] (mixer_irq_handler) from [<c00610b0>]
> (handle_irq_event_percpu+0x3c/0x138)
> [  195.257627]  r7:00000000 r6:00000000 r5:ee1e2720 r4:ed89e9c0
> [  195.257644] [<c0061074>] (handle_irq_event_percpu) from [<c00611f0>]
> (handle_irq_event+0x44/0x64)
> [  195.257649]  r10:00000000 r9:f0020000 r8:ee008000 r7:00000001
> r6:ed89e9c0 r5:ee1e2720
> [  195.257664]  r4:ee1e26c0
> [  195.257677] [<c00611ac>] (handle_irq_event) from [<c0063d84>]
> (handle_fasteoi_irq+0xb8/0x188)
> [  195.257683]  r6:c063be14 r5:ee1e2720 r4:ee1e26c0 r3:00000000
> [  195.257701] [<c0063ccc>] (handle_fasteoi_irq) from [<c0060748>]
> (generic_handle_irq+0x34/0x44)
> [  195.257706]  r6:00000000 r5:00000000 r4:00000041 r3:c0063ccc
> [  195.257723] [<c0060714>] (generic_handle_irq) from [<c0060a28>]
> (__handle_domain_irq+0x64/0xb8)
> [  195.257728]  r4:c0620a38 r3:00000062
> [  195.257741] [<c00609c4>] (__handle_domain_irq) from [<c0008604>]
> (gic_handle_irq+0x38/0x70)
> [  195.257746]  r8:c0625f08 r7:c062c944 r6:0000006b r5:0000007b
> r4:f002000c r3:c0625f08
> [  195.257769] [<c00085cc>] (gic_handle_irq) from [<c0012ec0>]
> (__irq_svc+0x40/0x74)
> [  195.257775] Exception stack(0xc0625f08 to 0xc0625f50)
> [  195.257785] 5f00:                   ffffffed 00000000 00000000
> c001fa80 c062c510 c062c4c4
> [  195.257794] 5f20: 00000000 00000000 c0625f60 c0624000 00000000
> c0625f5c c0625f60 c0625f50
> [  195.257801] 5f40: c000f780 c000f784 600f0053 ffffffff
> [  195.257806]  r9:c0624000 r8:c0625f60 r7:c0625f3c r6:ffffffff
> r5:600f0053 r4:c000f784
> [  195.257832] [<c000f744>] (arch_cpu_idle) from [<c0057ccc>]
> (cpu_startup_entry+0x19c/0x264)
> [  195.257845] [<c0057b30>] (cpu_startup_entry) from [<c048bba8>]
> (rest_init+0x8c/0x90)
> [  195.257850]  r7:ffffffff
> [  195.257863] [<c048bb1c>] (rest_init) from [<c05f0cd8>]
> (start_kernel+0x37c/0x388)
> [  195.257868]  r4:c062c5d8 r3:c0624000
> [  195.257882] [<c05f095c>] (start_kernel) from [<40008070>] (0x40008070)
> [  195.257888] ---[ end trace 540e9ba1a4f64db4 ]---
> [  204.079572] lcd0-power-domain: Power-on latency exceeded, new value
> 470417 ns
> [  204.080079] tv-power-domain: Power-on latency exceeded, new value
> 449208 ns
> 
> 
> So something is fishy...
> 
> With best wishes,
> Tobias
> 
> --
> 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
> 

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Marek Szyprowski]

Hello,

On 2015-01-16 23:32, Tobias Jakobi wrote:
> Hello,
>
> so OK, this doesn't look too good.
>
> Tobias Jakobi wrote:
>> I checked with my panel just now and played around a bit with the DRM
>> (opening, vsync, etc.). However on deinitialization the entire system
>> locked up. I currently haven't hooked the board up to the serial
>> console, otherwise I would've tried to extract some more meaningful
>> information.
>>
>> Going to check again more thoroughly on the weekend what exactly
>> triggers the lockup.
> So, first of all I did my initial test with the exynos video backend of
> RetroArch. But it turns out that there's no fancy application needed. I
> now tested this with the 'modetest' application from libdrm, and did this:
>
> ./modetest -M exynos -s 16@13:1920x1080
> setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
> setting mode 640x480-60Hz@XR24 on connectors 16, crtc 13
> ^C
> ./modetest -M exynos -s 16@13:640x480
>
> The board instantly died then. No kernel log output from the serial
> console, the heartbeat just stops and the board is dead. Need to
> power-cycle to get it running again.
>
> I'm unsure how to triage this at all.

Thanks for you tests and pointing this issue. I turned out that the 
initial fix proposed
by Andrzej Hajda 
(http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
fine, while the final version merged to clock fixes ('clk: samsung: 
exynos4: set parent
of sclk_hdmiphy to hdmi' - commit 
df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
properly.

Please check the following kernel tree - instead of hacking around hdmi 
clock I've added
handling of it directly to drm mixer driver:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
I hope that this will finally solve all mixer initialization related 
issues (also for
Odroid XU3, discussed recently in the other thread). If it works fine, I 
will resend
exynos4 hdmi patches to include this change.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Hello!

Marek Szyprowski wrote:
> Thanks for you tests and pointing this issue. I turned out that the
> initial fix proposed
> by Andrzej Hajda
> (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
> fine, while the final version merged to clock fixes ('clk: samsung:
> exynos4: set parent
> of sclk_hdmiphy to hdmi' - commit
> df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
> properly.
I should thank you for pushing all this code to mainline. It's really
nice to see how all the pieces now come together.


> Please check the following kernel tree - instead of hacking around hdmi
> clock I've added
> handling of it directly to drm mixer driver:
> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
> 
> I hope that this will finally solve all mixer initialization related
> issues (also for
> Odroid XU3, discussed recently in the other thread). If it works fine, I
> will resend
> exynos4 hdmi patches to include this change.
I have picked the additional patches to my tree, which currently has a
bunch of other stuff in it, in particular v4 of the IOMMU series.

Anyway, now the 'modetest' application immediately crashes the system,
but I get a least something on the serial console:
http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt

So this is probably due to the IOMMU. Please note that DRM IOMMU support
(CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
CONFIG_EXYNOS_IOMMU however was on.

I'm going to retest with the IOMMU series removed and
CONFIG_EXYNOS_IOMMU disabled as well.

Just posting this already since you're probably interested in these
'side-issues' as well.


With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Marek Szyprowski]

Hello,

On 2015-01-20 00:03, Tobias Jakobi wrote:
> Hello!
>
> Marek Szyprowski wrote:
>> Thanks for you tests and pointing this issue. I turned out that the
>> initial fix proposed
>> by Andrzej Hajda
>> (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
>> fine, while the final version merged to clock fixes ('clk: samsung:
>> exynos4: set parent
>> of sclk_hdmiphy to hdmi' - commit
>> df019a5c0f7083001cb694f44821ca506425bda2) doesn't work
>> properly.
> I should thank you for pushing all this code to mainline. It's really
> nice to see how all the pieces now come together.
>
>
>> Please check the following kernel tree - instead of hacking around hdmi
>> clock I've added
>> handling of it directly to drm mixer driver:
>> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
>>
>> I hope that this will finally solve all mixer initialization related
>> issues (also for
>> Odroid XU3, discussed recently in the other thread). If it works fine, I
>> will resend
>> exynos4 hdmi patches to include this change.
> I have picked the additional patches to my tree, which currently has a
> bunch of other stuff in it, in particular v4 of the IOMMU series.

This is a known issue. When Exynos IOMMU DRM driver is enabled, you need 
also
to enabled CONFIG_DRM_EXYNOS_IOMMU, otherwise the driver will crash on init.
This also need to be fixed, but for the time being I focused on other 
issues...

> Anyway, now the 'modetest' application immediately crashes the system,
> but I get a least something on the serial console:
> http://www.math.uni-bielefeld.de/~tjakobi/archive/odroid_modetest_crash_sysmmu.txt
>
> So this is probably due to the IOMMU. Please note that DRM IOMMU support
> (CONFIG_DRM_EXYNOS_IOMMU) was disabled (!) in my config.
> CONFIG_EXYNOS_IOMMU however was on.
>
> I'm going to retest with the IOMMU series removed and
> CONFIG_EXYNOS_IOMMU disabled as well.
>
> Just posting this already since you're probably interested in these
> 'side-issues' as well.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Tobias Jakobi]

Marek Szyprowski wrote:
> Please check the following kernel tree - instead of hacking around hdmi
> clock I've added
> handling of it directly to drm mixer driver:
> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
> 
> I hope that this will finally solve all mixer initialization related
> issues (also for
> Odroid XU3, discussed recently in the other thread). If it works fine, I
> will resend
> exynos4 hdmi patches to include this change.
OK, I can verify that with the additional patches the lockup issues no
longer occur.

When doing the vsync tests though there are still the drm_vblank_put
warnings. I have yet to check if patch by Joonyoung (thanks Joonyoung
for the hint!) fixes these warnings.

With best wishes,
Tobias

Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms

[Javier Martinez Canillas]

[Adding Inki and Joonyoung to cc list]

Hello Marek,

On Mon, Jan 19, 2015 at 5:30 PM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>>
>> The board instantly died then. No kernel log output from the serial
>> console, the heartbeat just stops and the board is dead. Need to
>> power-cycle to get it running again.
>>
>> I'm unsure how to triage this at all.
>
>
> Thanks for you tests and pointing this issue. I turned out that the initial
> fix proposed
> by Andrzej Hajda
> (http://www.spinics.net/lists/linux-samsung-soc/msg38915.html) worked
> fine, while the final version merged to clock fixes ('clk: samsung: exynos4:
> set parent
> of sclk_hdmiphy to hdmi' - commit df019a5c0f7083001cb694f44821ca506425bda2)
> doesn't work
> properly.
>

I was working on adding HDMI support for Exynos5420/5422/5800 and I
also found that the hdmi clock being gated by the exynos_hdmi driver
on hdmi_poweroff(), was causing a system hang when the exynos_mixer
driver tried to access the mixer module registers.

My first approach was to do the same than Andrzej's patch, that is set
the parent of mixer gate clock to hdmi so when the exynos_mixer driver
enables its mixer clock, the hdmi clock would be enabled too.
Unfortunately that didn't work (more on that below)

> Please check the following kernel tree - instead of hacking around hdmi
> clock I've added
> handling of it directly to drm mixer driver:
> https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/shortlog/refs/heads/v3.19-odroid-hdmi
> I hope that this will finally solve all mixer initialization related issues

My second approach was indeed the same that you are doing, to add a
phandle to the hdmi clock directly in the exynos_mixer driver to avoid
having to set the parent of the mixer clock on each exynos clock
driver.

When dumping the value of the CLK_GATE_IP_DISP1 register I see that
both CLK_HDMI and CLK_MIXER are set with both approaches but the
system still crashes. So enabling the hdmi clock seems to be enough to
make the mixer happy on Exynos4 but unfortunately is not enough on
Exynos5420.

> (also for
> Odroid XU3, discussed recently in the other thread). If it works fine, I
> will resend
> exynos4 hdmi patches to include this change.
>
>

I compared the clock hierarchy when the system is able to turn on and
off the fb blank and when it crash and I notice this difference:

Working:

 sclk_pwi                                 0            0    24000000
       0 0
 sclk_hdmiphy                             1            1    24000000
       0 0
    mout_hdmi                             1            1    24000000
       0 0
       sclk_hdmi                          1            1    24000000
       0 0
...
    mout_pixel                            0            0    24000000
       0 0
       dout_hdmi_pixel                    0            0    24000000
       0 0
          sclk_pixel                      0            0    24000000
       0 0


Not working:

 sclk_pwi                                 0            0    24000000
       0 0
 sclk_hdmiphy                             0            0    24000000
       0 0
...
    mout_pixel                            0            0    24000000
       0 0
       dout_hdmi_pixel                    0            0    24000000
       0 0
          mout_hdmi                       0            0    24000000
       0 0
             sclk_hdmi                    0            0    24000000
       0 0
          sclk_pixel                      0            0    24000000
       0 0

The difference is because the source clock of the hdmi clock is
generated by the output of a mux clock (mout_hdmi) that select either
dout_hdmi_pixel or sclk_hdmiphy as input parent. The exynos5420 clk
driver defines as:

PNAME(mout_hdmi_p) = {"dout_hdmi_pixel", "sclk_hdmiphy"};
...
MUX(CLK_MOUT_HDMI, "mout_hdmi", mout_hdmi_p, SRC_DISP10, 28, 1),

And the exynos_hdmi driver does:

clk_disable_unprepare(hdata->res.sclk_hdmi);
clk_set_parent(hdata->res.mout_hdmi, hdata->res.sclk_hdmiphy);
clk_prepare_enable(hdata->res.sclk_hdmi);

So is not only that the hdmi clock has to be enabled but also the
clock hierarchy matters. I don't even know if the hdmi clock is needed
or is that enabling this clock has the side effect of enabling another
clock in the hierarchy that is the one that is needed. It would be
good if someone can compare the clock hierarchy on an Exynos4.

So I would like to understand what is really the root cause here
instead of trying to only solve the symptoms for each platform.

I have also noticed this patch from Inki - commit 245f98f269714
("drm/exynos: hdmi: fix power order issue") that forces the
exynos_mixer to be disabled before exynos_hdmi to prevent a system
crash but only for DRM_MODE_DPMS_OFF. So I wonder if the same should
be true for DRM_MODE_DPMS_ON and the exynos_hdmi should be enabled
before exynos_hdmi.

IOW, I would like to know what is the dependency between the mixer and
hdmi modules at the module level first and then once that is clear we
can dig deeper on what clocks are needed and when those must be
enabled.

Best regards,
Javier

[RFC] drm/exynos: move hdmi clk disable out of pm ops

[Gustavo Padovan]

From: Prathyush K <prathyush.k@samsung.com>

When VPLL clock of less than 140 MHz was used and all the three
clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
during S2R when HDMI is connected. Since we want to use a vpll
clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
This patch moves the clk enable/disable of hdmi and sclk_hdmi
outside of the pm ops. Now system suspends and resumes with HDMI
connected with VPLL set at 70.5 MHz.

Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

---
This work depends on the HDMI support patches from Javier:
https://lkml.org/lkml/2015/1/20/235

This patch comes from a downstream tree (Google chormeOS) and it is
authored by a Samsung employee, but we still think this may not fix
the real cause of the bug, there might be something else that we
haven't found that could be the cause of this issue. Anyone has some
comment to add here?
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6aa0d65..7a473cb 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display)
 	regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
 			PMU_HDMI_PHY_ENABLE_BIT, 1);
 
-	clk_prepare_enable(res->hdmi);
-	clk_prepare_enable(res->sclk_hdmi);
-
 	hdmiphy_poweron(hdata);
 	hdmi_commit(display);
 }
@@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display)
 
 	cancel_delayed_work(&hdata->hotplug_work);
 
-	clk_disable_unprepare(res->sclk_hdmi);
-	clk_disable_unprepare(res->hdmi);
-
 	/* reset pmu hdmiphy control bit to disable hdmiphy */
 	regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
 			PMU_HDMI_PHY_ENABLE_BIT, 0);
@@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
 	} else
 		res->reg_hdmi_en = NULL;
 
+	/*
+	 * These two clocks are not moved into hdmi_poweron/off since system
+	 * fails to suspend if VPLL clock of 70.5 MHz is used and these
+	 * clocks are disabled before suspend. So enable them here.
+	 */
+	clk_prepare_enable(res->sclk_hdmi);
+	clk_prepare_enable(res->hdmi);
+
 	return ret;
 fail:
 	DRM_ERROR("HDMI resource init - failed\n");
@@ -2516,6 +2518,9 @@ static int hdmi_remove(struct platform_device *pdev)
 	if (hdata->res.reg_hdmi_en)
 		regulator_disable(hdata->res.reg_hdmi_en);
 
+	clk_disable_unprepare(hdata->res.sclk_hdmi);
+	clk_disable_unprepare(hdata->res.hdmi);
+
 	if (hdata->hdmiphy_port)
 		put_device(&hdata->hdmiphy_port->dev);
 	put_device(&hdata->ddc_adpt->dev);
-- 
1.9.3

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Joonyoung Shim]

+Cc Kukjin,

Hi,

On 01/29/2015 10:31 PM, Gustavo Padovan wrote:
> From: Prathyush K <prathyush.k@samsung.com>
> 
> When VPLL clock of less than 140 MHz was used and all the three
> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
> during S2R when HDMI is connected. Since we want to use a vpll
> clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
> This patch moves the clk enable/disable of hdmi and sclk_hdmi
> outside of the pm ops. Now system suspends and resumes with HDMI
> connected with VPLL set at 70.5 MHz.
> 
> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> 
> ---
> This work depends on the HDMI support patches from Javier:
> https://lkml.org/lkml/2015/1/20/235
> 
> This patch comes from a downstream tree (Google chormeOS) and it is
> authored by a Samsung employee, but we still think this may not fix
> the real cause of the bug, there might be something else that we
> haven't found that could be the cause of this issue. Anyone has some
> comment to add here?

Hmm, do you test from which exynos SoC?

Kukjin, if it is hw issue, do you know hw experts of exynos hdmi and
could we get any advice?

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6aa0d65..7a473cb 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display)
>  	regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>  			PMU_HDMI_PHY_ENABLE_BIT, 1);
>  
> -	clk_prepare_enable(res->hdmi);
> -	clk_prepare_enable(res->sclk_hdmi);
> -
>  	hdmiphy_poweron(hdata);
>  	hdmi_commit(display);
>  }
> @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display)
>  
>  	cancel_delayed_work(&hdata->hotplug_work);
>  
> -	clk_disable_unprepare(res->sclk_hdmi);
> -	clk_disable_unprepare(res->hdmi);
> -
>  	/* reset pmu hdmiphy control bit to disable hdmiphy */
>  	regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>  			PMU_HDMI_PHY_ENABLE_BIT, 0);
> @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
>  	} else
>  		res->reg_hdmi_en = NULL;
>  
> +	/*
> +	 * These two clocks are not moved into hdmi_poweron/off since system
> +	 * fails to suspend if VPLL clock of 70.5 MHz is used and these
> +	 * clocks are disabled before suspend. So enable them here.
> +	 */
> +	clk_prepare_enable(res->sclk_hdmi);
> +	clk_prepare_enable(res->hdmi);
> +

Then twe clocks are turned on always. I don't think it's reasonable.

Thanks.

>  	return ret;
>  fail:
>  	DRM_ERROR("HDMI resource init - failed\n");
> @@ -2516,6 +2518,9 @@ static int hdmi_remove(struct platform_device *pdev)
>  	if (hdata->res.reg_hdmi_en)
>  		regulator_disable(hdata->res.reg_hdmi_en);
>  
> +	clk_disable_unprepare(hdata->res.sclk_hdmi);
> +	clk_disable_unprepare(hdata->res.hdmi);
> +
>  	if (hdata->hdmiphy_port)
>  		put_device(&hdata->hdmiphy_port->dev);
>  	put_device(&hdata->ddc_adpt->dev);
> 

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Javier Martinez Canillas]

Hello Joonyoung,

On Fri, Jan 30, 2015 at 3:02 AM, Joonyoung Shim <jy0922.shim@samsung.com> wrote:
> +Cc Kukjin,
>
> Hi,
>
> On 01/29/2015 10:31 PM, Gustavo Padovan wrote:
>> From: Prathyush K <prathyush.k@samsung.com>
>>
>> When VPLL clock of less than 140 MHz was used and all the three
>> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
>> during S2R when HDMI is connected. Since we want to use a vpll
>> clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
>> This patch moves the clk enable/disable of hdmi and sclk_hdmi
>> outside of the pm ops. Now system suspends and resumes with HDMI
>> connected with VPLL set at 70.5 MHz.
>>
>> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>
>> ---
>> This work depends on the HDMI support patches from Javier:
>> https://lkml.org/lkml/2015/1/20/235
>>
>> This patch comes from a downstream tree (Google chormeOS) and it is
>> authored by a Samsung employee, but we still think this may not fix
>> the real cause of the bug, there might be something else that we
>> haven't found that could be the cause of this issue. Anyone has some
>> comment to add here?
>
> Hmm, do you test from which exynos SoC?
>

I haven't the S2R case since it is broken in mainline for Exynos5420
(even with $subject applied) but $subject fixes for me the system
crash we have discussed before [0]. That is when mixer_poweron() tries
to access the mixer register without hdmi_poweron() enabling the
"hdmi" clock.

> Kukjin, if it is hw issue, do you know hw experts of exynos hdmi and
> could we get any advice?
>

It would be great if someone can shed some light on both issues.

>> ---
>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++++++++++------
>>  1 file changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 6aa0d65..7a473cb 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display)
>>       regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>>                       PMU_HDMI_PHY_ENABLE_BIT, 1);
>>
>> -     clk_prepare_enable(res->hdmi);
>> -     clk_prepare_enable(res->sclk_hdmi);
>> -
>>       hdmiphy_poweron(hdata);
>>       hdmi_commit(display);
>>  }
>> @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display)
>>
>>       cancel_delayed_work(&hdata->hotplug_work);
>>
>> -     clk_disable_unprepare(res->sclk_hdmi);
>> -     clk_disable_unprepare(res->hdmi);
>> -
>>       /* reset pmu hdmiphy control bit to disable hdmiphy */
>>       regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>>                       PMU_HDMI_PHY_ENABLE_BIT, 0);
>> @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
>>       } else
>>               res->reg_hdmi_en = NULL;
>>
>> +     /*
>> +      * These two clocks are not moved into hdmi_poweron/off since system
>> +      * fails to suspend if VPLL clock of 70.5 MHz is used and these
>> +      * clocks are disabled before suspend. So enable them here.
>> +      */
>> +     clk_prepare_enable(res->sclk_hdmi);
>> +     clk_prepare_enable(res->hdmi);
>> +
>
> Then twe clocks are turned on always. I don't think it's reasonable.
>

Agreed that it would be better to gate/ungate the clocks as necessary
to reduce power consumption but OTOH is better to leave some clocks
enabled to avoid system crashes. Of course it would be even better to
understand the root cause and fix it.

Best regards,
Javier

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Javier Martinez Canillas]

Hello,

On Fri, Jan 30, 2015 at 9:03 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
>
> I haven't the S2R case since it is broken in mainline for Exynos5420
> (even with $subject applied) but $subject fixes for me the system
> crash we have discussed before [0]. That is when mixer_poweron() tries
> to access the mixer register without hdmi_poweron() enabling the
> "hdmi" clock.
>

I forgot to add the reference to the previously discussed issue, sorry
for the noise...

Best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg393206.html

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Joonyoung Shim]

Hi Javier,

On 01/30/2015 05:03 PM, Javier Martinez Canillas wrote:
> Hello Joonyoung,
> 
> On Fri, Jan 30, 2015 at 3:02 AM, Joonyoung Shim <jy0922.shim@samsung.com> wrote:
>> +Cc Kukjin,
>>
>> Hi,
>>
>> On 01/29/2015 10:31 PM, Gustavo Padovan wrote:
>>> From: Prathyush K <prathyush.k@samsung.com>
>>>
>>> When VPLL clock of less than 140 MHz was used and all the three
>>> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
>>> during S2R when HDMI is connected. Since we want to use a vpll
>>> clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
>>> This patch moves the clk enable/disable of hdmi and sclk_hdmi
>>> outside of the pm ops. Now system suspends and resumes with HDMI
>>> connected with VPLL set at 70.5 MHz.
>>>
>>> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>>
>>> ---
>>> This work depends on the HDMI support patches from Javier:
>>> https://lkml.org/lkml/2015/1/20/235
>>>
>>> This patch comes from a downstream tree (Google chormeOS) and it is
>>> authored by a Samsung employee, but we still think this may not fix
>>> the real cause of the bug, there might be something else that we
>>> haven't found that could be the cause of this issue. Anyone has some
>>> comment to add here?
>>
>> Hmm, do you test from which exynos SoC?
>>
> 
> I haven't the S2R case since it is broken in mainline for Exynos5420
> (even with $subject applied) but $subject fixes for me the system
> crash we have discussed before [0]. That is when mixer_poweron() tries
> to access the mixer register without hdmi_poweron() enabling the
> "hdmi" clock.
> 
>> Kukjin, if it is hw issue, do you know hw experts of exynos hdmi and
>> could we get any advice?
>>
> 
> It would be great if someone can shed some light on both issues.
> 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++++++++++------
>>>  1 file changed, 11 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index 6aa0d65..7a473cb 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display *display)
>>>       regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>>>                       PMU_HDMI_PHY_ENABLE_BIT, 1);
>>>
>>> -     clk_prepare_enable(res->hdmi);
>>> -     clk_prepare_enable(res->sclk_hdmi);
>>> -
>>>       hdmiphy_poweron(hdata);
>>>       hdmi_commit(display);
>>>  }
>>> @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display *display)
>>>
>>>       cancel_delayed_work(&hdata->hotplug_work);
>>>
>>> -     clk_disable_unprepare(res->sclk_hdmi);
>>> -     clk_disable_unprepare(res->hdmi);
>>> -
>>>       /* reset pmu hdmiphy control bit to disable hdmiphy */
>>>       regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>>>                       PMU_HDMI_PHY_ENABLE_BIT, 0);
>>> @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
>>>       } else
>>>               res->reg_hdmi_en = NULL;
>>>
>>> +     /*
>>> +      * These two clocks are not moved into hdmi_poweron/off since system
>>> +      * fails to suspend if VPLL clock of 70.5 MHz is used and these
>>> +      * clocks are disabled before suspend. So enable them here.
>>> +      */
>>> +     clk_prepare_enable(res->sclk_hdmi);
>>> +     clk_prepare_enable(res->hdmi);
>>> +
>>
>> Then twe clocks are turned on always. I don't think it's reasonable.
>>
> 
> Agreed that it would be better to gate/ungate the clocks as necessary
> to reduce power consumption but OTOH is better to leave some clocks
> enabled to avoid system crashes. Of course it would be even better to
> understand the root cause and fix it.
> 

It's ok to me if we apply workaround only about exynos5420 hdmi case.

Thanks.

[PATCH] drm/exynos: don' disable hdmi clocks for exynos5420

[Gustavo Padovan]

From: Prathyush K <prathyush.k@samsung.com>

When VPLL clock of less than 140 MHz was used and all the three
clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
during S2R when HDMI is connected. Since we want to use a vpll
clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
This patch moves the clk enable/disable of hdmi and sclk_hdmi
outside of the pm ops. Now system suspends and resumes with HDMI
connected with VPLL set at 70.5 MHz.

Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6aa0d65..0be6921 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2254,6 +2254,20 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
 	} else
 		res->reg_hdmi_en = NULL;
 
+	/*
+	 * For these two clocks exynos5420 fails to suspend if VPLL clock of
+	 * 70.5 MHz is used and these clocks are disabled before suspend. So
+	 * enable them here.
+	 * Note that this will keep the clocks enabled for the entire
+	 * lifetime of the driver and waste energy when it is suspended.
+	 * However it prevents the system crash until a better solution is
+	 * found
+	 */
+	if (of_machine_is_compatible("samsung,exynos5420")) {
+		clk_prepare_enable(res->sclk_hdmi);
+		clk_prepare_enable(res->hdmi);
+	}
+
 	return ret;
 fail:
 	DRM_ERROR("HDMI resource init - failed\n");
@@ -2516,6 +2530,11 @@ static int hdmi_remove(struct platform_device *pdev)
 	if (hdata->res.reg_hdmi_en)
 		regulator_disable(hdata->res.reg_hdmi_en);
 
+	if (of_machine_is_compatible("samsung,exynos5420")) {
+		clk_disable_unprepare(hdata->res.sclk_hdmi);
+		clk_disable_unprepare(hdata->res.hdmi);
+	}
+
 	if (hdata->hdmiphy_port)
 		put_device(&hdata->hdmiphy_port->dev);
 	put_device(&hdata->ddc_adpt->dev);
-- 
1.9.3

Re: [PATCH] drm/exynos: don' disable hdmi clocks for exynos5420

[Joonyoung Shim]

+Cc dri-devel ML,

Hi,

On 01/31/2015 06:45 AM, Gustavo Padovan wrote:
> From: Prathyush K <prathyush.k@samsung.com>
> 
> When VPLL clock of less than 140 MHz was used and all the three
> clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
> during S2R when HDMI is connected. Since we want to use a vpll
> clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
> This patch moves the clk enable/disable of hdmi and sclk_hdmi
> outside of the pm ops. Now system suspends and resumes with HDMI
> connected with VPLL set at 70.5 MHz.
> 

I think commit messages should be updated because it is different with
prior posting codes.

Thanks.

> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 6aa0d65..0be6921 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2254,6 +2254,20 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
>  	} else
>  		res->reg_hdmi_en = NULL;
>  
> +	/*
> +	 * For these two clocks exynos5420 fails to suspend if VPLL clock of
> +	 * 70.5 MHz is used and these clocks are disabled before suspend. So
> +	 * enable them here.
> +	 * Note that this will keep the clocks enabled for the entire
> +	 * lifetime of the driver and waste energy when it is suspended.
> +	 * However it prevents the system crash until a better solution is
> +	 * found
> +	 */
> +	if (of_machine_is_compatible("samsung,exynos5420")) {

I'm not sure it's ok to use SoC compatible in driver and doesn't
exynos5800 also have same issue?

How about just use driver_data?

Thanks.

> +		clk_prepare_enable(res->sclk_hdmi);
> +		clk_prepare_enable(res->hdmi);
> +	}
> +
>  	return ret;
>  fail:
>  	DRM_ERROR("HDMI resource init - failed\n");
> @@ -2516,6 +2530,11 @@ static int hdmi_remove(struct platform_device *pdev)
>  	if (hdata->res.reg_hdmi_en)
>  		regulator_disable(hdata->res.reg_hdmi_en);
>  
> +	if (of_machine_is_compatible("samsung,exynos5420")) {
> +		clk_disable_unprepare(hdata->res.sclk_hdmi);
> +		clk_disable_unprepare(hdata->res.hdmi);
> +	}
> +
>  	if (hdata->hdmiphy_port)
>  		put_device(&hdata->hdmiphy_port->dev);
>  	put_device(&hdata->ddc_adpt->dev);
>