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-dhinakar... (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;
/*
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-dhinakar... (cherry picked from commit b5ea9c9337007d6e700280c8a60b4e10d070fb53)
There is no such commit in Linus's kernel tree :(
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-dhinakar... (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?
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-dhinakar... (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
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-dhinakar... (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
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-dhinakar... (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
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-dhinakar... (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
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-dhinakar... > (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
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-dhinakar... > > (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
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-dhinakar... > > > (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
-----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
> > > > 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
linux-stable-mirror@lists.linaro.org
-
Dhinakaran Pandiyan -
Greg KH -
Pandiyan, Dhinakaran
-
Rodrigo Vivi -
Souza, Jose