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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
