> -----Original Message----- > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, July 30, 2019 10:09 AM > To: Vivi, Rodrigo <rodrigo.vivi@xxxxxxxxx> > Cc: Nikula, Jani <jani.nikula@xxxxxxxxx>; Joonas Lahtinen > <joonas.lahtinen@xxxxxxxxxxxxxxx>; Souza, Jose <jose.souza@xxxxxxxxx>; > sashal@xxxxxxxxxx; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; > Pandiyan, Dhinakaran <dhinakaran.pandiyan@xxxxxxxxx> > 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@xxxxxxxxx> > > > > > > > > > > Cc: José Roberto de Souza <jose.souza@xxxxxxxxx> > > > > > > > > > > Cc: stable@xxxxxxxxxxxxxxx > > > > > > > > > > Cc: stable@xxxxxxxxxxxxxxx #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@xxxxxxxxx> > > > > > > > > > > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > Reviewed-by: José Roberto de Souza <jose.souza@xxxxxxxxx> > > > > > > > > > > Acked-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > > > > > > > Tested-by: François Guerraz <kubrick@xxxxxxxx> > > > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > > > > > > > > > Link: > > > > > > > > > > > https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1- > dhinakaran.pandiyan@xxxxxxxxx > > > > > > > > > > (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
