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