The Crystal Cove PMIC has a pin which can be used to connect the IRQ of
an external charger IC. On some boards this is used so we need a way to
look this up.
Note that the Intel PMICs have 2 levels of interrupts and thus
2 levels of IRQ domains all tied to a single fwnode.
Level 1 is the irqchip which demultiplexes the actual PMIC interrupt into
interrupts for the various MFD cells. Level 2 are the irqchips used in the
cell drivers which themselves export IRQs, such as the crystal_cove_gpio
driver, which de-multiplexes the level 2 interrupts for the GPIOs into
individual per GPIO IRQs.
The crystal_cove_charger driver registers an irqchip with a single IRQ for
the charger driver to consume. Note the MFD cell IRQ cannot be consumed
directly because the level 2 interrupts must be explicitly acked.
To allow finding the right IRQ domain when looking up the IRQ for
the charger, the crystal_cove_charger driver sets a DOMAIN_BUS_WIRED token
on its IRQ domain.
Add support for looking up the IRQ from the crystal_cove_charger driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211229231431.437982-6-hdegoede@redhat.com
The Glavey TM800A550L tablet is a tablet which ships with Android as
factory OS. As such it has the typical broken DSDT which x86 Android
tablets tend to have.
Specifically the touchscreen ACPI device node is missing the IRQ for
the touchscreen. So far users were expected to fix this with a DSDT
overlay, but support for the TM800A550L has been added to the new
x86-android-modules kernel-module and that will now automatically
instantiate a proper i2c-client with the IRQ set for the touchscreen,
including the necessary device-properties for the firmware loading.
This means that the touchscreen_dmi entry for the TM800A550L is
no longer necessary (and it no longer matches either since the
touchscreen is no longer enumerated through ACPI), remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20220103112700.111414-1-hdegoede@redhat.com
The firmware distributed as part of the Windows and Android drivers uses
significantly different min and max values for the x- and y-axis,
compared to the EFI's embedded touchscreen firmware.
The difference is large enough that e.g. typing on an onscreen keyboard
results in the wrong "keys" getting pressed.
Adjust the values to match those of the firmware distributed with the
Windows and Android drivers (which is necessary for pen support) and
put the EFI-fw version's min/max values in the new "silead,efi-fw-min-max"
property. The silead driver will use these when it is using the
EFI embedded firmware, so as to not regress functionality in that case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211225120247.95380-1-hdegoede@redhat.com
Driver for the external-charger IRQ pass-through function of the
Intel Bay Trail Crystal Cove PMIC.
Note this is NOT a power_supply class driver, it just deals with IRQ
pass-through, this requires this separate driver because the PMIC's
level 2 interrupt for this must be explicitly acked.
This new driver gets enabled by the existing X86_ANDROID_TABLETS Kconfig
option because the x86-android-tablets module is the only consumer of the
exported external-charger IRQ.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211225115509.94891-5-hdegoede@redhat.com
x86 tablets which ship with Android as (part of) the factory image
typically have various problems with their DSDTs. The factory kernels
shipped on these devices typically have device addresses and GPIOs
hardcoded in the kernel, rather then specified in their DSDT.
With the DSDT containing a random collection of devices which may or
may not actually be present as well as missing devices which are
actually present.
This driver, which loads only on affected models based on DMI matching,
adds DMI based instantiating of kernel devices for devices which are
missing from the DSDT, fixing e.g. battery monitoring, touchpads and/or
accelerometers not working.
Note the Kconfig help text also refers to "various fixes" ATM there are
no such fixes, but there are also known cases where entries are present
in the DSDT but they contain bugs, such as missing/wrong GPIOs. The plan
is to also add fixes for things like this here in the future.
This is the least ugly option to get these devices to fully work and to
do so without adding any extra code to the main kernel image (vmlinuz)
when built as a module.
Link: https://lore.kernel.org/platform-driver-x86/20211031162428.22368-1-hdegoede@redhat.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211223190750.397487-1-hdegoede@redhat.com
When BIOS disables turbo, the cpuinfo_max_freq will also be same as the
power up base frequency. When SST-PP causes increase in base frequency
the performance will be still limited to the old base frequency as the
cpuinfo_max_freq will not be updated.
In this case we need to update scaling_max frequency to the new
base_frequency. This will result in setting updated max performance
limit in the Pstate driver. So performance will not be limited to the
old base frequency.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Siemens industrial PCs unfortunately can not always be properly
identified the way we used to. An earlier commit introduced code that
allows proper identification without looking at DMI strings that could
differ based on product branding.
Switch over to that proper way and revert commits that used to collect
the machines based on unstable strings.
Fixes: 648e921888 ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Fixes: e8796c6c69 ("platform/x86: pmc_atom: Add Siemens CONNECT ...")
Fixes: f110d252ae ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Fixes: ad0d315b4d ("platform/x86: pmc_atom: Add Siemens SIMATIC ...")
Tested-by: Michael Haener <michael.haener@siemens.com>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20211213120502.20661-5-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This mainly implements detection of these devices and will allow
secondary drivers to work on such machines.
The identification is DMI-based with a vendor specific way to tell them
apart in a reliable way.
Drivers for LEDs and Watchdogs will follow to make use of that platform
detection.
There is also some code to allow secondary drivers to find GPIO memory,
that needs to be in place because the pinctrl drivers do not come up.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Link: https://lore.kernel.org/r/20211213120502.20661-2-henning.schild@siemens.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
While introduction of this menu brings a nice view in the configuration tools,
it brought more issues than solves, i.e. it prevents to locate files in the
intel/ subfolder without touching non-related Kconfig dependencies elsewhere.
Drop X86_PLATFORM_DRIVERS_INTEL altogether.
Note, on x86 it's enabled by default and it's quite unlikely anybody wants to
disable all of the modules in this submenu.
Fixes: 8bd836feb6 ("platform/x86: intel_skl_int3472: Move to intel/ subfolder")
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211222194941.76054-1-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
There needs to be a check to prevent negative offsets for
setting->index. I have reviewed this code and I think that the
"if (block->instance_count <= instance)" check in __query_block() will
prevent this from resulting in an out of bounds access. But it's
still worth fixing.
Fixes: 640a5fa50a ("platform/x86: think-lmi: Opcode support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211217071209.GF26548@kili
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>