Hi, On 1/6/21 7:52 PM, Limonciello, Mario wrote: >> So I was wondering if anyone else has any better ideas here? >> >> Regards, >> >> Hans >> >> >> p.s. >> >> Just FYI the 2 issues which I want to resolve are: >> >> 1. Prevent drivers/platform/x86/intel_int0002_vgpio.c binding on Braswell >> (non "tablet") SoCs. The INT0002 ACPI device is used for some wakeup >> events (from S2idle) on the tablet (Cherry Trail) versions of the SoC. >> >> The current code will also bind to the INT0002 ACPI device (if present) on >> Braswell, this is causing suspend/resume issues on some devices. >> ATM we are working around this by setting the IRQCHIP_SKIP_SET_WAKE on >> the irq-chip for the INT0002 vGPIO pin. But this in turn is breaking wakeup >> by USB peripherals on Cherry Trail devices. If we can just stop the driver >> from binding on Braswell devices all together then that would be better. >> > > Would it be possible to ask the vendor to remove INT0002 device from the > firmware? Even if all vendors would issue BIOs updates for this for all models (which they won't) then we still cannot count on users installing those BIOS updates. Because of this relying on a BIOS update is almost never the right answer. (Note I guess there might be some extreme circumstans / some corner case where things are so broken that we will tell users to just upgrade their BIOS) >> 2. Deal with non functional /sys/class/backlight/acpi_video[0-7] devices >> showing up on BYT/CHT based media-boxes / hdmi-sticks. These devices do >> not have a LCD panel, so there will be no "native" backlight driver causing >> drivers/acpi/video-detect.c to select acpi_backlight_video as backlight-type. >> drivers/acpi/acpi-video.c tries to avoid registering non-functional >> /sys/class/backlight/acpi_video devices in cases like this, but that depends >> on a DMI chassis-type check (to avoid suppressing the backlight interface >> on laptops where we likely do want it) and many of these media-boxes / >> hdmi-sticks are derived from BYT/CHT tablet designs and often the DMI >> chassis type still says "Tablet". Actual Cherry Trail devices with a LCD >> panel always use the native intel_backlight interface, but I guess some >> Braswell based devices might use the acpi_video interface. > > Maybe a function to look at specifically the DMI chassis type of "Tablet" and > check for the lack of an internal LCD panel. That seems like detecting that > combination shouldn't ever try to run this code. The issue is that we cannot detect the presence of a LCD panel from the ACPI-video code. That is done by the i915 driver (on these devices) and we really don't want any (more) dependencies between the acpi-video code and the i915 code as those are very hard to manage wrt things like the probing order. Also the ACPI-video code is supposed to be platform and even architecture independent. Regards, Hans
