diff options
author | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-06-01 08:34:08 +0200 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab+huawei@kernel.org> | 2020-06-11 19:10:35 +0200 |
commit | c371af686972ee2a7946b56f6b6b42bcb80d2091 (patch) | |
tree | 2f90822e1dce960cd895a1d893bad92dc3c74581 /mm/mmzone.c | |
parent | 946881109181d9def4002156bfa85b020dc05583 (diff) | |
download | linux-c371af686972ee2a7946b56f6b6b42bcb80d2091.tar.gz linux-c371af686972ee2a7946b56f6b6b42bcb80d2091.tar.bz2 linux-c371af686972ee2a7946b56f6b6b42bcb80d2091.zip |
media: atomisp: get rid of a detection hack for a BYT Andorid-based tablet
There's a hack at the driver that selects a different table
for a BYT tablet, which sets the maximum frequency to 320 MHz,
instead of 400 MHz.
After looking at the Intel Aero Yocto's version from:
https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/
It was noticed that this depends on an Android-specific modprobe parameter,
which uses a macro (INTEL_MID_BOARD) from this file:
arch/x86/include/asm/spid.h
>From the comments there, it looks like this macro parses a
variable passed at boot time:
cmdline : androidboot.spid=vend:cust:manu:plat:prod:hard
The devices in question are identified there as:
INTEL_BYT_TABLET_BLK_PRO = 0x0000
INTEL_BYT_TABLET_BLK_ENG = 0x8000
Well, this is something that we don't have upstream. So,
without further details about that, we can't really parse it.
If we ever end supporting those devices with the upstream driver,
this patch can be reverted and the device can be detected
via DMI (or maybe via PCI ID?).
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Diffstat (limited to 'mm/mmzone.c')
0 files changed, 0 insertions, 0 deletions