Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>]

Hi Doug, Sean:

I would like to move this forward.

On 26 February 2018 at 15:23, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul <seanpaul@chromium.org> wrote:
>> This patch adds an override mode for kevin devices. The mode increases
>> both back porches to allow a pixel clock of 26666kHz as opposed to the
>> 'typical' value of 252750kHz. This is needed to avoid interference with
>> the touch digitizer on these laptops.
>>
>> Changes in v2:
>>  - Wrap the timing in display-timings node to match binding (Rob/Thierry)
>> Changes in v3:
>>  - Unwrap the timing from display-timings and rename panel-timing (Rob)
>>
>> Cc: Doug Anderson <dianders@chromium.org>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Heiko Stuebner <heiko@sntech.de>
>> Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Stéphane Marchesin <marcheu@chromium.org>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Cc: devicetree@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: linux-rockchip@lists.infradead.org
>> Signed-off-by: Sean Paul <seanpaul@chromium.org>
>> ---
>>  arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++++++++++++++
>>  1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>> index 191a6bcb1704..658411ce37ea 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
>> @@ -98,6 +98,20 @@
>>                 backlight = <&backlight>;
>>                 power-supply = <&pp3300_disp>;
>>
>> +               panel-timing {
>> +                       clock-frequency = <266604720>;
>> +                       hactive = <2400>;
>> +                       hfront-porch = <48>;
>> +                       hback-porch = <84>;
>> +                       hsync-len = <32>;
>> +                       hsync-active = <0>;
>> +                       vactive = <1600>;
>> +                       vfront-porch = <3>;
>> +                       vback-porch = <120>;
>> +                       vsync-len = <10>;
>> +                       vsync-active = <0>;
>> +               };
>> +
>>                 ports {
>>                         panel_in_edp: endpoint {
>>                                 remote-endpoint = <&edp_out_panel>;
>
> Kristian brought an old bug to my attention
> <https://bugs.chromium.org/p/chromium/issues/detail?id=750354> and it
> made me think.  Should we somehow adjust the bindings here to account
> for the fact that a board may source several different panels?
>
> AKA: on some boards an ODM may want to second source (or third source,
> or ...) the panel.  They'll randomly connect several different panels
> to the board and ship the boards out.  The panels are all compatible
> electrically (same power sequencing) but might need slightly different
> timings.  In this particular case there's no board-level strappings
> for the different panels--it's assumed that the EDID on the panels can
> be used to distinguish them.
>
> In that case it seems like it would be nice to allow specifying more
> than one "panel-timing" nodes.  Maybe keyed off some type of ID that's
> present in the EDID?
>
>
> Is that something we'd want to account for before we land this series?
>  It seems like it would just be adding an extra level of nodes?
>

AFAICS, there is no EDID without a DDC bus, which we don't
seem to have on gru platforms, do we?

Regards,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel