d6980ce55c
Changes:
- Fix IOMMU errors with IPTS (@libanp)
- PR: https://github.com/linux-surface/kernel/pull/120
- Refactor support for Surface 3 buttons (@jwrdegoede)
- Rebase onto v5.17.4
Links:
- kernel: a48902e579
114 lines
4.5 KiB
Diff
114 lines
4.5 KiB
Diff
From f31a3ad42c2c04a17f8675438a1b5a6500bafea5 Mon Sep 17 00:00:00 2001
|
|
From: Hans de Goede <hdegoede@redhat.com>
|
|
Date: Sun, 10 Oct 2021 20:56:57 +0200
|
|
Subject: [PATCH] ACPI: delay enumeration of devices with a _DEP pointing to an
|
|
INT3472 device
|
|
|
|
The clk and regulator frameworks expect clk/regulator consumer-devices
|
|
to have info about the consumed clks/regulators described in the device's
|
|
fw_node.
|
|
|
|
To work around cases where this info is not present in the firmware tables,
|
|
which is often the case on x86/ACPI devices, both frameworks allow the
|
|
provider-driver to attach info about consumers to the clks/regulators
|
|
when registering these.
|
|
|
|
This causes problems with the probe ordering wrt drivers for consumers
|
|
of these clks/regulators. Since the lookups are only registered when the
|
|
provider-driver binds, trying to get these clks/regulators before then
|
|
results in a -ENOENT error for clks and a dummy regulator for regulators.
|
|
|
|
One case where we hit this issue is camera sensors such as e.g. the OV8865
|
|
sensor found on the Microsoft Surface Go. The sensor uses clks, regulators
|
|
and GPIOs provided by a TPS68470 PMIC which is described in an INT3472
|
|
ACPI device. There is special platform code handling this and setting
|
|
platform_data with the necessary consumer info on the MFD cells
|
|
instantiated for the PMIC under: drivers/platform/x86/intel/int3472.
|
|
|
|
For this to work properly the ov8865 driver must not bind to the I2C-client
|
|
for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and
|
|
clk MFD cells have all been fully setup.
|
|
|
|
The OV8865 on the Microsoft Surface Go is just one example, all X86
|
|
devices using the Intel IPU3 camera block found on recent Intel SoCs
|
|
have similar issues where there is an INT3472 HID ACPI-device, which
|
|
describes the clks and regulators, and the driver for this INT3472 device
|
|
must be fully initialized before the sensor driver (any sensor driver)
|
|
binds for things to work properly.
|
|
|
|
On these devices the ACPI nodes describing the sensors all have a _DEP
|
|
dependency on the matching INT3472 ACPI device (there is one per sensor).
|
|
|
|
This allows solving the probe-ordering problem by delaying the enumeration
|
|
(instantiation of the I2C-client in the ov8865 example) of ACPI-devices
|
|
which have a _DEP dependency on an INT3472 device.
|
|
|
|
The new acpi_dev_ready_for_enumeration() helper used for this is also
|
|
exported because for devices, which have the enumeration_by_parent flag
|
|
set, the parent-driver will do its own scan of child ACPI devices and
|
|
it will try to enumerate those during its probe(). Code doing this such
|
|
as e.g. the i2c-core-acpi.c code must call this new helper to ensure
|
|
that it too delays the enumeration until all the _DEP dependencies are
|
|
met on devices which have the new honor_deps flag set.
|
|
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Patchset: cameras
|
|
---
|
|
drivers/acpi/scan.c | 3 +++
|
|
1 file changed, 3 insertions(+)
|
|
|
|
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
|
|
index c82b1bfa1c3d..2227625202aa 100644
|
|
--- a/drivers/acpi/scan.c
|
|
+++ b/drivers/acpi/scan.c
|
|
@@ -2130,6 +2130,9 @@ static acpi_status acpi_bus_check_add_2(acpi_handle handle, u32 lvl_not_used,
|
|
|
|
static void acpi_default_enumeration(struct acpi_device *device)
|
|
{
|
|
+ if (!acpi_dev_ready_for_enumeration(device))
|
|
+ return;
|
|
+
|
|
/*
|
|
* Do not enumerate devices with enumeration_by_parent flag set as
|
|
* they will be enumerated by their respective parents.
|
|
--
|
|
2.36.0
|
|
|
|
From 3f7aa178a14b5cdaa3ca424743299d0c271fd202 Mon Sep 17 00:00:00 2001
|
|
From: Daniel Scally <djrscally@gmail.com>
|
|
Date: Sun, 10 Oct 2021 20:57:02 +0200
|
|
Subject: [PATCH] platform/x86: int3472: Enable I2c daisy chain
|
|
|
|
The TPS68470 PMIC has an I2C passthrough mode through which I2C traffic
|
|
can be forwarded to a device connected to the PMIC as though it were
|
|
connected directly to the system bus. Enable this mode when the chip
|
|
is initialised.
|
|
|
|
Signed-off-by: Daniel Scally <djrscally@gmail.com>
|
|
Patchset: cameras
|
|
---
|
|
drivers/platform/x86/intel/int3472/tps68470.c | 7 +++++++
|
|
1 file changed, 7 insertions(+)
|
|
|
|
diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
|
|
index 22f61b47f9e5..e1de1ff40bba 100644
|
|
--- a/drivers/platform/x86/intel/int3472/tps68470.c
|
|
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
|
|
@@ -45,6 +45,13 @@ static int tps68470_chip_init(struct device *dev, struct regmap *regmap)
|
|
return ret;
|
|
}
|
|
|
|
+ /* Enable I2C daisy chain */
|
|
+ ret = regmap_write(regmap, TPS68470_REG_S_I2C_CTL, 0x03);
|
|
+ if (ret) {
|
|
+ dev_err(dev, "Failed to enable i2c daisy chain\n");
|
|
+ return ret;
|
|
+ }
|
|
+
|
|
dev_info(dev, "TPS68470 REVID: 0x%02x\n", version);
|
|
|
|
return 0;
|
|
--
|
|
2.36.0
|
|
|