[PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Douglas Anderson]

I'm reviving Sean Paul's old patchset to get mode support in device
tree.  The cover letter for his v3 is at:
https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html

No code is different between v4 and v5, just commit messages and text
in the bindings.

I've pulled together the patches that didn't land in v3, addressed
outstanding feedback, and reposted.  Atop them I've added patches for
rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
rk3288-veryon-minnie.

Please let me know how they look.

In general I have added people to the whole series who I think would
like the whole series and then let get_maintainer pick extra people it
thinks are relevant to each individual patch.  If I see you respond to
any of the patches in the series, though, I'll add you to the whole
series Cc list next time.

Changes in v5:
- Removed bit about OS may ignore (Rob/Ezequiel)
- Added Heiko's Tested-by
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- Simplify desc. for when override should be used (Thierry/Laurent)
- Removed Rob H review since it's been a year and wording changed
- Don't add mode from timing if override was specified (Thierry)
- Add warning if timing and fixed mode was specified (Thierry)
- Don't add fixed mode if timing was specified (Thierry)
- Refactor/rename a bit to avoid extra indentation from "if" tests
- i should be unsigned (Thierry)
- Add annoying WARN_ONs for some cases (Thierry)
- Simplify 'No display_timing found' handling (Thierry)
- Rename to panel_simple_parse_override_mode() (Thierry)
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.
- display_timing for Innolux n116bge new for v4.
- display_timing for AUO b101ean01 new for v4.
- rk3288-veyron-jerry patch new for v4.
- rk3288-veyron-minnie patch new for v4.

Changes in v3:
- Go back to using the timing subnode directly, but rename to
  panel-timing (Rob)
- No longer parse display-timings subnode, use panel-timing (Rob)
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Split out the binding into a new patch (Rob)
- display-timings is a new section (Rob)
- Use the full display-timings subnode instead of picking the timing
  out (Rob/Thierry)
- Parse the full display-timings node (using the native-mode) (Rob)
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

Douglas Anderson (4):
  drm/panel: simple: Use display_timing for Innolux n116bge
  drm/panel: simple: Use display_timing for AUO b101ean01
  ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
  ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

Sean Paul (3):
  dt-bindings: Add panel-timing subnode to simple-panel
  drm/panel: simple: Add ability to override typical timing
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/simple-panel.txt   |  22 +++
 .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
 .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
 drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
 5 files changed, 203 insertions(+), 32 deletions(-)

-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Douglas Anderson]

I'm reviving Sean Paul's old patchset to get mode support in device
tree.  The cover letter for his v3 is at:
https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html

No code is different between v4 and v5, just commit messages and text
in the bindings.

I've pulled together the patches that didn't land in v3, addressed
outstanding feedback, and reposted.  Atop them I've added patches for
rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
rk3288-veryon-minnie.

Please let me know how they look.

In general I have added people to the whole series who I think would
like the whole series and then let get_maintainer pick extra people it
thinks are relevant to each individual patch.  If I see you respond to
any of the patches in the series, though, I'll add you to the whole
series Cc list next time.

Changes in v5:
- Removed bit about OS may ignore (Rob/Ezequiel)
- Added Heiko's Tested-by
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- Simplify desc. for when override should be used (Thierry/Laurent)
- Removed Rob H review since it's been a year and wording changed
- Don't add mode from timing if override was specified (Thierry)
- Add warning if timing and fixed mode was specified (Thierry)
- Don't add fixed mode if timing was specified (Thierry)
- Refactor/rename a bit to avoid extra indentation from "if" tests
- i should be unsigned (Thierry)
- Add annoying WARN_ONs for some cases (Thierry)
- Simplify 'No display_timing found' handling (Thierry)
- Rename to panel_simple_parse_override_mode() (Thierry)
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.
- display_timing for Innolux n116bge new for v4.
- display_timing for AUO b101ean01 new for v4.
- rk3288-veyron-jerry patch new for v4.
- rk3288-veyron-minnie patch new for v4.

Changes in v3:
- Go back to using the timing subnode directly, but rename to
  panel-timing (Rob)
- No longer parse display-timings subnode, use panel-timing (Rob)
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Split out the binding into a new patch (Rob)
- display-timings is a new section (Rob)
- Use the full display-timings subnode instead of picking the timing
  out (Rob/Thierry)
- Parse the full display-timings node (using the native-mode) (Rob)
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

Douglas Anderson (4):
  drm/panel: simple: Use display_timing for Innolux n116bge
  drm/panel: simple: Use display_timing for AUO b101ean01
  ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
  ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

Sean Paul (3):
  dt-bindings: Add panel-timing subnode to simple-panel
  drm/panel: simple: Add ability to override typical timing
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/simple-panel.txt   |  22 +++
 .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
 .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
 drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
 5 files changed, 203 insertions(+), 32 deletions(-)

-- 
2.21.0.392.gf8f6787159e-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Douglas Anderson]

I'm reviving Sean Paul's old patchset to get mode support in device
tree.  The cover letter for his v3 is at:
https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html

No code is different between v4 and v5, just commit messages and text
in the bindings.

I've pulled together the patches that didn't land in v3, addressed
outstanding feedback, and reposted.  Atop them I've added patches for
rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
rk3288-veryon-minnie.

Please let me know how they look.

In general I have added people to the whole series who I think would
like the whole series and then let get_maintainer pick extra people it
thinks are relevant to each individual patch.  If I see you respond to
any of the patches in the series, though, I'll add you to the whole
series Cc list next time.

Changes in v5:
- Removed bit about OS may ignore (Rob/Ezequiel)
- Added Heiko's Tested-by
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- Simplify desc. for when override should be used (Thierry/Laurent)
- Removed Rob H review since it's been a year and wording changed
- Don't add mode from timing if override was specified (Thierry)
- Add warning if timing and fixed mode was specified (Thierry)
- Don't add fixed mode if timing was specified (Thierry)
- Refactor/rename a bit to avoid extra indentation from "if" tests
- i should be unsigned (Thierry)
- Add annoying WARN_ONs for some cases (Thierry)
- Simplify 'No display_timing found' handling (Thierry)
- Rename to panel_simple_parse_override_mode() (Thierry)
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.
- display_timing for Innolux n116bge new for v4.
- display_timing for AUO b101ean01 new for v4.
- rk3288-veyron-jerry patch new for v4.
- rk3288-veyron-minnie patch new for v4.

Changes in v3:
- Go back to using the timing subnode directly, but rename to
  panel-timing (Rob)
- No longer parse display-timings subnode, use panel-timing (Rob)
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Split out the binding into a new patch (Rob)
- display-timings is a new section (Rob)
- Use the full display-timings subnode instead of picking the timing
  out (Rob/Thierry)
- Parse the full display-timings node (using the native-mode) (Rob)
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

Douglas Anderson (4):
  drm/panel: simple: Use display_timing for Innolux n116bge
  drm/panel: simple: Use display_timing for AUO b101ean01
  ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
  ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

Sean Paul (3):
  dt-bindings: Add panel-timing subnode to simple-panel
  drm/panel: simple: Add ability to override typical timing
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/simple-panel.txt   |  22 +++
 .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
 .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
 drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
 5 files changed, 203 insertions(+), 32 deletions(-)

-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.

Changes in v2:
 - Split out the binding into a new patch (Rob)
 - display-timings is a new section (Rob)
 - Use the full display-timings subnode instead of picking the timing
   out (Rob/Thierry)
Changes in v3:
 - Go back to using the timing subnode directly, but rename to
   panel-timing (Rob)
Changes in v4:
 - Simplify desc. for when override should be used (Thierry/Laurent)
 - Removed Rob H review since it's been a year and wording changed
Changes in v5:
 - Removed bit about OS may ignore (Rob/Ezequiel)

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>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..93882268c0b9 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -15,6 +15,16 @@ Optional properties:
   (hot plug detect) signal, but the signal isn't hooked up so we should
   hardcode the max delay from the panel spec when powering up the panel.
 
+panel-timing subnode
+--------------------
+
+This optional subnode is for devices which require a mode differing
+from the panel's "typical" display timing.
+
+Format information on the panel-timing subnode can be found in
+display-timing.txt.
+
+
 Example:
 
 	panel: panel {
@@ -25,4 +35,16 @@ Example:
 		enable-gpios = <&gpio 90 0>;
 
 		backlight = <&backlight>;
+
+		panel-timing {
+			clock-frequency = <266604720>;
+			hactive = <2400>;
+			hfront-porch = <48>;
+			hback-porch = <84>;
+			hsync-len = <32>;
+			vactive = <1600>;
+			vfront-porch = <3>;
+			vback-porch = <120>;
+			vsync-len = <10>;
+		};
 	};
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.

Changes in v2:
 - Split out the binding into a new patch (Rob)
 - display-timings is a new section (Rob)
 - Use the full display-timings subnode instead of picking the timing
   out (Rob/Thierry)
Changes in v3:
 - Go back to using the timing subnode directly, but rename to
   panel-timing (Rob)
Changes in v4:
 - Simplify desc. for when override should be used (Thierry/Laurent)
 - Removed Rob H review since it's been a year and wording changed
Changes in v5:
 - Removed bit about OS may ignore (Rob/Ezequiel)

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>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..93882268c0b9 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -15,6 +15,16 @@ Optional properties:
   (hot plug detect) signal, but the signal isn't hooked up so we should
   hardcode the max delay from the panel spec when powering up the panel.
 
+panel-timing subnode
+--------------------
+
+This optional subnode is for devices which require a mode differing
+from the panel's "typical" display timing.
+
+Format information on the panel-timing subnode can be found in
+display-timing.txt.
+
+
 Example:
 
 	panel: panel {
@@ -25,4 +35,16 @@ Example:
 		enable-gpios = <&gpio 90 0>;
 
 		backlight = <&backlight>;
+
+		panel-timing {
+			clock-frequency = <266604720>;
+			hactive = <2400>;
+			hfront-porch = <48>;
+			hback-porch = <84>;
+			hsync-len = <32>;
+			vactive = <1600>;
+			vfront-porch = <3>;
+			vback-porch = <120>;
+			vsync-len = <10>;
+		};
 	};
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Rob Herring]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

On Mon,  1 Apr 2019 10:17:18 -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Rob Herring]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

On Mon,  1 Apr 2019 10:17:18 -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Boris Brezillon]

On Mon,  1 Apr 2019 10:17:18 -0700
Douglas Anderson <dianders@chromium.org> wrote:

> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..93882268c0b9 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -15,6 +15,16 @@ Optional properties:
>    (hot plug detect) signal, but the signal isn't hooked up so we should
>    hardcode the max delay from the panel spec when powering up the panel.
>  
> +panel-timing subnode
> +--------------------
> +
> +This optional subnode is for devices which require a mode differing
> +from the panel's "typical" display timing.
> +
> +Format information on the panel-timing subnode can be found in
> +display-timing.txt.
> +
> +
>  Example:
>  
>  	panel: panel {
> @@ -25,4 +35,16 @@ Example:
>  		enable-gpios = <&gpio 90 0>;
>  
>  		backlight = <&backlight>;
> +
> +		panel-timing {
> +			clock-frequency = <266604720>;
> +			hactive = <2400>;
> +			hfront-porch = <48>;
> +			hback-porch = <84>;
> +			hsync-len = <32>;
> +			vactive = <1600>;
> +			vfront-porch = <3>;
> +			vback-porch = <120>;
> +			vsync-len = <10>;
> +		};
>  	};

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..93882268c0b9 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -15,6 +15,16 @@ Optional properties:
>    (hot plug detect) signal, but the signal isn't hooked up so we should
>    hardcode the max delay from the panel spec when powering up the panel.
>  
> +panel-timing subnode

Is there any reason why we need the panel- prefix? This is already part
of a panel definition, so it's completely redundant. Why not just name
the subnode "timing"?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Thierry,

On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
> >
> > Changes in v2:
> >  - Split out the binding into a new patch (Rob)
> >  - display-timings is a new section (Rob)
> >  - Use the full display-timings subnode instead of picking the timing
> >    out (Rob/Thierry)
> > Changes in v3:
> >  - Go back to using the timing subnode directly, but rename to
> >    panel-timing (Rob)
> > Changes in v4:
> >  - Simplify desc. for when override should be used (Thierry/Laurent)
> >  - Removed Rob H review since it's been a year and wording changed
> > Changes in v5:
> >  - Removed bit about OS may ignore (Rob/Ezequiel)
> >
> > 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>
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index b2b872c710f2..93882268c0b9 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -15,6 +15,16 @@ Optional properties:
> >    (hot plug detect) signal, but the signal isn't hooked up so we should
> >    hardcode the max delay from the panel spec when powering up the panel.
> >
> > +panel-timing subnode
>
> Is there any reason why we need the panel- prefix? This is already part
> of a panel definition, so it's completely redundant. Why not just name
> the subnode "timing"?

It was a really long time ago since this patch series was idle for a
while, but you previous had similar feedback in v3 but ended up OK
with it.  See:

https://patchwork.kernel.org/patch/10207583/

I believe the original node name came out of some back and forth
between Rob and Sean.  As far as I can tell, the context is back in
<https://patchwork.kernel.org/patch/10203483/>.  I think Rob wanted it
to follow other similar node names.


That all being said, if you feel strongly about it being called
"timing" and Rob's OK w/ that too then I'll re-spin the series.

-Doug

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Thierry,

On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
> >
> > Changes in v2:
> >  - Split out the binding into a new patch (Rob)
> >  - display-timings is a new section (Rob)
> >  - Use the full display-timings subnode instead of picking the timing
> >    out (Rob/Thierry)
> > Changes in v3:
> >  - Go back to using the timing subnode directly, but rename to
> >    panel-timing (Rob)
> > Changes in v4:
> >  - Simplify desc. for when override should be used (Thierry/Laurent)
> >  - Removed Rob H review since it's been a year and wording changed
> > Changes in v5:
> >  - Removed bit about OS may ignore (Rob/Ezequiel)
> >
> > 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>
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index b2b872c710f2..93882268c0b9 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -15,6 +15,16 @@ Optional properties:
> >    (hot plug detect) signal, but the signal isn't hooked up so we should
> >    hardcode the max delay from the panel spec when powering up the panel.
> >
> > +panel-timing subnode
>
> Is there any reason why we need the panel- prefix? This is already part
> of a panel definition, so it's completely redundant. Why not just name
> the subnode "timing"?

It was a really long time ago since this patch series was idle for a
while, but you previous had similar feedback in v3 but ended up OK
with it.  See:

https://patchwork.kernel.org/patch/10207583/

I believe the original node name came out of some back and forth
between Rob and Sean.  As far as I can tell, the context is back in
<https://patchwork.kernel.org/patch/10203483/>.  I think Rob wanted it
to follow other similar node names.


That all being said, if you feel strongly about it being called
"timing" and Rob's OK w/ that too then I'll re-spin the series.

-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Thierry,

On Mon, Apr 8, 2019 at 7:39 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Thierry,
>
> On Mon, Apr 8, 2019 at 3:32 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > > From: Sean Paul <seanpaul@chromium.org>
> > >
> > > This patch adds a new subnode to simple-panel allowing us to override
> > > the typical timing expressed in the panel's display_timing.
> > >
> > > Changes in v2:
> > >  - Split out the binding into a new patch (Rob)
> > >  - display-timings is a new section (Rob)
> > >  - Use the full display-timings subnode instead of picking the timing
> > >    out (Rob/Thierry)
> > > Changes in v3:
> > >  - Go back to using the timing subnode directly, but rename to
> > >    panel-timing (Rob)
> > > Changes in v4:
> > >  - Simplify desc. for when override should be used (Thierry/Laurent)
> > >  - Removed Rob H review since it's been a year and wording changed
> > > Changes in v5:
> > >  - Removed bit about OS may ignore (Rob/Ezequiel)
> > >
> > > 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>
> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > ---
> > >
> > >  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
> > >  1 file changed, 22 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > index b2b872c710f2..93882268c0b9 100644
> > > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > > @@ -15,6 +15,16 @@ Optional properties:
> > >    (hot plug detect) signal, but the signal isn't hooked up so we should
> > >    hardcode the max delay from the panel spec when powering up the panel.
> > >
> > > +panel-timing subnode
> >
> > Is there any reason why we need the panel- prefix? This is already part
> > of a panel definition, so it's completely redundant. Why not just name
> > the subnode "timing"?
>
> It was a really long time ago since this patch series was idle for a
> while, but you previous had similar feedback in v3 but ended up OK
> with it.  See:
>
> https://patchwork.kernel.org/patch/10207583/
>
> I believe the original node name came out of some back and forth
> between Rob and Sean.  As far as I can tell, the context is back in
> <https://patchwork.kernel.org/patch/10203483/>.  I think Rob wanted it
> to follow other similar node names.
>
>
> That all being said, if you feel strongly about it being called
> "timing" and Rob's OK w/ that too then I'll re-spin the series.

With 5.2-rc1 out, maybe this series is ready to land?  If you'd like
me to change things as per above I can.  ...but it feels like keeping
the already-agreed-upon name might be easiest / best?  Presumably
you'd land patches 1, 2, 4, and 5 and then Heiko could land the dts
patches?

Thanks!

-Doug

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]

On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)

Sorry for taking so long to get back to this, sounds good to me:

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1588 bytes --]

On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)

Sorry for taking so long to get back to this, sounds good to me:

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Sam Ravnborg]

Hi Douglas.

Some long overdue review feedback.

On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..93882268c0b9 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -15,6 +15,16 @@ Optional properties:
>    (hot plug detect) signal, but the signal isn't hooked up so we should
>    hardcode the max delay from the panel spec when powering up the panel.
>  
> +panel-timing subnode
> +--------------------
> +
> +This optional subnode is for devices which require a mode differing
> +from the panel's "typical" display timing.
Meybe add here that it is expected that the panel has included timing
in the driver itself, and not as part of DT.
So what is specified here is a more precise variant, within the limits
of what is specified for the panel.

> +
> +Format information on the panel-timing subnode can be found in
> +display-timing.txt.
display-timing defines otional properties:
hsync-active, pixelclk-active, doublescan etc.
It is not from the above obvious which properties from display-timings
that can be specified for a panel-timing sub-node.
Maybe because they can all be specified?

Display-timing allows timings to be specified as a range.
If it is also OK to specify a range for panle-timing then everythign is
fine. But if the panel-timign subnode do not allow ranges this needs to
be specified.

> +
> +
>  Example:
>  
>  	panel: panel {
> @@ -25,4 +35,16 @@ Example:
>  		enable-gpios = <&gpio 90 0>;
>  
>  		backlight = <&backlight>;
> +
> +		panel-timing {
> +			clock-frequency = <266604720>;
> +			hactive = <2400>;
> +			hfront-porch = <48>;
> +			hback-porch = <84>;
> +			hsync-len = <32>;
> +			vactive = <1600>;
> +			vfront-porch = <3>;
> +			vback-porch = <120>;
> +			vsync-len = <10>;
> +		};
>  	};
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Sam Ravnborg]

Hi Douglas.

Some long overdue review feedback.

On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
> 
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>    out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>    panel-timing (Rob)
> Changes in v4:
>  - Simplify desc. for when override should be used (Thierry/Laurent)
>  - Removed Rob H review since it's been a year and wording changed
> Changes in v5:
>  - Removed bit about OS may ignore (Rob/Ezequiel)
> 
> 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>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> index b2b872c710f2..93882268c0b9 100644
> --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> @@ -15,6 +15,16 @@ Optional properties:
>    (hot plug detect) signal, but the signal isn't hooked up so we should
>    hardcode the max delay from the panel spec when powering up the panel.
>  
> +panel-timing subnode
> +--------------------
> +
> +This optional subnode is for devices which require a mode differing
> +from the panel's "typical" display timing.
Meybe add here that it is expected that the panel has included timing
in the driver itself, and not as part of DT.
So what is specified here is a more precise variant, within the limits
of what is specified for the panel.

> +
> +Format information on the panel-timing subnode can be found in
> +display-timing.txt.
display-timing defines otional properties:
hsync-active, pixelclk-active, doublescan etc.
It is not from the above obvious which properties from display-timings
that can be specified for a panel-timing sub-node.
Maybe because they can all be specified?

Display-timing allows timings to be specified as a range.
If it is also OK to specify a range for panle-timing then everythign is
fine. But if the panel-timign subnode do not allow ranges this needs to
be specified.

> +
> +
>  Example:
>  
>  	panel: panel {
> @@ -25,4 +35,16 @@ Example:
>  		enable-gpios = <&gpio 90 0>;
>  
>  		backlight = <&backlight>;
> +
> +		panel-timing {
> +			clock-frequency = <266604720>;
> +			hactive = <2400>;
> +			hfront-porch = <48>;
> +			hback-porch = <84>;
> +			hsync-len = <32>;
> +			vactive = <1600>;
> +			vfront-porch = <3>;
> +			vback-porch = <120>;
> +			vsync-len = <10>;
> +		};
>  	};
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:03 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> Some long overdue review feedback.
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
> >
> > Changes in v2:
> >  - Split out the binding into a new patch (Rob)
> >  - display-timings is a new section (Rob)
> >  - Use the full display-timings subnode instead of picking the timing
> >    out (Rob/Thierry)
> > Changes in v3:
> >  - Go back to using the timing subnode directly, but rename to
> >    panel-timing (Rob)
> > Changes in v4:
> >  - Simplify desc. for when override should be used (Thierry/Laurent)
> >  - Removed Rob H review since it's been a year and wording changed
> > Changes in v5:
> >  - Removed bit about OS may ignore (Rob/Ezequiel)
> >
> > 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>
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index b2b872c710f2..93882268c0b9 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -15,6 +15,16 @@ Optional properties:
> >    (hot plug detect) signal, but the signal isn't hooked up so we should
> >    hardcode the max delay from the panel spec when powering up the panel.
> >
> > +panel-timing subnode
> > +--------------------
> > +
> > +This optional subnode is for devices which require a mode differing
> > +from the panel's "typical" display timing.
> Meybe add here that it is expected that the panel has included timing
> in the driver itself, and not as part of DT.
> So what is specified here is a more precise variant, within the limits
> of what is specified for the panel.

See discussions previous versions of this patch.  Specifically you can
see v4 at <https://patchwork.kernel.org/patch/10875505/> and v3
(posted by Sean) at <https://patchwork.kernel.org/patch/10207591/>.

Specifically: According to Rob H it is generally not required to
validate what's in device tree--it can be just blindly applied.  Thus
the bindings shouldn't really say anything about trying to reconcile
with the driver (especially since that's heavily relying on the
current driver implementation).

At the moment the driver still does validate things and we could
discuss removing that in a future patchset if it was deemed important
/ desirable.


> > +Format information on the panel-timing subnode can be found in
> > +display-timing.txt.
> display-timing defines otional properties:
> hsync-active, pixelclk-active, doublescan etc.
> It is not from the above obvious which properties from display-timings
> that can be specified for a panel-timing sub-node.
> Maybe because they can all be specified?
>
> Display-timing allows timings to be specified as a range.
> If it is also OK to specify a range for panle-timing then everythign is
> fine. But if the panel-timign subnode do not allow ranges this needs to
> be specified.

One thing to think about here is that the bindings are a bit divorced
from the real world.  Specifically the bindings should describe
hardware / what's possible and it's OK for bindings to describe things
that aren't yet supported in code.  You've gotta be really careful
here, of course, because it's easy to write ridiculous bindings if
there is no implementation backing them up, but in general that's
supposed to be the idea.

Here it seems like it should be possible to specify timings as a range
and that would be a sensible thing to do.  ...and we're already using
existing code to parse this node, specifically
of_get_display_timing().  If simple-panel can't (yet) handle
reconciling ranges specified in DT then presumably we shouldn't rely
on that yet.  ...but if it becomes useful then we can add it later.
...but it's OK to already have it in the bindings.

Did that make sense?  If I'm misunderstanding something about the
situation then please yell!  :-)

I will also note that perhaps we shouldn't nit-pick too much as per
Rob's comment in the cover letter [1] of v5 of the series.
Specifically he said this binding is going away anyway.

Summary: I think I have no actions here and this could go to drm-misc
with Theirry's Ack plus other tags.


[1] https://lore.kernel.org/patchwork/cover/1057038/

Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:03 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> Some long overdue review feedback.
>
> On Mon, Apr 01, 2019 at 10:17:18AM -0700, Douglas Anderson wrote:
> > From: Sean Paul <seanpaul@chromium.org>
> >
> > This patch adds a new subnode to simple-panel allowing us to override
> > the typical timing expressed in the panel's display_timing.
> >
> > Changes in v2:
> >  - Split out the binding into a new patch (Rob)
> >  - display-timings is a new section (Rob)
> >  - Use the full display-timings subnode instead of picking the timing
> >    out (Rob/Thierry)
> > Changes in v3:
> >  - Go back to using the timing subnode directly, but rename to
> >    panel-timing (Rob)
> > Changes in v4:
> >  - Simplify desc. for when override should be used (Thierry/Laurent)
> >  - Removed Rob H review since it's been a year and wording changed
> > Changes in v5:
> >  - Removed bit about OS may ignore (Rob/Ezequiel)
> >
> > 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>
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  .../bindings/display/panel/simple-panel.txt   | 22 +++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > index b2b872c710f2..93882268c0b9 100644
> > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > @@ -15,6 +15,16 @@ Optional properties:
> >    (hot plug detect) signal, but the signal isn't hooked up so we should
> >    hardcode the max delay from the panel spec when powering up the panel.
> >
> > +panel-timing subnode
> > +--------------------
> > +
> > +This optional subnode is for devices which require a mode differing
> > +from the panel's "typical" display timing.
> Meybe add here that it is expected that the panel has included timing
> in the driver itself, and not as part of DT.
> So what is specified here is a more precise variant, within the limits
> of what is specified for the panel.

See discussions previous versions of this patch.  Specifically you can
see v4 at <https://patchwork.kernel.org/patch/10875505/> and v3
(posted by Sean) at <https://patchwork.kernel.org/patch/10207591/>.

Specifically: According to Rob H it is generally not required to
validate what's in device tree--it can be just blindly applied.  Thus
the bindings shouldn't really say anything about trying to reconcile
with the driver (especially since that's heavily relying on the
current driver implementation).

At the moment the driver still does validate things and we could
discuss removing that in a future patchset if it was deemed important
/ desirable.


> > +Format information on the panel-timing subnode can be found in
> > +display-timing.txt.
> display-timing defines otional properties:
> hsync-active, pixelclk-active, doublescan etc.
> It is not from the above obvious which properties from display-timings
> that can be specified for a panel-timing sub-node.
> Maybe because they can all be specified?
>
> Display-timing allows timings to be specified as a range.
> If it is also OK to specify a range for panle-timing then everythign is
> fine. But if the panel-timign subnode do not allow ranges this needs to
> be specified.

One thing to think about here is that the bindings are a bit divorced
from the real world.  Specifically the bindings should describe
hardware / what's possible and it's OK for bindings to describe things
that aren't yet supported in code.  You've gotta be really careful
here, of course, because it's easy to write ridiculous bindings if
there is no implementation backing them up, but in general that's
supposed to be the idea.

Here it seems like it should be possible to specify timings as a range
and that would be a sensible thing to do.  ...and we're already using
existing code to parse this node, specifically
of_get_display_timing().  If simple-panel can't (yet) handle
reconciling ranges specified in DT then presumably we shouldn't rely
on that yet.  ...but if it becomes useful then we can add it later.
...but it's OK to already have it in the bindings.

Did that make sense?  If I'm misunderstanding something about the
situation then please yell!  :-)

I will also note that perhaps we shouldn't nit-pick too much as per
Rob's comment in the cover letter [1] of v5 of the series.
Specifically he said this binding is going away anyway.

Summary: I think I have no actions here and this could go to drm-misc
with Theirry's Ack plus other tags.


[1] https://lore.kernel.org/patchwork/cover/1057038/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:

- panel must not specify fixed mode (since the override mode will
  either be the same as the fixed mode, or we'll be unable to
  check the bounds of the overried)
- panel must specify at least one display_timing range which will be
  used to ensure the override mode fits within its bounds

Changes in v2:
 - Parse the full display-timings node (using the native-mode) (Rob)
Changes in v3:
 - No longer parse display-timings subnode, use panel-timing (Rob)
Changes in v4:
 - Don't add mode from timing if override was specified (Thierry)
 - Add warning if timing and fixed mode was specified (Thierry)
 - Don't add fixed mode if timing was specified (Thierry)
 - Refactor/rename a bit to avoid extra indentation from "if" tests
 - i should be unsigned (Thierry)
 - Add annoying WARN_ONs for some cases (Thierry)
 - Simplify 'No display_timing found' handling (Thierry)
 - Rename to panel_simple_parse_override_mode() (Thierry)
Changes in v5:
 - Added Heiko's Tested-by

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
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---

 drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
 1 file changed, 104 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..ad4f4aac2d44 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -34,6 +34,7 @@
 #include <drm/drm_panel.h>
 
 #include <video/display_timing.h>
+#include <video/of_display_timing.h>
 #include <video/videomode.h>
 
 struct panel_desc {
@@ -91,6 +92,8 @@ struct panel_simple {
 	struct i2c_adapter *ddc;
 
 	struct gpio_desc *enable_gpio;
+
+	struct drm_display_mode override_mode;
 };
 
 static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
 	return container_of(panel, struct panel_simple, base);
 }
 
-static int panel_simple_get_fixed_modes(struct panel_simple *panel)
+static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
 {
 	struct drm_connector *connector = panel->base.connector;
 	struct drm_device *drm = panel->base.drm;
 	struct drm_display_mode *mode;
 	unsigned int i, num = 0;
 
-	if (!panel->desc)
-		return 0;
-
 	for (i = 0; i < panel->desc->num_timings; i++) {
 		const struct display_timing *dt = &panel->desc->timings[i];
 		struct videomode vm;
@@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
 		num++;
 	}
 
+	return num;
+}
+
+static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
+{
+	struct drm_connector *connector = panel->base.connector;
+	struct drm_device *drm = panel->base.drm;
+	struct drm_display_mode *mode;
+	unsigned int i, num = 0;
+
 	for (i = 0; i < panel->desc->num_modes; i++) {
 		const struct drm_display_mode *m = &panel->desc->modes[i];
 
@@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
 		num++;
 	}
 
+	return num;
+}
+
+static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
+{
+	struct drm_connector *connector = panel->base.connector;
+	struct drm_device *drm = panel->base.drm;
+	struct drm_display_mode *mode;
+	bool has_override = panel->override_mode.type;
+	unsigned int num = 0;
+
+	if (!panel->desc)
+		return 0;
+
+	if (has_override) {
+		mode = drm_mode_duplicate(drm, &panel->override_mode);
+		if (mode) {
+			drm_mode_probed_add(connector, mode);
+			num = 1;
+		} else {
+			dev_err(drm->dev, "failed to add override mode\n");
+		}
+	}
+
+	/* Only add timings if override was not there or failed to validate */
+	if (num == 0 && panel->desc->num_timings)
+		num = panel_simple_get_timings_modes(panel);
+
+	/*
+	 * Only add fixed modes if timings/override added no mode.
+	 *
+	 * We should only ever have either the display timings specified
+	 * or a fixed mode. Anything else is rather bogus.
+	 */
+	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
+	if (num == 0)
+		num = panel_simple_get_fixed_modes(panel);
+
 	connector->display_info.bpc = panel->desc->bpc;
 	connector->display_info.width_mm = panel->desc->size.width;
 	connector->display_info.height_mm = panel->desc->size.height;
@@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
 	}
 
 	/* add hard-coded panel modes */
-	num += panel_simple_get_fixed_modes(p);
+	num += panel_simple_get_non_edid_modes(p);
 
 	return num;
 }
@@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
 	.get_timings = panel_simple_get_timings,
 };
 
+#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
+	(to_check->field.typ >= bounds->field.min && \
+	 to_check->field.typ <= bounds->field.max)
+static void panel_simple_parse_override_mode(struct device *dev,
+					     struct panel_simple *panel,
+					     const struct display_timing *ot)
+{
+	const struct panel_desc *desc = panel->desc;
+	struct videomode vm;
+	unsigned int i;
+
+	if (WARN_ON(desc->num_modes)) {
+		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
+		return;
+	}
+	if (WARN_ON(!desc->num_timings)) {
+		dev_err(dev, "Reject override mode: no timings specified\n");
+		return;
+	}
+
+	for (i = 0; i < panel->desc->num_timings; i++) {
+		const struct display_timing *dt = &panel->desc->timings[i];
+
+		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
+			continue;
+
+		if (ot->flags != dt->flags)
+			continue;
+
+		videomode_from_timing(ot, &vm);
+		drm_display_mode_from_videomode(&vm, &panel->override_mode);
+		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
+					     DRM_MODE_TYPE_PREFERRED;
+		break;
+	}
+
+	if (WARN_ON(!panel->override_mode.type))
+		dev_err(dev, "Reject override mode: No display_timing found\n");
+}
+
 static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
 {
 	struct device_node *backlight, *ddc;
 	struct panel_simple *panel;
+	struct display_timing dt;
 	int err;
 
 	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
@@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
 		}
 	}
 
+	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
+		panel_simple_parse_override_mode(dev, panel, &dt);
+
 	drm_panel_init(&panel->base);
 	panel->base.dev = dev;
 	panel->base.funcs = &panel_simple_funcs;
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:

- panel must not specify fixed mode (since the override mode will
  either be the same as the fixed mode, or we'll be unable to
  check the bounds of the overried)
- panel must specify at least one display_timing range which will be
  used to ensure the override mode fits within its bounds

Changes in v2:
 - Parse the full display-timings node (using the native-mode) (Rob)
Changes in v3:
 - No longer parse display-timings subnode, use panel-timing (Rob)
Changes in v4:
 - Don't add mode from timing if override was specified (Thierry)
 - Add warning if timing and fixed mode was specified (Thierry)
 - Don't add fixed mode if timing was specified (Thierry)
 - Refactor/rename a bit to avoid extra indentation from "if" tests
 - i should be unsigned (Thierry)
 - Add annoying WARN_ONs for some cases (Thierry)
 - Simplify 'No display_timing found' handling (Thierry)
 - Rename to panel_simple_parse_override_mode() (Thierry)
Changes in v5:
 - Added Heiko's Tested-by

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
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---

 drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
 1 file changed, 104 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..ad4f4aac2d44 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -34,6 +34,7 @@
 #include <drm/drm_panel.h>
 
 #include <video/display_timing.h>
+#include <video/of_display_timing.h>
 #include <video/videomode.h>
 
 struct panel_desc {
@@ -91,6 +92,8 @@ struct panel_simple {
 	struct i2c_adapter *ddc;
 
 	struct gpio_desc *enable_gpio;
+
+	struct drm_display_mode override_mode;
 };
 
 static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
 	return container_of(panel, struct panel_simple, base);
 }
 
-static int panel_simple_get_fixed_modes(struct panel_simple *panel)
+static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
 {
 	struct drm_connector *connector = panel->base.connector;
 	struct drm_device *drm = panel->base.drm;
 	struct drm_display_mode *mode;
 	unsigned int i, num = 0;
 
-	if (!panel->desc)
-		return 0;
-
 	for (i = 0; i < panel->desc->num_timings; i++) {
 		const struct display_timing *dt = &panel->desc->timings[i];
 		struct videomode vm;
@@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
 		num++;
 	}
 
+	return num;
+}
+
+static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
+{
+	struct drm_connector *connector = panel->base.connector;
+	struct drm_device *drm = panel->base.drm;
+	struct drm_display_mode *mode;
+	unsigned int i, num = 0;
+
 	for (i = 0; i < panel->desc->num_modes; i++) {
 		const struct drm_display_mode *m = &panel->desc->modes[i];
 
@@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
 		num++;
 	}
 
+	return num;
+}
+
+static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
+{
+	struct drm_connector *connector = panel->base.connector;
+	struct drm_device *drm = panel->base.drm;
+	struct drm_display_mode *mode;
+	bool has_override = panel->override_mode.type;
+	unsigned int num = 0;
+
+	if (!panel->desc)
+		return 0;
+
+	if (has_override) {
+		mode = drm_mode_duplicate(drm, &panel->override_mode);
+		if (mode) {
+			drm_mode_probed_add(connector, mode);
+			num = 1;
+		} else {
+			dev_err(drm->dev, "failed to add override mode\n");
+		}
+	}
+
+	/* Only add timings if override was not there or failed to validate */
+	if (num == 0 && panel->desc->num_timings)
+		num = panel_simple_get_timings_modes(panel);
+
+	/*
+	 * Only add fixed modes if timings/override added no mode.
+	 *
+	 * We should only ever have either the display timings specified
+	 * or a fixed mode. Anything else is rather bogus.
+	 */
+	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
+	if (num == 0)
+		num = panel_simple_get_fixed_modes(panel);
+
 	connector->display_info.bpc = panel->desc->bpc;
 	connector->display_info.width_mm = panel->desc->size.width;
 	connector->display_info.height_mm = panel->desc->size.height;
@@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
 	}
 
 	/* add hard-coded panel modes */
-	num += panel_simple_get_fixed_modes(p);
+	num += panel_simple_get_non_edid_modes(p);
 
 	return num;
 }
@@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
 	.get_timings = panel_simple_get_timings,
 };
 
+#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
+	(to_check->field.typ >= bounds->field.min && \
+	 to_check->field.typ <= bounds->field.max)
+static void panel_simple_parse_override_mode(struct device *dev,
+					     struct panel_simple *panel,
+					     const struct display_timing *ot)
+{
+	const struct panel_desc *desc = panel->desc;
+	struct videomode vm;
+	unsigned int i;
+
+	if (WARN_ON(desc->num_modes)) {
+		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
+		return;
+	}
+	if (WARN_ON(!desc->num_timings)) {
+		dev_err(dev, "Reject override mode: no timings specified\n");
+		return;
+	}
+
+	for (i = 0; i < panel->desc->num_timings; i++) {
+		const struct display_timing *dt = &panel->desc->timings[i];
+
+		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
+		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
+			continue;
+
+		if (ot->flags != dt->flags)
+			continue;
+
+		videomode_from_timing(ot, &vm);
+		drm_display_mode_from_videomode(&vm, &panel->override_mode);
+		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
+					     DRM_MODE_TYPE_PREFERRED;
+		break;
+	}
+
+	if (WARN_ON(!panel->override_mode.type))
+		dev_err(dev, "Reject override mode: No display_timing found\n");
+}
+
 static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
 {
 	struct device_node *backlight, *ddc;
 	struct panel_simple *panel;
+	struct display_timing dt;
 	int err;
 
 	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
@@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
 		}
 	}
 
+	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
+		panel_simple_parse_override_mode(dev, panel, &dt);
+
 	drm_panel_init(&panel->base);
 	panel->base.dev = dev;
 	panel->base.funcs = &panel_simple_funcs;
-- 
2.21.0.392.gf8f6787159e-goog


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Boris Brezillon]

On Mon,  1 Apr 2019 10:17:19 -0700
Douglas Anderson <dianders@chromium.org> wrote:

> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..ad4f4aac2d44 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include <drm/drm_panel.h>
>  
>  #include <video/display_timing.h>
> +#include <video/of_display_timing.h>
>  #include <video/videomode.h>
>  
>  struct panel_desc {
> @@ -91,6 +92,8 @@ struct panel_simple {
>  	struct i2c_adapter *ddc;
>  
>  	struct gpio_desc *enable_gpio;
> +
> +	struct drm_display_mode override_mode;
>  };
>  
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
>  	return container_of(panel, struct panel_simple, base);
>  }
>  
> -static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
>  {
>  	struct drm_connector *connector = panel->base.connector;
>  	struct drm_device *drm = panel->base.drm;
>  	struct drm_display_mode *mode;
>  	unsigned int i, num = 0;
>  
> -	if (!panel->desc)
> -		return 0;
> -
>  	for (i = 0; i < panel->desc->num_timings; i++) {
>  		const struct display_timing *dt = &panel->desc->timings[i];
>  		struct videomode vm;
> @@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	unsigned int i, num = 0;
> +
>  	for (i = 0; i < panel->desc->num_modes; i++) {
>  		const struct drm_display_mode *m = &panel->desc->modes[i];
>  
> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	bool has_override = panel->override_mode.type;
> +	unsigned int num = 0;
> +
> +	if (!panel->desc)
> +		return 0;
> +
> +	if (has_override) {
> +		mode = drm_mode_duplicate(drm, &panel->override_mode);
> +		if (mode) {
> +			drm_mode_probed_add(connector, mode);
> +			num = 1;
> +		} else {
> +			dev_err(drm->dev, "failed to add override mode\n");
> +		}
> +	}
> +
> +	/* Only add timings if override was not there or failed to validate */
> +	if (num == 0 && panel->desc->num_timings)
> +		num = panel_simple_get_timings_modes(panel);
> +
> +	/*
> +	 * Only add fixed modes if timings/override added no mode.
> +	 *
> +	 * We should only ever have either the display timings specified
> +	 * or a fixed mode. Anything else is rather bogus.
> +	 */
> +	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
> +	if (num == 0)
> +		num = panel_simple_get_fixed_modes(panel);
> +
>  	connector->display_info.bpc = panel->desc->bpc;
>  	connector->display_info.width_mm = panel->desc->size.width;
>  	connector->display_info.height_mm = panel->desc->size.height;
> @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
>  	}
>  
>  	/* add hard-coded panel modes */
> -	num += panel_simple_get_fixed_modes(p);
> +	num += panel_simple_get_non_edid_modes(p);
>  
>  	return num;
>  }
> @@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
>  	.get_timings = panel_simple_get_timings,
>  };
>  
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +	(to_check->field.typ >= bounds->field.min && \
> +	 to_check->field.typ <= bounds->field.max)
> +static void panel_simple_parse_override_mode(struct device *dev,
> +					     struct panel_simple *panel,
> +					     const struct display_timing *ot)
> +{
> +	const struct panel_desc *desc = panel->desc;
> +	struct videomode vm;
> +	unsigned int i;
> +
> +	if (WARN_ON(desc->num_modes)) {
> +		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> +		return;
> +	}
> +	if (WARN_ON(!desc->num_timings)) {
> +		dev_err(dev, "Reject override mode: no timings specified\n");
> +		return;
> +	}
> +
> +	for (i = 0; i < panel->desc->num_timings; i++) {
> +		const struct display_timing *dt = &panel->desc->timings[i];
> +
> +		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> +			continue;
> +
> +		if (ot->flags != dt->flags)
> +			continue;
> +
> +		videomode_from_timing(ot, &vm);
> +		drm_display_mode_from_videomode(&vm, &panel->override_mode);
> +		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> +					     DRM_MODE_TYPE_PREFERRED;
> +		break;
> +	}
> +
> +	if (WARN_ON(!panel->override_mode.type))
> +		dev_err(dev, "Reject override mode: No display_timing found\n");
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  {
>  	struct device_node *backlight, *ddc;
>  	struct panel_simple *panel;
> +	struct display_timing dt;
>  	int err;
>  
>  	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  		}
>  	}
>  
> +	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> +		panel_simple_parse_override_mode(dev, panel, &dt);
> +
>  	drm_panel_init(&panel->base);
>  	panel->base.dev = dev;
>  	panel->base.funcs = &panel_simple_funcs;

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Boris Brezillon]

On Mon,  1 Apr 2019 10:17:19 -0700
Douglas Anderson <dianders@chromium.org> wrote:

> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..ad4f4aac2d44 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include <drm/drm_panel.h>
>  
>  #include <video/display_timing.h>
> +#include <video/of_display_timing.h>
>  #include <video/videomode.h>
>  
>  struct panel_desc {
> @@ -91,6 +92,8 @@ struct panel_simple {
>  	struct i2c_adapter *ddc;
>  
>  	struct gpio_desc *enable_gpio;
> +
> +	struct drm_display_mode override_mode;
>  };
>  
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
>  	return container_of(panel, struct panel_simple, base);
>  }
>  
> -static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
>  {
>  	struct drm_connector *connector = panel->base.connector;
>  	struct drm_device *drm = panel->base.drm;
>  	struct drm_display_mode *mode;
>  	unsigned int i, num = 0;
>  
> -	if (!panel->desc)
> -		return 0;
> -
>  	for (i = 0; i < panel->desc->num_timings; i++) {
>  		const struct display_timing *dt = &panel->desc->timings[i];
>  		struct videomode vm;
> @@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	unsigned int i, num = 0;
> +
>  	for (i = 0; i < panel->desc->num_modes; i++) {
>  		const struct drm_display_mode *m = &panel->desc->modes[i];
>  
> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	bool has_override = panel->override_mode.type;
> +	unsigned int num = 0;
> +
> +	if (!panel->desc)
> +		return 0;
> +
> +	if (has_override) {
> +		mode = drm_mode_duplicate(drm, &panel->override_mode);
> +		if (mode) {
> +			drm_mode_probed_add(connector, mode);
> +			num = 1;
> +		} else {
> +			dev_err(drm->dev, "failed to add override mode\n");
> +		}
> +	}
> +
> +	/* Only add timings if override was not there or failed to validate */
> +	if (num == 0 && panel->desc->num_timings)
> +		num = panel_simple_get_timings_modes(panel);
> +
> +	/*
> +	 * Only add fixed modes if timings/override added no mode.
> +	 *
> +	 * We should only ever have either the display timings specified
> +	 * or a fixed mode. Anything else is rather bogus.
> +	 */
> +	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
> +	if (num == 0)
> +		num = panel_simple_get_fixed_modes(panel);
> +
>  	connector->display_info.bpc = panel->desc->bpc;
>  	connector->display_info.width_mm = panel->desc->size.width;
>  	connector->display_info.height_mm = panel->desc->size.height;
> @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
>  	}
>  
>  	/* add hard-coded panel modes */
> -	num += panel_simple_get_fixed_modes(p);
> +	num += panel_simple_get_non_edid_modes(p);
>  
>  	return num;
>  }
> @@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
>  	.get_timings = panel_simple_get_timings,
>  };
>  
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +	(to_check->field.typ >= bounds->field.min && \
> +	 to_check->field.typ <= bounds->field.max)
> +static void panel_simple_parse_override_mode(struct device *dev,
> +					     struct panel_simple *panel,
> +					     const struct display_timing *ot)
> +{
> +	const struct panel_desc *desc = panel->desc;
> +	struct videomode vm;
> +	unsigned int i;
> +
> +	if (WARN_ON(desc->num_modes)) {
> +		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> +		return;
> +	}
> +	if (WARN_ON(!desc->num_timings)) {
> +		dev_err(dev, "Reject override mode: no timings specified\n");
> +		return;
> +	}
> +
> +	for (i = 0; i < panel->desc->num_timings; i++) {
> +		const struct display_timing *dt = &panel->desc->timings[i];
> +
> +		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> +			continue;
> +
> +		if (ot->flags != dt->flags)
> +			continue;
> +
> +		videomode_from_timing(ot, &vm);
> +		drm_display_mode_from_videomode(&vm, &panel->override_mode);
> +		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> +					     DRM_MODE_TYPE_PREFERRED;
> +		break;
> +	}
> +
> +	if (WARN_ON(!panel->override_mode.type))
> +		dev_err(dev, "Reject override mode: No display_timing found\n");
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  {
>  	struct device_node *backlight, *ddc;
>  	struct panel_simple *panel;
> +	struct display_timing dt;
>  	int err;
>  
>  	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  		}
>  	}
>  
> +	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> +		panel_simple_parse_override_mode(dev, panel, &dt);
> +
>  	drm_panel_init(&panel->base);
>  	panel->base.dev = dev;
>  	panel->base.funcs = &panel_simple_funcs;

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2264 bytes --]

On Mon, Apr 01, 2019 at 10:17:19AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2264 bytes --]

On Mon, Apr 01, 2019 at 10:17:19AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Douglas.

Again, long overdue. The review triggered several questions that you
should have had a long time ago.
Hopefully they makes sense to you.

	Sam

On Mon, Apr 01, 2019 at 10:17:19AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..ad4f4aac2d44 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include <drm/drm_panel.h>
>  
>  #include <video/display_timing.h>
> +#include <video/of_display_timing.h>
>  #include <video/videomode.h>
>  
>  struct panel_desc {
> @@ -91,6 +92,8 @@ struct panel_simple {
>  	struct i2c_adapter *ddc;
>  
>  	struct gpio_desc *enable_gpio;
> +
> +	struct drm_display_mode override_mode;
I fail to see where this poiter is assigned.


>  };
>  
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
>  	return container_of(panel, struct panel_simple, base);
>  }
>  
> -static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
>  {
>  	struct drm_connector *connector = panel->base.connector;
>  	struct drm_device *drm = panel->base.drm;
>  	struct drm_display_mode *mode;
>  	unsigned int i, num = 0;
>  
> -	if (!panel->desc)
> -		return 0;
> -
>  	for (i = 0; i < panel->desc->num_timings; i++) {
>  		const struct display_timing *dt = &panel->desc->timings[i];
>  		struct videomode vm;
> @@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	unsigned int i, num = 0;
> +
>  	for (i = 0; i < panel->desc->num_modes; i++) {
>  		const struct drm_display_mode *m = &panel->desc->modes[i];
>  
> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	bool has_override = panel->override_mode.type;
This looks suspicious.
panel->override_mode.type is an unsigned int that may have a number of
bits set.
So the above code implicitly convert a .type != 0 to a true.
This can be expressed in a much more reader friendly way.

And on top of this, I cannot see that panel->override_mode points to a
valid instance of display_mode, at least not always.
> +	unsigned int num = 0;
> +
> +	if (!panel->desc)
> +		return 0;
> +
> +	if (has_override) {
> +		mode = drm_mode_duplicate(drm, &panel->override_mode);
> +		if (mode) {
> +			drm_mode_probed_add(connector, mode);
> +			num = 1;
> +		} else {
> +			dev_err(drm->dev, "failed to add override mode\n");
> +		}
> +	}
> +
> +	/* Only add timings if override was not there or failed to validate */
> +	if (num == 0 && panel->desc->num_timings)
> +		num = panel_simple_get_timings_modes(panel);
> +
> +	/*
> +	 * Only add fixed modes if timings/override added no mode.

This part I fail to understand.
If we have a panel where we in panel-simple have specified the timings,
and done so using display_timing so with proper {min, typ, max} then it
should be perfectly legal to specify a more precise variant in the DT
file.
Or what did I miss here?

> +	 *
> +	 * We should only ever have either the display timings specified
> +	 * or a fixed mode. Anything else is rather bogus.
> +	 */
> +	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
> +	if (num == 0)
> +		num = panel_simple_get_fixed_modes(panel);
> +
>  	connector->display_info.bpc = panel->desc->bpc;
>  	connector->display_info.width_mm = panel->desc->size.width;
>  	connector->display_info.height_mm = panel->desc->size.height;
> @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
>  	}
>  
>  	/* add hard-coded panel modes */
> -	num += panel_simple_get_fixed_modes(p);
> +	num += panel_simple_get_non_edid_modes(p);
>  
>  	return num;
>  }
> @@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
>  	.get_timings = panel_simple_get_timings,
>  };
>  
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +	(to_check->field.typ >= bounds->field.min && \
> +	 to_check->field.typ <= bounds->field.max)
> +static void panel_simple_parse_override_mode(struct device *dev,
> +					     struct panel_simple *panel,
> +					     const struct display_timing *ot)
> +{
> +	const struct panel_desc *desc = panel->desc;
> +	struct videomode vm;
> +	unsigned int i;
> +
> +	if (WARN_ON(desc->num_modes)) {
> +		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> +		return;
> +	}
> +	if (WARN_ON(!desc->num_timings)) {
> +		dev_err(dev, "Reject override mode: no timings specified\n");
> +		return;
> +	}
> +
> +	for (i = 0; i < panel->desc->num_timings; i++) {
> +		const struct display_timing *dt = &panel->desc->timings[i];
> +
> +		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> +			continue;
> +
> +		if (ot->flags != dt->flags)
> +			continue;
The binding do not say anything about flags. Is this check really
needed?

> +
> +		videomode_from_timing(ot, &vm);
> +		drm_display_mode_from_videomode(&vm, &panel->override_mode);

> +		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> +					     DRM_MODE_TYPE_PREFERRED;
> +		break;
> +	}
> +
> +	if (WARN_ON(!panel->override_mode.type))
> +		dev_err(dev, "Reject override mode: No display_timing found\n");
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  {
>  	struct device_node *backlight, *ddc;
>  	struct panel_simple *panel;
> +	struct display_timing dt;
>  	int err;
>  
>  	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  		}
>  	}
>  
> +	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> +		panel_simple_parse_override_mode(dev, panel, &dt);
> +
Naming bike-shedding.
With the new node name, the function name
panel_simple_parse_override_mode() could use an update.
Maybe: panel_simple_parse_panel_timing_node()


>  	drm_panel_init(&panel->base);
>  	panel->base.dev = dev;
>  	panel->base.funcs = &panel_simple_funcs;
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Douglas.

Again, long overdue. The review triggered several questions that you
should have had a long time ago.
Hopefully they makes sense to you.

	Sam

On Mon, Apr 01, 2019 at 10:17:19AM -0700, Douglas Anderson wrote:
> From: Sean Paul <seanpaul@chromium.org>
> 
> This patch adds the ability to override the typical display timing for a
> given panel. This is useful for devices which have timing constraints
> that do not apply across the entire display driver (eg: to avoid
> crosstalk between panel and digitizer on certain laptops). The rules are
> as follows:
> 
> - panel must not specify fixed mode (since the override mode will
>   either be the same as the fixed mode, or we'll be unable to
>   check the bounds of the overried)
> - panel must specify at least one display_timing range which will be
>   used to ensure the override mode fits within its bounds
> 
> Changes in v2:
>  - Parse the full display-timings node (using the native-mode) (Rob)
> Changes in v3:
>  - No longer parse display-timings subnode, use panel-timing (Rob)
> Changes in v4:
>  - Don't add mode from timing if override was specified (Thierry)
>  - Add warning if timing and fixed mode was specified (Thierry)
>  - Don't add fixed mode if timing was specified (Thierry)
>  - Refactor/rename a bit to avoid extra indentation from "if" tests
>  - i should be unsigned (Thierry)
>  - Add annoying WARN_ONs for some cases (Thierry)
>  - Simplify 'No display_timing found' handling (Thierry)
>  - Rename to panel_simple_parse_override_mode() (Thierry)
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> 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
> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 109 +++++++++++++++++++++++++--
>  1 file changed, 104 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 9e8218f6a3f2..ad4f4aac2d44 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -34,6 +34,7 @@
>  #include <drm/drm_panel.h>
>  
>  #include <video/display_timing.h>
> +#include <video/of_display_timing.h>
>  #include <video/videomode.h>
>  
>  struct panel_desc {
> @@ -91,6 +92,8 @@ struct panel_simple {
>  	struct i2c_adapter *ddc;
>  
>  	struct gpio_desc *enable_gpio;
> +
> +	struct drm_display_mode override_mode;
I fail to see where this poiter is assigned.


>  };
>  
>  static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> @@ -98,16 +101,13 @@ static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
>  	return container_of(panel, struct panel_simple, base);
>  }
>  
> -static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
>  {
>  	struct drm_connector *connector = panel->base.connector;
>  	struct drm_device *drm = panel->base.drm;
>  	struct drm_display_mode *mode;
>  	unsigned int i, num = 0;
>  
> -	if (!panel->desc)
> -		return 0;
> -
>  	for (i = 0; i < panel->desc->num_timings; i++) {
>  		const struct display_timing *dt = &panel->desc->timings[i];
>  		struct videomode vm;
> @@ -131,6 +131,16 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	unsigned int i, num = 0;
> +
>  	for (i = 0; i < panel->desc->num_modes; i++) {
>  		const struct drm_display_mode *m = &panel->desc->modes[i];
>  
> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
>  		num++;
>  	}
>  
> +	return num;
> +}
> +
> +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> +{
> +	struct drm_connector *connector = panel->base.connector;
> +	struct drm_device *drm = panel->base.drm;
> +	struct drm_display_mode *mode;
> +	bool has_override = panel->override_mode.type;
This looks suspicious.
panel->override_mode.type is an unsigned int that may have a number of
bits set.
So the above code implicitly convert a .type != 0 to a true.
This can be expressed in a much more reader friendly way.

And on top of this, I cannot see that panel->override_mode points to a
valid instance of display_mode, at least not always.
> +	unsigned int num = 0;
> +
> +	if (!panel->desc)
> +		return 0;
> +
> +	if (has_override) {
> +		mode = drm_mode_duplicate(drm, &panel->override_mode);
> +		if (mode) {
> +			drm_mode_probed_add(connector, mode);
> +			num = 1;
> +		} else {
> +			dev_err(drm->dev, "failed to add override mode\n");
> +		}
> +	}
> +
> +	/* Only add timings if override was not there or failed to validate */
> +	if (num == 0 && panel->desc->num_timings)
> +		num = panel_simple_get_timings_modes(panel);
> +
> +	/*
> +	 * Only add fixed modes if timings/override added no mode.

This part I fail to understand.
If we have a panel where we in panel-simple have specified the timings,
and done so using display_timing so with proper {min, typ, max} then it
should be perfectly legal to specify a more precise variant in the DT
file.
Or what did I miss here?

> +	 *
> +	 * We should only ever have either the display timings specified
> +	 * or a fixed mode. Anything else is rather bogus.
> +	 */
> +	WARN_ON(panel->desc->num_timings && panel->desc->num_modes);
> +	if (num == 0)
> +		num = panel_simple_get_fixed_modes(panel);
> +
>  	connector->display_info.bpc = panel->desc->bpc;
>  	connector->display_info.width_mm = panel->desc->size.width;
>  	connector->display_info.height_mm = panel->desc->size.height;
> @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
>  	}
>  
>  	/* add hard-coded panel modes */
> -	num += panel_simple_get_fixed_modes(p);
> +	num += panel_simple_get_non_edid_modes(p);
>  
>  	return num;
>  }
> @@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
>  	.get_timings = panel_simple_get_timings,
>  };
>  
> +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> +	(to_check->field.typ >= bounds->field.min && \
> +	 to_check->field.typ <= bounds->field.max)
> +static void panel_simple_parse_override_mode(struct device *dev,
> +					     struct panel_simple *panel,
> +					     const struct display_timing *ot)
> +{
> +	const struct panel_desc *desc = panel->desc;
> +	struct videomode vm;
> +	unsigned int i;
> +
> +	if (WARN_ON(desc->num_modes)) {
> +		dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> +		return;
> +	}
> +	if (WARN_ON(!desc->num_timings)) {
> +		dev_err(dev, "Reject override mode: no timings specified\n");
> +		return;
> +	}
> +
> +	for (i = 0; i < panel->desc->num_timings; i++) {
> +		const struct display_timing *dt = &panel->desc->timings[i];
> +
> +		if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> +		    !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> +			continue;
> +
> +		if (ot->flags != dt->flags)
> +			continue;
The binding do not say anything about flags. Is this check really
needed?

> +
> +		videomode_from_timing(ot, &vm);
> +		drm_display_mode_from_videomode(&vm, &panel->override_mode);

> +		panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> +					     DRM_MODE_TYPE_PREFERRED;
> +		break;
> +	}
> +
> +	if (WARN_ON(!panel->override_mode.type))
> +		dev_err(dev, "Reject override mode: No display_timing found\n");
> +}
> +
>  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  {
>  	struct device_node *backlight, *ddc;
>  	struct panel_simple *panel;
> +	struct display_timing dt;
>  	int err;
>  
>  	panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> @@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
>  		}
>  	}
>  
> +	if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> +		panel_simple_parse_override_mode(dev, panel, &dt);
> +
Naming bike-shedding.
With the new node name, the function name
panel_simple_parse_override_mode() could use an update.
Maybe: panel_simple_parse_panel_timing_node()


>  	drm_panel_init(&panel->base);
>  	panel->base.dev = dev;
>  	panel->base.funcs = &panel_simple_funcs;
> -- 
> 2.21.0.392.gf8f6787159e-goog
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Douglas.

> > +
> > +	/* Only add timings if override was not there or failed to validate */
> > +	if (num == 0 && panel->desc->num_timings)
> > +		num = panel_simple_get_timings_modes(panel);
> > +
> > +	/*
> > +	 * Only add fixed modes if timings/override added no mode.
> 
> This part I fail to understand.
> If we have a panel where we in panel-simple have specified the timings,
> and done so using display_timing so with proper {min, typ, max} then it
> should be perfectly legal to specify a more precise variant in the DT
> file.
> Or what did I miss here?

Got it now.
If display_mode is used for timings this is what you call "fixed mode".
Hmm, if I got confused someone else may also be confused by this naming.

	Sam

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Douglas.

> > +
> > +	/* Only add timings if override was not there or failed to validate */
> > +	if (num == 0 && panel->desc->num_timings)
> > +		num = panel_simple_get_timings_modes(panel);
> > +
> > +	/*
> > +	 * Only add fixed modes if timings/override added no mode.
> 
> This part I fail to understand.
> If we have a panel where we in panel-simple have specified the timings,
> and done so using display_timing so with proper {min, typ, max} then it
> should be perfectly legal to specify a more precise variant in the DT
> file.
> Or what did I miss here?

Got it now.
If display_mode is used for timings this is what you call "fixed mode".
Hmm, if I got confused someone else may also be confused by this naming.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> > > +
> > > +   /* Only add timings if override was not there or failed to validate */
> > > +   if (num == 0 && panel->desc->num_timings)
> > > +           num = panel_simple_get_timings_modes(panel);
> > > +
> > > +   /*
> > > +    * Only add fixed modes if timings/override added no mode.
> >
> > This part I fail to understand.
> > If we have a panel where we in panel-simple have specified the timings,
> > and done so using display_timing so with proper {min, typ, max} then it
> > should be perfectly legal to specify a more precise variant in the DT
> > file.
> > Or what did I miss here?
>
> Got it now.
> If display_mode is used for timings this is what you call "fixed mode".
> Hmm, if I got confused someone else may also be confused by this naming.

The name "fixed mode" comes from the old code, though I guess in the
old code it used to refer to a mode that came from either the
display_timing or the display_mode.

How about if I call it "panel_simple_get_from_fixed_display_mode"?
...or if you have another suggestion feel free to chime in.

NOTE: Since this feedback is minor and this patch has been outstanding
for a while (and is blocking other work), I am assuming that the best
path forward is for Heiko to land this patch with Thierry's Ack and
I'll send a follow-up.  Please yell if you disagree.  I'll respond to
each of your emails separately and then wait for your response before
sending the follow-up series.


-Doug

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Douglas.
> >
> > > > +
> > > > +   /* Only add timings if override was not there or failed to validate */
> > > > +   if (num == 0 && panel->desc->num_timings)
> > > > +           num = panel_simple_get_timings_modes(panel);
> > > > +
> > > > +   /*
> > > > +    * Only add fixed modes if timings/override added no mode.
> > >
> > > This part I fail to understand.
> > > If we have a panel where we in panel-simple have specified the timings,
> > > and done so using display_timing so with proper {min, typ, max} then it
> > > should be perfectly legal to specify a more precise variant in the DT
> > > file.
> > > Or what did I miss here?
> >
> > Got it now.
> > If display_mode is used for timings this is what you call "fixed mode".
> > Hmm, if I got confused someone else may also be confused by this naming.
> 
> The name "fixed mode" comes from the old code, though I guess in the
> old code it used to refer to a mode that came from either the
> display_timing or the display_mode.
> 
> How about if I call it "panel_simple_get_from_fixed_display_mode"?
> ...or if you have another suggestion feel free to chime in.
What we really want to distingush here is the use of display_mode
and display_timings (if I got the names right).
That display_mode specify a fixed timing and display_timing specify
a valid range is something in the semantics of the two types.
So naming that refer to display_mode versus display_timing will make the
code simpler to understand. and then a nice comment that when
display_mode
is used one looses the possibility to use override_mode.
That would be fine to have in the struct in the driver.

> NOTE: Since this feedback is minor and this patch has been outstanding
> for a while (and is blocking other work), I am assuming that the best
> path forward is for Heiko to land this patch with Thierry's Ack and
> I'll send a follow-up.  Please yell if you disagree.
Let's give the patches a spin more as we have passed the possibility for
the current merge window.

I am on vacation at the moment and thus slow in responses, but will be back
at the home office next week and will be more responsive again.

	Sam - who is enjoying the alps in Austria

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Hi,

On Mon, Jul 8, 2019 at 10:56 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Douglas.
> > >
> > > > > +
> > > > > +   /* Only add timings if override was not there or failed to validate */
> > > > > +   if (num == 0 && panel->desc->num_timings)
> > > > > +           num = panel_simple_get_timings_modes(panel);
> > > > > +
> > > > > +   /*
> > > > > +    * Only add fixed modes if timings/override added no mode.
> > > >
> > > > This part I fail to understand.
> > > > If we have a panel where we in panel-simple have specified the timings,
> > > > and done so using display_timing so with proper {min, typ, max} then it
> > > > should be perfectly legal to specify a more precise variant in the DT
> > > > file.
> > > > Or what did I miss here?
> > >
> > > Got it now.
> > > If display_mode is used for timings this is what you call "fixed mode".
> > > Hmm, if I got confused someone else may also be confused by this naming.
> >
> > The name "fixed mode" comes from the old code, though I guess in the
> > old code it used to refer to a mode that came from either the
> > display_timing or the display_mode.
> >
> > How about if I call it "panel_simple_get_from_fixed_display_mode"?
> > ...or if you have another suggestion feel free to chime in.
> What we really want to distingush here is the use of display_mode
> and display_timings (if I got the names right).
> That display_mode specify a fixed timing and display_timing specify
> a valid range is something in the semantics of the two types.
> So naming that refer to display_mode versus display_timing will make the
> code simpler to understand. and then a nice comment that when
> display_mode
> is used one looses the possibility to use override_mode.
> That would be fine to have in the struct in the driver.

OK, I can change the names here and try to find a good place to add a comment.


> > NOTE: Since this feedback is minor and this patch has been outstanding
> > for a while (and is blocking other work), I am assuming that the best
> > path forward is for Heiko to land this patch with Thierry's Ack and
> > I'll send a follow-up.  Please yell if you disagree.
> Let's give the patches a spin more as we have passed the possibility for
> the current merge window.

Any way I can convince you to change your mind here?  There are no
functional changes requested so far in your feedback and no bugs--it's
just a few variable names and comments.  By landing the existing
patches as-is:

1. We stop spamming all the people CCed on this whole series (which
includes device tree patches) that might be interested in the series
as a whole but aren't interested in details.

2. We can debate the bikeshed-type issues on their own merit and I
don't have to debate removing existing Acks / Reviewed-by / Tested-by
tags as I make changes.

3. Even if it's not a good time to land the patches right now we know
that these patches will be ready to land as soon as the window opens.
As I mentioned earlier these patches are blocking other work [1] and
landing that patch is actually preventing Matthias from submitting
another series of patches to add support for rk3288-veyron-tiger and
rk3288-veyron-fievel.  Certainly I know that upstream doesn't make a
policy of landing things just to suit the timelines of a downstream
project, but in this case there seems very little downsides to landing
the existing patches and taking a later cleanup patch.


> I am on vacation at the moment and thus slow in responses, but will be back
> at the home office next week and will be more responsive again.
>
>         Sam - who is enjoying the alps in Austria

Hope you have had a great vacation!

[1] https://lkml.kernel.org/r/20190625222629.154619-1-mka@chromium.org

-Doug

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

On Wed, Jul 10, 2019 at 6:56 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Jul 8, 2019 at 10:56 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Hi Douglas.
> > > >
> > > > > > +
> > > > > > +   /* Only add timings if override was not there or failed to validate */
> > > > > > +   if (num == 0 && panel->desc->num_timings)
> > > > > > +           num = panel_simple_get_timings_modes(panel);
> > > > > > +
> > > > > > +   /*
> > > > > > +    * Only add fixed modes if timings/override added no mode.
> > > > >
> > > > > This part I fail to understand.
> > > > > If we have a panel where we in panel-simple have specified the timings,
> > > > > and done so using display_timing so with proper {min, typ, max} then it
> > > > > should be perfectly legal to specify a more precise variant in the DT
> > > > > file.
> > > > > Or what did I miss here?
> > > >
> > > > Got it now.
> > > > If display_mode is used for timings this is what you call "fixed mode".
> > > > Hmm, if I got confused someone else may also be confused by this naming.
> > >
> > > The name "fixed mode" comes from the old code, though I guess in the
> > > old code it used to refer to a mode that came from either the
> > > display_timing or the display_mode.
> > >
> > > How about if I call it "panel_simple_get_from_fixed_display_mode"?
> > > ...or if you have another suggestion feel free to chime in.
> > What we really want to distingush here is the use of display_mode
> > and display_timings (if I got the names right).
> > That display_mode specify a fixed timing and display_timing specify
> > a valid range is something in the semantics of the two types.
> > So naming that refer to display_mode versus display_timing will make the
> > code simpler to understand. and then a nice comment that when
> > display_mode
> > is used one looses the possibility to use override_mode.
> > That would be fine to have in the struct in the driver.
>
> OK, I can change the names here and try to find a good place to add a comment.
>
>
> > > NOTE: Since this feedback is minor and this patch has been outstanding
> > > for a while (and is blocking other work), I am assuming that the best
> > > path forward is for Heiko to land this patch with Thierry's Ack and
> > > I'll send a follow-up.  Please yell if you disagree.
> > Let's give the patches a spin more as we have passed the possibility for
> > the current merge window.
>
> Any way I can convince you to change your mind here?  There are no
> functional changes requested so far in your feedback and no bugs--it's
> just a few variable names and comments.  By landing the existing
> patches as-is:
>
> 1. We stop spamming all the people CCed on this whole series (which
> includes device tree patches) that might be interested in the series
> as a whole but aren't interested in details.
>
> 2. We can debate the bikeshed-type issues on their own merit and I
> don't have to debate removing existing Acks / Reviewed-by / Tested-by
> tags as I make changes.
>
> 3. Even if it's not a good time to land the patches right now we know
> that these patches will be ready to land as soon as the window opens.
> As I mentioned earlier these patches are blocking other work [1] and
> landing that patch is actually preventing Matthias from submitting
> another series of patches to add support for rk3288-veyron-tiger and
> rk3288-veyron-fievel.  Certainly I know that upstream doesn't make a
> policy of landing things just to suit the timelines of a downstream
> project, but in this case there seems very little downsides to landing
> the existing patches and taking a later cleanup patch.
>

[sending from my @chromium.org address so any appearance of bias is
explicit :) ]

Agree with Doug here, the naming and casting discussion is pretty
subjective and non-functional. We've got an Ack from Thierry and a
Review from Boris (both seasoned drm_panel'ers), this patch has been
sitting in review for a while. Let's not let the perfect be the enemy
of the good.

Sean

>
> > I am on vacation at the moment and thus slow in responses, but will be back
> > at the home office next week and will be more responsive again.
> >
> >         Sam - who is enjoying the alps in Austria
>
> Hope you have had a great vacation!
>
> [1] https://lkml.kernel.org/r/20190625222629.154619-1-mka@chromium.org
>
> -Doug

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

On Wed, Jul 10, 2019 at 6:56 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Jul 8, 2019 at 10:56 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > > >
> > > > Hi Douglas.
> > > >
> > > > > > +
> > > > > > +   /* Only add timings if override was not there or failed to validate */
> > > > > > +   if (num == 0 && panel->desc->num_timings)
> > > > > > +           num = panel_simple_get_timings_modes(panel);
> > > > > > +
> > > > > > +   /*
> > > > > > +    * Only add fixed modes if timings/override added no mode.
> > > > >
> > > > > This part I fail to understand.
> > > > > If we have a panel where we in panel-simple have specified the timings,
> > > > > and done so using display_timing so with proper {min, typ, max} then it
> > > > > should be perfectly legal to specify a more precise variant in the DT
> > > > > file.
> > > > > Or what did I miss here?
> > > >
> > > > Got it now.
> > > > If display_mode is used for timings this is what you call "fixed mode".
> > > > Hmm, if I got confused someone else may also be confused by this naming.
> > >
> > > The name "fixed mode" comes from the old code, though I guess in the
> > > old code it used to refer to a mode that came from either the
> > > display_timing or the display_mode.
> > >
> > > How about if I call it "panel_simple_get_from_fixed_display_mode"?
> > > ...or if you have another suggestion feel free to chime in.
> > What we really want to distingush here is the use of display_mode
> > and display_timings (if I got the names right).
> > That display_mode specify a fixed timing and display_timing specify
> > a valid range is something in the semantics of the two types.
> > So naming that refer to display_mode versus display_timing will make the
> > code simpler to understand. and then a nice comment that when
> > display_mode
> > is used one looses the possibility to use override_mode.
> > That would be fine to have in the struct in the driver.
>
> OK, I can change the names here and try to find a good place to add a comment.
>
>
> > > NOTE: Since this feedback is minor and this patch has been outstanding
> > > for a while (and is blocking other work), I am assuming that the best
> > > path forward is for Heiko to land this patch with Thierry's Ack and
> > > I'll send a follow-up.  Please yell if you disagree.
> > Let's give the patches a spin more as we have passed the possibility for
> > the current merge window.
>
> Any way I can convince you to change your mind here?  There are no
> functional changes requested so far in your feedback and no bugs--it's
> just a few variable names and comments.  By landing the existing
> patches as-is:
>
> 1. We stop spamming all the people CCed on this whole series (which
> includes device tree patches) that might be interested in the series
> as a whole but aren't interested in details.
>
> 2. We can debate the bikeshed-type issues on their own merit and I
> don't have to debate removing existing Acks / Reviewed-by / Tested-by
> tags as I make changes.
>
> 3. Even if it's not a good time to land the patches right now we know
> that these patches will be ready to land as soon as the window opens.
> As I mentioned earlier these patches are blocking other work [1] and
> landing that patch is actually preventing Matthias from submitting
> another series of patches to add support for rk3288-veyron-tiger and
> rk3288-veyron-fievel.  Certainly I know that upstream doesn't make a
> policy of landing things just to suit the timelines of a downstream
> project, but in this case there seems very little downsides to landing
> the existing patches and taking a later cleanup patch.
>

[sending from my @chromium.org address so any appearance of bias is
explicit :) ]

Agree with Doug here, the naming and casting discussion is pretty
subjective and non-functional. We've got an Ack from Thierry and a
Review from Boris (both seasoned drm_panel'ers), this patch has been
sitting in review for a while. Let's not let the perfect be the enemy
of the good.

Sean

>
> > I am on vacation at the moment and thus slow in responses, but will be back
> > at the home office next week and will be more responsive again.
> >
> >         Sam - who is enjoying the alps in Austria
>
> Hope you have had a great vacation!
>
> [1] https://lkml.kernel.org/r/20190625222629.154619-1-mka@chromium.org
>
> -Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Hi,

On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > @@ -91,6 +92,8 @@ struct panel_simple {
> >       struct i2c_adapter *ddc;
> >
> >       struct gpio_desc *enable_gpio;
> > +
> > +     struct drm_display_mode override_mode;
> I fail to see where this poiter is assigned.

In panel_simple_parse_override_mode().  Specifically:

drm_display_mode_from_videomode(&vm, &panel->override_mode);


> @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> >               num++;
> >       }
> >
> > +     return num;
> > +}
> > +
> > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > +{
> > +     struct drm_connector *connector = panel->base.connector;
> > +     struct drm_device *drm = panel->base.drm;
> > +     struct drm_display_mode *mode;
> > +     bool has_override = panel->override_mode.type;
> This looks suspicious.
> panel->override_mode.type is an unsigned int that may have a number of
> bits set.
> So the above code implicitly convert a .type != 0 to a true.
> This can be expressed in a much more reader friendly way.

You would suggest that I add a boolean field to a structure to
indicate whether an override mode is present?  I will certainly do
that if you're sure that's what you want, but my understanding of the
convention for much of the kernel is that you generally rely on
structures being zero-initialized and then (assuming that zero isn't a
valid value) it's safe to confirm they've been initialized by seeing
that they're non-zero.

In this case panel_simple_parse_override_mode() will _definitely_ set
a non-zero value for this field in the case that it ran to completion.
...and, even further, the end of that function has a WARN_ON() if it
doesn't.

Any chance you missed reading panel_simple_parse_override_mode() in
the original patch?


> And on top of this, I cannot see that panel->override_mode points to a
> valid instance of display_mode, at least not always.

override_mode isn't a pointer, right?  It's a structure straight in
the panel.  So all its fields will be initted to 0 by the kzalloc in
panel_simple_probe().  If the type is non-zero then we know
panel_simple_parse_override_mode() finished to completion.


> > @@ -268,7 +316,7 @@ static int panel_simple_get_modes(struct drm_panel *panel)
> >       }
> >
> >       /* add hard-coded panel modes */
> > -     num += panel_simple_get_fixed_modes(p);
> > +     num += panel_simple_get_non_edid_modes(p);
> >
> >       return num;
> >  }
> > @@ -299,10 +347,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
> >       .get_timings = panel_simple_get_timings,
> >  };
> >
> > +#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
> > +     (to_check->field.typ >= bounds->field.min && \
> > +      to_check->field.typ <= bounds->field.max)
> > +static void panel_simple_parse_override_mode(struct device *dev,
> > +                                          struct panel_simple *panel,
> > +                                          const struct display_timing *ot)
> > +{
> > +     const struct panel_desc *desc = panel->desc;
> > +     struct videomode vm;
> > +     unsigned int i;
> > +
> > +     if (WARN_ON(desc->num_modes)) {
> > +             dev_err(dev, "Reject override mode: panel has a fixed mode\n");
> > +             return;
> > +     }
> > +     if (WARN_ON(!desc->num_timings)) {
> > +             dev_err(dev, "Reject override mode: no timings specified\n");
> > +             return;
> > +     }
> > +
> > +     for (i = 0; i < panel->desc->num_timings; i++) {
> > +             const struct display_timing *dt = &panel->desc->timings[i];
> > +
> > +             if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
> > +                 !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
> > +                     continue;
> > +
> > +             if (ot->flags != dt->flags)
> > +                     continue;
> The binding do not say anything about flags. Is this check really
> needed?

Flags here is an implementation detail of the Linux driver and the
bindings are supposed to be Linux-agnostic.  The bindings started out
talking about lots of stuff that happened in the driver and I was told
to take all those out.  ;-)

Specifically note that flags here holds whether we have specified a
positive or negative for hsync or vsync.  These are the "hsync-active"
and "vsync-active" properties of the panel bindings.  Take a look at
of_parse_display_timing().

...so to summarize the flags here is just a different set of
properties to check like the checks above.


> > +
> > +             videomode_from_timing(ot, &vm);
> > +             drm_display_mode_from_videomode(&vm, &panel->override_mode);
>
> > +             panel->override_mode.type |= DRM_MODE_TYPE_DRIVER |
> > +                                          DRM_MODE_TYPE_PREFERRED;
> > +             break;
> > +     }
> > +
> > +     if (WARN_ON(!panel->override_mode.type))
> > +             dev_err(dev, "Reject override mode: No display_timing found\n");
> > +}
> > +
> >  static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> >  {
> >       struct device_node *backlight, *ddc;
> >       struct panel_simple *panel;
> > +     struct display_timing dt;
> >       int err;
> >
> >       panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL);
> > @@ -348,6 +444,9 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
> >               }
> >       }
> >
> > +     if (!of_get_display_timing(dev->of_node, "panel-timing", &dt))
> > +             panel_simple_parse_override_mode(dev, panel, &dt);
> > +
> Naming bike-shedding.
> With the new node name, the function name
> panel_simple_parse_override_mode() could use an update.
> Maybe: panel_simple_parse_panel_timing_node()

Happy to change the name to panel_simple_parse_panel_timing_node().

---

Summary of the above:

* Unless you say otherwise, I will leave the check of "type != 0" and
not introduce a new boolean.

* Only action request is rename of panel_simple_parse_override_mode()
to panel_simple_parse_panel_timing_node()

NOTE: Since this feedback is minor and this patch has been outstanding
for a while (and is blocking other work), I am assuming that the best
path forward is for Heiko to land this patch with Thierry's Ack and
I'll send a follow-up.  Please yell if you disagree.  I'll respond to
each of your emails separately and then wait for your response before
sending the follow-up series.


-Doug

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Dough.

On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > > @@ -91,6 +92,8 @@ struct panel_simple {
> > >       struct i2c_adapter *ddc;
> > >
> > >       struct gpio_desc *enable_gpio;
> > > +
> > > +     struct drm_display_mode override_mode;
> > I fail to see where this poiter is assigned.
> 
> In panel_simple_parse_override_mode().  Specifically:
> 
> drm_display_mode_from_videomode(&vm, &panel->override_mode);

The above code-snippet is only called in the panel has specified display
timings using display_timings - it is not called when display_mode is
used.
So override_mode is only assigned in some cases and not all cases.
This needs to be fixed so we do not reference override_mode unless
it is set.

> 
> 
> > @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> > >               num++;
> > >       }
> > >
> > > +     return num;
> > > +}
> > > +
> > > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > > +{
> > > +     struct drm_connector *connector = panel->base.connector;
> > > +     struct drm_device *drm = panel->base.drm;
> > > +     struct drm_display_mode *mode;
> > > +     bool has_override = panel->override_mode.type;
> > This looks suspicious.
> > panel->override_mode.type is an unsigned int that may have a number of
> > bits set.
> > So the above code implicitly convert a .type != 0 to a true.
> > This can be expressed in a much more reader friendly way.
> 
> You would suggest that I add a boolean field to a structure to
> indicate whether an override mode is present?
A simple  bool has_override = panel->override_mode.type != 0;
would do the trick here.
Then there is no hidden conversion from int to a bool.

But as override_mode can be NULL something more needs to be done.

	Sam

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Dough.

On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > > @@ -91,6 +92,8 @@ struct panel_simple {
> > >       struct i2c_adapter *ddc;
> > >
> > >       struct gpio_desc *enable_gpio;
> > > +
> > > +     struct drm_display_mode override_mode;
> > I fail to see where this poiter is assigned.
> 
> In panel_simple_parse_override_mode().  Specifically:
> 
> drm_display_mode_from_videomode(&vm, &panel->override_mode);

The above code-snippet is only called in the panel has specified display
timings using display_timings - it is not called when display_mode is
used.
So override_mode is only assigned in some cases and not all cases.
This needs to be fixed so we do not reference override_mode unless
it is set.

> 
> 
> > @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> > >               num++;
> > >       }
> > >
> > > +     return num;
> > > +}
> > > +
> > > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > > +{
> > > +     struct drm_connector *connector = panel->base.connector;
> > > +     struct drm_device *drm = panel->base.drm;
> > > +     struct drm_display_mode *mode;
> > > +     bool has_override = panel->override_mode.type;
> > This looks suspicious.
> > panel->override_mode.type is an unsigned int that may have a number of
> > bits set.
> > So the above code implicitly convert a .type != 0 to a true.
> > This can be expressed in a much more reader friendly way.
> 
> You would suggest that I add a boolean field to a structure to
> indicate whether an override mode is present?
A simple  bool has_override = panel->override_mode.type != 0;
would do the trick here.
Then there is no hidden conversion from int to a bool.

But as override_mode can be NULL something more needs to be done.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Sam,

On Mon, Jul 8, 2019 at 10:50 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Dough.
>
> On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > >       struct i2c_adapter *ddc;
> > > >
> > > >       struct gpio_desc *enable_gpio;
> > > > +
> > > > +     struct drm_display_mode override_mode;
> > > I fail to see where this poiter is assigned.
> >
> > In panel_simple_parse_override_mode().  Specifically:
> >
> > drm_display_mode_from_videomode(&vm, &panel->override_mode);
>
> The above code-snippet is only called in the panel has specified display
> timings using display_timings - it is not called when display_mode is
> used.
> So override_mode is only assigned in some cases and not all cases.
> This needs to be fixed so we do not reference override_mode unless
> it is set.

I'm afraid I'm not following you here.

* override_mode is a structure that's directly part of "struct panel_simple".

* The panel is allocated in panel_simple_probe() with devm_kzalloc().

* The "z" in kzalloc means that this memory will be zero-initialized.

From the points above, "override_mode" will always be set to
something.  If we didn't run "drm_display_mode_from_videomode(&vm,
&panel->override_mode);" then we know the entire override_mode
structure will be zero.

While it took a while for me to get used to it, the kernel convention
is to rely on zero-initialization and not to explicitly init things to
zero.  As an example of this being codified in the source, you can see
that "checkpatch.pl" will yell at you for a similar thing: "do not
initialise globals to 0".


> > > @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> > > >               num++;
> > > >       }
> > > >
> > > > +     return num;
> > > > +}
> > > > +
> > > > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > > > +{
> > > > +     struct drm_connector *connector = panel->base.connector;
> > > > +     struct drm_device *drm = panel->base.drm;
> > > > +     struct drm_display_mode *mode;
> > > > +     bool has_override = panel->override_mode.type;
> > > This looks suspicious.
> > > panel->override_mode.type is an unsigned int that may have a number of
> > > bits set.
> > > So the above code implicitly convert a .type != 0 to a true.
> > > This can be expressed in a much more reader friendly way.
> >
> > You would suggest that I add a boolean field to a structure to
> > indicate whether an override mode is present?
> A simple  bool has_override = panel->override_mode.type != 0;
> would do the trick here.
> Then there is no hidden conversion from int to a bool.

I will change this to "panel->override_mode.type != 0" if you're
really sure, but this seems both against the general Linux style
feedback I've received over the years (though there is definitely not
100% consistency) and also against the local convention in this file.
Examples in this file of treating ints as bools without an explicit
"!= 0":

* panel_simple_get_fixed_modes checks "if (panel->desc->bus_format)"
* panel_simple_disable checks "if (p->desc->delay.disable)"
* panel_simple_unprepare checks "if (p->desc->delay.unprepare)"
* panel_simple_prepare checks "if (delay)"
* panel_simple_enable checks "if (p->desc->delay.enable)"

...and, although slightly different, pointers in this file are checked
for NULL vs. non-NULL without an explicit "== NULL".

Of course just because all the other examples in the file do it one
way doesn't mean that new code has to do it another way, but I wanted
to be really sure you wanted me to go against the existing convention
before changing this.


> But as override_mode can be NULL something more needs to be done.

I'm afraid I don't understand how override_mode can be NULL since it's
not a pointer.  Can you clarify?


-Doug

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Doug Anderson]

Sam,

On Mon, Jul 8, 2019 at 10:50 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Dough.
>
> On Mon, Jul 01, 2019 at 09:39:24AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, Jun 30, 2019 at 1:22 PM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > >       struct i2c_adapter *ddc;
> > > >
> > > >       struct gpio_desc *enable_gpio;
> > > > +
> > > > +     struct drm_display_mode override_mode;
> > > I fail to see where this poiter is assigned.
> >
> > In panel_simple_parse_override_mode().  Specifically:
> >
> > drm_display_mode_from_videomode(&vm, &panel->override_mode);
>
> The above code-snippet is only called in the panel has specified display
> timings using display_timings - it is not called when display_mode is
> used.
> So override_mode is only assigned in some cases and not all cases.
> This needs to be fixed so we do not reference override_mode unless
> it is set.

I'm afraid I'm not following you here.

* override_mode is a structure that's directly part of "struct panel_simple".

* The panel is allocated in panel_simple_probe() with devm_kzalloc().

* The "z" in kzalloc means that this memory will be zero-initialized.

From the points above, "override_mode" will always be set to
something.  If we didn't run "drm_display_mode_from_videomode(&vm,
&panel->override_mode);" then we know the entire override_mode
structure will be zero.

While it took a while for me to get used to it, the kernel convention
is to rely on zero-initialization and not to explicitly init things to
zero.  As an example of this being codified in the source, you can see
that "checkpatch.pl" will yell at you for a similar thing: "do not
initialise globals to 0".


> > > @@ -152,6 +162,44 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
> > > >               num++;
> > > >       }
> > > >
> > > > +     return num;
> > > > +}
> > > > +
> > > > +static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
> > > > +{
> > > > +     struct drm_connector *connector = panel->base.connector;
> > > > +     struct drm_device *drm = panel->base.drm;
> > > > +     struct drm_display_mode *mode;
> > > > +     bool has_override = panel->override_mode.type;
> > > This looks suspicious.
> > > panel->override_mode.type is an unsigned int that may have a number of
> > > bits set.
> > > So the above code implicitly convert a .type != 0 to a true.
> > > This can be expressed in a much more reader friendly way.
> >
> > You would suggest that I add a boolean field to a structure to
> > indicate whether an override mode is present?
> A simple  bool has_override = panel->override_mode.type != 0;
> would do the trick here.
> Then there is no hidden conversion from int to a bool.

I will change this to "panel->override_mode.type != 0" if you're
really sure, but this seems both against the general Linux style
feedback I've received over the years (though there is definitely not
100% consistency) and also against the local convention in this file.
Examples in this file of treating ints as bools without an explicit
"!= 0":

* panel_simple_get_fixed_modes checks "if (panel->desc->bus_format)"
* panel_simple_disable checks "if (p->desc->delay.disable)"
* panel_simple_unprepare checks "if (p->desc->delay.unprepare)"
* panel_simple_prepare checks "if (delay)"
* panel_simple_enable checks "if (p->desc->delay.enable)"

...and, although slightly different, pointers in this file are checked
for NULL vs. non-NULL without an explicit "== NULL".

Of course just because all the other examples in the file do it one
way doesn't mean that new code has to do it another way, but I wanted
to be really sure you wanted me to go against the existing convention
before changing this.


> But as override_mode can be NULL something more needs to be done.

I'm afraid I don't understand how override_mode can be NULL since it's
not a pointer.  Can you clarify?


-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing

[Sam Ravnborg]

Hi Doug.

> > > > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > > >       struct i2c_adapter *ddc;
> > > > >
> > > > >       struct gpio_desc *enable_gpio;
> > > > > +
> > > > > +     struct drm_display_mode override_mode;
> > > > I fail to see where this poiter is assigned.
> > >
> > > In panel_simple_parse_override_mode().  Specifically:
> > >
> > > drm_display_mode_from_videomode(&vm, &panel->override_mode);
> >
> > The above code-snippet is only called in the panel has specified display
> > timings using display_timings - it is not called when display_mode is
> > used.
> > So override_mode is only assigned in some cases and not all cases.
> > This needs to be fixed so we do not reference override_mode unless
> > it is set.
> 
> I'm afraid I'm not following you here.

> 
> * override_mode is a structure that's directly part of "struct panel_simple".
I had somehow confused myself to think this was a pointer.
And you are right that override_mode is properly initialized when the
structure is allocated.

Sorry for not reading the code and your replies carefully enough.

	Sam

[PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

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.

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>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5: None
Changes in v4:
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.

Changes in v3:
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

 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 15e254a77391..454f4149585f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -43,6 +43,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>;
+		};
+
 		port {
 			panel_in_edp: endpoint {
 				remote-endpoint = <&edp_out_panel>;
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

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.

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>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5: None
Changes in v4:
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.

Changes in v3:
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

 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 15e254a77391..454f4149585f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -43,6 +43,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>;
+		};
+
 		port {
 			panel_in_edp: endpoint {
 				remote-endpoint = <&edp_out_panel>;
-- 
2.21.0.392.gf8f6787159e-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Douglas Anderson]

From: Sean Paul <seanpaul@chromium.org>

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.

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>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5: None
Changes in v4:
- Rebase to top of Heiko's tree
- Converted changelog to after-the-cut for non-DRM change.

Changes in v3:
- Unwrap the timing from display-timings and rename panel-timing (Rob)

Changes in v2:
- Wrap the timing in display-timings node to match binding (Rob/Thierry)

 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 15e254a77391..454f4149585f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -43,6 +43,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>;
+		};
+
 		port {
 			panel_in_edp: endpoint {
 				remote-endpoint = <&edp_out_panel>;
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:20 CEST schrieb Douglas Anderson:
> From: Sean Paul <seanpaul@chromium.org>
> 
> 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.
> 
> 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>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko

Re: [PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:20 CEST schrieb Douglas Anderson:
> From: Sean Paul <seanpaul@chromium.org>
> 
> 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.
> 
> 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>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:20 CEST schrieb Douglas Anderson:
> From: Sean Paul <seanpaul@chromium.org>
> 
> 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.
> 
> 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>
> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/7] drm/panel: simple: Use display_timing for Innolux n116bge

[Douglas Anderson]

Convert the Innolux n116bge from using a fixed mode to specifying a
display timing with min/typ/max values.

Note that the n116bge's datasheet doesn't fit too well into DRM's way
of specifying things.  Specifically the panel's datasheet just
specifies the vertical blanking period and horizontal blanking period
and doesn't break things out.  For now we'll leave everything as a
fixed value but just allow adjusting the pixel clock.  I've added a
comment on what the datasheet claims so someone could later expand
things to fit their needs if they wanted to test other blanking
periods.

The goal here is to be able to specify the panel timings in the device
tree for several rk3288 Chromebooks (like rk3288-veryon-jerry).  These
Chromebooks have all been running in the downstream kernel with the
standard porches and sync lengths but just with a slightly slower
pixel clock because the 76.42 MHz clock is not achievable from the
fixed PLL that was available.  These Chromebooks only achieve a
refresh rate of ~58 Hz.  While it's probable that we could adjust the
timings to achieve 60 Hz it's probably wisest to match what's been
running on these devices all these years.

I'll note that though the upstream kernel has always tried to achieve
76.42 MHz, it has actually been running at 74.25 MHz also since the
video processor is parented off the same fixed PLL.

Changes in v4:
 - display_timing for Innolux n116bge new for v4.

Changes in v5:
 - Added Heiko's Tested-by

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---

 drivers/gpu/drm/panel/panel-simple.c | 37 +++++++++++++++++-----------
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index ad4f4aac2d44..7d407fab3628 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1550,23 +1550,32 @@ static const struct panel_desc innolux_g121x1_l03 = {
 	},
 };
 
-static const struct drm_display_mode innolux_n116bge_mode = {
-	.clock = 76420,
-	.hdisplay = 1366,
-	.hsync_start = 1366 + 136,
-	.hsync_end = 1366 + 136 + 30,
-	.htotal = 1366 + 136 + 30 + 60,
-	.vdisplay = 768,
-	.vsync_start = 768 + 8,
-	.vsync_end = 768 + 8 + 12,
-	.vtotal = 768 + 8 + 12 + 12,
-	.vrefresh = 60,
-	.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+/*
+ * Datasheet specifies that at 60 Hz refresh rate:
+ * - total horizontal time: { 1506, 1592, 1716 }
+ * - total vertical time: { 788, 800, 868 }
+ *
+ * ...but doesn't go into exactly how that should be split into a front
+ * porch, back porch, or sync length.  For now we'll leave a single setting
+ * here which allows a bit of tweaking of the pixel clock at the expense of
+ * refresh rate.
+ */
+static const struct display_timing innolux_n116bge_timing = {
+	.pixelclock = { 72600000, 76420000, 80240000 },
+	.hactive = { 1366, 1366, 1366 },
+	.hfront_porch = { 136, 136, 136 },
+	.hback_porch = { 60, 60, 60 },
+	.hsync_len = { 30, 30, 30 },
+	.vactive = { 768, 768, 768 },
+	.vfront_porch = { 8, 8, 8 },
+	.vback_porch = { 12, 12, 12 },
+	.vsync_len = { 12, 12, 12 },
+	.flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
 };
 
 static const struct panel_desc innolux_n116bge = {
-	.modes = &innolux_n116bge_mode,
-	.num_modes = 1,
+	.timings = &innolux_n116bge_timing,
+	.num_timings = 1,
 	.bpc = 6,
 	.size = {
 		.width = 256,
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 4/7] drm/panel: simple: Use display_timing for Innolux n116bge

[Douglas Anderson]

Convert the Innolux n116bge from using a fixed mode to specifying a
display timing with min/typ/max values.

Note that the n116bge's datasheet doesn't fit too well into DRM's way
of specifying things.  Specifically the panel's datasheet just
specifies the vertical blanking period and horizontal blanking period
and doesn't break things out.  For now we'll leave everything as a
fixed value but just allow adjusting the pixel clock.  I've added a
comment on what the datasheet claims so someone could later expand
things to fit their needs if they wanted to test other blanking
periods.

The goal here is to be able to specify the panel timings in the device
tree for several rk3288 Chromebooks (like rk3288-veryon-jerry).  These
Chromebooks have all been running in the downstream kernel with the
standard porches and sync lengths but just with a slightly slower
pixel clock because the 76.42 MHz clock is not achievable from the
fixed PLL that was available.  These Chromebooks only achieve a
refresh rate of ~58 Hz.  While it's probable that we could adjust the
timings to achieve 60 Hz it's probably wisest to match what's been
running on these devices all these years.

I'll note that though the upstream kernel has always tried to achieve
76.42 MHz, it has actually been running at 74.25 MHz also since the
video processor is parented off the same fixed PLL.

Changes in v4:
 - display_timing for Innolux n116bge new for v4.

Changes in v5:
 - Added Heiko's Tested-by

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---

 drivers/gpu/drm/panel/panel-simple.c | 37 +++++++++++++++++-----------
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index ad4f4aac2d44..7d407fab3628 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1550,23 +1550,32 @@ static const struct panel_desc innolux_g121x1_l03 = {
 	},
 };
 
-static const struct drm_display_mode innolux_n116bge_mode = {
-	.clock = 76420,
-	.hdisplay = 1366,
-	.hsync_start = 1366 + 136,
-	.hsync_end = 1366 + 136 + 30,
-	.htotal = 1366 + 136 + 30 + 60,
-	.vdisplay = 768,
-	.vsync_start = 768 + 8,
-	.vsync_end = 768 + 8 + 12,
-	.vtotal = 768 + 8 + 12 + 12,
-	.vrefresh = 60,
-	.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+/*
+ * Datasheet specifies that at 60 Hz refresh rate:
+ * - total horizontal time: { 1506, 1592, 1716 }
+ * - total vertical time: { 788, 800, 868 }
+ *
+ * ...but doesn't go into exactly how that should be split into a front
+ * porch, back porch, or sync length.  For now we'll leave a single setting
+ * here which allows a bit of tweaking of the pixel clock at the expense of
+ * refresh rate.
+ */
+static const struct display_timing innolux_n116bge_timing = {
+	.pixelclock = { 72600000, 76420000, 80240000 },
+	.hactive = { 1366, 1366, 1366 },
+	.hfront_porch = { 136, 136, 136 },
+	.hback_porch = { 60, 60, 60 },
+	.hsync_len = { 30, 30, 30 },
+	.vactive = { 768, 768, 768 },
+	.vfront_porch = { 8, 8, 8 },
+	.vback_porch = { 12, 12, 12 },
+	.vsync_len = { 12, 12, 12 },
+	.flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
 };
 
 static const struct panel_desc innolux_n116bge = {
-	.modes = &innolux_n116bge_mode,
-	.num_modes = 1,
+	.timings = &innolux_n116bge_timing,
+	.num_timings = 1,
 	.bpc = 6,
 	.size = {
 		.width = 256,
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/7] drm/panel: simple: Use display_timing for Innolux n116bge

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

On Mon, Apr 01, 2019 at 10:17:21AM -0700, Douglas Anderson wrote:
> Convert the Innolux n116bge from using a fixed mode to specifying a
> display timing with min/typ/max values.
> 
> Note that the n116bge's datasheet doesn't fit too well into DRM's way
> of specifying things.  Specifically the panel's datasheet just
> specifies the vertical blanking period and horizontal blanking period
> and doesn't break things out.  For now we'll leave everything as a
> fixed value but just allow adjusting the pixel clock.  I've added a
> comment on what the datasheet claims so someone could later expand
> things to fit their needs if they wanted to test other blanking
> periods.
> 
> The goal here is to be able to specify the panel timings in the device
> tree for several rk3288 Chromebooks (like rk3288-veryon-jerry).  These
> Chromebooks have all been running in the downstream kernel with the
> standard porches and sync lengths but just with a slightly slower
> pixel clock because the 76.42 MHz clock is not achievable from the
> fixed PLL that was available.  These Chromebooks only achieve a
> refresh rate of ~58 Hz.  While it's probable that we could adjust the
> timings to achieve 60 Hz it's probably wisest to match what's been
> running on these devices all these years.
> 
> I'll note that though the upstream kernel has always tried to achieve
> 76.42 MHz, it has actually been running at 74.25 MHz also since the
> video processor is parented off the same fixed PLL.
> 
> Changes in v4:
>  - display_timing for Innolux n116bge new for v4.
> 
> Changes in v5:
>  - Added Heiko's Tested-by
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 37 +++++++++++++++++-----------
>  1 file changed, 23 insertions(+), 14 deletions(-)

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v5 5/7] drm/panel: simple: Use display_timing for AUO b101ean01

[Douglas Anderson]

Convert the AUO b101ean01 from using a fixed mode to specifying a
display timing with min/typ/max values.

The AUO b101ean01's datasheet says:
* Vertical blanking min is 12
* Horizontal blanking min is 60
* Pixel clock is between 65.3 MHz and 75 MHz

The goal here is to be able to specify the proper timing in device
tree to use on rk3288-veyron-minnie to match what the downstream
kernel is using so that it can used the fixed PLL.

Changes in v4:
 - display_timing for AUO b101ean01 new for v4.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 drivers/gpu/drm/panel/panel-simple.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 7d407fab3628..c6c0625e1684 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -568,22 +568,21 @@ static const struct panel_desc auo_b101aw03 = {
 	},
 };
 
-static const struct drm_display_mode auo_b101ean01_mode = {
-	.clock = 72500,
-	.hdisplay = 1280,
-	.hsync_start = 1280 + 119,
-	.hsync_end = 1280 + 119 + 32,
-	.htotal = 1280 + 119 + 32 + 21,
-	.vdisplay = 800,
-	.vsync_start = 800 + 4,
-	.vsync_end = 800 + 4 + 20,
-	.vtotal = 800 + 4 + 20 + 8,
-	.vrefresh = 60,
+static const struct display_timing auo_b101ean01_timing = {
+	.pixelclock = { 65300000, 72500000, 75000000 },
+	.hactive = { 1280, 1280, 1280 },
+	.hfront_porch = { 18, 119, 119 },
+	.hback_porch = { 21, 21, 21 },
+	.hsync_len = { 32, 32, 32 },
+	.vactive = { 800, 800, 800 },
+	.vfront_porch = { 4, 4, 4 },
+	.vback_porch = { 8, 8, 8 },
+	.vsync_len = { 18, 20, 20 },
 };
 
 static const struct panel_desc auo_b101ean01 = {
-	.modes = &auo_b101ean01_mode,
-	.num_modes = 1,
+	.timings = &auo_b101ean01_timing,
+	.num_timings = 1,
 	.bpc = 6,
 	.size = {
 		.width = 217,
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 5/7] drm/panel: simple: Use display_timing for AUO b101ean01

[Douglas Anderson]

Convert the AUO b101ean01 from using a fixed mode to specifying a
display timing with min/typ/max values.

The AUO b101ean01's datasheet says:
* Vertical blanking min is 12
* Horizontal blanking min is 60
* Pixel clock is between 65.3 MHz and 75 MHz

The goal here is to be able to specify the proper timing in device
tree to use on rk3288-veyron-minnie to match what the downstream
kernel is using so that it can used the fixed PLL.

Changes in v4:
 - display_timing for AUO b101ean01 new for v4.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 drivers/gpu/drm/panel/panel-simple.c | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 7d407fab3628..c6c0625e1684 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -568,22 +568,21 @@ static const struct panel_desc auo_b101aw03 = {
 	},
 };
 
-static const struct drm_display_mode auo_b101ean01_mode = {
-	.clock = 72500,
-	.hdisplay = 1280,
-	.hsync_start = 1280 + 119,
-	.hsync_end = 1280 + 119 + 32,
-	.htotal = 1280 + 119 + 32 + 21,
-	.vdisplay = 800,
-	.vsync_start = 800 + 4,
-	.vsync_end = 800 + 4 + 20,
-	.vtotal = 800 + 4 + 20 + 8,
-	.vrefresh = 60,
+static const struct display_timing auo_b101ean01_timing = {
+	.pixelclock = { 65300000, 72500000, 75000000 },
+	.hactive = { 1280, 1280, 1280 },
+	.hfront_porch = { 18, 119, 119 },
+	.hback_porch = { 21, 21, 21 },
+	.hsync_len = { 32, 32, 32 },
+	.vactive = { 800, 800, 800 },
+	.vfront_porch = { 4, 4, 4 },
+	.vback_porch = { 8, 8, 8 },
+	.vsync_len = { 18, 20, 20 },
 };
 
 static const struct panel_desc auo_b101ean01 = {
-	.modes = &auo_b101ean01_mode,
-	.num_modes = 1,
+	.timings = &auo_b101ean01_timing,
+	.num_timings = 1,
 	.bpc = 6,
 	.size = {
 		.width = 217,
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 5/7] drm/panel: simple: Use display_timing for AUO b101ean01

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Mon, Apr 01, 2019 at 10:17:22AM -0700, Douglas Anderson wrote:
> Convert the AUO b101ean01 from using a fixed mode to specifying a
> display timing with min/typ/max values.
> 
> The AUO b101ean01's datasheet says:
> * Vertical blanking min is 12
> * Horizontal blanking min is 60
> * Pixel clock is between 65.3 MHz and 75 MHz
> 
> The goal here is to be able to specify the proper timing in device
> tree to use on rk3288-veyron-minnie to match what the downstream
> kernel is using so that it can used the fixed PLL.
> 
> Changes in v4:
>  - display_timing for AUO b101ean01 new for v4.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  drivers/gpu/drm/panel/panel-simple.c | 25 ++++++++++++-------------
>  1 file changed, 12 insertions(+), 13 deletions(-)

Acked-by: Thierry Reding <thierry.reding@gmail.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Douglas Anderson]

Let's document the display timings that most veyron chromebooks (like
jaq, jerry, mighty, speedy) have been using out in the field.  This
uses the standard blankings but a slightly slower clock rate, thus
getting a refresh rate 58.3 Hz.

NOTE: this won't really do anything except cause DRM to properly
report the refresh rate since vop_crtc_mode_fixup() was rounding the
pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
exposed to userspace so it's important that the rate we're trying to
achieve is mostly right.

For the downstream kernel change related to this see See
https://crrev.com/c/324558.

NOTE: minnie uses a different panel will be fixed up in a future
patch, so for now we'll just delete the panel timings there.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-jerry patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 14 ++++++++++++++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts      |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b54746df3661..0b1789b50c21 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -76,6 +76,20 @@
 		power-supply = <&vcc33_lcd>;
 		backlight = <&backlight>;
 
+		panel-timing {
+			clock-frequency = <74250000>;
+			hactive = <1366>;
+			hfront-porch = <136>;
+			hback-porch = <60>;
+			hsync-len = <30>;
+			hsync-active = <0>;
+			vactive = <768>;
+			vfront-porch = <8>;
+			vback-porch = <12>;
+			vsync-len = <12>;
+			vsync-active = <0>;
+		};
+
 		ports {
 			panel_in: port {
 				panel_in_edp: endpoint {
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index f95d0c5fcf71..ca7512ade222 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -142,6 +142,8 @@
 &panel {
 	compatible = "auo,b101ean01", "simple-panel";
 	power-supply= <&panel_regulator>;
+
+	/delete-node/ panel-timing;
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Douglas Anderson]

Let's document the display timings that most veyron chromebooks (like
jaq, jerry, mighty, speedy) have been using out in the field.  This
uses the standard blankings but a slightly slower clock rate, thus
getting a refresh rate 58.3 Hz.

NOTE: this won't really do anything except cause DRM to properly
report the refresh rate since vop_crtc_mode_fixup() was rounding the
pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
exposed to userspace so it's important that the rate we're trying to
achieve is mostly right.

For the downstream kernel change related to this see See
https://crrev.com/c/324558.

NOTE: minnie uses a different panel will be fixed up in a future
patch, so for now we'll just delete the panel timings there.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-jerry patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 14 ++++++++++++++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts      |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b54746df3661..0b1789b50c21 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -76,6 +76,20 @@
 		power-supply = <&vcc33_lcd>;
 		backlight = <&backlight>;
 
+		panel-timing {
+			clock-frequency = <74250000>;
+			hactive = <1366>;
+			hfront-porch = <136>;
+			hback-porch = <60>;
+			hsync-len = <30>;
+			hsync-active = <0>;
+			vactive = <768>;
+			vfront-porch = <8>;
+			vback-porch = <12>;
+			vsync-len = <12>;
+			vsync-active = <0>;
+		};
+
 		ports {
 			panel_in: port {
 				panel_in_edp: endpoint {
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index f95d0c5fcf71..ca7512ade222 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -142,6 +142,8 @@
 &panel {
 	compatible = "auo,b101ean01", "simple-panel";
 	power-supply= <&panel_regulator>;
+
+	/delete-node/ panel-timing;
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Douglas Anderson]

Let's document the display timings that most veyron chromebooks (like
jaq, jerry, mighty, speedy) have been using out in the field.  This
uses the standard blankings but a slightly slower clock rate, thus
getting a refresh rate 58.3 Hz.

NOTE: this won't really do anything except cause DRM to properly
report the refresh rate since vop_crtc_mode_fixup() was rounding the
pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
exposed to userspace so it's important that the rate we're trying to
achieve is mostly right.

For the downstream kernel change related to this see See
https://crrev.com/c/324558.

NOTE: minnie uses a different panel will be fixed up in a future
patch, so for now we'll just delete the panel timings there.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-jerry patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 14 ++++++++++++++
 arch/arm/boot/dts/rk3288-veyron-minnie.dts      |  2 ++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index b54746df3661..0b1789b50c21 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -76,6 +76,20 @@
 		power-supply = <&vcc33_lcd>;
 		backlight = <&backlight>;
 
+		panel-timing {
+			clock-frequency = <74250000>;
+			hactive = <1366>;
+			hfront-porch = <136>;
+			hback-porch = <60>;
+			hsync-len = <30>;
+			hsync-active = <0>;
+			vactive = <768>;
+			vfront-porch = <8>;
+			vback-porch = <12>;
+			vsync-len = <12>;
+			vsync-active = <0>;
+		};
+
 		ports {
 			panel_in: port {
 				panel_in_edp: endpoint {
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index f95d0c5fcf71..ca7512ade222 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -142,6 +142,8 @@
 &panel {
 	compatible = "auo,b101ean01", "simple-panel";
 	power-supply= <&panel_regulator>;
+
+	/delete-node/ panel-timing;
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Urja Rannikko]

Hi,

On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> Let's document the display timings that most veyron chromebooks (like
> jaq, jerry, mighty, speedy) have been using out in the field.  This
> uses the standard blankings but a slightly slower clock rate, thus
> getting a refresh rate 58.3 Hz.
>
> NOTE: this won't really do anything except cause DRM to properly
> report the refresh rate since vop_crtc_mode_fixup() was rounding the
> pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> exposed to userspace so it's important that the rate we're trying to
> achieve is mostly right.

I just thought it would be worth mentioning that I have picked &
tested a close to 60Hz mode on two veyron speedys of mine, but thought
it too much effort to try and upstream, especially as it was done as a
change to the actual panel info:
https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae

The difference would be in this format just setting hfront-porch = 87
and vback-porch = 14.
Anyways the point is: I support moving this mode info into the dts,
and I'd like to know how if at all should i go about getting a
60Hz(ish) mode upstreamed?

-- 
Urja Rannikko

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Urja Rannikko]

Hi,

On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote:
>
> Let's document the display timings that most veyron chromebooks (like
> jaq, jerry, mighty, speedy) have been using out in the field.  This
> uses the standard blankings but a slightly slower clock rate, thus
> getting a refresh rate 58.3 Hz.
>
> NOTE: this won't really do anything except cause DRM to properly
> report the refresh rate since vop_crtc_mode_fixup() was rounding the
> pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> exposed to userspace so it's important that the rate we're trying to
> achieve is mostly right.

I just thought it would be worth mentioning that I have picked &
tested a close to 60Hz mode on two veyron speedys of mine, but thought
it too much effort to try and upstream, especially as it was done as a
change to the actual panel info:
https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae

The difference would be in this format just setting hfront-porch = 87
and vback-porch = 14.
Anyways the point is: I support moving this mode info into the dts,
and I'd like to know how if at all should i go about getting a
60Hz(ish) mode upstreamed?

-- 
Urja Rannikko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Doug Anderson]

Hi,

On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> >
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
>
> I just thought it would be worth mentioning that I have picked &
> tested a close to 60Hz mode on two veyron speedys of mine, but thought
> it too much effort to try and upstream, especially as it was done as a
> change to the actual panel info:
> https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae
>
> The difference would be in this format just setting hfront-porch = 87
> and vback-porch = 14.
> Anyways the point is: I support moving this mode info into the dts,
> and I'd like to know how if at all should i go about getting a
> 60Hz(ish) mode upstreamed?

I'm a bit torn here.  I like the idea of actually getting 60 Hz and
you also increase the vblank time by a little bit (which means that if
anyone ever gets DDRFreq upstream it will work better).  ...but I'm
also slightly nervous changing something like this without a really
good motivation.  As you said in your commit message the pixels clocks
claimed by the spec don't actually all work and thus, to some extent,
we can only rely on trial-and-error here.  While your new mode works
well on your device (and you wisely gave it a bit of margin), it is
_possible_ that there could be devices out there where it doesn't work
(especially across various temperature extremes).  All devices were
tested in the factory with the old timings and presumably have been
running fine for years like that...

I will certainly admit that it's unlikely devices would be affected,
but at the same time I'd want to know how much of a difference going
from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
visible difference, or was it just nice to be at 60 Hz?


-Doug

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Doug Anderson]

Hi,

On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> >
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
>
> I just thought it would be worth mentioning that I have picked &
> tested a close to 60Hz mode on two veyron speedys of mine, but thought
> it too much effort to try and upstream, especially as it was done as a
> change to the actual panel info:
> https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae
>
> The difference would be in this format just setting hfront-porch = 87
> and vback-porch = 14.
> Anyways the point is: I support moving this mode info into the dts,
> and I'd like to know how if at all should i go about getting a
> 60Hz(ish) mode upstreamed?

I'm a bit torn here.  I like the idea of actually getting 60 Hz and
you also increase the vblank time by a little bit (which means that if
anyone ever gets DDRFreq upstream it will work better).  ...but I'm
also slightly nervous changing something like this without a really
good motivation.  As you said in your commit message the pixels clocks
claimed by the spec don't actually all work and thus, to some extent,
we can only rely on trial-and-error here.  While your new mode works
well on your device (and you wisely gave it a bit of margin), it is
_possible_ that there could be devices out there where it doesn't work
(especially across various temperature extremes).  All devices were
tested in the factory with the old timings and presumably have been
running fine for years like that...

I will certainly admit that it's unlikely devices would be affected,
but at the same time I'd want to know how much of a difference going
from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
visible difference, or was it just nice to be at 60 Hz?


-Doug

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Urja Rannikko]

Hi,

On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
> >
> > Hi,
<snip>
> >
> > The difference would be in this format just setting hfront-porch = 87
> > and vback-porch = 14.
> > Anyways the point is: I support moving this mode info into the dts,
> > and I'd like to know how if at all should i go about getting a
> > 60Hz(ish) mode upstreamed?
>
> I'm a bit torn here.  I like the idea of actually getting 60 Hz and
> you also increase the vblank time by a little bit (which means that if
> anyone ever gets DDRFreq upstream it will work better).  ...but I'm
> also slightly nervous changing something like this without a really
> good motivation.  As you said in your commit message the pixels clocks
> claimed by the spec don't actually all work and thus, to some extent,
> we can only rely on trial-and-error here.  While your new mode works
> well on your device (and you wisely gave it a bit of margin), it is
> _possible_ that there could be devices out there where it doesn't work
> (especially across various temperature extremes).  All devices were
> tested in the factory with the old timings and presumably have been
> running fine for years like that...
Re: the trial and error: it might be the case that the panels actually
work at 1506 vtotal if you also adjust the sync length and/or back
porch "accordingly", whatever that accordingly would be for this panel
since the datasheet doesnt tell. I missed this point when i was doing
my testing and just adjusted the variables with the most
"adjustability" (bigger starting value) to them.

> I will certainly admit that it's unlikely devices would be affected,
> but at the same time I'd want to know how much of a difference going
> from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
> visible difference, or was it just nice to be at 60 Hz?
Honestly I was just doing this because i really liked the idea of
actually making it 60Hz and my eyes arent that good at noticing
high-fps things - i think the one case where it might be visible to a
keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..)
frames a second if running at 58.3 Hz. But currently the C201 isnt
doing a lot of that given i dont think i/we have a good software setup
for it. That could be changing in the future with panfrost and the VPU
hardware decoder support, etc.

Anyways I'm thinking it would be prudent to first get this framework
of device-tree modes in and then maybe adjust the mode later.

Testing the 60Hz mode is simple enough:
xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802
-HSync -VSync
xrandr --addmode eDP-1 1366x768p60
xrandr --output eDP-1 --mode 1366x768p60

(The mode name can be anything...)
So meanwhile I would appreciate it if we could get some test reports
of the mode with other veyron chromebooks that have this panel :)

-- 
Urja Rannikko

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Urja Rannikko]

Hi,

On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
> >
> > Hi,
<snip>
> >
> > The difference would be in this format just setting hfront-porch = 87
> > and vback-porch = 14.
> > Anyways the point is: I support moving this mode info into the dts,
> > and I'd like to know how if at all should i go about getting a
> > 60Hz(ish) mode upstreamed?
>
> I'm a bit torn here.  I like the idea of actually getting 60 Hz and
> you also increase the vblank time by a little bit (which means that if
> anyone ever gets DDRFreq upstream it will work better).  ...but I'm
> also slightly nervous changing something like this without a really
> good motivation.  As you said in your commit message the pixels clocks
> claimed by the spec don't actually all work and thus, to some extent,
> we can only rely on trial-and-error here.  While your new mode works
> well on your device (and you wisely gave it a bit of margin), it is
> _possible_ that there could be devices out there where it doesn't work
> (especially across various temperature extremes).  All devices were
> tested in the factory with the old timings and presumably have been
> running fine for years like that...
Re: the trial and error: it might be the case that the panels actually
work at 1506 vtotal if you also adjust the sync length and/or back
porch "accordingly", whatever that accordingly would be for this panel
since the datasheet doesnt tell. I missed this point when i was doing
my testing and just adjusted the variables with the most
"adjustability" (bigger starting value) to them.

> I will certainly admit that it's unlikely devices would be affected,
> but at the same time I'd want to know how much of a difference going
> from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
> visible difference, or was it just nice to be at 60 Hz?
Honestly I was just doing this because i really liked the idea of
actually making it 60Hz and my eyes arent that good at noticing
high-fps things - i think the one case where it might be visible to a
keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..)
frames a second if running at 58.3 Hz. But currently the C201 isnt
doing a lot of that given i dont think i/we have a good software setup
for it. That could be changing in the future with panfrost and the VPU
hardware decoder support, etc.

Anyways I'm thinking it would be prudent to first get this framework
of device-tree modes in and then maybe adjust the mode later.

Testing the 60Hz mode is simple enough:
xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802
-HSync -VSync
xrandr --addmode eDP-1 1366x768p60
xrandr --output eDP-1 --mode 1366x768p60

(The mode name can be anything...)
So meanwhile I would appreciate it if we could get some test reports
of the mode with other veyron chromebooks that have this panel :)

-- 
Urja Rannikko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Doug Anderson]

Hi,

On Mon, Apr 8, 2019 at 9:26 AM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
> > >
> > > Hi,
> <snip>
> > >
> > > The difference would be in this format just setting hfront-porch = 87
> > > and vback-porch = 14.
> > > Anyways the point is: I support moving this mode info into the dts,
> > > and I'd like to know how if at all should i go about getting a
> > > 60Hz(ish) mode upstreamed?
> >
> > I'm a bit torn here.  I like the idea of actually getting 60 Hz and
> > you also increase the vblank time by a little bit (which means that if
> > anyone ever gets DDRFreq upstream it will work better).  ...but I'm
> > also slightly nervous changing something like this without a really
> > good motivation.  As you said in your commit message the pixels clocks
> > claimed by the spec don't actually all work and thus, to some extent,
> > we can only rely on trial-and-error here.  While your new mode works
> > well on your device (and you wisely gave it a bit of margin), it is
> > _possible_ that there could be devices out there where it doesn't work
> > (especially across various temperature extremes).  All devices were
> > tested in the factory with the old timings and presumably have been
> > running fine for years like that...
> Re: the trial and error: it might be the case that the panels actually
> work at 1506 vtotal if you also adjust the sync length and/or back
> porch "accordingly", whatever that accordingly would be for this panel
> since the datasheet doesnt tell. I missed this point when i was doing
> my testing and just adjusted the variables with the most
> "adjustability" (bigger starting value) to them.

Fair enough.  I guess I just have my gut instincts that say that this
will break some device somewhere, but it's certainly possible that's
wrong.


> > I will certainly admit that it's unlikely devices would be affected,
> > but at the same time I'd want to know how much of a difference going
> > from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
> > visible difference, or was it just nice to be at 60 Hz?
> Honestly I was just doing this because i really liked the idea of
> actually making it 60Hz and my eyes arent that good at noticing
> high-fps things - i think the one case where it might be visible to a
> keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..)
> frames a second if running at 58.3 Hz. But currently the C201 isnt
> doing a lot of that given i dont think i/we have a good software setup
> for it. That could be changing in the future with panfrost and the VPU
> hardware decoder support, etc.

Yeah, I'd definitely wonder how easy this is to notice.  Since I
haven't ever heard of anyone who thought that the current 58.3 Hz was
causing problems that they could actually notice it makes me hesitant
to change it.


> Anyways I'm thinking it would be prudent to first get this framework
> of device-tree modes in and then maybe adjust the mode later.

If you're OK with it, let's aim to land things with the current 58.3
and then we can do think about the 60 Hz mode.

...I'm probably sounding super paranoid here since (presumably) anyone
who is running upstream Linux on their Chromebook is more than capable
of bisecting problems like this if it causes problems, but I guess I'm
worried that this could eventually make its way into a Chrome OS tree
(either through a kernel uprev or simple cherry-picks) and affect
people.


> Testing the 60Hz mode is simple enough:
> xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802
> -HSync -VSync
> xrandr --addmode eDP-1 1366x768p60
> xrandr --output eDP-1 --mode 1366x768p60
>
> (The mode name can be anything...)
> So meanwhile I would appreciate it if we could get some test reports
> of the mode with other veyron chromebooks that have this panel :)

I still haven't done this and I'm not in front of my Chromebook now.
I'll try to give it a try soon.  The kinds of problems I'd expect (if
there are any) would be flickers that happen _very_ rarely though, but
I can at least do some basic testing.

One other note to justify my paranoia: on a past Chromebook we
certainly had crazy flickering problems.  On one device one day you'd
get two flickers and then see nothing for the next two weeks.  ...some
devices would see at least a flicker a day and some would see no
flickers ever.  Obviously it's unlikely that would happen here, but
such past experience just makes me paranoid.  ;-)


-Doug

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Doug Anderson]

Hi,

On Mon, Apr 8, 2019 at 9:26 AM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
> > >
> > > Hi,
> <snip>
> > >
> > > The difference would be in this format just setting hfront-porch = 87
> > > and vback-porch = 14.
> > > Anyways the point is: I support moving this mode info into the dts,
> > > and I'd like to know how if at all should i go about getting a
> > > 60Hz(ish) mode upstreamed?
> >
> > I'm a bit torn here.  I like the idea of actually getting 60 Hz and
> > you also increase the vblank time by a little bit (which means that if
> > anyone ever gets DDRFreq upstream it will work better).  ...but I'm
> > also slightly nervous changing something like this without a really
> > good motivation.  As you said in your commit message the pixels clocks
> > claimed by the spec don't actually all work and thus, to some extent,
> > we can only rely on trial-and-error here.  While your new mode works
> > well on your device (and you wisely gave it a bit of margin), it is
> > _possible_ that there could be devices out there where it doesn't work
> > (especially across various temperature extremes).  All devices were
> > tested in the factory with the old timings and presumably have been
> > running fine for years like that...
> Re: the trial and error: it might be the case that the panels actually
> work at 1506 vtotal if you also adjust the sync length and/or back
> porch "accordingly", whatever that accordingly would be for this panel
> since the datasheet doesnt tell. I missed this point when i was doing
> my testing and just adjusted the variables with the most
> "adjustability" (bigger starting value) to them.

Fair enough.  I guess I just have my gut instincts that say that this
will break some device somewhere, but it's certainly possible that's
wrong.


> > I will certainly admit that it's unlikely devices would be affected,
> > but at the same time I'd want to know how much of a difference going
> > from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
> > visible difference, or was it just nice to be at 60 Hz?
> Honestly I was just doing this because i really liked the idea of
> actually making it 60Hz and my eyes arent that good at noticing
> high-fps things - i think the one case where it might be visible to a
> keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..)
> frames a second if running at 58.3 Hz. But currently the C201 isnt
> doing a lot of that given i dont think i/we have a good software setup
> for it. That could be changing in the future with panfrost and the VPU
> hardware decoder support, etc.

Yeah, I'd definitely wonder how easy this is to notice.  Since I
haven't ever heard of anyone who thought that the current 58.3 Hz was
causing problems that they could actually notice it makes me hesitant
to change it.


> Anyways I'm thinking it would be prudent to first get this framework
> of device-tree modes in and then maybe adjust the mode later.

If you're OK with it, let's aim to land things with the current 58.3
and then we can do think about the 60 Hz mode.

...I'm probably sounding super paranoid here since (presumably) anyone
who is running upstream Linux on their Chromebook is more than capable
of bisecting problems like this if it causes problems, but I guess I'm
worried that this could eventually make its way into a Chrome OS tree
(either through a kernel uprev or simple cherry-picks) and affect
people.


> Testing the 60Hz mode is simple enough:
> xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802
> -HSync -VSync
> xrandr --addmode eDP-1 1366x768p60
> xrandr --output eDP-1 --mode 1366x768p60
>
> (The mode name can be anything...)
> So meanwhile I would appreciate it if we could get some test reports
> of the mode with other veyron chromebooks that have this panel :)

I still haven't done this and I'm not in front of my Chromebook now.
I'll try to give it a try soon.  The kinds of problems I'd expect (if
there are any) would be flickers that happen _very_ rarely though, but
I can at least do some basic testing.

One other note to justify my paranoia: on a past Chromebook we
certainly had crazy flickering problems.  On one device one day you'd
get two flickers and then see nothing for the next two weeks.  ...some
devices would see at least a flicker a day and some would see no
flickers ever.  Obviously it's unlikely that would happen here, but
such past experience just makes me paranoid.  ;-)


-Doug

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Doug Anderson]

Hi,

On Mon, Apr 8, 2019 at 9:26 AM Urja Rannikko <urjaman@gmail.com> wrote:
>
> Hi,
>
> On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote:
> > >
> > > Hi,
> <snip>
> > >
> > > The difference would be in this format just setting hfront-porch = 87
> > > and vback-porch = 14.
> > > Anyways the point is: I support moving this mode info into the dts,
> > > and I'd like to know how if at all should i go about getting a
> > > 60Hz(ish) mode upstreamed?
> >
> > I'm a bit torn here.  I like the idea of actually getting 60 Hz and
> > you also increase the vblank time by a little bit (which means that if
> > anyone ever gets DDRFreq upstream it will work better).  ...but I'm
> > also slightly nervous changing something like this without a really
> > good motivation.  As you said in your commit message the pixels clocks
> > claimed by the spec don't actually all work and thus, to some extent,
> > we can only rely on trial-and-error here.  While your new mode works
> > well on your device (and you wisely gave it a bit of margin), it is
> > _possible_ that there could be devices out there where it doesn't work
> > (especially across various temperature extremes).  All devices were
> > tested in the factory with the old timings and presumably have been
> > running fine for years like that...
> Re: the trial and error: it might be the case that the panels actually
> work at 1506 vtotal if you also adjust the sync length and/or back
> porch "accordingly", whatever that accordingly would be for this panel
> since the datasheet doesnt tell. I missed this point when i was doing
> my testing and just adjusted the variables with the most
> "adjustability" (bigger starting value) to them.

Fair enough.  I guess I just have my gut instincts that say that this
will break some device somewhere, but it's certainly possible that's
wrong.


> > I will certainly admit that it's unlikely devices would be affected,
> > but at the same time I'd want to know how much of a difference going
> > from 58.3 Hz to 60 Hz made for you.  Could you actually notice any
> > visible difference, or was it just nice to be at 60 Hz?
> Honestly I was just doing this because i really liked the idea of
> actually making it 60Hz and my eyes arent that good at noticing
> high-fps things - i think the one case where it might be visible to a
> keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..)
> frames a second if running at 58.3 Hz. But currently the C201 isnt
> doing a lot of that given i dont think i/we have a good software setup
> for it. That could be changing in the future with panfrost and the VPU
> hardware decoder support, etc.

Yeah, I'd definitely wonder how easy this is to notice.  Since I
haven't ever heard of anyone who thought that the current 58.3 Hz was
causing problems that they could actually notice it makes me hesitant
to change it.


> Anyways I'm thinking it would be prudent to first get this framework
> of device-tree modes in and then maybe adjust the mode later.

If you're OK with it, let's aim to land things with the current 58.3
and then we can do think about the 60 Hz mode.

...I'm probably sounding super paranoid here since (presumably) anyone
who is running upstream Linux on their Chromebook is more than capable
of bisecting problems like this if it causes problems, but I guess I'm
worried that this could eventually make its way into a Chrome OS tree
(either through a kernel uprev or simple cherry-picks) and affect
people.


> Testing the 60Hz mode is simple enough:
> xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802
> -HSync -VSync
> xrandr --addmode eDP-1 1366x768p60
> xrandr --output eDP-1 --mode 1366x768p60
>
> (The mode name can be anything...)
> So meanwhile I would appreciate it if we could get some test reports
> of the mode with other veyron chromebooks that have this panel :)

I still haven't done this and I'm not in front of my Chromebook now.
I'll try to give it a try soon.  The kinds of problems I'd expect (if
there are any) would be flickers that happen _very_ rarely though, but
I can at least do some basic testing.

One other note to justify my paranoia: on a past Chromebook we
certainly had crazy flickering problems.  On one device one day you'd
get two flickers and then see nothing for the next two weeks.  ...some
devices would see at least a flicker a day and some would see no
flickers ever.  Obviously it's unlikely that would happen here, but
such past experience just makes me paranoid.  ;-)


-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> Let's document the display timings that most veyron chromebooks (like
> jaq, jerry, mighty, speedy) have been using out in the field.  This
> uses the standard blankings but a slightly slower clock rate, thus
> getting a refresh rate 58.3 Hz.
> 
> NOTE: this won't really do anything except cause DRM to properly
> report the refresh rate since vop_crtc_mode_fixup() was rounding the
> pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> exposed to userspace so it's important that the rate we're trying to
> achieve is mostly right.
> 
> For the downstream kernel change related to this see See
> https://crrev.com/c/324558.
> 
> NOTE: minnie uses a different panel will be fixed up in a future
> patch, so for now we'll just delete the panel timings there.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.3

Thanks
Heiko

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> Let's document the display timings that most veyron chromebooks (like
> jaq, jerry, mighty, speedy) have been using out in the field.  This
> uses the standard blankings but a slightly slower clock rate, thus
> getting a refresh rate 58.3 Hz.
> 
> NOTE: this won't really do anything except cause DRM to properly
> report the refresh rate since vop_crtc_mode_fixup() was rounding the
> pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> exposed to userspace so it's important that the rate we're trying to
> achieve is mostly right.
> 
> For the downstream kernel change related to this see See
> https://crrev.com/c/324558.
> 
> NOTE: minnie uses a different panel will be fixed up in a future
> patch, so for now we'll just delete the panel timings there.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.3

Thanks
Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> Let's document the display timings that most veyron chromebooks (like
> jaq, jerry, mighty, speedy) have been using out in the field.  This
> uses the standard blankings but a slightly slower clock rate, thus
> getting a refresh rate 58.3 Hz.
> 
> NOTE: this won't really do anything except cause DRM to properly
> report the refresh rate since vop_crtc_mode_fixup() was rounding the
> pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> exposed to userspace so it's important that the rate we're trying to
> achieve is mostly right.
> 
> For the downstream kernel change related to this see See
> https://crrev.com/c/324558.
> 
> NOTE: minnie uses a different panel will be fixed up in a future
> patch, so for now we'll just delete the panel timings there.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.3

Thanks
Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Donnerstag, 11. Juli 2019, 23:27:44 CEST schrieb Heiko Stübner:
> Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> > 
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
> > 
> > For the downstream kernel change related to this see See
> > https://crrev.com/c/324558.
> > 
> > NOTE: minnie uses a different panel will be fixed up in a future
> > patch, so for now we'll just delete the panel timings there.
> > 
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> 
> applied for 5.3

5.4 obviously
[just to not confuse people reading that later]

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Donnerstag, 11. Juli 2019, 23:27:44 CEST schrieb Heiko Stübner:
> Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> > 
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
> > 
> > For the downstream kernel change related to this see See
> > https://crrev.com/c/324558.
> > 
> > NOTE: minnie uses a different panel will be fixed up in a future
> > patch, so for now we'll just delete the panel timings there.
> > 
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> 
> applied for 5.3

5.4 obviously
[just to not confuse people reading that later]



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings

[Heiko Stübner]

Am Donnerstag, 11. Juli 2019, 23:27:44 CEST schrieb Heiko Stübner:
> Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson:
> > Let's document the display timings that most veyron chromebooks (like
> > jaq, jerry, mighty, speedy) have been using out in the field.  This
> > uses the standard blankings but a slightly slower clock rate, thus
> > getting a refresh rate 58.3 Hz.
> > 
> > NOTE: this won't really do anything except cause DRM to properly
> > report the refresh rate since vop_crtc_mode_fixup() was rounding the
> > pixel clock to 74.25 MHz anyway.  Apparently the adjusted rate isn't
> > exposed to userspace so it's important that the rate we're trying to
> > achieve is mostly right.
> > 
> > For the downstream kernel change related to this see See
> > https://crrev.com/c/324558.
> > 
> > NOTE: minnie uses a different panel will be fixed up in a future
> > patch, so for now we'll just delete the panel timings there.
> > 
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> 
> applied for 5.3

5.4 obviously
[just to not confuse people reading that later]


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Douglas Anderson]

Just like we did for rk3288-veyron-chromebook, we want to be able to
use one of the fixed PLLs in the system to make the pixel clock for
minnie.

Specifying these timings matches us with how the display is used on
the downstream Chrome OS kernel.  See https://crrev.com/c/323211.

Unlike what we did for rk3288-veyron-chromebook, this CL actually
changes the timings (though not the pixel clock) that is used when
using the upstream kernel.  Booting up a minnie shows that it ended up
with a 66.67 MHz pixel clock but it was still using the
porches/blankings it would have wanted for a 72.5 MHz pixel clock.

NOTE: compared to the downstream kernel, this seems to cause a
slightly different result reported in the 'modetest' command on a
Chromebook.  The downstream kernel shows:
  1280x800 60 1280 1298 1330 1351 800 804 822 830 66667

With this patch we have:
  1280x800 59 1280 1298 1330 1351 800 804 822 830 66666

Specifically modetest was reporting 60 Hz on the downstream kernel but
the upstream kernel does the math and comesup with 59 (because we
actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
when converting to kHz--it seems to truncate.

ALSO NOTE: when I look at the EDID from the datasheet, I see:
  -hsync -vsync
...but it seems like we've never actually run with that so I've
continued leaving that out.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-minnie patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index ca7512ade222..8179cf9f6e98 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -144,6 +144,18 @@
 	power-supply= <&panel_regulator>;
 
 	/delete-node/ panel-timing;
+
+	panel-timing {
+		clock-frequency = <66666667>;
+		hactive = <1280>;
+		hfront-porch = <18>;
+		hback-porch = <21>;
+		hsync-len = <32>;
+		vactive = <800>;
+		vfront-porch = <4>;
+		vback-porch = <8>;
+		vsync-len = <18>;
+	};
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog

[PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Douglas Anderson]

Just like we did for rk3288-veyron-chromebook, we want to be able to
use one of the fixed PLLs in the system to make the pixel clock for
minnie.

Specifying these timings matches us with how the display is used on
the downstream Chrome OS kernel.  See https://crrev.com/c/323211.

Unlike what we did for rk3288-veyron-chromebook, this CL actually
changes the timings (though not the pixel clock) that is used when
using the upstream kernel.  Booting up a minnie shows that it ended up
with a 66.67 MHz pixel clock but it was still using the
porches/blankings it would have wanted for a 72.5 MHz pixel clock.

NOTE: compared to the downstream kernel, this seems to cause a
slightly different result reported in the 'modetest' command on a
Chromebook.  The downstream kernel shows:
  1280x800 60 1280 1298 1330 1351 800 804 822 830 66667

With this patch we have:
  1280x800 59 1280 1298 1330 1351 800 804 822 830 66666

Specifically modetest was reporting 60 Hz on the downstream kernel but
the upstream kernel does the math and comesup with 59 (because we
actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
when converting to kHz--it seems to truncate.

ALSO NOTE: when I look at the EDID from the datasheet, I see:
  -hsync -vsync
...but it seems like we've never actually run with that so I've
continued leaving that out.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-minnie patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index ca7512ade222..8179cf9f6e98 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -144,6 +144,18 @@
 	power-supply= <&panel_regulator>;
 
 	/delete-node/ panel-timing;
+
+	panel-timing {
+		clock-frequency = <66666667>;
+		hactive = <1280>;
+		hfront-porch = <18>;
+		hback-porch = <21>;
+		hsync-len = <32>;
+		vactive = <800>;
+		vfront-porch = <4>;
+		vback-porch = <8>;
+		vsync-len = <18>;
+	};
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Douglas Anderson]

Just like we did for rk3288-veyron-chromebook, we want to be able to
use one of the fixed PLLs in the system to make the pixel clock for
minnie.

Specifying these timings matches us with how the display is used on
the downstream Chrome OS kernel.  See https://crrev.com/c/323211.

Unlike what we did for rk3288-veyron-chromebook, this CL actually
changes the timings (though not the pixel clock) that is used when
using the upstream kernel.  Booting up a minnie shows that it ended up
with a 66.67 MHz pixel clock but it was still using the
porches/blankings it would have wanted for a 72.5 MHz pixel clock.

NOTE: compared to the downstream kernel, this seems to cause a
slightly different result reported in the 'modetest' command on a
Chromebook.  The downstream kernel shows:
  1280x800 60 1280 1298 1330 1351 800 804 822 830 66667

With this patch we have:
  1280x800 59 1280 1298 1330 1351 800 804 822 830 66666

Specifically modetest was reporting 60 Hz on the downstream kernel but
the upstream kernel does the math and comesup with 59 (because we
actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
when converting to kHz--it seems to truncate.

ALSO NOTE: when I look at the EDID from the datasheet, I see:
  -hsync -vsync
...but it seems like we've never actually run with that so I've
continued leaving that out.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

Changes in v5:
- It's not just jerry, it's most rk3288 Chromebooks (Heiko)

Changes in v4:
- rk3288-veyron-minnie patch new for v4.

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-veyron-minnie.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index ca7512ade222..8179cf9f6e98 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -144,6 +144,18 @@
 	power-supply= <&panel_regulator>;
 
 	/delete-node/ panel-timing;
+
+	panel-timing {
+		clock-frequency = <66666667>;
+		hactive = <1280>;
+		hfront-porch = <18>;
+		hback-porch = <21>;
+		hsync-len = <32>;
+		vactive = <800>;
+		vfront-porch = <4>;
+		vback-porch = <8>;
+		vsync-len = <18>;
+	};
 };
 
 &rk808 {
-- 
2.21.0.392.gf8f6787159e-goog

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:24 CEST schrieb Douglas Anderson:
> Just like we did for rk3288-veyron-chromebook, we want to be able to
> use one of the fixed PLLs in the system to make the pixel clock for
> minnie.
> 
> Specifying these timings matches us with how the display is used on
> the downstream Chrome OS kernel.  See https://crrev.com/c/323211.
> 
> Unlike what we did for rk3288-veyron-chromebook, this CL actually
> changes the timings (though not the pixel clock) that is used when
> using the upstream kernel.  Booting up a minnie shows that it ended up
> with a 66.67 MHz pixel clock but it was still using the
> porches/blankings it would have wanted for a 72.5 MHz pixel clock.
> 
> NOTE: compared to the downstream kernel, this seems to cause a
> slightly different result reported in the 'modetest' command on a
> Chromebook.  The downstream kernel shows:
>   1280x800 60 1280 1298 1330 1351 800 804 822 830 66667
> 
> With this patch we have:
>   1280x800 59 1280 1298 1330 1351 800 804 822 830 66666
> 
> Specifically modetest was reporting 60 Hz on the downstream kernel but
> the upstream kernel does the math and comesup with 59 (because we
> actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
> when converting to kHz--it seems to truncate.
> 
> ALSO NOTE: when I look at the EDID from the datasheet, I see:
>   -hsync -vsync
> ...but it seems like we've never actually run with that so I've
> continued leaving that out.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko

Re: [PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:24 CEST schrieb Douglas Anderson:
> Just like we did for rk3288-veyron-chromebook, we want to be able to
> use one of the fixed PLLs in the system to make the pixel clock for
> minnie.
> 
> Specifying these timings matches us with how the display is used on
> the downstream Chrome OS kernel.  See https://crrev.com/c/323211.
> 
> Unlike what we did for rk3288-veyron-chromebook, this CL actually
> changes the timings (though not the pixel clock) that is used when
> using the upstream kernel.  Booting up a minnie shows that it ended up
> with a 66.67 MHz pixel clock but it was still using the
> porches/blankings it would have wanted for a 72.5 MHz pixel clock.
> 
> NOTE: compared to the downstream kernel, this seems to cause a
> slightly different result reported in the 'modetest' command on a
> Chromebook.  The downstream kernel shows:
>   1280x800 60 1280 1298 1330 1351 800 804 822 830 66667
> 
> With this patch we have:
>   1280x800 59 1280 1298 1330 1351 800 804 822 830 66666
> 
> Specifically modetest was reporting 60 Hz on the downstream kernel but
> the upstream kernel does the math and comesup with 59 (because we
> actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
> when converting to kHz--it seems to truncate.
> 
> ALSO NOTE: when I look at the EDID from the datasheet, I see:
>   -hsync -vsync
> ...but it seems like we've never actually run with that so I've
> continued leaving that out.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings

[Heiko Stübner]

Am Montag, 1. April 2019, 19:17:24 CEST schrieb Douglas Anderson:
> Just like we did for rk3288-veyron-chromebook, we want to be able to
> use one of the fixed PLLs in the system to make the pixel clock for
> minnie.
> 
> Specifying these timings matches us with how the display is used on
> the downstream Chrome OS kernel.  See https://crrev.com/c/323211.
> 
> Unlike what we did for rk3288-veyron-chromebook, this CL actually
> changes the timings (though not the pixel clock) that is used when
> using the upstream kernel.  Booting up a minnie shows that it ended up
> with a 66.67 MHz pixel clock but it was still using the
> porches/blankings it would have wanted for a 72.5 MHz pixel clock.
> 
> NOTE: compared to the downstream kernel, this seems to cause a
> slightly different result reported in the 'modetest' command on a
> Chromebook.  The downstream kernel shows:
>   1280x800 60 1280 1298 1330 1351 800 804 822 830 66667
> 
> With this patch we have:
>   1280x800 59 1280 1298 1330 1351 800 804 822 830 66666
> 
> Specifically modetest was reporting 60 Hz on the downstream kernel but
> the upstream kernel does the math and comesup with 59 (because we
> actually achieve 59.45 Hz).  Also upstream doesn't round the Hz up
> when converting to kHz--it seems to truncate.
> 
> ALSO NOTE: when I look at the EDID from the datasheet, I see:
>   -hsync -vsync
> ...but it seems like we've never actually run with that so I've
> continued leaving that out.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

applied for 5.4

Thanks
Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stuebner]

Am Montag, 1. April 2019, 19:17:17 CEST schrieb Douglas Anderson:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.

sadly it looks like the panel-simple parts haven't made it into
drm-misc yet and the conversation on patch 1/7 seems to have stalled
after Doug's replies.

Thierry, do you have an opinion on these?


Thanks
Heiko

> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> 
> Changes in v4:
> - Simplify desc. for when override should be used (Thierry/Laurent)
> - Removed Rob H review since it's been a year and wording changed
> - Don't add mode from timing if override was specified (Thierry)
> - Add warning if timing and fixed mode was specified (Thierry)
> - Don't add fixed mode if timing was specified (Thierry)
> - Refactor/rename a bit to avoid extra indentation from "if" tests
> - i should be unsigned (Thierry)
> - Add annoying WARN_ONs for some cases (Thierry)
> - Simplify 'No display_timing found' handling (Thierry)
> - Rename to panel_simple_parse_override_mode() (Thierry)
> - Rebase to top of Heiko's tree
> - Converted changelog to after-the-cut for non-DRM change.
> - display_timing for Innolux n116bge new for v4.
> - display_timing for AUO b101ean01 new for v4.
> - rk3288-veyron-jerry patch new for v4.
> - rk3288-veyron-minnie patch new for v4.
> 
> Changes in v3:
> - Go back to using the timing subnode directly, but rename to
>   panel-timing (Rob)
> - No longer parse display-timings subnode, use panel-timing (Rob)
> - Unwrap the timing from display-timings and rename panel-timing (Rob)
> 
> Changes in v2:
> - Split out the binding into a new patch (Rob)
> - display-timings is a new section (Rob)
> - Use the full display-timings subnode instead of picking the timing
>   out (Rob/Thierry)
> - Parse the full display-timings node (using the native-mode) (Rob)
> - Wrap the timing in display-timings node to match binding (Rob/Thierry)
> 
> Douglas Anderson (4):
>   drm/panel: simple: Use display_timing for Innolux n116bge
>   drm/panel: simple: Use display_timing for AUO b101ean01
>   ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
>   ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings
> 
> Sean Paul (3):
>   dt-bindings: Add panel-timing subnode to simple-panel
>   drm/panel: simple: Add ability to override typical timing
>   arm64: dts: rockchip: Specify override mode for kevin panel
> 
>  .../bindings/display/panel/simple-panel.txt   |  22 +++
>  .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
>  arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
>  .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
>  drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
>  5 files changed, 203 insertions(+), 32 deletions(-)
> 
> 

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stuebner]

Am Montag, 1. April 2019, 19:17:17 CEST schrieb Douglas Anderson:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.

sadly it looks like the panel-simple parts haven't made it into
drm-misc yet and the conversation on patch 1/7 seems to have stalled
after Doug's replies.

Thierry, do you have an opinion on these?


Thanks
Heiko

> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> 
> Changes in v4:
> - Simplify desc. for when override should be used (Thierry/Laurent)
> - Removed Rob H review since it's been a year and wording changed
> - Don't add mode from timing if override was specified (Thierry)
> - Add warning if timing and fixed mode was specified (Thierry)
> - Don't add fixed mode if timing was specified (Thierry)
> - Refactor/rename a bit to avoid extra indentation from "if" tests
> - i should be unsigned (Thierry)
> - Add annoying WARN_ONs for some cases (Thierry)
> - Simplify 'No display_timing found' handling (Thierry)
> - Rename to panel_simple_parse_override_mode() (Thierry)
> - Rebase to top of Heiko's tree
> - Converted changelog to after-the-cut for non-DRM change.
> - display_timing for Innolux n116bge new for v4.
> - display_timing for AUO b101ean01 new for v4.
> - rk3288-veyron-jerry patch new for v4.
> - rk3288-veyron-minnie patch new for v4.
> 
> Changes in v3:
> - Go back to using the timing subnode directly, but rename to
>   panel-timing (Rob)
> - No longer parse display-timings subnode, use panel-timing (Rob)
> - Unwrap the timing from display-timings and rename panel-timing (Rob)
> 
> Changes in v2:
> - Split out the binding into a new patch (Rob)
> - display-timings is a new section (Rob)
> - Use the full display-timings subnode instead of picking the timing
>   out (Rob/Thierry)
> - Parse the full display-timings node (using the native-mode) (Rob)
> - Wrap the timing in display-timings node to match binding (Rob/Thierry)
> 
> Douglas Anderson (4):
>   drm/panel: simple: Use display_timing for Innolux n116bge
>   drm/panel: simple: Use display_timing for AUO b101ean01
>   ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
>   ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings
> 
> Sean Paul (3):
>   dt-bindings: Add panel-timing subnode to simple-panel
>   drm/panel: simple: Add ability to override typical timing
>   arm64: dts: rockchip: Specify override mode for kevin panel
> 
>  .../bindings/display/panel/simple-panel.txt   |  22 +++
>  .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
>  arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
>  .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
>  drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
>  5 files changed, 203 insertions(+), 32 deletions(-)
> 
> 





_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stuebner]

Am Montag, 1. April 2019, 19:17:17 CEST schrieb Douglas Anderson:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.

sadly it looks like the panel-simple parts haven't made it into
drm-misc yet and the conversation on patch 1/7 seems to have stalled
after Doug's replies.

Thierry, do you have an opinion on these?


Thanks
Heiko

> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> 
> Changes in v4:
> - Simplify desc. for when override should be used (Thierry/Laurent)
> - Removed Rob H review since it's been a year and wording changed
> - Don't add mode from timing if override was specified (Thierry)
> - Add warning if timing and fixed mode was specified (Thierry)
> - Don't add fixed mode if timing was specified (Thierry)
> - Refactor/rename a bit to avoid extra indentation from "if" tests
> - i should be unsigned (Thierry)
> - Add annoying WARN_ONs for some cases (Thierry)
> - Simplify 'No display_timing found' handling (Thierry)
> - Rename to panel_simple_parse_override_mode() (Thierry)
> - Rebase to top of Heiko's tree
> - Converted changelog to after-the-cut for non-DRM change.
> - display_timing for Innolux n116bge new for v4.
> - display_timing for AUO b101ean01 new for v4.
> - rk3288-veyron-jerry patch new for v4.
> - rk3288-veyron-minnie patch new for v4.
> 
> Changes in v3:
> - Go back to using the timing subnode directly, but rename to
>   panel-timing (Rob)
> - No longer parse display-timings subnode, use panel-timing (Rob)
> - Unwrap the timing from display-timings and rename panel-timing (Rob)
> 
> Changes in v2:
> - Split out the binding into a new patch (Rob)
> - display-timings is a new section (Rob)
> - Use the full display-timings subnode instead of picking the timing
>   out (Rob/Thierry)
> - Parse the full display-timings node (using the native-mode) (Rob)
> - Wrap the timing in display-timings node to match binding (Rob/Thierry)
> 
> Douglas Anderson (4):
>   drm/panel: simple: Use display_timing for Innolux n116bge
>   drm/panel: simple: Use display_timing for AUO b101ean01
>   ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
>   ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings
> 
> Sean Paul (3):
>   dt-bindings: Add panel-timing subnode to simple-panel
>   drm/panel: simple: Add ability to override typical timing
>   arm64: dts: rockchip: Specify override mode for kevin panel
> 
>  .../bindings/display/panel/simple-panel.txt   |  22 +++
>  .../boot/dts/rk3288-veyron-chromebook.dtsi    |  14 ++
>  arch/arm/boot/dts/rk3288-veyron-minnie.dts    |  14 ++
>  .../boot/dts/rockchip/rk3399-gru-kevin.dts    |  14 ++
>  drivers/gpu/drm/panel/panel-simple.c          | 171 ++++++++++++++----
>  5 files changed, 203 insertions(+), 32 deletions(-)
> 
> 




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Douglas.

On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.
> 
> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)

What are the plans to move forward with this?
Or did you drop the whole idea again?

	Sam

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Douglas.

On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.
> 
> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)

What are the plans to move forward with this?
Or did you drop the whole idea again?

	Sam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Douglas.

On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> I'm reviving Sean Paul's old patchset to get mode support in device
> tree.  The cover letter for his v3 is at:
> https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> 
> No code is different between v4 and v5, just commit messages and text
> in the bindings.
> 
> I've pulled together the patches that didn't land in v3, addressed
> outstanding feedback, and reposted.  Atop them I've added patches for
> rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> rk3288-veryon-minnie.
> 
> Please let me know how they look.
> 
> In general I have added people to the whole series who I think would
> like the whole series and then let get_maintainer pick extra people it
> thinks are relevant to each individual patch.  If I see you respond to
> any of the patches in the series, though, I'll add you to the whole
> series Cc list next time.
> 
> Changes in v5:
> - Removed bit about OS may ignore (Rob/Ezequiel)
> - Added Heiko's Tested-by
> - It's not just jerry, it's most rk3288 Chromebooks (Heiko)

What are the plans to move forward with this?
Or did you drop the whole idea again?

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > I'm reviving Sean Paul's old patchset to get mode support in device
> > tree.  The cover letter for his v3 is at:
> > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> >
> > No code is different between v4 and v5, just commit messages and text
> > in the bindings.
> >
> > I've pulled together the patches that didn't land in v3, addressed
> > outstanding feedback, and reposted.  Atop them I've added patches for
> > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > rk3288-veryon-minnie.
> >
> > Please let me know how they look.
> >
> > In general I have added people to the whole series who I think would
> > like the whole series and then let get_maintainer pick extra people it
> > thinks are relevant to each individual patch.  If I see you respond to
> > any of the patches in the series, though, I'll add you to the whole
> > series Cc list next time.
> >
> > Changes in v5:
> > - Removed bit about OS may ignore (Rob/Ezequiel)
> > - Added Heiko's Tested-by
> > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
>
> What are the plans to move forward with this?
> Or did you drop the whole idea again?

At the moment I'm blocked on Thierry responding, either taking the
patch or telling me what I need to do to fix it.  I saw Sean Paul ping
Thierry on IRC on June 3rd and as far as I could tell there was no
response.

https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true

...and as you can see Heiko pinged this thread on June 14th.

Thierry: can you help give us some direction?  Are you uninterested in
reviewing them and would prefer that I find someone to land them in
drm-misc directly?


-Doug

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > I'm reviving Sean Paul's old patchset to get mode support in device
> > tree.  The cover letter for his v3 is at:
> > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> >
> > No code is different between v4 and v5, just commit messages and text
> > in the bindings.
> >
> > I've pulled together the patches that didn't land in v3, addressed
> > outstanding feedback, and reposted.  Atop them I've added patches for
> > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > rk3288-veryon-minnie.
> >
> > Please let me know how they look.
> >
> > In general I have added people to the whole series who I think would
> > like the whole series and then let get_maintainer pick extra people it
> > thinks are relevant to each individual patch.  If I see you respond to
> > any of the patches in the series, though, I'll add you to the whole
> > series Cc list next time.
> >
> > Changes in v5:
> > - Removed bit about OS may ignore (Rob/Ezequiel)
> > - Added Heiko's Tested-by
> > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
>
> What are the plans to move forward with this?
> Or did you drop the whole idea again?

At the moment I'm blocked on Thierry responding, either taking the
patch or telling me what I need to do to fix it.  I saw Sean Paul ping
Thierry on IRC on June 3rd and as far as I could tell there was no
response.

https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true

...and as you can see Heiko pinged this thread on June 14th.

Thierry: can you help give us some direction?  Are you uninterested in
reviewing them and would prefer that I find someone to land them in
drm-misc directly?


-Doug

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Douglas.
>
> On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > I'm reviving Sean Paul's old patchset to get mode support in device
> > tree.  The cover letter for his v3 is at:
> > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> >
> > No code is different between v4 and v5, just commit messages and text
> > in the bindings.
> >
> > I've pulled together the patches that didn't land in v3, addressed
> > outstanding feedback, and reposted.  Atop them I've added patches for
> > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > rk3288-veryon-minnie.
> >
> > Please let me know how they look.
> >
> > In general I have added people to the whole series who I think would
> > like the whole series and then let get_maintainer pick extra people it
> > thinks are relevant to each individual patch.  If I see you respond to
> > any of the patches in the series, though, I'll add you to the whole
> > series Cc list next time.
> >
> > Changes in v5:
> > - Removed bit about OS may ignore (Rob/Ezequiel)
> > - Added Heiko's Tested-by
> > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
>
> What are the plans to move forward with this?
> Or did you drop the whole idea again?

At the moment I'm blocked on Thierry responding, either taking the
patch or telling me what I need to do to fix it.  I saw Sean Paul ping
Thierry on IRC on June 3rd and as far as I could tell there was no
response.

https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true

...and as you can see Heiko pinged this thread on June 14th.

Thierry: can you help give us some direction?  Are you uninterested in
reviewing them and would prefer that I find someone to land them in
drm-misc directly?


-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Douglas.
> >
> > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > tree.  The cover letter for his v3 is at:
> > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > >
> > > No code is different between v4 and v5, just commit messages and text
> > > in the bindings.
> > >
> > > I've pulled together the patches that didn't land in v3, addressed
> > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > rk3288-veryon-minnie.
> > >
> > > Please let me know how they look.
> > >
> > > In general I have added people to the whole series who I think would
> > > like the whole series and then let get_maintainer pick extra people it
> > > thinks are relevant to each individual patch.  If I see you respond to
> > > any of the patches in the series, though, I'll add you to the whole
> > > series Cc list next time.
> > >
> > > Changes in v5:
> > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > - Added Heiko's Tested-by
> > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> >
> > What are the plans to move forward with this?
> > Or did you drop the whole idea again?
>
> At the moment I'm blocked on Thierry responding, either taking the
> patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> Thierry on IRC on June 3rd and as far as I could tell there was no
> response.
>
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
>
> ...and as you can see Heiko pinged this thread on June 14th.
>
> Thierry: can you help give us some direction?  Are you uninterested in
> reviewing them and would prefer that I find someone to land them in
> drm-misc directly?

Sam: Oh!  I hadn't noticed that you've been added as a panel
maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
for drm/panel").  Does that mean you are able to provide some advice
for how to land this series?  As far as I know everything is in order
for it to land, but if you are aware of something I need to do to spin
it then please let me know!

Thanks!

-Doug

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Douglas.
> >
> > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > tree.  The cover letter for his v3 is at:
> > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > >
> > > No code is different between v4 and v5, just commit messages and text
> > > in the bindings.
> > >
> > > I've pulled together the patches that didn't land in v3, addressed
> > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > rk3288-veryon-minnie.
> > >
> > > Please let me know how they look.
> > >
> > > In general I have added people to the whole series who I think would
> > > like the whole series and then let get_maintainer pick extra people it
> > > thinks are relevant to each individual patch.  If I see you respond to
> > > any of the patches in the series, though, I'll add you to the whole
> > > series Cc list next time.
> > >
> > > Changes in v5:
> > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > - Added Heiko's Tested-by
> > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> >
> > What are the plans to move forward with this?
> > Or did you drop the whole idea again?
>
> At the moment I'm blocked on Thierry responding, either taking the
> patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> Thierry on IRC on June 3rd and as far as I could tell there was no
> response.
>
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
>
> ...and as you can see Heiko pinged this thread on June 14th.
>
> Thierry: can you help give us some direction?  Are you uninterested in
> reviewing them and would prefer that I find someone to land them in
> drm-misc directly?

Sam: Oh!  I hadn't noticed that you've been added as a panel
maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
for drm/panel").  Does that mean you are able to provide some advice
for how to land this series?  As far as I know everything is in order
for it to land, but if you are aware of something I need to do to spin
it then please let me know!

Thanks!

-Doug

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi,

On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> >
> > Hi Douglas.
> >
> > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > tree.  The cover letter for his v3 is at:
> > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > >
> > > No code is different between v4 and v5, just commit messages and text
> > > in the bindings.
> > >
> > > I've pulled together the patches that didn't land in v3, addressed
> > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > rk3288-veryon-minnie.
> > >
> > > Please let me know how they look.
> > >
> > > In general I have added people to the whole series who I think would
> > > like the whole series and then let get_maintainer pick extra people it
> > > thinks are relevant to each individual patch.  If I see you respond to
> > > any of the patches in the series, though, I'll add you to the whole
> > > series Cc list next time.
> > >
> > > Changes in v5:
> > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > - Added Heiko's Tested-by
> > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> >
> > What are the plans to move forward with this?
> > Or did you drop the whole idea again?
>
> At the moment I'm blocked on Thierry responding, either taking the
> patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> Thierry on IRC on June 3rd and as far as I could tell there was no
> response.
>
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
>
> ...and as you can see Heiko pinged this thread on June 14th.
>
> Thierry: can you help give us some direction?  Are you uninterested in
> reviewing them and would prefer that I find someone to land them in
> drm-misc directly?

Sam: Oh!  I hadn't noticed that you've been added as a panel
maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
for drm/panel").  Does that mean you are able to provide some advice
for how to land this series?  As far as I know everything is in order
for it to land, but if you are aware of something I need to do to spin
it then please let me know!

Thanks!

-Doug

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Rob Herring]

On Fri, Jun 28, 2019 at 9:55 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Douglas.
> > >
> > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > > tree.  The cover letter for his v3 is at:
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > > >
> > > > No code is different between v4 and v5, just commit messages and text
> > > > in the bindings.
> > > >
> > > > I've pulled together the patches that didn't land in v3, addressed
> > > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > > rk3288-veryon-minnie.
> > > >
> > > > Please let me know how they look.
> > > >
> > > > In general I have added people to the whole series who I think would
> > > > like the whole series and then let get_maintainer pick extra people it
> > > > thinks are relevant to each individual patch.  If I see you respond to
> > > > any of the patches in the series, though, I'll add you to the whole
> > > > series Cc list next time.
> > > >
> > > > Changes in v5:
> > > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > > - Added Heiko's Tested-by
> > > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> > >
> > > What are the plans to move forward with this?
> > > Or did you drop the whole idea again?
> >
> > At the moment I'm blocked on Thierry responding, either taking the
> > patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> > Thierry on IRC on June 3rd and as far as I could tell there was no
> > response.
> >
> > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
> >
> > ...and as you can see Heiko pinged this thread on June 14th.
> >
> > Thierry: can you help give us some direction?  Are you uninterested in
> > reviewing them and would prefer that I find someone to land them in
> > drm-misc directly?
>
> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?  As far as I know everything is in order
> for it to land, but if you are aware of something I need to do to spin
> it then please let me know!

BTW, at least for the binding, this will get implicitly supported in
the schema conversion[1] as simple-panel as a binding is gone and
panel-common already had timing node defined. A schema for the timing
node is still needed though (hint :) ).

Rob

[1] https://patchwork.ozlabs.org/patch/1121538/

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Rob Herring]

On Fri, Jun 28, 2019 at 9:55 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Douglas.
> > >
> > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > > tree.  The cover letter for his v3 is at:
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > > >
> > > > No code is different between v4 and v5, just commit messages and text
> > > > in the bindings.
> > > >
> > > > I've pulled together the patches that didn't land in v3, addressed
> > > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > > rk3288-veryon-minnie.
> > > >
> > > > Please let me know how they look.
> > > >
> > > > In general I have added people to the whole series who I think would
> > > > like the whole series and then let get_maintainer pick extra people it
> > > > thinks are relevant to each individual patch.  If I see you respond to
> > > > any of the patches in the series, though, I'll add you to the whole
> > > > series Cc list next time.
> > > >
> > > > Changes in v5:
> > > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > > - Added Heiko's Tested-by
> > > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> > >
> > > What are the plans to move forward with this?
> > > Or did you drop the whole idea again?
> >
> > At the moment I'm blocked on Thierry responding, either taking the
> > patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> > Thierry on IRC on June 3rd and as far as I could tell there was no
> > response.
> >
> > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
> >
> > ...and as you can see Heiko pinged this thread on June 14th.
> >
> > Thierry: can you help give us some direction?  Are you uninterested in
> > reviewing them and would prefer that I find someone to land them in
> > drm-misc directly?
>
> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?  As far as I know everything is in order
> for it to land, but if you are aware of something I need to do to spin
> it then please let me know!

BTW, at least for the binding, this will get implicitly supported in
the schema conversion[1] as simple-panel as a binding is gone and
panel-common already had timing node defined. A schema for the timing
node is still needed though (hint :) ).

Rob

[1] https://patchwork.ozlabs.org/patch/1121538/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Rob Herring]

On Fri, Jun 28, 2019 at 9:55 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote:
> > >
> > > Hi Douglas.
> > >
> > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > > > I'm reviving Sean Paul's old patchset to get mode support in device
> > > > tree.  The cover letter for his v3 is at:
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
> > > >
> > > > No code is different between v4 and v5, just commit messages and text
> > > > in the bindings.
> > > >
> > > > I've pulled together the patches that didn't land in v3, addressed
> > > > outstanding feedback, and reposted.  Atop them I've added patches for
> > > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and
> > > > rk3288-veryon-minnie.
> > > >
> > > > Please let me know how they look.
> > > >
> > > > In general I have added people to the whole series who I think would
> > > > like the whole series and then let get_maintainer pick extra people it
> > > > thinks are relevant to each individual patch.  If I see you respond to
> > > > any of the patches in the series, though, I'll add you to the whole
> > > > series Cc list next time.
> > > >
> > > > Changes in v5:
> > > > - Removed bit about OS may ignore (Rob/Ezequiel)
> > > > - Added Heiko's Tested-by
> > > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko)
> > >
> > > What are the plans to move forward with this?
> > > Or did you drop the whole idea again?
> >
> > At the moment I'm blocked on Thierry responding, either taking the
> > patch or telling me what I need to do to fix it.  I saw Sean Paul ping
> > Thierry on IRC on June 3rd and as far as I could tell there was no
> > response.
> >
> > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true
> >
> > ...and as you can see Heiko pinged this thread on June 14th.
> >
> > Thierry: can you help give us some direction?  Are you uninterested in
> > reviewing them and would prefer that I find someone to land them in
> > drm-misc directly?
>
> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?  As far as I know everything is in order
> for it to land, but if you are aware of something I need to do to spin
> it then please let me know!

BTW, at least for the binding, this will get implicitly supported in
the schema conversion[1] as simple-panel as a binding is gone and
panel-common already had timing node defined. A schema for the timing
node is still needed though (hint :) ).

Rob

[1] https://patchwork.ozlabs.org/patch/1121538/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Doug.

> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?
Reviewer only, not maintainer....

It is on my TODO list for the weekend to go through the patch set in
details and provide feedback. I have read them before, but I miss to do
a more detailed read through.

But I cannot apply this unless Thierry or one of the DRM maintainers
ack it.
We simply need someone with a better general knowledge of DRM to ack it
than I have.

	Sam

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Doug.

> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?
Reviewer only, not maintainer....

It is on my TODO list for the weekend to go through the patch set in
details and provide feedback. I have read them before, but I miss to do
a more detailed read through.

But I cannot apply this unless Thierry or one of the DRM maintainers
ack it.
We simply need someone with a better general knowledge of DRM to ack it
than I have.

	Sam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Doug.

> Sam: Oh!  I hadn't noticed that you've been added as a panel
> maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> for drm/panel").  Does that mean you are able to provide some advice
> for how to land this series?
Reviewer only, not maintainer....

It is on my TODO list for the weekend to go through the patch set in
details and provide feedback. I have read them before, but I miss to do
a more detailed read through.

But I cannot apply this unless Thierry or one of the DRM maintainers
ack it.
We simply need someone with a better general knowledge of DRM to ack it
than I have.

	Sam

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stübner]

Hi Sam,

Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> Hi Doug.
> 
> > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > for drm/panel").  Does that mean you are able to provide some advice
> > for how to land this series?
> Reviewer only, not maintainer....
> 
> It is on my TODO list for the weekend to go through the patch set in
> details and provide feedback. I have read them before, but I miss to do
> a more detailed read through.
> 
> But I cannot apply this unless Thierry or one of the DRM maintainers
> ack it.
> We simply need someone with a better general knowledge of DRM to ack it
> than I have.

So Thierry was able to look at the patches yesterday it seems and has Acked
all the relevant ones. As a drm-misc-contributor I could also apply them
myself, but now don't want to preempt any additional comments you might
have ;-) . So I guess my question would be if you still want to do a review
or if I should apply them.


In any case, I'd like to take the actual dts patches (patches 3+6+7 if
I'm not mistaken) through my tree up to arm-soc after the fact, to
prevent conflicts.

Thanks
Heiko

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stübner]

Hi Sam,

Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> Hi Doug.
> 
> > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > for drm/panel").  Does that mean you are able to provide some advice
> > for how to land this series?
> Reviewer only, not maintainer....
> 
> It is on my TODO list for the weekend to go through the patch set in
> details and provide feedback. I have read them before, but I miss to do
> a more detailed read through.
> 
> But I cannot apply this unless Thierry or one of the DRM maintainers
> ack it.
> We simply need someone with a better general knowledge of DRM to ack it
> than I have.

So Thierry was able to look at the patches yesterday it seems and has Acked
all the relevant ones. As a drm-misc-contributor I could also apply them
myself, but now don't want to preempt any additional comments you might
have ;-) . So I guess my question would be if you still want to do a review
or if I should apply them.


In any case, I'd like to take the actual dts patches (patches 3+6+7 if
I'm not mistaken) through my tree up to arm-soc after the fact, to
prevent conflicts.

Thanks
Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Heiko Stübner]

Hi Sam,

Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> Hi Doug.
> 
> > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > for drm/panel").  Does that mean you are able to provide some advice
> > for how to land this series?
> Reviewer only, not maintainer....
> 
> It is on my TODO list for the weekend to go through the patch set in
> details and provide feedback. I have read them before, but I miss to do
> a more detailed read through.
> 
> But I cannot apply this unless Thierry or one of the DRM maintainers
> ack it.
> We simply need someone with a better general knowledge of DRM to ack it
> than I have.

So Thierry was able to look at the patches yesterday it seems and has Acked
all the relevant ones. As a drm-misc-contributor I could also apply them
myself, but now don't want to preempt any additional comments you might
have ;-) . So I guess my question would be if you still want to do a review
or if I should apply them.


In any case, I'd like to take the actual dts patches (patches 3+6+7 if
I'm not mistaken) through my tree up to arm-soc after the fact, to
prevent conflicts.

Thanks
Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi Sam,

On Sat, Jun 29, 2019 at 7:09 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Sam,
>
> Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> > Hi Doug.
> >
> > > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > > for drm/panel").  Does that mean you are able to provide some advice
> > > for how to land this series?
> > Reviewer only, not maintainer....
> >
> > It is on my TODO list for the weekend to go through the patch set in
> > details and provide feedback. I have read them before, but I miss to do
> > a more detailed read through.
> >
> > But I cannot apply this unless Thierry or one of the DRM maintainers
> > ack it.
> > We simply need someone with a better general knowledge of DRM to ack it
> > than I have.
>
> So Thierry was able to look at the patches yesterday it seems and has Acked
> all the relevant ones. As a drm-misc-contributor I could also apply them
> myself, but now don't want to preempt any additional comments you might
> have ;-) . So I guess my question would be if you still want to do a review
> or if I should apply them.

Hopefully you saw, but I responded to all of your review feedback.  In
the end, I thought it'd be OK to land the series as-is and I can fix
up nits in a follow-up series, though I'm waiting for your responses
to a couple questions first.

It would be ideal if you could confirm that you're OK with this plan
even if you don't have time to respond in detail to my emails yet.  I
think Heiko can land them all through the appropriate channels since
the patches have all the proper Acks.

Thanks!

-Doug

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi Sam,

On Sat, Jun 29, 2019 at 7:09 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Sam,
>
> Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> > Hi Doug.
> >
> > > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > > for drm/panel").  Does that mean you are able to provide some advice
> > > for how to land this series?
> > Reviewer only, not maintainer....
> >
> > It is on my TODO list for the weekend to go through the patch set in
> > details and provide feedback. I have read them before, but I miss to do
> > a more detailed read through.
> >
> > But I cannot apply this unless Thierry or one of the DRM maintainers
> > ack it.
> > We simply need someone with a better general knowledge of DRM to ack it
> > than I have.
>
> So Thierry was able to look at the patches yesterday it seems and has Acked
> all the relevant ones. As a drm-misc-contributor I could also apply them
> myself, but now don't want to preempt any additional comments you might
> have ;-) . So I guess my question would be if you still want to do a review
> or if I should apply them.

Hopefully you saw, but I responded to all of your review feedback.  In
the end, I thought it'd be OK to land the series as-is and I can fix
up nits in a follow-up series, though I'm waiting for your responses
to a couple questions first.

It would be ideal if you could confirm that you're OK with this plan
even if you don't have time to respond in detail to my emails yet.  I
think Heiko can land them all through the appropriate channels since
the patches have all the proper Acks.

Thanks!

-Doug

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Doug Anderson]

Hi Sam,

On Sat, Jun 29, 2019 at 7:09 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Sam,
>
> Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg:
> > Hi Doug.
> >
> > > Sam: Oh!  I hadn't noticed that you've been added as a panel
> > > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer
> > > for drm/panel").  Does that mean you are able to provide some advice
> > > for how to land this series?
> > Reviewer only, not maintainer....
> >
> > It is on my TODO list for the weekend to go through the patch set in
> > details and provide feedback. I have read them before, but I miss to do
> > a more detailed read through.
> >
> > But I cannot apply this unless Thierry or one of the DRM maintainers
> > ack it.
> > We simply need someone with a better general knowledge of DRM to ack it
> > than I have.
>
> So Thierry was able to look at the patches yesterday it seems and has Acked
> all the relevant ones. As a drm-misc-contributor I could also apply them
> myself, but now don't want to preempt any additional comments you might
> have ;-) . So I guess my question would be if you still want to do a review
> or if I should apply them.

Hopefully you saw, but I responded to all of your review feedback.  In
the end, I thought it'd be OK to land the series as-is and I can fix
up nits in a follow-up series, though I'm waiting for your responses
to a couple questions first.

It would be ideal if you could confirm that you're OK with this plan
even if you don't have time to respond in detail to my emails yet.  I
think Heiko can land them all through the appropriate channels since
the patches have all the proper Acks.

Thanks!

-Doug

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Dough.

> > So Thierry was able to look at the patches yesterday it seems and has Acked
> > all the relevant ones. As a drm-misc-contributor I could also apply them
> > myself, but now don't want to preempt any additional comments you might
> > have ;-) . So I guess my question would be if you still want to do a review
> > or if I should apply them.
> 
> Hopefully you saw, but I responded to all of your review feedback.  In
> the end, I thought it'd be OK to land the series as-is and I can fix
> up nits in a follow-up series, though I'm waiting for your responses
> to a couple questions first.
> 
> It would be ideal if you could confirm that you're OK with this plan
> even if you don't have time to respond in detail to my emails yet.  I
> think Heiko can land them all through the appropriate channels since
> the patches have all the proper Acks.
My main concern was the bug cocerning override_mode - which turned out to
be me confused.
There is one part about flags that does not yet makes sense but
we can fix it later.

Please resend a series that applies to drm-misc-next so
we can land this.

	Sam

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Dough.

> > So Thierry was able to look at the patches yesterday it seems and has Acked
> > all the relevant ones. As a drm-misc-contributor I could also apply them
> > myself, but now don't want to preempt any additional comments you might
> > have ;-) . So I guess my question would be if you still want to do a review
> > or if I should apply them.
> 
> Hopefully you saw, but I responded to all of your review feedback.  In
> the end, I thought it'd be OK to land the series as-is and I can fix
> up nits in a follow-up series, though I'm waiting for your responses
> to a couple questions first.
> 
> It would be ideal if you could confirm that you're OK with this plan
> even if you don't have time to respond in detail to my emails yet.  I
> think Heiko can land them all through the appropriate channels since
> the patches have all the proper Acks.
My main concern was the bug cocerning override_mode - which turned out to
be me confused.
There is one part about flags that does not yet makes sense but
we can fix it later.

Please resend a series that applies to drm-misc-next so
we can land this.

	Sam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree

[Sam Ravnborg]

Hi Dough.

> > So Thierry was able to look at the patches yesterday it seems and has Acked
> > all the relevant ones. As a drm-misc-contributor I could also apply them
> > myself, but now don't want to preempt any additional comments you might
> > have ;-) . So I guess my question would be if you still want to do a review
> > or if I should apply them.
> 
> Hopefully you saw, but I responded to all of your review feedback.  In
> the end, I thought it'd be OK to land the series as-is and I can fix
> up nits in a follow-up series, though I'm waiting for your responses
> to a couple questions first.
> 
> It would be ideal if you could confirm that you're OK with this plan
> even if you don't have time to respond in detail to my emails yet.  I
> think Heiko can land them all through the appropriate channels since
> the patches have all the proper Acks.
My main concern was the bug cocerning override_mode - which turned out to
be me confused.
There is one part about flags that does not yet makes sense but
we can fix it later.

Please resend a series that applies to drm-misc-next so
we can land this.

	Sam