Hi, > I'll send out a v2 shortly: Alex, can you > please retest when I do to make sure there aren't any regressions? None > of these suggestions affect the core flow of how either of the > workarounds work, so I'm not expecting any that wouldn't also reproduce > on my EC backlight system that doesn't have either of these problems, > but I can send you the updated version off-list first if you prefer. It's ok either way. You can send me an updated version off-list. > Alex, just FYI this was something that came to an AMD bug tracker and wanted you to be aware there are W/A going into nvidia-wmi-ec-backlight for some firmware problems with the mux. > IIRC that was the original suspicion too on the bug reports. Yes, thanks -- I followed this issue first: https://gitlab.freedesktop.org/drm/amd/-/issues/1671. > However I think it's still worth at least noting near the quirk in a comment > what firmware version it was identified. If later there is confirmation that > a particular firmware version had fixed it the quirk can be adjusted to be > dropped. That's a good tip. The laptop I tested this on (Lenovo Legion S7 15ACH6) originally shipped with: UEFI: LENOVO v: HACN27WW date: 08/02/2021 There is an update to version HACN31WW (see lenovo support: https://support.lenovo.com/ro/en/downloads/ds550201-bios-update-for-windows-10-64-bit-legion-s7-15ach6) -- which I applied, however, the issue was not addressed, which seems to be expected given the rather short /changelog: HACN31WW BIOS Notification : 1. Fixed 1) N/A. 2. Add 1) Add BOE0A1C support with Cookie and DR Key 3. Modified 1) Modify MinShortTerm & MinLongTerm PowerLimit value EC Notification : 1. Fixed 1) None. 2. Add 1) None. 3. Modified 1)None. > If you end up introducing a module parameter to try to activate these quirks > it might be viable to ask the folks in those issues to try the v2 of your patch too > when you're ready with the module parameter. I posted a link to this mailing list to https://gitlab.freedesktop.org/drm/amd/-/issues/1671, so people can be aware and try to test. Regards, Alex On Wed, 16 Mar 2022 at 20:45, Mail Delivery System <MAILER-DAEMON@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > This is the mail system at host lindbergh.monkeyblade.net. > > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to postmaster. > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The mail system > > <platform-driver-x86@xxxxxxxxxxxxxxx>: host 23.128.96.18[23.128.96.18] said: > 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, > therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! > BF:<U 0.5>; S1353677AbiCPSqF (in reply to end of DATA command) > > > > ---------- Forwarded message ---------- > From: Alexandru Dinu <alex.dinu07@xxxxxxxxx> > To: platform-driver-x86@xxxxxxxxxxxxxxx > Cc: > Bcc: > Date: Wed, 16 Mar 2022 20:44:13 +0200 > Subject: Re: Undelivered Mail Returned to Sender > Hi, > > > I'll send out a v2 shortly: Alex, can you > > please retest when I do to make sure there aren't any regressions? None > > of these suggestions affect the core flow of how either of the > > workarounds work, so I'm not expecting any that wouldn't also reproduce > > on my EC backlight system that doesn't have either of these problems, > > but I can send you the updated version off-list first if you prefer. > > It's ok either way. You can send me an updated version off-list. > > > Alex, just FYI this was something that came to an AMD bug tracker and wanted you to be aware there are W/A going into nvidia-wmi-ec-backlight for some firmware problems with the mux. > > IIRC that was the original suspicion too on the bug reports. > > Yes, thanks -- I followed this issue first: https://gitlab.freedesktop.org/drm/amd/-/issues/1671. > > > However I think it's still worth at least noting near the quirk in a comment > > what firmware version it was identified. If later there is confirmation that > > a particular firmware version had fixed it the quirk can be adjusted to be > > dropped. > > That's a good tip. The laptop I tested this on (Lenovo Legion S7 15ACH6) originally shipped with: > > UEFI: LENOVO v: HACN27WW date: 08/02/2021 > > There is an update to version HACN31WW (see lenovo support: https://support.lenovo.com/ro/en/downloads/ds550201-bios-update-for-windows-10-64-bit-legion-s7-15ach6) -- which I applied, however, the issue was not addressed, which seems to be expected given the rather short /changelog: > HACN31WW > BIOS Notification : > 1. Fixed > 1) N/A. > 2. Add > 1) Add BOE0A1C support with Cookie and DR Key > 3. Modified > 1) Modify MinShortTerm & MinLongTerm PowerLimit value > EC Notification : > 1. Fixed > 1) None. > 2. Add > 1) None. > 3. Modified > 1)None. > > > If you end up introducing a module parameter to try to activate these quirks > > it might be viable to ask the folks in those issues to try the v2 of your patch too > > when you're ready with the module parameter. > > I posted a link to this mailing list to https://gitlab.freedesktop.org/drm/amd/-/issues/1671, so people can be aware and try to test. > Regards, > Alex > > On Wed, 16 Mar 2022 at 20:40, Mail Delivery System <MAILER-DAEMON@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> This is the mail system at host lindbergh.monkeyblade.net. >> >> I'm sorry to have to inform you that your message could not >> be delivered to one or more recipients. It's attached below. >> >> For further assistance, please send mail to postmaster. >> >> If you do so, please include this problem report. You can >> delete your own text from the attached returned message. >> >> The mail system >> >> <platform-driver-x86@xxxxxxxxxxxxxxx>: host 23.128.96.18[23.128.96.18] said: >> 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, >> therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! >> BF:<U 0.499997>; S240813AbiCPSkN (in reply to end of DATA command) >> >> >> >> ---------- Forwarded message ---------- >> From: Alexandru Dinu <alex.dinu07@xxxxxxxxx> >> To: "Limonciello, Mario" <Mario.Limonciello@xxxxxxx> >> Cc: Daniel Dadap <ddadap@xxxxxxxxxx>, "Barnabás Pőcze" <pobrn@xxxxxxxxxxxxxx>, "platform-driver-x86@xxxxxxxxxxxxxxx" <platform-driver-x86@xxxxxxxxxxxxxxx>, Hans de Goede <hdegoede@xxxxxxxxxx>, "markgross@xxxxxxxxxx" <markgross@xxxxxxxxxx>, "Deucher, Alexander" <Alexander.Deucher@xxxxxxx> >> Bcc: >> Date: Wed, 16 Mar 2022 20:38:21 +0200 >> Subject: Re: [PATCH] nvidia-wmi-ec-backlight: Add workarounds for confused firmware >> Hi, >> >>> > I'll send out a v2 shortly: Alex, can you >>> please retest when I do to make sure there aren't any regressions? None >>> of these suggestions affect the core flow of how either of the >>> workarounds work, so I'm not expecting any that wouldn't also reproduce >>> on my EC backlight system that doesn't have either of these problems, >>> but I can send you the updated version off-list first if you prefer. >> >> >> It's ok either way. You can send me an updated version off-list. >> >>> > Alex, just FYI this was something that came to an AMD bug tracker and wanted you to be aware there are W/A going into nvidia-wmi-ec-backlight for some firmware problems with the mux. >>> IIRC that was the original suspicion too on the bug reports. >> >> >> Yes, thanks -- I followed this issue first: https://gitlab.freedesktop.org/drm/amd/-/issues/1671. >> >>> > However I think it's still worth at least noting near the quirk in a comment >>> what firmware version it was identified. If later there is confirmation that >>> a particular firmware version had fixed it the quirk can be adjusted to be >>> dropped. >> >> >> That's a good tip. The laptop I tested this on (Lenovo Legion S7 15ACH6) originally shipped with: >> >> UEFI: LENOVO v: HACN27WW date: 08/02/2021 >> >> There is an update to version HACN31WW (see lenovo support) -- which I applied, however, the issue was not addressed, which seems to be expected given the rather short /changelog: >> HACN31WW >> BIOS Notification : >> 1. Fixed >> 1) N/A. >> 2. Add >> 1) Add BOE0A1C support with Cookie and DR Key >> 3. Modified >> 1) Modify MinShortTerm & MinLongTerm PowerLimit value >> EC Notification : >> 1. Fixed >> 1) None. >> 2. Add >> 1) None. >> 3. Modified >> 1)None. >>> >>> > If you end up introducing a module parameter to try to activate these quirks >>> it might be viable to ask the folks in those issues to try the v2 of your patch too >>> when you're ready with the module parameter. >> >> >> I posted a link to this mailing list to https://gitlab.freedesktop.org/drm/amd/-/issues/1671, so people can be aware and try to test. >> >> Regards, >> Alex >> >> On Wed, 16 Mar 2022 at 20:25, Limonciello, Mario <Mario.Limonciello@xxxxxxx> wrote: >>> >>> [Public] >>> >>> > > >>> > > IIRC this is the bug you want linked in the commit message: >>> > > >>> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla >>> > b.freedesktop.org%2Fdrm%2Famd%2F- >>> > %2Fissues%2F1671&data=04%7C01%7CMario.Limonciello%40amd.com >>> > %7C5559a4f23f46426add1808da0773b4ac%7C3dd8961fe4884e608e11a82d994 >>> > e183d%7C0%7C0%7C637830490785879396%7CUnknown%7CTWFpbGZsb3d8 >>> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >>> > D%7C3000&sdata=P%2FBcLeN9rnjGam4kh68ZQUBAPIDM4G%2Bk1ukb5 >>> > k%2BRFVg%3D&reserved=0 >>> > >>> > >>> > Ah, thanks. Most of the people on this bug seem like their problem was >>> > that they didn't have the nvidia-wmi-ec-backlight driver, which also >>> > didn't exist at the time the bug was filed. There is one person with a >>> > newer comment reporting behavior that sounds like what this patch works >>> > around, and it is the same person who initially reported the issue to me. :) >>> > >>> > >>> >>> Thanks for looking at those. >>> >>> > > But these two look possible to be the same root cause: >>> > > >>> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla >>> > b.freedesktop.org%2Fdrm%2Famd%2F- >>> > %2Fissues%2F1791&data=04%7C01%7CMario.Limonciello%40amd.com >>> > %7C5559a4f23f46426add1808da0773b4ac%7C3dd8961fe4884e608e11a82d994 >>> > e183d%7C0%7C0%7C637830490785879396%7CUnknown%7CTWFpbGZsb3d8 >>> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >>> > D%7C3000&sdata=Bv3lJJOG7BZxlvizh0L4gmHgakzjlJkl7TqGh9HTho4%3D >>> > &reserved=0 >>> > >>> > >>> > This one sounds like it might be a different issue, since it was >>> > apparently working at some point with a kernel that didn't have the EC >>> > backlight driver, and then not working on a newer kernel that also >>> > didn't have the EC backlight driver. That is, of course, assuming >>> > vanilla kernels: it is certainly possible that the EC backlight driver >>> > was backported. >>> > >>> > > >>> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla >>> > b.freedesktop.org%2Fdrm%2Famd%2F- >>> > %2Fissues%2F1794&data=04%7C01%7CMario.Limonciello%40amd.com >>> > %7C5559a4f23f46426add1808da0773b4ac%7C3dd8961fe4884e608e11a82d994 >>> > e183d%7C0%7C0%7C637830490785879396%7CUnknown%7CTWFpbGZsb3d8 >>> > eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 >>> > D%7C3000&sdata=JfUhLPRIMVLypLXoAxKhpSw7WIN4M%2BS4Y48MQ >>> > %2BzXdbk%3D&reserved=0 >>> > >>> > >>> > This sounds like it could possibly be a simple case of not having the EC >>> > backlight driver. Notably, the backlight device exposed by the amdgpu >>> > driver never works, in contrast to the system these workarounds are >>> > targeting, where the amdgpu driver's backlight device initially works, >>> > but then stops working after the first suspend/resume cycle (and the EC >>> > backlight driver doesn't work initially, but then starts working after >>> > suspend/resume). >>> >>> I guess when we see backlight issues on these A+N designs the checks should be: >>> 1) Are they supposed to be using the nvidia-wmi-ec-backlight driver? >>> 2) Is their kernel new enough to have it? >>> 3) Do they have the config enabled? >>> >>> Do you have a script or could you perhaps include some documentation we can >>> point people to check "1" so we don't always have to go tear apart ACPI tables >>> and make guesses? >>> >>> I guess it's something like grab _WDG and then parse it to see if there is an entry. >>> >>> > >>> > >>> > > >>> > > If you end up introducing a module parameter to try to activate these >>> > quirks >>> > > it might be viable to ask the folks in those issues to try the v2 of your patch >>> > too >>> > > when you're ready with the module parameter. >>> > > >>> > >>> > v1 already has the quirks plumbed up to module parameters (those module >>> > parameters just don't have corresponding sysfs entries). In any case, I >>> > only see one report between those bugs that sounds like the issue these >>> > WARs are meant to address, and since it's from the same reporter, it >>> > sounds like we won't need to be adding any additional quirks table >>> > entries right away. >>> > >>> > >>> > >> >>> > >>> Comments inline as well. >>> > >>> >>> > >>>> -----Original Message----- >>> > >>>> From: Daniel Dadap <ddadap@xxxxxxxxxx> >>> > >>>> Sent: Wednesday, March 16, 2022 10:11 >>> > >>>> To: Barnabás Pőcze <pobrn@xxxxxxxxxxxxxx> >>> > >>>> Cc: platform-driver-x86@xxxxxxxxxxxxxxx; Alexandru Dinu >>> > >>>> <alex.dinu07@xxxxxxxxx>; Hans de Goede <hdegoede@xxxxxxxxxx>; >>> > >>>> markgross@xxxxxxxxxx >>> > >>>> Subject: Re: [PATCH] nvidia-wmi-ec-backlight: Add workarounds for >>> > >>>> confused firmware >>> > >>>> >>> > >> [ ... ] >>> > >> >>> > >> >>> > >>>> On 3/15/22 9:50 PM, Barnabás Pőcze wrote: >>> > >>>>> [ ... ] >>> > >>>>> Lastly, is it expected that these bugs will be properly fixed? >>> > >>>> Possibly, but I wouldn't hold out hope for it for an issue at this scale >>> > >>>> on an already shipping system. >>> > >>> This question I'm assuming was aimed at narrowing the quirk to only >>> > >>> match certain FW versions or so. If there is no certainty of when/if it >>> > >>> will be fixed I agree with current direction. >>> > >>> However I think it's still worth at least noting near the quirk in a >>> > comment >>> > >>> what firmware version it was identified. If later there is confirmation >>> > that >>> > >>> a particular firmware version had fixed it the quirk can be adjusted to be >>> > >>> dropped. >>> > >>> >>> > >> Thanks, Mario. Sure, I'll make sure the firmware version this was first >>> > >> observed in is noted. >>> > >> >>> > >>
