[PATCH] tegra: ventana: display and backlight DT entries

[PATCH] tegra: ventana: display and backlight DT entries

[Alexandre Courbot]

Enable internal panel:
- add EDID file
- add power sequence to control backlight and panel (panel is currently
  controlled by the backlight sequence, this will need to be fixed once
  the panel framework has power sequences support)

Also enable HDMI output.

Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 arch/arm/boot/dts/tegra20-ventana.dts  | 114 +++++++++++++++++++++++++++++++--
 arch/arm/boot/dts/tegra20-ventana.edid | Bin 0 -> 128 bytes
 2 files changed, 109 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/tegra20-ventana.edid

diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index adc4754..849a374 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -318,11 +318,30 @@
 		};
 	};
 
-	i2c@7000c400 {
+	hdmiddc: i2c@7000c400 {
 		status = "okay";
 		clock-frequency = <400000>;
 	};
 
+	host1x {
+                dc@54200000 {
+			rgb {
+				status = "okay";
+				nvidia,edid = /incbin/("tegra20-ventana.edid");
+			};
+		};
+
+		hdmi {
+			status = "okay";
+
+			vdd-supply = <&avddhdmi>;
+			pll-supply = <&avddhdmipll>;
+
+			nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
+			nvidia,ddc-i2c-bus = <&hdmiddc>;
+		};
+	};
+
 	i2cmux {
 		compatible = "i2c-mux-pinctrl";
 		#address-cells = <1>;
@@ -446,13 +465,13 @@
 					regulator-max-microvolt = <1800000>;
 				};
 
-				ldo7 {
+				avddhdmi: ldo7 {
 					regulator-name = "vdd_ldo7,avdd_hdmi,vdd_fuse";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
 				};
 
-				ldo8 {
+				avddhdmipll: ldo8 {
 					regulator-name = "vdd_ldo8,avdd_hdmi_pll";
 					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <1800000>;
@@ -516,6 +535,91 @@
 		bus-width = <8>;
 	};
 
+	backlight {
+		compatible = "pwm-backlight";
+		brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
+		default-brightness-level = <12>;
+
+		/* resources used by the power sequences */
+		pwms = <&pwm 2 5000000>;
+		pwm-names = "backlight";
+		power-supply = <&vdd_bl_reg>;
+		panel-supply = <&vdd_panel_reg>;
+
+		power-sequences {
+			power-on {
+				/*
+				 * Panel power and LDVS enable.
+				 * TODO: move into the panel device as soon as
+				 * panel framework supports power sequences.
+				 */
+				step0 {
+					type = "regulator";
+					id = "panel";
+					enable;
+				};
+				step1 {
+					type = "gpio";
+					gpio = <&gpio 10 0>;
+					value = <1>;
+				};
+				/* Backlight sequence. This belongs here. */
+				step2 {
+					type = "regulator";
+					id = "power";
+					enable;
+				};
+				step3 {
+					type = "delay";
+					delay = <10000>;
+				};
+				step4 {
+					type = "pwm";
+					id = "backlight";
+					enable;
+				};
+				step5 {
+					type = "gpio";
+					gpio = <&gpio 28 0>;
+					value = <1>;
+				};
+			};
+
+			power-off {
+				step0 {
+					type = "gpio";
+					gpio = <&gpio 28 0>;
+					value = <0>;
+				};
+				step1 {
+					type = "pwm";
+					id = "backlight";
+					disable;
+				};
+				step2 {
+					type = "delay";
+					delay = <10000>;
+				};
+				step3 {
+					type = "regulator";
+					id = "power";
+					disable;
+				};
+				/* This also belongs to the panel sequence */
+				step4 {
+					type = "gpio";
+					gpio = <&gpio 10 0>;
+					value = <0>;
+				};
+				step5 {
+					type = "regulator";
+					id = "panel";
+					disable;
+				};
+			};
+		};
+	};
+
 	regulators {
 		compatible = "simple-bus";
 		#address-cells = <1>;
@@ -549,7 +653,7 @@
 			enable-active-high;
 		};
 
-		regulator@3 {
+		vdd_panel_reg: regulator@3 {
 			compatible = "regulator-fixed";
 			reg = <3>;
 			regulator-name = "vdd_pnl";
@@ -559,7 +663,7 @@
 			enable-active-high;
 		};
 
-		regulator@4 {
+		vdd_bl_reg: regulator@4 {
 			compatible = "regulator-fixed";
 			reg = <4>;
 			regulator-name = "vdd_bl";
diff --git a/arch/arm/boot/dts/tegra20-ventana.edid b/arch/arm/boot/dts/tegra20-ventana.edid
new file mode 100644
index 0000000000000000000000000000000000000000..a96ab0e895515cc1f7b9e7b4f3cda359f4b6a285
GIT binary patch
literal 128
zcmZSh4+ac;BCRqEKp-o^$lM^tQ^D0#J2TvWrkYGZ2vC#}4OGa69SUGjGq6^VWVlxg
tR3Hh&{0s_Eu;4$F5m12PAA@s12p3FL0V3k#=xAtQ8186b=%~Q39sq-e8vy_S

literal 0
HcmV?d00001

-- 
1.8.0

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Thierry Reding]

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

On Tue, Nov 13, 2012 at 07:23:24PM +0900, Alexandre Courbot wrote:
> Enable internal panel:
> - add EDID file
> - add power sequence to control backlight and panel (panel is currently
>   controlled by the backlight sequence, this will need to be fixed once
>   the panel framework has power sequences support)
> 
> Also enable HDMI output.
> 
> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Hi Alex,

Thanks for the patch. It seems like we may actually get the tegra-drm in
for 3.8, so I think it's time we start collecting patches to the DTS
files to enable it on the various boards. I can collect these in my
tegra/next branch to provide a common location and feed them to Stephen
at the appropriate time.

I think the canonical subject for Tegra-related patches against arch/arm
is: "ARM: tegra". A few more comments inline.

> ---
>  arch/arm/boot/dts/tegra20-ventana.dts  | 114 +++++++++++++++++++++++++++++++--
>  arch/arm/boot/dts/tegra20-ventana.edid | Bin 0 -> 128 bytes
>  2 files changed, 109 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/boot/dts/tegra20-ventana.edid
> 
> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
> index adc4754..849a374 100644
> --- a/arch/arm/boot/dts/tegra20-ventana.dts
> +++ b/arch/arm/boot/dts/tegra20-ventana.dts
> @@ -318,11 +318,30 @@
>  		};
>  	};
>  
> -	i2c@7000c400 {
> +	hdmiddc: i2c@7000c400 {
>  		status = "okay";
>  		clock-frequency = <400000>;
>  	};

I believe you said Mark already told you, but this probably needs to
reference the DDC in the i2c-pinmux rather than the physical parent.

>  
> +	host1x {
> +                dc@54200000 {

This looks like it is indented using spaces instead of tabs.

> +			rgb {
> +				status = "okay";
> +				nvidia,edid = /incbin/("tegra20-ventana.edid");

We've briefly discussed this on IRC already, but for the sake of
completeness I'll restate it here. I think this should be converted to
the bindings as defined by the videomode helpers. These are not merged
yet, but they provide a much more readable representation than a binary
blob.

I know that Stephen mentioned using the nvidia,edid property for boards
where the blob is actually available in some sort. I seem to remember
him mentioning Ventana in particular, but I may be wrong.

> +			};
> +		};
> +
> +		hdmi {
> +			status = "okay";
> +
> +			vdd-supply = <&avddhdmi>;
> +			pll-supply = <&avddhdmipll>;
> +
> +			nvidia,hpd-gpio = <&gpio 111 0>; /* PN7 */
> +			nvidia,ddc-i2c-bus = <&hdmiddc>;
> +		};
> +	};
> +

The host1x node should be sorted higher, according to its unit address.
I believe the right place would be immediately above the pinmux node.

> +	backlight {
> +		compatible = "pwm-backlight";
> +		brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
> +		default-brightness-level = <12>;
> +
> +		/* resources used by the power sequences */
> +		pwms = <&pwm 2 5000000>;
> +		pwm-names = "backlight";
> +		power-supply = <&vdd_bl_reg>;
> +		panel-supply = <&vdd_panel_reg>;
> +
> +		power-sequences {
> +			power-on {
> +				/*
> +				 * Panel power and LDVS enable.

"LVDS".

Thierry

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

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Stephen Warren]

On 11/13/2012 05:34 AM, Thierry Reding wrote:
> On Tue, Nov 13, 2012 at 07:23:24PM +0900, Alexandre Courbot wrote:
>> Enable internal panel: - add EDID file - add power sequence to
>> control backlight and panel (panel is currently controlled by the
>> backlight sequence, this will need to be fixed once the panel
>> framework has power sequences support)
>> 
>> Also enable HDMI output.

>> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
>> b/arch/arm/boot/dts/tegra20-ventana.dts

>> +			rgb { +				status = "okay"; +				nvidia,edid =
>> /incbin/("tegra20-ventana.edid");
> 
> We've briefly discussed this on IRC already, but for the sake of 
> completeness I'll restate it here. I think this should be converted
> to the bindings as defined by the videomode helpers. These are not
> merged yet, but they provide a much more readable representation
> than a binary blob.
> 
> I know that Stephen mentioned using the nvidia,edid property for
> boards where the blob is actually available in some sort. I seem to
> remember him mentioning Ventana in particular, but I may be wrong.

I do tend to think that we should use EDID where there is one.

1) If there is an EDID in the panel HW, and the panel's I2C is hooked
up to Tegra, we should read it out at runtime.

2) Otherwise, if the panel's documentation provides an EDID, we should
use that, since it's the most canonical/common/standard representation
of the panel's properties.

3) Otherwise, use the videomode DT bindings.

Another benefit of (2) is that we can actually support the panel
without waiting for the videomode DT bindings to be finalized and merged.

Although if Ventana requires the power sequences helpers, that already
means we won't be able to support Ventana's panel in 3.8 unless the
power sequences code gets merged for 3.8; is that likely?

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Mark Zhang]

On 11/14/2012 12:46 AM, Stephen Warren wrote:
> On 11/13/2012 05:34 AM, Thierry Reding wrote:
>> On Tue, Nov 13, 2012 at 07:23:24PM +0900, Alexandre Courbot wrote:
>>> Enable internal panel: - add EDID file - add power sequence to
>>> control backlight and panel (panel is currently controlled by the
>>> backlight sequence, this will need to be fixed once the panel
>>> framework has power sequences support)
>>>
>>> Also enable HDMI output.
> 
>>> diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
>>> b/arch/arm/boot/dts/tegra20-ventana.dts
> 
>>> +			rgb { +				status = "okay"; +				nvidia,edid =
>>> /incbin/("tegra20-ventana.edid");
>>
>> We've briefly discussed this on IRC already, but for the sake of 
>> completeness I'll restate it here. I think this should be converted
>> to the bindings as defined by the videomode helpers. These are not
>> merged yet, but they provide a much more readable representation
>> than a binary blob.
>>
>> I know that Stephen mentioned using the nvidia,edid property for
>> boards where the blob is actually available in some sort. I seem to
>> remember him mentioning Ventana in particular, but I may be wrong.
> 
> I do tend to think that we should use EDID where there is one.
> 
> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
> up to Tegra, we should read it out at runtime.
> 
> 2) Otherwise, if the panel's documentation provides an EDID, we should
> use that, since it's the most canonical/common/standard representation
> of the panel's properties.
> 
> 3) Otherwise, use the videomode DT bindings.
> 
> Another benefit of (2) is that we can actually support the panel
> without waiting for the videomode DT bindings to be finalized and merged.
> 

Basically I agree with you. Although EDID blob is not friendly to read
but it's more flexible.
In addition, I recall I can use "i2cget" to get the EDID of Ventana's
panel but I've no idea why we can't do that in drm driver. I can spend
some time to take a look at this again and if the EDID can be fetched
dynamically, I think it's no need to consider videomode DT bindings
anymore.

> Although if Ventana requires the power sequences helpers, that already
> means we won't be able to support Ventana's panel in 3.8 unless the
> power sequences code gets merged for 3.8; is that likely?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Alex Courbot]

On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote:
> I do tend to think that we should use EDID where there is one.
> 
> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
> up to Tegra, we should read it out at runtime.

According to Ventana' platform design guide the LCD panel is hooked on I2C2. 
The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are 
for I2C, but there is no mention of an I2C address in both guides.

> 2) Otherwise, if the panel's documentation provides an EDID, we should
> use that, since it's the most canonical/common/standard representation
> of the panel's properties.

Panel's documentation indeed provides full EDID specification in appendix. Mark 
sent me an EDID blob which works but I don't know where it comes from - Mark, 
could you tell us?

> 3) Otherwise, use the videomode DT bindings.
> 
> Another benefit of (2) is that we can actually support the panel
> without waiting for the videomode DT bindings to be finalized and merged.

Is there another incentive for preferring (2) over (3)? EDID specs can easily 
be turned into videomode bindings, and it would also avoid introducing a new 
file into the kernel source.

> Although if Ventana requires the power sequences helpers, that already
> means we won't be able to support Ventana's panel in 3.8 unless the
> power sequences code gets merged for 3.8; is that likely?

Likely, I don't know, possible - maybe. Power seqs work and I could push to 
get them merged, but the following points need to be considered:
- DT bindings are likely to change from their current form. I want to take 
advantage of the gpio API changes that are undergoing, and also probably of 
your preprocessor patch for dtc (not sure if that is already usable in the 
kernel?). Considering the feature is young I don't think a DT change would be 
a big deal, but the general consensus seems to be that DT bindings are 
immutable - maybe my perception is wrong?
- If I am to take maintainership of the feature, I guess I will have to get 
the patches sufficiently Ack'ed by enough people, and also have someone else 
pull from my tree (Linus? Or maybe some other power maintainer?). I am not 
familiar with the exact procedure here - moreover, my GPG key only has one 
signature from a trusted kernel dev, I am not sure if this is enough.

Alex.

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Mark Zhang]

On 11/14/2012 01:36 PM, Alex Courbot wrote:
> On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote:
>> I do tend to think that we should use EDID where there is one.
>>
>> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
>> up to Tegra, we should read it out at runtime.
> 
> According to Ventana' platform design guide the LCD panel is hooked on I2C2. 
> The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are 
> for I2C, but there is no mention of an I2C address in both guides.
> 

Normally the address is 0x50. Take a look at function
"drm_do_probe_ddc_edid" as a reference.

>> 2) Otherwise, if the panel's documentation provides an EDID, we should
>> use that, since it's the most canonical/common/standard representation
>> of the panel's properties.
> 
> Panel's documentation indeed provides full EDID specification in appendix. Mark 
> sent me an EDID blob which works but I don't know where it comes from - Mark, 
> could you tell us?
> 

Actually I use a tool named "i2cget" to get this 128 bytes EDID. For
Ventana, I use a script like this:

for i in  $(seq 0 127)
do
	#echo " Reading byte no : $i "
	i2cget -y 0 0x50 $i | xxd -r -p >> tegra20-ventana.edid
done

>> 3) Otherwise, use the videomode DT bindings.
>>
>> Another benefit of (2) is that we can actually support the panel
>> without waiting for the videomode DT bindings to be finalized and merged.
> 
> Is there another incentive for preferring (2) over (3)? EDID specs can easily 
> be turned into videomode bindings, and it would also avoid introducing a new 
> file into the kernel source.
> 
>> Although if Ventana requires the power sequences helpers, that already
>> means we won't be able to support Ventana's panel in 3.8 unless the
>> power sequences code gets merged for 3.8; is that likely?
> 
> Likely, I don't know, possible - maybe. Power seqs work and I could push to 
> get them merged, but the following points need to be considered:
> - DT bindings are likely to change from their current form. I want to take 
> advantage of the gpio API changes that are undergoing, and also probably of 
> your preprocessor patch for dtc (not sure if that is already usable in the 
> kernel?). Considering the feature is young I don't think a DT change would be 
> a big deal, but the general consensus seems to be that DT bindings are 
> immutable - maybe my perception is wrong?
> - If I am to take maintainership of the feature, I guess I will have to get 
> the patches sufficiently Ack'ed by enough people, and also have someone else 
> pull from my tree (Linus? Or maybe some other power maintainer?). I am not 
> familiar with the exact procedure here - moreover, my GPG key only has one 
> signature from a trusted kernel dev, I am not sure if this is enough.
> 
> Alex.
> 

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Mark Zhang]

On 11/14/2012 01:56 PM, Mark Zhang wrote:
> On 11/14/2012 01:36 PM, Alex Courbot wrote:
>> On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote:
>>> I do tend to think that we should use EDID where there is one.
>>>
>>> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
>>> up to Tegra, we should read it out at runtime.
>>
>> According to Ventana' platform design guide the LCD panel is hooked on I2C2. 
>> The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are 
>> for I2C, but there is no mention of an I2C address in both guides.
>>
> 
> Normally the address is 0x50. Take a look at function
> "drm_do_probe_ddc_edid" as a reference.
> 
>>> 2) Otherwise, if the panel's documentation provides an EDID, we should
>>> use that, since it's the most canonical/common/standard representation
>>> of the panel's properties.
>>
>> Panel's documentation indeed provides full EDID specification in appendix. Mark 
>> sent me an EDID blob which works but I don't know where it comes from - Mark, 
>> could you tell us?
>>
> 
> Actually I use a tool named "i2cget" to get this 128 bytes EDID. For
> Ventana, I use a script like this:
> 
> for i in  $(seq 0 127)
> do
> 	#echo " Reading byte no : $i "
> 	i2cget -y 0 0x50 $i | xxd -r -p >> tegra20-ventana.edid

Sorry, this should be: i2cget -y 2 0x50 $i...

> done
> 
>>> 3) Otherwise, use the videomode DT bindings.
>>>
>>> Another benefit of (2) is that we can actually support the panel
>>> without waiting for the videomode DT bindings to be finalized and merged.
>>
>> Is there another incentive for preferring (2) over (3)? EDID specs can easily 
>> be turned into videomode bindings, and it would also avoid introducing a new 
>> file into the kernel source.
>>
>>> Although if Ventana requires the power sequences helpers, that already
>>> means we won't be able to support Ventana's panel in 3.8 unless the
>>> power sequences code gets merged for 3.8; is that likely?
>>
>> Likely, I don't know, possible - maybe. Power seqs work and I could push to 
>> get them merged, but the following points need to be considered:
>> - DT bindings are likely to change from their current form. I want to take 
>> advantage of the gpio API changes that are undergoing, and also probably of 
>> your preprocessor patch for dtc (not sure if that is already usable in the 
>> kernel?). Considering the feature is young I don't think a DT change would be 
>> a big deal, but the general consensus seems to be that DT bindings are 
>> immutable - maybe my perception is wrong?
>> - If I am to take maintainership of the feature, I guess I will have to get 
>> the patches sufficiently Ack'ed by enough people, and also have someone else 
>> pull from my tree (Linus? Or maybe some other power maintainer?). I am not 
>> familiar with the exact procedure here - moreover, my GPG key only has one 
>> signature from a trusted kernel dev, I am not sure if this is enough.
>>
>> Alex.
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Thierry Reding]

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

On Wed, Nov 14, 2012 at 01:56:45PM +0800, Mark Zhang wrote:
> On 11/14/2012 01:36 PM, Alex Courbot wrote:
> > On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote:
> >> I do tend to think that we should use EDID where there is one.
> >>
> >> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
> >> up to Tegra, we should read it out at runtime.
> > 
> > According to Ventana' platform design guide the LCD panel is hooked on I2C2. 
> > The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are 
> > for I2C, but there is no mention of an I2C address in both guides.
> > 
> 
> Normally the address is 0x50. Take a look at function
> "drm_do_probe_ddc_edid" as a reference.
> 
> >> 2) Otherwise, if the panel's documentation provides an EDID, we should
> >> use that, since it's the most canonical/common/standard representation
> >> of the panel's properties.
> > 
> > Panel's documentation indeed provides full EDID specification in appendix. Mark 
> > sent me an EDID blob which works but I don't know where it comes from - Mark, 
> > could you tell us?
> > 
> 
> Actually I use a tool named "i2cget" to get this 128 bytes EDID. For
> Ventana, I use a script like this:
> 
> for i in  $(seq 0 127)
> do
> 	#echo " Reading byte no : $i "
> 	i2cget -y 0 0x50 $i | xxd -r -p >> tegra20-ventana.edid
> done

There is also i2cdump but I suppose for writing the data into a binary
file it isn't as well suited as the above loop. I seem to remember a
tool that could be used to dump EDID directly, but I can't get a fix on
the name.

Anyway, if you can get the EDID data that way it should also be possible
to get it directly within tegra-drm.

Thierry

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

Re: [PATCH] tegra: ventana: display and backlight DT entries

[Stephen Warren]

On 11/13/2012 10:36 PM, Alex Courbot wrote:
> On Wednesday 14 November 2012 00:46:52 Stephen Warren wrote:
>> I do tend to think that we should use EDID where there is one.
>>
>> 1) If there is an EDID in the panel HW, and the panel's I2C is hooked
>> up to Tegra, we should read it out at runtime.
> 
> According to Ventana' platform design guide the LCD panel is hooked on I2C2. 
> The panel's data sheet lists CLK_EDID and DATA_EDID pins, which I assume are 
> for I2C, but there is no mention of an I2C address in both guides.

EDID would always be on I2C address 0x50.

>> 2) Otherwise, if the panel's documentation provides an EDID, we should
>> use that, since it's the most canonical/common/standard representation
>> of the panel's properties.
> 
> Panel's documentation indeed provides full EDID specification in appendix. Mark 
> sent me an EDID blob which works but I don't know where it comes from - Mark, 
> could you tell us?
>
>> 3) Otherwise, use the videomode DT bindings.
>>
>> Another benefit of (2) is that we can actually support the panel
>> without waiting for the videomode DT bindings to be finalized and merged.
> 
> Is there another incentive for preferring (2) over (3)? EDID specs can easily 
> be turned into videomode bindings, and it would also avoid introducing a new 
> file into the kernel source.

If there's an EDID, it is the canonical representation of the display's
features. As such, we should use it directly rather than encoded it into
a different format. Also, the EDID provides much more information than
the display mode bindings, e.g. vendor/model name, serial number, IIRC
perhaps some (limited?) color space information, etc.

>> Although if Ventana requires the power sequences helpers, that already
>> means we won't be able to support Ventana's panel in 3.8 unless the
>> power sequences code gets merged for 3.8; is that likely?
> 
> Likely, I don't know, possible - maybe. Power seqs work and I could push to 
> get them merged, but the following points need to be considered:
> - DT bindings are likely to change from their current form. I want to take 
> advantage of the gpio API changes that are undergoing, and also probably of 
> your preprocessor patch for dtc (not sure if that is already usable in the 
> kernel?). Considering the feature is young I don't think a DT change would be 
> a big deal, but the general consensus seems to be that DT bindings are 
> immutable - maybe my perception is wrong?

The DT bindings are certainly supposed to be fixed. I'm still not
convinced that there is any mileage at all in changing the DT bindings
for GPIOs as part of the power sequences or similar work; the GPIO
bindings have been around for years and can't change.

> - If I am to take maintainership of the feature, I guess I will have to get 
> the patches sufficiently Ack'ed by enough people, and also have someone else 
> pull from my tree (Linus? Or maybe some other power maintainer?). I am not 
> familiar with the exact procedure here - moreover, my GPG key only has one 
> signature from a trusted kernel dev, I am not sure if this is enough.

It's probably best to go ask whoever maintains the rest of the code in
the directory above where you placed it. See if they'll take your pull
request. If not, you can try sending directly to Linus, CCing enough
other known people to get acks (I think you already collected a few right?)

Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Alex Courbot]

On Thursday 15 November 2012 00:09:48 Stephen Warren wrote:
> On 11/13/2012 10:36 PM, Alex Courbot wrote:
> > - If I am to take maintainership of the feature, I guess I will have to
> > get
> > the patches sufficiently Ack'ed by enough people, and also have someone
> > else pull from my tree (Linus? Or maybe some other power maintainer?). I
> > am not familiar with the exact procedure here - moreover, my GPG key only
> > has one signature from a trusted kernel dev, I am not sure if this is
> > enough.
> It's probably best to go ask whoever maintains the rest of the code in
> the directory above where you placed it. See if they'll take your pull
> request. If not, you can try sending directly to Linus, CCing enough
> other known people to get acks (I think you already collected a few right?)

Anton, David, would you agree to pull power sequences support from my tree 
(considering I will maintain it)? It will reside in drivers/power/power_seq 
and as it is not a major feature it might not be worth dealing with Linus 
directly.

The feature has gone through 5 review cycles, received some Acks and is being 
used by the pwm-backlight driver and very probably others in the future (I am 
particularly thinking about the panel framework which is likely to need them). 
We would like to push Tegra display support in 3.8, and this feature will be 
needed to support our reference boards. Please let me know if you would be the 
right intermediate or if I should ask someone else.

Thanks,
Alex.

Re: Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Anton Vorontsov]

On Thu, Nov 15, 2012 at 02:45:44PM +0900, Alex Courbot wrote:
> On Thursday 15 November 2012 00:09:48 Stephen Warren wrote:
> > On 11/13/2012 10:36 PM, Alex Courbot wrote:
> > > - If I am to take maintainership of the feature, I guess I will have to
> > > get
> > > the patches sufficiently Ack'ed by enough people, and also have someone
> > > else pull from my tree (Linus? Or maybe some other power maintainer?). I
> > > am not familiar with the exact procedure here - moreover, my GPG key only
> > > has one signature from a trusted kernel dev, I am not sure if this is
> > > enough.
> > It's probably best to go ask whoever maintains the rest of the code in
> > the directory above where you placed it. See if they'll take your pull
> > request. If not, you can try sending directly to Linus, CCing enough
> > other known people to get acks (I think you already collected a few right?)
> 
> Anton, David, would you agree to pull power sequences support from my tree 
> (considering I will maintain it)? It will reside in drivers/power/power_seq 
> and as it is not a major feature it might not be worth dealing with Linus 
> directly.
> 
> The feature has gone through 5 review cycles, received some Acks and is being 
> used by the pwm-backlight driver and very probably others in the future (I am 
> particularly thinking about the panel framework which is likely to need them). 
> We would like to push Tegra display support in 3.8, and this feature will be 
> needed to support our reference boards. Please let me know if you would be the 
> right intermediate or if I should ask someone else.

Sure, I can easily pull your tree (assuming you guys agree on the
subsystem design, i.e. if the code has no strong NAKs).

Thanks,
Anton.

Re: Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Alex Courbot]

On Thursday 15 November 2012 14:03:10 Anton Vorontsov wrote:
> On Thu, Nov 15, 2012 at 02:45:44PM +0900, Alex Courbot wrote:
> > Anton, David, would you agree to pull power sequences support from my tree
> >  (considering I will maintain it)? It will reside in
> > drivers/power/power_seq and as it is not a major feature it might not be
> > worth dealing with Linus directly.
> > 
> > The feature has gone through 5 review cycles, received some Acks and is
> > being  used by the pwm-backlight driver and very probably others in the
> > future (I am particularly thinking about the panel framework which is
> > likely to need them). We would like to push Tegra display support in 3.8,
> > and this feature will be needed to support our reference boards. Please
> > let me know if you would be the right intermediate or if I should ask
> > someone else.
> 
> Sure, I can easily pull your tree (assuming you guys agree on the
> subsystem design, i.e. if the code has no strong NAKs).

Excellent, thanks - when would you need the code in order to be on time for 
3.8?

Alex.

Re: Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Anton Vorontsov]

On Thu, Nov 15, 2012 at 03:09:10PM +0900, Alex Courbot wrote:
> > > The feature has gone through 5 review cycles, received some Acks and is
> > > being  used by the pwm-backlight driver and very probably others in the
> > > future (I am particularly thinking about the panel framework which is
> > > likely to need them). We would like to push Tegra display support in 3.8,
> > > and this feature will be needed to support our reference boards. Please
> > > let me know if you would be the right intermediate or if I should ask
> > > someone else.
> > 
> > Sure, I can easily pull your tree (assuming you guys agree on the
> > subsystem design, i.e. if the code has no strong NAKs).
> 
> Excellent, thanks - when would you need the code in order to be on time for 
> 3.8?

Generally, that would be one week before the merge window, i.e. when Linus
announces that some -rc is the last one.

Thanks,
Anton.

Re: Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Alex Courbot]

On Thursday 15 November 2012 14:25:02 Anton Vorontsov wrote:
> > Excellent, thanks - when would you need the code in order to be on time
> > for 3.8?
> 
> 
> Generally, that would be one week before the merge window, i.e. when Linus
> announces that some -rc is the last one.

Ok, I will try to make sure you get something at least during the weekend. 
Would like to post a new revision today in order to get some more Acks though.

Btw, when issuing my pull request to you, should I place Linus or someone else 
in CC? We are introducing a new feature in the kernel, and since you are the 
intermediate he might not hear about it otherwise. I am not very familiar with 
the chain of trust of the kernel yet.

Thanks,
Alex.

Re: Power sequences upstreaming (Was: Re: [PATCH] tegra: ventana: display and backlight DT entries)

[Anton Vorontsov]

On Fri, Nov 16, 2012 at 02:52:12PM +0900, Alex Courbot wrote:
> On Thursday 15 November 2012 14:25:02 Anton Vorontsov wrote:
> > > Excellent, thanks - when would you need the code in order to be on time
> > > for 3.8?
> > 
> > Generally, that would be one week before the merge window, i.e. when Linus
> > announces that some -rc is the last one.
> 
> Ok, I will try to make sure you get something at least during the weekend. 
> Would like to post a new revision today in order to get some more Acks though.
> 
> Btw, when issuing my pull request to you, should I place Linus or someone else 
> in CC? We are introducing a new feature in the kernel, and since you are the 
> intermediate he might not hear about it otherwise. I am not very familiar with 
> the chain of trust of the kernel yet.

It's up to you. Usually, though, there's no reason to do so, unless it's a
major feature (e.g. a new general purpose filesystem or architecture, or a
vast memory management rework) or contraversal feature (with people
constantly arguing about it).

Thanks,
Anton.