[PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Dhinakaran Pandiyan]

A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org #v5.2
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: François Guerraz <kubrick@fgv6.net>
---
 drivers/gpu/drm/i915/display/intel_bios.c     | 2 +-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
index 21501d565327..b416b394b641 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 	}
 
 	if (bdb->version >= 226) {
-		u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
+		u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
 
 		wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
 		switch (wakeup_time) {
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 93f5c9d204d6..09cd37fb0b1c 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -481,13 +481,13 @@ struct psr_table {
 	/* TP wake up time in multiple of 100 */
 	u16 tp1_wakeup_time;
 	u16 tp2_tp3_wakeup_time;
-
-	/* PSR2 TP2/TP3 wakeup time for 16 panels */
-	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 struct bdb_psr {
 	struct psr_table psr_table[16];
+
+	/* PSR2 TP2/TP3 wakeup time for 16 panels */
+	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 /*
-- 
2.17.1

[PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Dhinakaran Pandiyan]

A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org #v5.2
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: François Guerraz <kubrick@fgv6.net>
---
 drivers/gpu/drm/i915/display/intel_bios.c     | 2 +-
 drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
index 21501d565327..b416b394b641 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 	}
 
 	if (bdb->version >= 226) {
-		u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
+		u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
 
 		wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
 		switch (wakeup_time) {
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 93f5c9d204d6..09cd37fb0b1c 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -481,13 +481,13 @@ struct psr_table {
 	/* TP wake up time in multiple of 100 */
 	u16 tp1_wakeup_time;
 	u16 tp2_tp3_wakeup_time;
-
-	/* PSR2 TP2/TP3 wakeup time for 16 panels */
-	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 struct bdb_psr {
 	struct psr_table psr_table[16];
+
+	/* PSR2 TP2/TP3 wakeup time for 16 panels */
+	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 /*
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for drm/i915/vbt: Fix VBT parsing for the PSR section (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/vbt: Fix VBT parsing for the PSR section (rev3)
URL   : https://patchwork.freedesktop.org/series/63774/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6502 -> Patchwork_13678
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/

Known issues
------------

  Here are the changes found in Patchwork_13678 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_module_load@reload:
    - fi-blb-e6850:       [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-blb-e6850/igt@i915_module_load@reload.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-blb-e6850/igt@i915_module_load@reload.html

  * igt@kms_chamelium@dp-edid-read:
    - fi-cml-u2:          [PASS][3] -> [FAIL][4] ([fdo#109483])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html

  
#### Possible fixes ####

  * igt@gem_basic@bad-close:
    - fi-icl-u3:          [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-icl-u3/igt@gem_basic@bad-close.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-icl-u3/igt@gem_basic@bad-close.html

  * igt@gem_ctx_create@basic-files:
    - fi-icl-u3:          [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) -> [PASS][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-icl-u3/igt@gem_ctx_create@basic-files.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-icl-u3/igt@gem_ctx_create@basic-files.html

  * {igt@gem_ctx_switch@legacy-render}:
    - fi-icl-guc:         [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-icl-guc/igt@gem_ctx_switch@legacy-render.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-icl-guc/igt@gem_ctx_switch@legacy-render.html

  * {igt@gem_ctx_switch@rcs0}:
    - fi-icl-u2:          [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-icl-u2/igt@gem_ctx_switch@rcs0.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-icl-u2/igt@gem_ctx_switch@rcs0.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][13] ([fdo#109485]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6502/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (52 -> 46)
------------------------------

  Additional (1): fi-apl-guc 
  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_6502 -> Patchwork_13678

  CI_DRM_6502: 606a844d5d932fb07b2377b95c0fe7b08383e32a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5102: 6038ace76016d8892f4d13aef5301f71ca1a6e2d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13678: d709a963b6350446325d666fa40fb59bc57b5902 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d709a963b635 drm/i915/vbt: Fix VBT parsing for the PSR section

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13678/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Wed, Jul 17, 2019 at 03:34:51PM -0700, Dhinakaran Pandiyan wrote:
> A single 32-bit PSR2 training pattern field follows the sixteen element
> array of PSR table entries in the VBT spec. But, we incorrectly define
> this PSR2 field for each of the PSR table entries. As a result, the PSR1
> training pattern duration for any panel_type != 0 will be parsed
> incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
> version >= 226 will also be wrong.
> 
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Cc: stable@vger.kernel.org
> Cc: stable@vger.kernel.org #v5.2
> Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Tested-by: François Guerraz <kubrick@fgv6.net>

pushed, thanks for the patches, reviews and tests.

> ---
>  Drivers/gpu/drm/i915/display/intel_bios.c     | 2 +-
>  drivers/gpu/drm/i915/display/intel_vbt_defs.h | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> index 21501d565327..b416b394b641 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -766,7 +766,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
>  	}
>  
>  	if (bdb->version >= 226) {
> -		u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
> +		u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
>  
>  		wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
>  		switch (wakeup_time) {
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 93f5c9d204d6..09cd37fb0b1c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -481,13 +481,13 @@ struct psr_table {
>  	/* TP wake up time in multiple of 100 */
>  	u16 tp1_wakeup_time;
>  	u16 tp2_tp3_wakeup_time;
> -
> -	/* PSR2 TP2/TP3 wakeup time for 16 panels */
> -	u32 psr2_tp2_tp3_wakeup_time;
>  } __packed;
>  
>  struct bdb_psr {
>  	struct psr_table psr_table[16];
> +
> +	/* PSR2 TP2/TP3 wakeup time for 16 panels */
> +	u32 psr2_tp2_tp3_wakeup_time;
>  } __packed;
>  
>  /*
> -- 
> 2.17.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Sasha Levin]

Hi,

[This is an automated email]

This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 88a0d9606aff drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time.

The bot has tested the following trees: v5.2.1.

v5.2.1: Failed to apply! Possible dependencies:
    231dcffc234f ("drm/i915/bios: add BDB block comments before definitions")
    843444ed1301 ("drm/i915/bios: sort BDB block definitions using block ID")
    f87f6599c843 ("drm/i915/bios: reserve struct bdb_ prefix for BDB blocks")


NOTE: The patch will not be queued to stable trees until it is upstream.

How should we proceed with this patch?

--
Thanks,
Sasha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Dhinakaran Pandiyan]

A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org #v5.2
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: François Guerraz <kubrick@fgv6.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit b5ea9c9337007d6e700280c8a60b4e10d070fb53)
---
 drivers/gpu/drm/i915/intel_bios.c     | 2 +-
 drivers/gpu/drm/i915/intel_vbt_defs.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index 1dc8d03ff127..ee6fa75d65a2 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -762,7 +762,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
 	}
 
 	if (bdb->version >= 226) {
-		u32 wakeup_time = psr_table->psr2_tp2_tp3_wakeup_time;
+		u32 wakeup_time = psr->psr2_tp2_tp3_wakeup_time;
 
 		wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
 		switch (wakeup_time) {
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h
index fdbbb9a53804..796c070bbe6f 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -772,13 +772,13 @@ struct psr_table {
 	/* TP wake up time in multiple of 100 */
 	u16 tp1_wakeup_time;
 	u16 tp2_tp3_wakeup_time;
-
-	/* PSR2 TP2/TP3 wakeup time for 16 panels */
-	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 struct bdb_psr {
 	struct psr_table psr_table[16];
+
+	/* PSR2 TP2/TP3 wakeup time for 16 panels */
+	u32 psr2_tp2_tp3_wakeup_time;
 } __packed;
 
 /*
-- 
2.17.1

Re: [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Greg KH]

On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> A single 32-bit PSR2 training pattern field follows the sixteen element
> array of PSR table entries in the VBT spec. But, we incorrectly define
> this PSR2 field for each of the PSR table entries. As a result, the PSR1
> training pattern duration for any panel_type != 0 will be parsed
> incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
> version >= 226 will also be wrong.
> 
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Cc: stable@vger.kernel.org
> Cc: stable@vger.kernel.org #v5.2
> Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Tested-by: François Guerraz <kubrick@fgv6.net>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> (cherry picked from commit b5ea9c9337007d6e700280c8a60b4e10d070fb53)

There is no such commit in Linus's kernel tree :(

Re: [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Souza, Jose]

On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > A single 32-bit PSR2 training pattern field follows the sixteen
> > element
> > array of PSR table entries in the VBT spec. But, we incorrectly
> > define
> > this PSR2 field for each of the PSR table entries. As a result, the
> > PSR1
> > training pattern duration for any panel_type != 0 will be parsed
> > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > with bdb
> > version >= 226 will also be wrong.
> > 
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: José Roberto de Souza <jose.souza@intel.com>
> > Cc: stable@vger.kernel.org
> > Cc: stable@vger.kernel.org #v5.2
> > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > with PSR2 TP2/3 wakeup time")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Tested-by: François Guerraz <kubrick@fgv6.net>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > (cherry picked from commit
> > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> 
> There is no such commit in Linus's kernel tree :(
> 

It is still on drm-intel/drm-intel-next-queued -
ssh://git.freedesktop.org/git/drm-intel

Rodrigo do you know when is the next pull-request to Linus?

Re: [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Souza, Jose]

On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > A single 32-bit PSR2 training pattern field follows the sixteen
> > element
> > array of PSR table entries in the VBT spec. But, we incorrectly
> > define
> > this PSR2 field for each of the PSR table entries. As a result, the
> > PSR1
> > training pattern duration for any panel_type != 0 will be parsed
> > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > with bdb
> > version >= 226 will also be wrong.
> > 
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Cc: José Roberto de Souza <jose.souza@intel.com>
> > Cc: stable@vger.kernel.org
> > Cc: stable@vger.kernel.org #v5.2
> > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > with PSR2 TP2/3 wakeup time")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Tested-by: François Guerraz <kubrick@fgv6.net>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > (cherry picked from commit
> > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> 
> There is no such commit in Linus's kernel tree :(
> 

It is still on drm-intel/drm-intel-next-queued -
ssh://git.freedesktop.org/git/drm-intel

Rodrigo do you know when is the next pull-request to Linus?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > element
> > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > define
> > > this PSR2 field for each of the PSR table entries. As a result, the
> > > PSR1
> > > training pattern duration for any panel_type != 0 will be parsed
> > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > with bdb
> > > version >= 226 will also be wrong.
> > > 
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > Cc: stable@vger.kernel.org
> > > Cc: stable@vger.kernel.org #v5.2
> > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > with PSR2 TP2/3 wakeup time")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > (cherry picked from commit
> > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > 
> > There is no such commit in Linus's kernel tree :(

not yet... It is queued for 5.3 on drm-intel-next-queued.

This line is automatically added by "dim" tool when
cherry-picking queued stuff for our drm-intel fixes branches.

> > 
> 
> It is still on drm-intel/drm-intel-next-queued -
> ssh://git.freedesktop.org/git/drm-intel
> 
> Rodrigo do you know when is the next pull-request to Linus?

I will start doing the pull requests to Dave and Daniel soon,
but this doesn't reach Linus tree before next merge window.

Eventually it will be there.

If this is a blocker fell free to remove the line and merge the
patch please, because this fix very critical issue that impact users.
So we can continue the discussion in parallel on how to handle
commit links like this in a better way.

Thanks,
Rodrigo.

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > element
> > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > define
> > > this PSR2 field for each of the PSR table entries. As a result, the
> > > PSR1
> > > training pattern duration for any panel_type != 0 will be parsed
> > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > with bdb
> > > version >= 226 will also be wrong.
> > > 
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > Cc: stable@vger.kernel.org
> > > Cc: stable@vger.kernel.org #v5.2
> > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > with PSR2 TP2/3 wakeup time")
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > (cherry picked from commit
> > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > 
> > There is no such commit in Linus's kernel tree :(

not yet... It is queued for 5.3 on drm-intel-next-queued.

This line is automatically added by "dim" tool when
cherry-picking queued stuff for our drm-intel fixes branches.

> > 
> 
> It is still on drm-intel/drm-intel-next-queued -
> ssh://git.freedesktop.org/git/drm-intel
> 
> Rodrigo do you know when is the next pull-request to Linus?

I will start doing the pull requests to Dave and Daniel soon,
but this doesn't reach Linus tree before next merge window.

Eventually it will be there.

If this is a blocker fell free to remove the line and merge the
patch please, because this fix very critical issue that impact users.
So we can continue the discussion in parallel on how to handle
commit links like this in a better way.

Thanks,
Rodrigo.

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

Hi Greg,

On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > element
> > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > define
> > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > PSR1
> > > > training pattern duration for any panel_type != 0 will be parsed
> > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > with bdb
> > > > version >= 226 will also be wrong.
> > > > 
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > Cc: stable@vger.kernel.org
> > > > Cc: stable@vger.kernel.org #v5.2
> > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > with PSR2 TP2/3 wakeup time")
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > (cherry picked from commit
> > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > 
> > > There is no such commit in Linus's kernel tree :(
> 
> not yet... It is queued for 5.3 on drm-intel-next-queued.
> 
> This line is automatically added by "dim" tool when
> cherry-picking queued stuff for our drm-intel fixes branches.

What do you need her from us to accept this patch?

> 
> > > 
> > 
> > It is still on drm-intel/drm-intel-next-queued -
> > ssh://git.freedesktop.org/git/drm-intel
> > 
> > Rodrigo do you know when is the next pull-request to Linus?
> 
> I will start doing the pull requests to Dave and Daniel soon,
> but this doesn't reach Linus tree before next merge window.
> 
> Eventually it will be there.
> 
> If this is a blocker fell free to remove the line and merge the
> patch please, because this fix very critical issue that impact users.
> So we can continue the discussion in parallel on how to handle
> commit links like this in a better way.
> 
> Thanks,
> Rodrigo.
> 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

Hi Greg,

On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > element
> > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > define
> > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > PSR1
> > > > training pattern duration for any panel_type != 0 will be parsed
> > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > with bdb
> > > > version >= 226 will also be wrong.
> > > > 
> > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > Cc: stable@vger.kernel.org
> > > > Cc: stable@vger.kernel.org #v5.2
> > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > with PSR2 TP2/3 wakeup time")
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > (cherry picked from commit
> > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > 
> > > There is no such commit in Linus's kernel tree :(
> 
> not yet... It is queued for 5.3 on drm-intel-next-queued.
> 
> This line is automatically added by "dim" tool when
> cherry-picking queued stuff for our drm-intel fixes branches.

What do you need her from us to accept this patch?

> 
> > > 
> > 
> > It is still on drm-intel/drm-intel-next-queued -
> > ssh://git.freedesktop.org/git/drm-intel
> > 
> > Rodrigo do you know when is the next pull-request to Linus?
> 
> I will start doing the pull requests to Dave and Daniel soon,
> but this doesn't reach Linus tree before next merge window.
> 
> Eventually it will be there.
> 
> If this is a blocker fell free to remove the line and merge the
> patch please, because this fix very critical issue that impact users.
> So we can continue the discussion in parallel on how to handle
> commit links like this in a better way.
> 
> Thanks,
> Rodrigo.
> 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Greg KH]

On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> Hi Greg,
> 
> On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > element
> > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > define
> > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > PSR1
> > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > with bdb
> > > > > version >= 226 will also be wrong.
> > > > > 
> > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > Cc: stable@vger.kernel.org
> > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > with PSR2 TP2/3 wakeup time")
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > Link: 
> > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > (cherry picked from commit
> > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > 
> > > > There is no such commit in Linus's kernel tree :(
> > 
> > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > 
> > This line is automatically added by "dim" tool when
> > cherry-picking queued stuff for our drm-intel fixes branches.
> 
> What do you need her from us to accept this patch?

Um, you have read the stable kernel rules, right?
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

That's what I need for it to go into a stable kernel release.

thanks,

greg k-h

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > Hi Greg,
> > 
> > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > element
> > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > define
> > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > PSR1
> > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > with bdb
> > > > > > version >= 226 will also be wrong.
> > > > > > 
> > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > Cc: stable@vger.kernel.org
> > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > Link: 
> > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > (cherry picked from commit
> > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > 
> > > > > There is no such commit in Linus's kernel tree :(
> > > 
> > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > 
> > > This line is automatically added by "dim" tool when
> > > cherry-picking queued stuff for our drm-intel fixes branches.
> > 
> > What do you need her from us to accept this patch?
> 
> Um, you have read the stable kernel rules, right?
>     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
> That's what I need for it to go into a stable kernel release.

Yes, I have read it. Maybe what I don't understand is just the fact that we will
let customers facing issues for 6 weeks or more while the original patch
doesn't land on Linus tree. :(

> 
> thanks,
> 
> greg k-h

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Greg KH]

On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > Hi Greg,
> > > 
> > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > element
> > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > define
> > > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > > PSR1
> > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > with bdb
> > > > > > > version >= 226 will also be wrong.
> > > > > > > 
> > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > Cc: stable@vger.kernel.org
> > > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > Link: 
> > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > > (cherry picked from commit
> > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > 
> > > > > > There is no such commit in Linus's kernel tree :(
> > > > 
> > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > 
> > > > This line is automatically added by "dim" tool when
> > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > 
> > > What do you need her from us to accept this patch?
> > 
> > Um, you have read the stable kernel rules, right?
> >     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> >
> > That's what I need for it to go into a stable kernel release.
> 
> Yes, I have read it. Maybe what I don't understand is just the fact that we will
> let customers facing issues for 6 weeks or more while the original patch
> doesn't land on Linus tree. :(

Then get the patch into Linus's tree!
Nothing I can do until that happens, you know this...

greg k-h

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > Hi Greg,
> > > > 
> > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > > element
> > > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > > define
> > > > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > > > PSR1
> > > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > > with bdb
> > > > > > > > version >= 226 will also be wrong.
> > > > > > > > 
> > > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Link: 
> > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > > > (cherry picked from commit
> > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > 
> > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > 
> > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > 
> > > > > This line is automatically added by "dim" tool when
> > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > 
> > > > What do you need her from us to accept this patch?
> > > 
> > > Um, you have read the stable kernel rules, right?
> > >     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > >
> > > That's what I need for it to go into a stable kernel release.
> > 
> > Yes, I have read it. Maybe what I don't understand is just the fact that we will
> > let customers facing issues for 6 weeks or more while the original patch
> > doesn't land on Linus tree. :(
> 
> Then get the patch into Linus's tree!
> Nothing I can do until that happens, you know this...

-ENOTENOUGHCOFFEE sorry.
For some reason I thought this thread had started as the reject of your scripts.

This patch is already queued on our drm-intel-fixes and will probably land on
Linus tree next week. Than your scripts will just get it.

So, back to your original concern:

The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
exist until 5.3 merge window though.

My question now is regarding our fixes flow adding these future references.
Do you have any concern with that?

Sorry and Thanks,
Rodrigo.

> 
> greg k-h

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > Hi Greg,
> > > > 
> > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > > element
> > > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > > define
> > > > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > > > PSR1
> > > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > > with bdb
> > > > > > > > version >= 226 will also be wrong.
> > > > > > > > 
> > > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > Link: 
> > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > > > (cherry picked from commit
> > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > 
> > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > 
> > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > 
> > > > > This line is automatically added by "dim" tool when
> > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > 
> > > > What do you need her from us to accept this patch?
> > > 
> > > Um, you have read the stable kernel rules, right?
> > >     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > >
> > > That's what I need for it to go into a stable kernel release.
> > 
> > Yes, I have read it. Maybe what I don't understand is just the fact that we will
> > let customers facing issues for 6 weeks or more while the original patch
> > doesn't land on Linus tree. :(
> 
> Then get the patch into Linus's tree!
> Nothing I can do until that happens, you know this...

-ENOTENOUGHCOFFEE sorry.
For some reason I thought this thread had started as the reject of your scripts.

This patch is already queued on our drm-intel-fixes and will probably land on
Linus tree next week. Than your scripts will just get it.

So, back to your original concern:

The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
exist until 5.3 merge window though.

My question now is regarding our fixes flow adding these future references.
Do you have any concern with that?

Sorry and Thanks,
Rodrigo.

> 
> greg k-h

Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Greg KH]

On Tue, Jul 30, 2019 at 09:56:59AM -0700, Rodrigo Vivi wrote:
> 
> On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> > On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > > Hi Greg,
> > > > > 
> > > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > > > element
> > > > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > > > define
> > > > > > > > > this PSR2 field for each of the PSR table entries. As a result, the
> > > > > > > > > PSR1
> > > > > > > > > training pattern duration for any panel_type != 0 will be parsed
> > > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > > > with bdb
> > > > > > > > > version >= 226 will also be wrong.
> > > > > > > > > 
> > > > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > > Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > Link: 
> > > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
> > > > > > > > > (cherry picked from commit
> > > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > > 
> > > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > > 
> > > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > > 
> > > > > > This line is automatically added by "dim" tool when
> > > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > > 
> > > > > What do you need her from us to accept this patch?
> > > > 
> > > > Um, you have read the stable kernel rules, right?
> > > >     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > >
> > > > That's what I need for it to go into a stable kernel release.
> > > 
> > > Yes, I have read it. Maybe what I don't understand is just the fact that we will
> > > let customers facing issues for 6 weeks or more while the original patch
> > > doesn't land on Linus tree. :(
> > 
> > Then get the patch into Linus's tree!
> > Nothing I can do until that happens, you know this...
> 
> -ENOTENOUGHCOFFEE sorry.
> For some reason I thought this thread had started as the reject of your scripts.

That is correct.  But more coffee is always good.

> This patch is already queued on our drm-intel-fixes and will probably land on
> Linus tree next week. Than your scripts will just get it.
> 
> So, back to your original concern:
> 
> The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
> exist until 5.3 merge window though.

That's fine.

> My question now is regarding our fixes flow adding these future references.
> Do you have any concern with that?

I hate and despise and complain endlessly about how you all are doing
this, but I have learned to just suck it up and accept it.  It is a
major pain in the rear, and I will say that it causes me to delay all
merges of stable drm patches that get merged in Linus's tree in -rc1
until -rc2 or -rc3 is out usually as I have to go through and
hand-determine if a reject happens because it really is a reject, or
because this patch is already in the tree.

So, if this hits Linus's tree "like normal", my scripts will pick it up
and all is good.  I can handle this crazy notation you all feel that
works for you, but I reserve the right to complain.

This original patch, however, was sent only to stable and it seemed to
indicate that I needed to pick it up because it already was upstream (I
saw the cherry-pick line.)  As that is not the case here, fine, no harm,
no foul, let's go get more coffee...

greg k-h

RE: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for the PSR section

[Pandiyan, Dhinakaran]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Tuesday, July 30, 2019 10:09 AM
> To: Vivi, Rodrigo <rodrigo.vivi@intel.com>
> Cc: Nikula, Jani <jani.nikula@intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>; Souza, Jose <jose.souza@intel.com>;
> sashal@kernel.org; intel-gfx@lists.freedesktop.org; stable@vger.kernel.org;
> Pandiyan, Dhinakaran <dhinakaran.pandiyan@intel.com>
> Subject: Re: [Intel-gfx] [PATCH stable v5.2] drm/i915/vbt: Fix VBT parsing for
> the PSR section
> 
> On Tue, Jul 30, 2019 at 09:56:59AM -0700, Rodrigo Vivi wrote:
> >
> > On Tue, Jul 30, 2019 at 06:27:09PM +0200, Greg KH wrote:
> > > On Tue, Jul 30, 2019 at 09:22:07AM -0700, Rodrigo Vivi wrote:
> > > > On Tue, Jul 30, 2019 at 05:27:24PM +0200, Greg KH wrote:
> > > > > On Tue, Jul 30, 2019 at 08:19:08AM -0700, Rodrigo Vivi wrote:
> > > > > > Hi Greg,
> > > > > >
> > > > > > On Wed, Jul 24, 2019 at 10:40:29AM -0700, Rodrigo Vivi wrote:
> > > > > > > On Wed, Jul 24, 2019 at 05:27:42PM +0000, Souza, Jose wrote:
> > > > > > > > On Wed, 2019-07-24 at 14:06 +0200, Greg KH wrote:
> > > > > > > > > On Mon, Jul 22, 2019 at 04:13:25PM -0700, Dhinakaran Pandiyan
> wrote:
> > > > > > > > > > A single 32-bit PSR2 training pattern field follows the sixteen
> > > > > > > > > > element
> > > > > > > > > > array of PSR table entries in the VBT spec. But, we incorrectly
> > > > > > > > > > define
> > > > > > > > > > this PSR2 field for each of the PSR table entries. As a result,
> the
> > > > > > > > > > PSR1
> > > > > > > > > > training pattern duration for any panel_type != 0 will be
> parsed
> > > > > > > > > > incorrectly. Secondly, PSR2 training pattern durations for VBTs
> > > > > > > > > > with bdb
> > > > > > > > > > version >= 226 will also be wrong.
> > > > > > > > > >
> > > > > > > > > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > Cc: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > > > Cc: stable@vger.kernel.org
> > > > > > > > > > Cc: stable@vger.kernel.org #v5.2
> > > > > > > > > > Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field
> > > > > > > > > > with PSR2 TP2/3 wakeup time")
> > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
> > > > > > > > > > Signed-off-by: Dhinakaran Pandiyan
> <dhinakaran.pandiyan@intel.com>
> > > > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
> > > > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > Tested-by: François Guerraz <kubrick@fgv6.net>
> > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > > > > > > Link:
> > > > > > > > > >
> https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-
> dhinakaran.pandiyan@intel.com
> > > > > > > > > > (cherry picked from commit
> > > > > > > > > > b5ea9c9337007d6e700280c8a60b4e10d070fb53)
> > > > > > > > >
> > > > > > > > > There is no such commit in Linus's kernel tree :(
> > > > > > >
> > > > > > > not yet... It is queued for 5.3 on drm-intel-next-queued.
> > > > > > >
> > > > > > > This line is automatically added by "dim" tool when
> > > > > > > cherry-picking queued stuff for our drm-intel fixes branches.
> > > > > >
> > > > > > What do you need her from us to accept this patch?
> > > > >
> > > > > Um, you have read the stable kernel rules, right?
> > > > >     https://www.kernel.org/doc/html/latest/process/stable-kernel-
> rules.html
> > > > >
> > > > > That's what I need for it to go into a stable kernel release.
> > > >
> > > > Yes, I have read it. Maybe what I don't understand is just the fact that we
> will
> > > > let customers facing issues for 6 weeks or more while the original patch
> > > > doesn't land on Linus tree. :(
> > >
> > > Then get the patch into Linus's tree!
> > > Nothing I can do until that happens, you know this...
> >
> > -ENOTENOUGHCOFFEE sorry.
> > For some reason I thought this thread had started as the reject of your
> scripts.
> 
> That is correct.  But more coffee is always good.
> 
> > This patch is already queued on our drm-intel-fixes and will probably land on
> > Linus tree next week. Than your scripts will just get it.
> >
> > So, back to your original concern:
> >
> > The referrence b5ea9c9337007d6e700280c8a60b4e10d070fb53 you pointed out won't
> > exist until 5.3 merge window though.
> 
> That's fine.
> 
> > My question now is regarding our fixes flow adding these future references.
> > Do you have any concern with that?
> 
> I hate and despise and complain endlessly about how you all are doing
> this, but I have learned to just suck it up and accept it.  It is a
> major pain in the rear, and I will say that it causes me to delay all
> merges of stable drm patches that get merged in Linus's tree in -rc1
> until -rc2 or -rc3 is out usually as I have to go through and
> hand-determine if a reject happens because it really is a reject, or
> because this patch is already in the tree.
> 
> So, if this hits Linus's tree "like normal", my scripts will pick it up
> and all is good.  I can handle this crazy notation you all feel that
> works for you, but I reserve the right to complain.
> 
> This original patch, however, was sent only to stable and it seemed to
> indicate that I needed to pick it up because it already was upstream (I
> saw the cherry-pick line.)  As that is not the case here, fine, no harm,
> no foul, let's go get more coffee...

Not sure if it was my fault to have included the cherry-pick line, I'll talk
to Rodrigo offline to understand if that was the source of confusion.

-DK

> 
> greg k-h

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Rodrigo Vivi]

Hi Sasha,

On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin <sashal@kernel.org> wrote:
>
> Hi,
>
> [This is an automated email]

Where did you get this patch from? Since stable needs patches merged
on Linus tree,
shouldn't your scripts run to try backporting only patches from there?

Thanks,
Rodrigo.

>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 88a0d9606aff drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time.
>
> The bot has tested the following trees: v5.2.1.
> v5.2.1: Failed to apply! Possible dependencies:
>     231dcffc234f ("drm/i915/bios: add BDB block comments before definitions")
>     843444ed1301 ("drm/i915/bios: sort BDB block definitions using block ID")
>     f87f6599c843 ("drm/i915/bios: reserve struct bdb_ prefix for BDB blocks")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Sasha Levin]

On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>Hi Sasha,

Hello!

>On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin <sashal@kernel.org> wrote:
>>
>> Hi,
>>
>> [This is an automated email]
>
>Where did you get this patch from? Since stable needs patches merged

This bot grabs them from various mailing lists.

>on Linus tree,
>shouldn't your scripts run to try backporting only patches from there?

There's a note a few lines down that says:

    "NOTE: The patch will not be queued to stable trees until it is upstream."

Otherwise, no, there's no rule that says we can't look at patches before
they are upstream. We can't queue them up, but we sure can poke them.

The reasoning behind this is that it's easier to get replies (and
backports) from folks who are actively working on the patch now, rather
than a few weeks later when Greg sends his "FAILED:" mails and gets
ignored because said folks have moved on.

--
Thanks,
Sasha

Re: [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Sasha Levin]

On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>Hi Sasha,

Hello!

>On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin <sashal@kernel.org> wrote:
>>
>> Hi,
>>
>> [This is an automated email]
>
>Where did you get this patch from? Since stable needs patches merged

This bot grabs them from various mailing lists.

>on Linus tree,
>shouldn't your scripts run to try backporting only patches from there?

There's a note a few lines down that says:

    "NOTE: The patch will not be queued to stable trees until it is upstream."

Otherwise, no, there's no rule that says we can't look at patches before
they are upstream. We can't queue them up, but we sure can poke them.

The reasoning behind this is that it's easier to get replies (and
backports) from folks who are actively working on the patch now, rather
than a few weeks later when Greg sends his "FAILED:" mails and gets
ignored because said folks have moved on.

--
Thanks,
Sasha
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Vivi, Rodrigo]

> On Jul 30, 2019, at 2:48 PM, Sasha Levin <sashal@kernel.org> wrote:
> 
> On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>> Hi Sasha,
> 
> Hello!
> 
>> On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin <sashal@kernel.org> wrote:
>>> 
>>> Hi,
>>> 
>>> [This is an automated email]
>> 
>> Where did you get this patch from? Since stable needs patches merged
> 
> This bot grabs them from various mailing lists.
> 
>> on Linus tree,
>> shouldn't your scripts run to try backporting only patches from there?
> 
> There's a note a few lines down that says:
> 
>   "NOTE: The patch will not be queued to stable trees until it is upstream."
> 
> Otherwise, no, there's no rule that says we can't look at patches before
> they are upstream. We can't queue them up, but we sure can poke them.
> 
> The reasoning behind this is that it's easier to get replies (and
> backports) from folks who are actively working on the patch now,


This is a very good reason indeed...

> rather
> than a few weeks later when Greg sends his "FAILED:" mails and gets
> ignored because said folks have moved on.

however this could potentially cause extra work and confusion like we can see on this
thread where the developer immediately responded to your email and sent the
backported patch to the stable mailing list.

Maybe it is just because we are used to Greg's failed to apply email or maybe
it was just a matter of education... 

But I wonder if there isn't something that could be improved on the automated
message here. Some message clearly stating:

- No action required at this point
- you can work to prepare the backport in advance
-  don't send it to stable before requested by Greg

Anyway, just few ideas. I just reached you to understand the flow and I'm already
happy to understand what happened here.

Thanks a lot for that,
Rodrigo.


> 
> --
> Thanks,
> Sasha
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Vivi, Rodrigo]

> On Jul 30, 2019, at 2:48 PM, Sasha Levin <sashal@kernel.org> wrote:
> 
> On Tue, Jul 30, 2019 at 01:42:45PM -0700, Rodrigo Vivi wrote:
>> Hi Sasha,
> 
> Hello!
> 
>> On Thu, Jul 18, 2019 at 5:45 PM Sasha Levin <sashal@kernel.org> wrote:
>>> 
>>> Hi,
>>> 
>>> [This is an automated email]
>> 
>> Where did you get this patch from? Since stable needs patches merged
> 
> This bot grabs them from various mailing lists.
> 
>> on Linus tree,
>> shouldn't your scripts run to try backporting only patches from there?
> 
> There's a note a few lines down that says:
> 
>   "NOTE: The patch will not be queued to stable trees until it is upstream."
> 
> Otherwise, no, there's no rule that says we can't look at patches before
> they are upstream. We can't queue them up, but we sure can poke them.
> 
> The reasoning behind this is that it's easier to get replies (and
> backports) from folks who are actively working on the patch now,


This is a very good reason indeed...

> rather
> than a few weeks later when Greg sends his "FAILED:" mails and gets
> ignored because said folks have moved on.

however this could potentially cause extra work and confusion like we can see on this
thread where the developer immediately responded to your email and sent the
backported patch to the stable mailing list.

Maybe it is just because we are used to Greg's failed to apply email or maybe
it was just a matter of education... 

But I wonder if there isn't something that could be improved on the automated
message here. Some message clearly stating:

- No action required at this point
- you can work to prepare the backport in advance
-  don't send it to stable before requested by Greg

Anyway, just few ideas. I just reached you to understand the flow and I'm already
happy to understand what happened here.

Thanks a lot for that,
Rodrigo.


> 
> --
> Thanks,
> Sasha
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Sasha Levin]

On Wed, Jul 31, 2019 at 05:14:38PM +0000, Vivi, Rodrigo wrote:
>> On Jul 30, 2019, at 2:48 PM, Sasha Levin <sashal@kernel.org> wrote:
>> rather
>> than a few weeks later when Greg sends his "FAILED:" mails and gets
>> ignored because said folks have moved on.
>
>however this could potentially cause extra work and confusion like we can see on this
>thread where the developer immediately responded to your email and sent the
>backported patch to the stable mailing list.
>
>Maybe it is just because we are used to Greg's failed to apply email or maybe
>it was just a matter of education...

I think that there were a few things here that ended up causing
confusion, but I'm not quite sure how to address them.

I think that stable should have a clearer rules as to how backports
should be sent. Right now we weed through mails to stable@ to figure out
what are backport requests, what are upstream patches, and what are just
confused folks.

We have gotten pretty good at this, but still not perfect...

>But I wonder if there isn't something that could be improved on the automated
>message here. Some message clearly stating:
>
>- No action required at this point

One *could* send a backport at this point. My understanding is that when
Greg sees a failure to apply a commit tagged for stable he'll grep
through his mailbox, hopefully finding the backport as a result of this
bot bugging people.

>- you can work to prepare the backport in advance
>-  don't send it to stable before requested by Greg

Why not? I think it's fine to put it on the mailing list, specially
under the same thread, and let us deal with it after the patch goes
upstream.

--
Thanks,
Sasha

Re: [Intel-gfx] [PATCH] drm/i915/vbt: Fix VBT parsing for the PSR section

[Sasha Levin]

On Wed, Jul 31, 2019 at 05:14:38PM +0000, Vivi, Rodrigo wrote:
>> On Jul 30, 2019, at 2:48 PM, Sasha Levin <sashal@kernel.org> wrote:
>> rather
>> than a few weeks later when Greg sends his "FAILED:" mails and gets
>> ignored because said folks have moved on.
>
>however this could potentially cause extra work and confusion like we can see on this
>thread where the developer immediately responded to your email and sent the
>backported patch to the stable mailing list.
>
>Maybe it is just because we are used to Greg's failed to apply email or maybe
>it was just a matter of education...

I think that there were a few things here that ended up causing
confusion, but I'm not quite sure how to address them.

I think that stable should have a clearer rules as to how backports
should be sent. Right now we weed through mails to stable@ to figure out
what are backport requests, what are upstream patches, and what are just
confused folks.

We have gotten pretty good at this, but still not perfect...

>But I wonder if there isn't something that could be improved on the automated
>message here. Some message clearly stating:
>
>- No action required at this point

One *could* send a backport at this point. My understanding is that when
Greg sees a failure to apply a commit tagged for stable he'll grep
through his mailbox, hopefully finding the backport as a result of this
bot bugging people.

>- you can work to prepare the backport in advance
>-  don't send it to stable before requested by Greg

Why not? I think it's fine to put it on the mailing list, specially
under the same thread, and let us deal with it after the patch goes
upstream.