On Mon, Feb 26, 2018 at 10:23:00AM -0800, Doug Anderson wrote:
> 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?
If you've got an EDID you should be relying on the EDID to provide the
timings. No need to have any timings in the DT in that case.
Thierry
Attachment:
signature.asc
Description: PGP signature
