Hi,
On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> Cc: Eric Anholt <eric@xxxxxxxxxx>
> Cc: Heiko Stuebner <heiko@xxxxxxxxx>
> Cc: Jeffy Chen <jeffy.chen@xxxxxxxxxxxxxx>
> Cc: Rob Herring <robh+dt@xxxxxxxxxx>
> Cc: Stéphane Marchesin <marcheu@xxxxxxxxxxxx>
> Cc: Thierry Reding <thierry.reding@xxxxxxxxx>
> Cc: devicetree@xxxxxxxxxxxxxxx
> Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> Cc: linux-rockchip@xxxxxxxxxxxxxxxxxxx
> Signed-off-by: Sean Paul <seanpaul@xxxxxxxxxxxx>
> ---
> 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?
-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
