summaryrefslogtreecommitdiffstats
path: root/mm/mmzone.c
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <mchehab+huawei@kernel.org>2020-06-01 08:34:08 +0200
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>2020-06-11 19:10:35 +0200
commitc371af686972ee2a7946b56f6b6b42bcb80d2091 (patch)
tree2f90822e1dce960cd895a1d893bad92dc3c74581 /mm/mmzone.c
parent946881109181d9def4002156bfa85b020dc05583 (diff)
downloadlinux-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