Drop 0fc6fea41c71 ("drm/i915: Disable DC states for all commits") from the 6.0.y series?

Drop 0fc6fea41c71 ("drm/i915: Disable DC states for all commits") from the 6.0.y series?

[Thorsten Leemhuis]

Hi Greg! Months ago you picked up mainline commit a2b6e99d8a6
("drm/i915: Disable DC states for all commits") for the 6.1.23 release
as commit 0fc6fea41c71. It causes issues vor a few people (at least
three, two of which are CCed) -- apparently because it depends on some
change that wasn't picked up for 6.1.y. This is known for a while now,
but nobody has yet found which change that is (Al found something that
worked for him, but that didn't work for others). For the whole story
skim this ticket:

https://gitlab.freedesktop.org/drm/intel/-/issues/8419

I wonder if it might be better if you revert that commit for 6.0.y; I
asked already in the ticket if this is likely to cause regressions for
users of 6.0.y, but got no answer from the i915 devs (or did I miss
something?). :-/

Ciao, Thorsten

Re: Drop 0fc6fea41c71 ("drm/i915: Disable DC states for all commits") from the 6.0.y series?

[Greg KH]

On Mon, Aug 07, 2023 at 12:52:03PM +0200, Thorsten Leemhuis wrote:
> Hi Greg! Months ago you picked up mainline commit a2b6e99d8a6
> ("drm/i915: Disable DC states for all commits") for the 6.1.23 release
> as commit 0fc6fea41c71. It causes issues vor a few people (at least
> three, two of which are CCed) -- apparently because it depends on some
> change that wasn't picked up for 6.1.y. This is known for a while now,
> but nobody has yet found which change that is (Al found something that
> worked for him, but that didn't work for others). For the whole story
> skim this ticket:
> 
> https://gitlab.freedesktop.org/drm/intel/-/issues/8419
> 
> I wonder if it might be better if you revert that commit for 6.0.y; I
> asked already in the ticket if this is likely to cause regressions for
> users of 6.0.y, but got no answer from the i915 devs (or did I miss
> something?). :-/

Now reverted (note, 6.0.y is long dead, I reverted this for 6.1.y)

thanks,

greg "drowning in kernel release numbers" k-h

Re: Drop 0fc6fea41c71 ("drm/i915: Disable DC states for all commits") from the 6.0.y series?

[Thorsten Leemhuis]

On 09.08.23 11:15, Greg KH wrote:
> On Mon, Aug 07, 2023 at 12:52:03PM +0200, Thorsten Leemhuis wrote:
>> Hi Greg! Months ago you picked up mainline commit a2b6e99d8a6
>> ("drm/i915: Disable DC states for all commits") for the 6.1.23 release
>> as commit 0fc6fea41c71. It causes issues vor a few people (at least
>> three, two of which are CCed) -- apparently because it depends on some
>> change that wasn't picked up for 6.1.y.

Fun fact: here I had an off-by-one error I noticed and fixed, but...

>> This is known for a while now,
>> but nobody has yet found which change that is (Al found something that
>> worked for him, but that didn't work for others). For the whole story
>> skim this ticket:
>>
>> https://gitlab.freedesktop.org/drm/intel/-/issues/8419
>>
>> I wonder if it might be better if you revert that commit for 6.0.y; I
>> asked already in the ticket if this is likely to cause regressions for
>> users of 6.0.y,

...here I did not. :-/ Sorry.

>> but got no answer from the i915 devs (or did I miss
>> something?). :-/
> 
> Now reverted (note, 6.0.y is long dead, I reverted this for 6.1.y)

Thx, but FWIW, seems my timing was bad. I had waited weeks before
escalating this to you (which looking back now is something I maybe
should have done earlier -- but first it looked like it was just one
person/machine affected by this problem). But it seems soon after I
brought this to your attention a solution came up, as a fix was posted
and confirmed working by one of the reporters -- and the developer wants
to post a backport for stable. For details see
https://gitlab.freedesktop.org/drm/intel/-/issues/8419#note_2035731

Not sure what's the right thing to do at this point for 6.1.y --
dropping the revert maybe before you do the release? You will know best
anyway.

> greg "drowning in kernel release numbers" k-h

Glad I'm not the only one. ;) But I guess it's worse for you...

Ciao, Thorsten

Re: Drop 0fc6fea41c71 ("drm/i915: Disable DC states for all commits") from the 6.0.y series?

[Greg KH]

On Thu, Aug 10, 2023 at 01:31:00PM +0200, Thorsten Leemhuis wrote:
> On 09.08.23 11:15, Greg KH wrote:
> > On Mon, Aug 07, 2023 at 12:52:03PM +0200, Thorsten Leemhuis wrote:
> >> Hi Greg! Months ago you picked up mainline commit a2b6e99d8a6
> >> ("drm/i915: Disable DC states for all commits") for the 6.1.23 release
> >> as commit 0fc6fea41c71. It causes issues vor a few people (at least
> >> three, two of which are CCed) -- apparently because it depends on some
> >> change that wasn't picked up for 6.1.y.
> 
> Fun fact: here I had an off-by-one error I noticed and fixed, but...
> 
> >> This is known for a while now,
> >> but nobody has yet found which change that is (Al found something that
> >> worked for him, but that didn't work for others). For the whole story
> >> skim this ticket:
> >>
> >> https://gitlab.freedesktop.org/drm/intel/-/issues/8419
> >>
> >> I wonder if it might be better if you revert that commit for 6.0.y; I
> >> asked already in the ticket if this is likely to cause regressions for
> >> users of 6.0.y,
> 
> ...here I did not. :-/ Sorry.
> 
> >> but got no answer from the i915 devs (or did I miss
> >> something?). :-/
> > 
> > Now reverted (note, 6.0.y is long dead, I reverted this for 6.1.y)
> 
> Thx, but FWIW, seems my timing was bad. I had waited weeks before
> escalating this to you (which looking back now is something I maybe
> should have done earlier -- but first it looked like it was just one
> person/machine affected by this problem). But it seems soon after I
> brought this to your attention a solution came up, as a fix was posted
> and confirmed working by one of the reporters -- and the developer wants
> to post a backport for stable. For details see
> https://gitlab.freedesktop.org/drm/intel/-/issues/8419#note_2035731
> 
> Not sure what's the right thing to do at this point for 6.1.y --
> dropping the revert maybe before you do the release? You will know best
> anyway.

Let me keep the revert, that will fix the issue now.  If upstream wants
to solve this in a different/better way, we can add both patches at once
to prevent any systems from being broken.

thanks,

greg k-h