| Message ID | 20230123113750.462144-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ACPI: video/apple-gmux: Improve apple-gmux backlight detection | expand |
On Mon, Jan 23, 2023 at 12:37:47PM +0100, Hans de Goede wrote: > Some apple laptop models have an ACPI device with a HID of APP000B > and that device has an IO resource (so it does not describe the new > unsupported MMIO based gmux type), but there actually is no gmux > in the laptop at all. > > This patch-series improves the drivers/acpi/video_detect.c so that > it no longer tries to use the non present gmux in this case. > > Note I'm still waiting for testing feedback from the reporter of > this problem. But from the logs the problem is clear > (the logs show: "apple_gmux: gmux device not present") Please provide a link to the original report. I would also like to know the exact MacBook model used and I would like to see full dmesg output as well as an acpidump. What you're saying here is that there's a fake APP000B device present in DSDT and I have a hard time believng that. We need to find out what's really going on and how macOS handles this. Thanks, Lukas
Hi, On 1/23/23 13:09, Lukas Wunner wrote: > On Mon, Jan 23, 2023 at 12:37:47PM +0100, Hans de Goede wrote: >> Some apple laptop models have an ACPI device with a HID of APP000B >> and that device has an IO resource (so it does not describe the new >> unsupported MMIO based gmux type), but there actually is no gmux >> in the laptop at all. >> >> This patch-series improves the drivers/acpi/video_detect.c so that >> it no longer tries to use the non present gmux in this case. >> >> Note I'm still waiting for testing feedback from the reporter of >> this problem. But from the logs the problem is clear >> (the logs show: "apple_gmux: gmux device not present") > > Please provide a link to the original report. I would also like to > know the exact MacBook model used and I would like to see full dmesg > output as well as an acpidump. I only have a report by private email. This does include full dmesg output and an acpidump. I will forward this to you in a private email. The reporter describes their model as a macbookpro8,1. > What you're saying here is that there's a fake APP000B device present > in DSDT Yes that is exactly what I'm saying. > and I have a hard time believng that. Yes that seems to be exactly what is happening. If you look at the drivers/platform/x86/apple-gmux.c code that is pretty much the only scenario which leads to the: apple_gmux: gmux device not present message getting logged; and it seems to me that the reason that check is there likely is exactly because of such machines actually existing. And /sys/class/backlight contains only intel_backlight suggesting that this is not a hybrid gfx machine. Which also matches with the specs which I can find for the macbookpro8,1. Yet there is an APP000B device present in the DSDT, here is the relevant bit of the DSDT: Device (GMUX) { Name (_HID, EisaId ("APP000B")) // _HID: Hardware ID Name (_CID, "gmux") // _CID: Compatible ID Name (_STA, 0x0B) // _STA: Status Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0700, // Range Minimum 0x07FF, // Range Maximum 0x01, // Alignment 0xFF, // Length ) }) Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake { 0x16, 0x03 }) Scope (\_GPE) { Method (_L16, 0, NotSerialized) // _Lxx: Level-Triggered GPE, xx=0x00-0xFF { Notify (\_SB.PCI0.LPCB.GMUX, 0x80) // Status Change } } Name (GMGP, 0x16) Method (GMSP, 1, NotSerialized) { If ((Arg0 <= 0x01)) { GP06 |= Arg0 } } Method (GMLV, 0, NotSerialized) { Return (GP06) /* \GP06 */ } } } Regards, Hans
On Mon, Jan 23, 2023 at 01:38:37PM +0100, Hans de Goede wrote: > On 1/23/23 13:09, Lukas Wunner wrote: > > On Mon, Jan 23, 2023 at 12:37:47PM +0100, Hans de Goede wrote: > > > Some apple laptop models have an ACPI device with a HID of APP000B > > > and that device has an IO resource (so it does not describe the new > > > unsupported MMIO based gmux type), but there actually is no gmux > > > in the laptop at all. > > > > > > This patch-series improves the drivers/acpi/video_detect.c so that > > > it no longer tries to use the non present gmux in this case. > > > > > > Note I'm still waiting for testing feedback from the reporter of > > > this problem. But from the logs the problem is clear > > > (the logs show: "apple_gmux: gmux device not present") > > > > Please provide a link to the original report. I would also like to > > know the exact MacBook model used and I would like to see full dmesg > > output as well as an acpidump. > > I only have a report by private email. This does include full dmesg > output and an acpidump. I will forward this to you in a private > email. > > The reporter describes their model as a macbookpro8,1. > > > What you're saying here is that there's a fake APP000B device present > > in DSDT > > Yes that is exactly what I'm saying. That's a 2011 13" MacBook Pro which indeed does not have dual GPUs. I searched for other affected models and this seems to be more common than I thought: MacBookPro5,4 https://pastebin.com/8Xjq7RhS MacBookPro8,1 https://linux-hardware.org/?probe=e513cfbadb&log=dmesg MacBookPro9,2 https://bugzilla.kernel.org/attachment.cgi?id=278961 MacBookPro10,2 https://lkml.org/lkml/2014/9/22/657 MacBookPro11,2 https://forums.fedora-fr.org/viewtopic.php?id=70142 MacBookPro11,4 https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/master/test-16/dmesg These are 13" and 15" models from the pre-retina and retina era (2009 - 2015). None of them have dual GPUs. (Only a subset of the 15" and 17" models had dual GPUs.) Apple sloppily included a GMUX device on all of them and it wasn't a problem so far because the gmux driver detects non-presence and bails out, but it throws off the new backlight algorithm. This is really sad. :( Please add a Reported-by to your commits as well as the list I've provided above so that we've got a complete record in the git history. Thanks, Lukas
> On 23-Jan-2023, at 5:07 PM, Hans de Goede <hdegoede@redhat.com> wrote: > > Hi All, > > Some apple laptop models have an ACPI device with a HID of APP000B > and that device has an IO resource (so it does not describe the new > unsupported MMIO based gmux type), but there actually is no gmux > in the laptop at all. > > This patch-series improves the drivers/acpi/video_detect.c so that > it no longer tries to use the non present gmux in this case. > > Note I'm still waiting for testing feedback from the reporter of > this problem. But from the logs the problem is clear > (the logs show: "apple_gmux: gmux device not present") and > the detection code is not changed, just moved so these patches > should be fine, but they can definitely use a good review. > > Aditya, can you perhaps test this on a model macbook which does > actually use the apple-gmux driver for backlight control > (assuming you have such a model) ? > Hi Hans Since I own a T2 MacBook, I’ll have to apply some out of tree patches as well from https://github.com/Redecorating/linux/commits/bits/010-gmux. I’ve requested the maintainer although he believes they shouldn't break anything on T2 Macs. I’ve still let a kernel compile without the out of tree patches, just with yours and shall send the outputs by tomorrow.
Hi, On 1/23/23 14:58, Lukas Wunner wrote: > On Mon, Jan 23, 2023 at 01:38:37PM +0100, Hans de Goede wrote: >> On 1/23/23 13:09, Lukas Wunner wrote: >>> On Mon, Jan 23, 2023 at 12:37:47PM +0100, Hans de Goede wrote: >>>> Some apple laptop models have an ACPI device with a HID of APP000B >>>> and that device has an IO resource (so it does not describe the new >>>> unsupported MMIO based gmux type), but there actually is no gmux >>>> in the laptop at all. >>>> >>>> This patch-series improves the drivers/acpi/video_detect.c so that >>>> it no longer tries to use the non present gmux in this case. >>>> >>>> Note I'm still waiting for testing feedback from the reporter of >>>> this problem. But from the logs the problem is clear >>>> (the logs show: "apple_gmux: gmux device not present") >>> >>> Please provide a link to the original report. I would also like to >>> know the exact MacBook model used and I would like to see full dmesg >>> output as well as an acpidump. >> >> I only have a report by private email. This does include full dmesg >> output and an acpidump. I will forward this to you in a private >> email. >> >> The reporter describes their model as a macbookpro8,1. >> >>> What you're saying here is that there's a fake APP000B device present >>> in DSDT >> >> Yes that is exactly what I'm saying. > > That's a 2011 13" MacBook Pro which indeed does not have dual GPUs. > > I searched for other affected models and this seems to be more common > than I thought: > > MacBookPro5,4 > https://pastebin.com/8Xjq7RhS > > MacBookPro8,1 > https://linux-hardware.org/?probe=e513cfbadb&log=dmesg > > MacBookPro9,2 > https://bugzilla.kernel.org/attachment.cgi?id=278961 > > MacBookPro10,2 > https://lkml.org/lkml/2014/9/22/657 > > MacBookPro11,2 > https://forums.fedora-fr.org/viewtopic.php?id=70142 > > MacBookPro11,4 > https://raw.githubusercontent.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/master/test-16/dmesg > > These are 13" and 15" models from the pre-retina and retina era > (2009 - 2015). None of them have dual GPUs. (Only a subset of > the 15" and 17" models had dual GPUs.) Apple sloppily included > a GMUX device on all of them and it wasn't a problem so far > because the gmux driver detects non-presence and bails out, > but it throws off the new backlight algorithm. > > This is really sad. :( > > Please add a Reported-by to your commits I was about to say that Emmanouil may want to keep their email private. But I see you've already added them to the Cc, so now the email is part of the platform-driver-x86 archives. Emmanouil, is it ok if I add a line like this: Reported-by: Emmanouil Kouroupakis <kartxxx@gmail.com> to the commit message of v2 of the patches ? This gives you credit for reporting the bug, but it also exposes your email address in public places. > as well as the list I've > provided above so that we've got a complete record in the git history. Ack, I'll add the list of devices to v2 of the patches. Regards, Hans
> > Aditya, can you perhaps test this on a model macbook which does > > actually use the apple-gmux driver for backlight control > > (assuming you have such a model) ? > > > > Hi Hans > > Since I own a T2 MacBook, I’ll have to apply some out of tree patches as well > from https://github.com/Redecorating/linux/commits/bits/010 gmux. I’ve > requested the maintainer although he believes they shouldn't break anything on > T2 Macs. I’ve still let a kernel compile without the out of tree patches, just > with yours and shall send the outputs by tomorrow. I'm the one that wrote those patches for gmux on the mmio T2 macs, and I've rebased them onto Hans' patchset with patch numbers 2004-2006 here https://github.com/t2linux/linux-t2-patches/tree/gmux It seems to work fine on my T2 Macbookpro16,1, the display backlight controls work and there aren't any other, not working, backlights present. > ls /sys/class/backlight gmux_backlight@
> I'm the one that wrote those patches for gmux on the mmio T2 macs, and > I've rebased them onto Hans' patchset with patch numbers 2004-2006 here > https://github.com/t2linux/linux-t2-patches/tree/gmux > > It seems to work fine on my T2 Macbookpro16,1, the display backlight > controls work and there aren't any other, not working, backlights > present. > >> ls /sys/class/backlight > gmux_backlight@ Thanks Orlando Since I own the same Mac as Orlando, his testing should be good enough.