> 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? > 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. > > I would like to be able to add some code the the ACPI video code which > simply ignores the broken acpi_video interface on Cherry Trail devices, > while still using its normal detection logic on Brasswell devices. > The alternative would be an ever growing list of DMI based quirks which > is undesirable.
