How to detect Cherry Trail vs Brasswell inside the kernel ?

* How to detect Cherry Trail vs Brasswell inside the kernel ?
@ 2021-01-06 12:31 Hans de Goede
  2021-01-06 14:59 ` Peter Zijlstra
  2021-01-06 18:52 ` Limonciello, Mario
  0 siblings, 2 replies; 6+ messages in thread
From: Hans de Goede @ 2021-01-06 12:31 UTC (permalink / raw)
  To: Andy Shevchenko; +Cc: linux-acpi, x86, platform-driver-x86

Hi All,

I've 2 different kernel bugs where the fix requires differentiating between
Cherry Trail vs Brasswell, just checking the CPU model does not allow to
differentiate between these 2 since they are both using Airmont cores.

I have the same issue with the Bay Trail laptop SoCs vs the
Bay Trail-T tablet SoCs, but for now lets focus on
Cherry Trail vs Brasswell since that is less confusing:

https://ark.intel.com/content/www/us/en/ark/products/codename/46629/cherry-trail.html
https://ark.intel.com/content/www/us/en/ark/products/codename/66094/braswell.html

So I see a number of possible solutions here:

1) Do a (substring) check on the CPU model-name checking for "x5-Z8" and "x7-Z8"
2) Check for presence of some embedded peripheral which is present on one but not the
other. E.g. The Braswell devices have HDA audio where as the Cherry Trail devices
use the "Low Power Engine (LPE) Audio Controller"
3) Check for acpi_gbl_reduced_hardware, but I'm not sure if that is a reliable
indicator of running on the tablet versions of the SoCs.

1 and 2 will work but neither is very pretty, I guess I could try to spend some
more time investigating 3. But I only have limited access to the non tablet versions
of the Bay Trail and I'm not sure if I have any Braswell devices at all. 

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.

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.

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread