| Message ID | 1352802204-1740-1-git-send-email-acourbot@nvidia.com |
|---|---|
| State | Deferred, archived |
| Headers | show |
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@nvidia.com> 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
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? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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?) -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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";
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@nvidia.com> --- 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.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