Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Michael Marineau]

On Tue, May 26, 2015 at 11:13 PM, Bruno PrÃmont
<bonbons@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, 26 May 2015 22:35:46 -0700 Michael Marineau wrote:
>> On Tue, May 26, 2015 at 9:47 PM, Darren Hart <dvhart@xxxxxxxxxxxxx> wrote:
>> > On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
>> >> FYI, this actually broke backlight controls on my MBP11,3 because the
>> >> assumption the patch makes that gmux is always loaded before graphics
>> >> drivers didn't hold true. At least for me dracut included the nouveau
>> >> module in the initrd but not gmux, ensuring the ordering was wrong. No
>> >> errors were reporting, and gmux still offered the backlight device, it
>> >> just became inoperable. I worked around this for my kernel by building
>> >> gmux into vmlinuz instead of as a module but that isn't going to in
>> >> more general configs because there is an apple backlight driver which
>> >> cannot be built at all in that configuration.
>> >>
>> >
>> > Thank you for reporting this Michael,
>> >
>> > That is tough as nouveau doesn't have an explicit dependency on gmux, so we
>> > could do something like a passive request_module(), but if it isn't in the
>> > initrd image, it would still fail as you describe.
>> >
>> >> Is there a way to make the ordering between nouveau and gmux more
>> >> explicit/reliable? Can gmux complain loudly if the ordering is ever
>> >> wrong?
>> >
>> > It should print an error if the probe fails due to the IO already being in use
>> > or if it can't be allocated. The disabled IO case is only info level though,
>> > perhaps that should be higher priority. Printing something when failing to probe
>> > seems like a reasonable thing to do.
>> >
>> > Michael, which message do you get if you boot with "debug" or "loglevel=6" when
>> > apple-gmux is not built-in?
>>
>> No error, gmux claims it worked:
>> [   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
>> [   13.693400] vgaarb: device changed decodes:
>> PCI:0000:01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
>> [   13.693404] apple_gmux: locked IO for PCI:0000:01:00.0
>>
>> Full dmesg: https://gist.github.com/marineam/0e5a23548e8b3b2e1d50
>
> What GPUs are there in your MBP11,3? From your dmesg it looks like all
> you have is NVIDIA GPU 0000:01:00.0 (lspci?).
>
> Is there a somehow hidden intel GPU around doing the backlight?

On this system if you don't futz with the firmware in just the right
way it hides the Intel GPU:

https://github.com/marineam/linux/commit/1f2fcbbca18176e2e6c862774428dad878bbac51

Exposing the Intel GPU isn't particularly great because power
management gets wonky and I've never figured out how to switch between
the GPUs, reconfiguring the eDP link never works right. Even when
running with the Intel hidden the current nouveau driver cannot redo
the eDP link so I have a hack to prevent modesetting from ever
powering the link down:

https://github.com/marineam/linux/commit/4b7e27ba268755963e24886e26e198531aa4da68

In short this machine is frickin weird.

> If so my locking does the wrong thing for your system as:
>
> [    0.393298] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=none,locks=none
> [    0.393299] vgaarb: loaded
> [    0.393300] vgaarb: setting as boot device: PCI:0000:01:00.0
> [    0.393301] vgaarb: bridge control possible 0000:01:00.0
> ...
> [   13.693379] apple_gmux: Found gmux version 4.0.8 [indexed]
> [   13.693400] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=io+mem:owns=none
> [   13.693404] apple_gmux: locked IO for PCI:0000:01:00.0
>
> Here it triggers "olddecodes=none -> io+mem".
>
> Making sure to lock only the intel GPU when present and especially protecting
> against nvidia driver will be hard if legacy-IO is being processed by a hidden
> device!

I had assumed that the Intel GPU was completely out of the game when
hidden but if that isn't the case this sounds complicated. :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/