RE: How to detect Cherry Trail vs Brasswell inside the kernel ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> >
> > 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)

It wasn't clear to me if this inquiry was for release or pre-release hardware.
If it's pre-release hardware this is actually quite preferable in my opinion.

> 
> >> 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





[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux