* [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data
@ 2021-11-02 9:48 Hans de Goede
2021-11-02 9:48 ` [PATCH v5 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device Hans de Goede
` (11 more replies)
0 siblings, 12 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:48 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
Here is v5 of my patch-set adding support for camera sensor connected to a
TPS68470 PMIC on x86/ACPI devices.
Changes in v5:
- Update regulator_init_data in patch 10/11 to include the VCM regulator
- Address various small review remarks from Andy
- Make a couple of functions / vars static in the clk + regulator drivers
Reported-by: kernel test robot <lkp@intel.com>
Changes in v4:
[PATCH 01/11] ACPI: delay enumeration of devices with a _DEP
pointing to an INT3472 device:
- Move the acpi_dev_ready_for_enumeration() check to acpi_bus_attach()
(replacing the acpi_device_is_present() check there)
[PATCH 04/11] regulator: Introduce tps68470-regulator driver:
- Make the top comment block use c++ style comments
- Drop the bogus builtin regulator_init_data
- Make the driver enable the PMIC clk when enabling the Core buck
regulator, this switching regulator needs the PLL to be on
- Kconfig: add || COMPILE_TEST, fix help text
[PATCH 05/11] clk: Introduce clk-tps68470 driver
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups
I'm quite happy with how this works now, so from my pov this is the final
version of the device-instantiation deferral code / approach.
###
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, but on ACPI this info is missing.
This series worksaround this by providing platform_data with the info to
the TPS68470 clk/regulator MFD cells.
Patches 1 - 2 deal with a probe-ordering problem this introduces,
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. See the patches
for more details.
Patch 3 adds a header file which adds tps68470_clk_platform_data and
tps68470_regulator_platform_data structs. The futher patches depend on
this new header file.
Patch 4 + 5 add the TPS68470 clk and regulator drivers
Patches 6 - 11 Modify the INT3472 driver which instantiates the MFD cells to
provide the necessary platform-data.
Assuming this series is acceptable to everyone, we need to talk about how
to merge this.
Patch 2 has already been acked by Wolfram for merging by Rafael, so patch
1 + 2 can be merged into linux-pm, independent of the rest of the series
(there are some runtime deps on other changes for everything to work,
but the camera-sensors impacted by this are not fully supported yet in
the mainline kernel anyways).
For "[PATCH 03/13] platform_data: Add linux/platform_data/tps68470.h file",
which all further patches depend on I plan to provide an immutable branch
myself (once it has been reviewed), which the clk / regulator maintainers
can then merge before merging the clk / regulator driver which depends on
this.
And I will merge that IM-branch + patches 6-11 into the pdx86 tree myself.
Regards,
Hans
Daniel Scally (1):
platform/x86: int3472: Enable I2c daisy chain
Hans de Goede (10):
ACPI: delay enumeration of devices with a _DEP pointing to an INT3472
device
i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
platform_data: Add linux/platform_data/tps68470.h file
regulator: Introduce tps68470-regulator driver
clk: Introduce clk-tps68470 driver
platform/x86: int3472: Split into 2 drivers
platform/x86: int3472: Add get_sensor_adev_and_name() helper
platform/x86: int3472: Pass tps68470_clk_platform_data to the
tps68470-regulator MFD-cell
platform/x86: int3472: Pass tps68470_regulator_platform_data to the
tps68470-regulator MFD-cell
platform/x86: int3472: Deal with probe ordering issues
drivers/acpi/scan.c | 37 ++-
drivers/clk/Kconfig | 8 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-tps68470.c | 257 ++++++++++++++++++
drivers/i2c/i2c-core-acpi.c | 5 +-
drivers/platform/x86/intel/int3472/Makefile | 9 +-
...lk_and_regulator.c => clk_and_regulator.c} | 2 +-
drivers/platform/x86/intel/int3472/common.c | 82 ++++++
.../{intel_skl_int3472_common.h => common.h} | 6 +-
...ntel_skl_int3472_discrete.c => discrete.c} | 51 ++--
.../intel/int3472/intel_skl_int3472_common.c | 106 --------
...ntel_skl_int3472_tps68470.c => tps68470.c} | 99 ++++++-
drivers/platform/x86/intel/int3472/tps68470.h | 25 ++
.../x86/intel/int3472/tps68470_board_data.c | 134 +++++++++
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/tps68470-regulator.c | 212 +++++++++++++++
include/acpi/acpi_bus.h | 5 +-
include/linux/mfd/tps68470.h | 11 +
include/linux/platform_data/tps68470.h | 35 +++
20 files changed, 944 insertions(+), 151 deletions(-)
create mode 100644 drivers/clk/clk-tps68470.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
create mode 100644 drivers/platform/x86/intel/int3472/common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (91%)
delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (54%)
create mode 100644 drivers/platform/x86/intel/int3472/tps68470.h
create mode 100644 drivers/platform/x86/intel/int3472/tps68470_board_data.c
create mode 100644 drivers/regulator/tps68470-regulator.c
create mode 100644 include/linux/platform_data/tps68470.h
--
2.31.1
^ permalink raw reply [flat|nested] 43+ messages in thread* [PATCH v5 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
@ 2021-11-02 9:48 ` Hans de Goede
2021-11-02 9:48 ` [PATCH v5 02/11] i2c: acpi: Use acpi_dev_ready_for_enumeration() helper Hans de Goede
` (10 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:48 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk, Rafael J . Wysocki
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.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v4:
- Move the acpi_dev_ready_for_enumeration() check to acpi_bus_attach()
(replacing the acpi_device_is_present() check there)
---
drivers/acpi/scan.c | 37 +++++++++++++++++++++++++++++++++----
include/acpi/acpi_bus.h | 5 ++++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 6b939e2af544..73fab3c992d2 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -796,6 +796,12 @@ static const char * const acpi_ignore_dep_ids[] = {
NULL
};
+/* List of HIDs for which we honor deps of matching ACPI devs, when checking _DEP lists. */
+static const char * const acpi_honor_dep_ids[] = {
+ "INT3472", /* Camera sensor PMIC / clk and regulator info */
+ NULL
+};
+
static struct acpi_device *acpi_bus_get_parent(acpi_handle handle)
{
struct acpi_device *device = NULL;
@@ -1757,8 +1763,12 @@ static void acpi_scan_dep_init(struct acpi_device *adev)
struct acpi_dep_data *dep;
list_for_each_entry(dep, &acpi_dep_list, node) {
- if (dep->consumer == adev->handle)
+ if (dep->consumer == adev->handle) {
+ if (dep->honor_dep)
+ adev->flags.honor_deps = 1;
+
adev->dep_unmet++;
+ }
}
}
@@ -1962,7 +1972,7 @@ static u32 acpi_scan_check_dep(acpi_handle handle, bool check_dep)
for (count = 0, i = 0; i < dep_devices.count; i++) {
struct acpi_device_info *info;
struct acpi_dep_data *dep;
- bool skip;
+ bool skip, honor_dep;
status = acpi_get_object_info(dep_devices.handles[i], &info);
if (ACPI_FAILURE(status)) {
@@ -1971,6 +1981,7 @@ static u32 acpi_scan_check_dep(acpi_handle handle, bool check_dep)
}
skip = acpi_info_matches_ids(info, acpi_ignore_dep_ids);
+ honor_dep = acpi_info_matches_ids(info, acpi_honor_dep_ids);
kfree(info);
if (skip)
@@ -1984,6 +1995,7 @@ static u32 acpi_scan_check_dep(acpi_handle handle, bool check_dep)
dep->supplier = dep_devices.handles[i];
dep->consumer = handle;
+ dep->honor_dep = honor_dep;
mutex_lock(&acpi_dep_list_lock);
list_add_tail(&dep->node , &acpi_dep_list);
@@ -2150,8 +2162,8 @@ static void acpi_bus_attach(struct acpi_device *device, bool first_pass)
register_dock_dependent_device(device, ejd);
acpi_bus_get_status(device);
- /* Skip devices that are not present. */
- if (!acpi_device_is_present(device)) {
+ /* Skip devices that are not ready for enumeration (e.g. not present) */
+ if (!acpi_dev_ready_for_enumeration(device)) {
device->flags.initialized = false;
acpi_device_clear_enumerated(device);
device->flags.power_manageable = 0;
@@ -2313,6 +2325,23 @@ void acpi_dev_clear_dependencies(struct acpi_device *supplier)
}
EXPORT_SYMBOL_GPL(acpi_dev_clear_dependencies);
+/**
+ * acpi_dev_ready_for_enumeration - Check if the ACPI device is ready for enumeration
+ * @device: Pointer to the &struct acpi_device to check
+ *
+ * Check if the device is present and has no unmet dependencies.
+ *
+ * Return true if the device is ready for enumeratino. Otherwise, return false.
+ */
+bool acpi_dev_ready_for_enumeration(const struct acpi_device *device)
+{
+ if (device->flags.honor_deps && device->dep_unmet)
+ return false;
+
+ return acpi_device_is_present(device);
+}
+EXPORT_SYMBOL_GPL(acpi_dev_ready_for_enumeration);
+
/**
* acpi_dev_get_first_consumer_dev - Return ACPI device dependent on @supplier
* @supplier: Pointer to the dependee device
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 13d93371790e..2da53b7b4965 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -202,7 +202,8 @@ struct acpi_device_flags {
u32 coherent_dma:1;
u32 cca_seen:1;
u32 enumeration_by_parent:1;
- u32 reserved:19;
+ u32 honor_deps:1;
+ u32 reserved:18;
};
/* File System */
@@ -284,6 +285,7 @@ struct acpi_dep_data {
struct list_head node;
acpi_handle supplier;
acpi_handle consumer;
+ bool honor_dep;
};
/* Performance Management */
@@ -693,6 +695,7 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev)
bool acpi_dev_hid_uid_match(struct acpi_device *adev, const char *hid2, const char *uid2);
void acpi_dev_clear_dependencies(struct acpi_device *supplier);
+bool acpi_dev_ready_for_enumeration(const struct acpi_device *device);
struct acpi_device *acpi_dev_get_first_consumer_dev(struct acpi_device *supplier);
struct acpi_device *
acpi_dev_get_next_match_dev(struct acpi_device *adev, const char *hid, const char *uid, s64 hrv);
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 02/11] i2c: acpi: Use acpi_dev_ready_for_enumeration() helper
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02 9:48 ` [PATCH v5 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device Hans de Goede
@ 2021-11-02 9:48 ` Hans de Goede
2021-11-02 9:48 ` [PATCH v5 03/11] platform_data: Add linux/platform_data/tps68470.h file Hans de Goede
` (9 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:48 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk, Wolfram Sang, Rafael J . Wysocki
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.
To ensure the correct probe-ordering the ACPI core has code to defer the
enumeration of consumers affected by this until the providers are ready.
Call the new acpi_dev_ready_for_enumeration() helper to avoid
enumerating / instantiating i2c-clients too early.
Acked-by: Wolfram Sang <wsa@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/i2c/i2c-core-acpi.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 546cc935e035..71eee5bc17ab 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -144,9 +144,12 @@ static int i2c_acpi_do_lookup(struct acpi_device *adev,
struct list_head resource_list;
int ret;
- if (acpi_bus_get_status(adev) || !adev->status.present)
+ if (acpi_bus_get_status(adev))
return -EINVAL;
+ if (!acpi_dev_ready_for_enumeration(adev))
+ return -ENODEV;
+
if (acpi_match_device_ids(adev, i2c_acpi_ignored_device_ids) == 0)
return -ENODEV;
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 03/11] platform_data: Add linux/platform_data/tps68470.h file
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02 9:48 ` [PATCH v5 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device Hans de Goede
2021-11-02 9:48 ` [PATCH v5 02/11] i2c: acpi: Use acpi_dev_ready_for_enumeration() helper Hans de Goede
@ 2021-11-02 9:48 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 04/11] regulator: Introduce tps68470-regulator driver Hans de Goede
` (8 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:48 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
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 provider-device
during probe/registration of the provider device.
The TI TPS68470 PMIC is used x86/ACPI devices with the consumer-info
missing from the ACPI tables. Thus the tps68470-clk and tps68470-regulator
drivers must provide the consumer-info at probe time.
Define tps68470_clk_platform_data and tps68470_regulator_platform_data
structs to allow the x86 platform code to pass the necessary consumer info
to these drivers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
include/linux/platform_data/tps68470.h | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 include/linux/platform_data/tps68470.h
diff --git a/include/linux/platform_data/tps68470.h b/include/linux/platform_data/tps68470.h
new file mode 100644
index 000000000000..126d082c3f2e
--- /dev/null
+++ b/include/linux/platform_data/tps68470.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * TI TPS68470 PMIC platform data definition.
+ *
+ * Copyright (c) 2021 Red Hat Inc.
+ *
+ * Red Hat authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+#ifndef __PDATA_TPS68470_H
+#define __PDATA_TPS68470_H
+
+enum tps68470_regulators {
+ TPS68470_CORE,
+ TPS68470_ANA,
+ TPS68470_VCM,
+ TPS68470_VIO,
+ TPS68470_VSIO,
+ TPS68470_AUX1,
+ TPS68470_AUX2,
+ TPS68470_NUM_REGULATORS
+};
+
+struct regulator_init_data;
+
+struct tps68470_regulator_platform_data {
+ const struct regulator_init_data *reg_init_data[TPS68470_NUM_REGULATORS];
+};
+
+struct tps68470_clk_platform_data {
+ const char *consumer_dev_name;
+ const char *consumer_con_id;
+};
+
+#endif
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 04/11] regulator: Introduce tps68470-regulator driver
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (2 preceding siblings ...)
2021-11-02 9:48 ` [PATCH v5 03/11] platform_data: Add linux/platform_data/tps68470.h file Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
` (7 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in
the kernel the Regulators and Clocks are controlled by an OpRegion
driver designed to work with power control methods defined in ACPI, but
some platforms lack those methods, meaning drivers need to be able to
consume the resources of these chips through the usual frameworks.
This commit adds a driver for the regulators provided by the tps68470,
and is designed to bind to the platform_device registered by the
intel_skl_int3472 module.
This is based on this out of tree driver written by Intel:
https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/regulator/tps68470-regulator.c
with various cleanups added.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v5:
- Small comment / code cleanups based on review from Andy
Changes in v4:
- Make the top comment block use c++ style comments
- Drop the bogus builtin regulator_init_data
- Add || COMPILE_TEST to Kconfig snippet
- Make the driver enable the PMIC clk when enabling the Core buck
regulator, this switching regulator needs the PLL to be on
Changes in v2:
- Update the comment on why a subsys_initcall is used to register the drv
- Make struct regulator_ops const
---
drivers/regulator/Kconfig | 9 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/tps68470-regulator.c | 212 +++++++++++++++++++++++++
3 files changed, 222 insertions(+)
create mode 100644 drivers/regulator/tps68470-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 4fd13b06231f..1f6a6adc4ab0 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1339,6 +1339,15 @@ config REGULATOR_TPS65912
help
This driver supports TPS65912 voltage regulator chip.
+config REGULATOR_TPS68470
+ tristate "TI TPS68370 PMIC Regulators Driver"
+ depends on INTEL_SKL_INT3472 || COMPILE_TEST
+ help
+ This driver adds support for the TPS68470 PMIC to register
+ regulators against the usual framework.
+
+ The module will be called "tps68470-regulator".
+
config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regulator driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 9e382b50a5ef..03c318110986 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
+obj-$(CONFIG_REGULATOR_TPS68470) += tps68470-regulator.o
obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
obj-$(CONFIG_REGULATOR_TPS65132) += tps65132-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o twl6030-regulator.o
diff --git a/drivers/regulator/tps68470-regulator.c b/drivers/regulator/tps68470-regulator.c
new file mode 100644
index 000000000000..44b4f24741d7
--- /dev/null
+++ b/drivers/regulator/tps68470-regulator.c
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Regulator driver for TPS68470 PMIC
+//
+// Copyright (c) 2021 Red Hat Inc.
+// Copyright (C) 2018 Intel Corporation
+//
+// Authors:
+// Hans de Goede <hdegoede@redhat.com>
+// Zaikuo Wang <zaikuo.wang@intel.com>
+// Tianshu Qiu <tian.shu.qiu@intel.com>
+// Jian Xu Zheng <jian.xu.zheng@intel.com>
+// Yuning Pu <yuning.pu@intel.com>
+// Rajmohan Mani <rajmohan.mani@intel.com>
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mfd/tps68470.h>
+#include <linux/module.h>
+#include <linux/platform_data/tps68470.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+
+struct tps68470_regulator_data {
+ struct clk *clk;
+};
+
+#define TPS68470_REGULATOR(_name, _id, _ops, _n, _vr, \
+ _vm, _er, _em, _t, _lr, _nlr) \
+ [TPS68470_ ## _name] = { \
+ .name = # _name, \
+ .id = _id, \
+ .ops = &_ops, \
+ .n_voltages = _n, \
+ .type = REGULATOR_VOLTAGE, \
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = _vm, \
+ .enable_reg = _er, \
+ .enable_mask = _em, \
+ .volt_table = _t, \
+ .linear_ranges = _lr, \
+ .n_linear_ranges = _nlr, \
+ }
+
+static const struct linear_range tps68470_ldo_ranges[] = {
+ REGULATOR_LINEAR_RANGE(875000, 0, 125, 17800),
+};
+
+static const struct linear_range tps68470_core_ranges[] = {
+ REGULATOR_LINEAR_RANGE(900000, 0, 42, 25000),
+};
+
+static int tps68470_regulator_enable(struct regulator_dev *rdev)
+{
+ struct tps68470_regulator_data *data = rdev->reg_data;
+ int ret;
+
+ /* The Core buck regulator needs the PMIC's PLL to be enabled */
+ if (rdev->desc->id == TPS68470_CORE) {
+ ret = clk_prepare_enable(data->clk);
+ if (ret) {
+ dev_err(&rdev->dev, "Error enabling TPS68470 clock\n");
+ return ret;
+ }
+ }
+
+ return regulator_enable_regmap(rdev);
+}
+
+static int tps68470_regulator_disable(struct regulator_dev *rdev)
+{
+ struct tps68470_regulator_data *data = rdev->reg_data;
+
+ if (rdev->desc->id == TPS68470_CORE)
+ clk_disable_unprepare(data->clk);
+
+ return regulator_disable_regmap(rdev);
+}
+
+/* Operations permitted on DCDCx, LDO2, LDO3 and LDO4 */
+static const struct regulator_ops tps68470_regulator_ops = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = tps68470_regulator_enable,
+ .disable = tps68470_regulator_disable,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+};
+
+static const struct regulator_desc regulators[] = {
+ TPS68470_REGULATOR(CORE, TPS68470_CORE,
+ tps68470_regulator_ops, 43, TPS68470_REG_VDVAL,
+ TPS68470_VDVAL_DVOLT_MASK, TPS68470_REG_VDCTL,
+ TPS68470_VDCTL_EN_MASK,
+ NULL, tps68470_core_ranges,
+ ARRAY_SIZE(tps68470_core_ranges)),
+ TPS68470_REGULATOR(ANA, TPS68470_ANA,
+ tps68470_regulator_ops, 126, TPS68470_REG_VAVAL,
+ TPS68470_VAVAL_AVOLT_MASK, TPS68470_REG_VACTL,
+ TPS68470_VACTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+ TPS68470_REGULATOR(VCM, TPS68470_VCM,
+ tps68470_regulator_ops, 126, TPS68470_REG_VCMVAL,
+ TPS68470_VCMVAL_VCVOLT_MASK, TPS68470_REG_VCMCTL,
+ TPS68470_VCMCTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+ TPS68470_REGULATOR(VIO, TPS68470_VIO,
+ tps68470_regulator_ops, 126, TPS68470_REG_VIOVAL,
+ TPS68470_VIOVAL_IOVOLT_MASK, TPS68470_REG_S_I2C_CTL,
+ TPS68470_S_I2C_CTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+
+/*
+ * (1) This register must have same setting as VIOVAL if S_IO LDO is used to
+ * power daisy chained IOs in the receive side.
+ * (2) If there is no I2C daisy chain it can be set freely.
+ */
+ TPS68470_REGULATOR(VSIO, TPS68470_VSIO,
+ tps68470_regulator_ops, 126, TPS68470_REG_VSIOVAL,
+ TPS68470_VSIOVAL_IOVOLT_MASK, TPS68470_REG_S_I2C_CTL,
+ TPS68470_S_I2C_CTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+ TPS68470_REGULATOR(AUX1, TPS68470_AUX1,
+ tps68470_regulator_ops, 126, TPS68470_REG_VAUX1VAL,
+ TPS68470_VAUX1VAL_AUX1VOLT_MASK,
+ TPS68470_REG_VAUX1CTL,
+ TPS68470_VAUX1CTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+ TPS68470_REGULATOR(AUX2, TPS68470_AUX2,
+ tps68470_regulator_ops, 126, TPS68470_REG_VAUX2VAL,
+ TPS68470_VAUX2VAL_AUX2VOLT_MASK,
+ TPS68470_REG_VAUX2CTL,
+ TPS68470_VAUX2CTL_EN_MASK,
+ NULL, tps68470_ldo_ranges,
+ ARRAY_SIZE(tps68470_ldo_ranges)),
+};
+
+static int tps68470_regulator_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct tps68470_regulator_platform_data *pdata = dev_get_platdata(dev);
+ struct tps68470_regulator_data *data;
+ struct regulator_config config = { };
+ struct regulator_dev *rdev;
+ int i;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->clk = devm_clk_get(dev, "tps68470-clk");
+ if (IS_ERR(data->clk))
+ return dev_err_probe(dev, PTR_ERR(data->clk), "getting tps68470-clk\n");
+
+ config.dev = dev->parent;
+ config.regmap = dev_get_drvdata(dev->parent);
+ config.driver_data = data;
+
+ for (i = 0; i < TPS68470_NUM_REGULATORS; i++) {
+ if (pdata)
+ config.init_data = pdata->reg_init_data[i];
+ else
+ config.init_data = NULL;
+
+ rdev = devm_regulator_register(dev, ®ulators[i], &config);
+ if (IS_ERR(rdev))
+ return dev_err_probe(dev, PTR_ERR(data->clk),
+ "registering %s regulator\n",
+ regulators[i].name);
+ }
+
+ return 0;
+}
+
+static struct platform_driver tps68470_regulator_driver = {
+ .driver = {
+ .name = "tps68470-regulator",
+ },
+ .probe = tps68470_regulator_probe,
+};
+
+/*
+ * The ACPI tps68470 probe-ordering depends on the clk/gpio/regulator drivers
+ * registering before the drivers for the camera-sensors which use them bind.
+ * subsys_initcall() ensures this when the drivers are builtin.
+ */
+static int __init tps68470_regulator_init(void)
+{
+ return platform_driver_register(&tps68470_regulator_driver);
+}
+subsys_initcall(tps68470_regulator_init);
+
+static void __exit tps68470_regulator_exit(void)
+{
+ platform_driver_unregister(&tps68470_regulator_driver);
+}
+module_exit(tps68470_regulator_exit);
+
+MODULE_ALIAS("platform:tps68470-regulator");
+MODULE_DESCRIPTION("TPS68470 voltage regulator driver");
+MODULE_LICENSE("GPL v2");
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 05/11] clk: Introduce clk-tps68470 driver
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (3 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 04/11] regulator: Introduce tps68470-regulator driver Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
[not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>
2021-11-02 9:49 ` [PATCH v5 06/11] platform/x86: int3472: Enable I2c daisy chain Hans de Goede
` (6 subsequent siblings)
11 siblings, 1 reply; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in
the kernel the Regulators and Clocks are controlled by an OpRegion
driver designed to work with power control methods defined in ACPI, but
some platforms lack those methods, meaning drivers need to be able to
consume the resources of these chips through the usual frameworks.
This commit adds a driver for the clocks provided by the tps68470,
and is designed to bind to the platform_device registered by the
intel_skl_int3472 module.
This is based on this out of tree driver written by Intel:
https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/clk/clk-tps68470.c
with various cleanups added.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v5:
- Small comment cleanups based on review from Andy
Changes in v4:
- Kconfig: select REGMAP_I2C, add || COMPILE_TEST, fix help text
- tps68470_clk_prepare(): Wait for the PLL to lock before returning
- tps68470_clk_unprepare(): Remove unnecesary clearing of divider regs
- tps68470_clk_probe(): Use devm_clk_hw_register()
- Misc. small cleanups
Changes in v2:
- Update the comment on why a subsys_initcall is used to register the drv
- Fix trailing whitespice on line 100
---
drivers/clk/Kconfig | 8 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-tps68470.c | 257 +++++++++++++++++++++++++++++++++++
include/linux/mfd/tps68470.h | 11 ++
4 files changed, 277 insertions(+)
create mode 100644 drivers/clk/clk-tps68470.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index c5b3dc97396a..4e9098d79249 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -169,6 +169,14 @@ config COMMON_CLK_CDCE706
help
This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
+config COMMON_CLK_TPS68470
+ tristate "Clock Driver for TI TPS68470 PMIC"
+ depends on I2C
+ depends on INTEL_SKL_INT3472 || COMPILE_TEST
+ select REGMAP_I2C
+ help
+ This driver supports the clocks provided by the TPS68470 PMIC.
+
config COMMON_CLK_CDCE925
tristate "Clock driver for TI CDCE913/925/937/949 devices"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index e42312121e51..6b6a88ae1425 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
obj-$(CONFIG_COMMON_CLK_STM32F) += clk-stm32f4.o
obj-$(CONFIG_COMMON_CLK_STM32H7) += clk-stm32h7.o
obj-$(CONFIG_COMMON_CLK_STM32MP157) += clk-stm32mp1.o
+obj-$(CONFIG_COMMON_CLK_TPS68470) += clk-tps68470.o
obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_COMMON_CLK_VC5) += clk-versaclock5.o
diff --git a/drivers/clk/clk-tps68470.c b/drivers/clk/clk-tps68470.c
new file mode 100644
index 000000000000..2ad0ac2f4096
--- /dev/null
+++ b/drivers/clk/clk-tps68470.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Clock driver for TPS68470 PMIC
+ *
+ * Copyright (c) 2021 Red Hat Inc.
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * Authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ * Zaikuo Wang <zaikuo.wang@intel.com>
+ * Tianshu Qiu <tian.shu.qiu@intel.com>
+ * Jian Xu Zheng <jian.xu.zheng@intel.com>
+ * Yuning Pu <yuning.pu@intel.com>
+ * Antti Laakso <antti.laakso@intel.com>
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/kernel.h>
+#include <linux/mfd/tps68470.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/platform_data/tps68470.h>
+#include <linux/regmap.h>
+
+#define TPS68470_CLK_NAME "tps68470-clk"
+
+#define to_tps68470_clkdata(clkd) \
+ container_of(clkd, struct tps68470_clkdata, clkout_hw)
+
+static struct tps68470_clkout_freqs {
+ unsigned long freq;
+ unsigned int xtaldiv;
+ unsigned int plldiv;
+ unsigned int postdiv;
+ unsigned int buckdiv;
+ unsigned int boostdiv;
+} clk_freqs[] = {
+/*
+ * The PLL is used to multiply the crystal oscillator
+ * frequency range of 3 MHz to 27 MHz by a programmable
+ * factor of F = (M/N)*(1/P) such that the output
+ * available at the HCLK_A or HCLK_B pins are in the range
+ * of 4 MHz to 64 MHz in increments of 0.1 MHz.
+ *
+ * hclk_# = osc_in * (((plldiv*2)+320) / (xtaldiv+30)) * (1 / 2^postdiv)
+ *
+ * PLL_REF_CLK should be as close as possible to 100kHz
+ * PLL_REF_CLK = input clk / XTALDIV[7:0] + 30)
+ *
+ * PLL_VCO_CLK = (PLL_REF_CLK * (plldiv*2 + 320))
+ *
+ * BOOST should be as close as possible to 2Mhz
+ * BOOST = PLL_VCO_CLK / (BOOSTDIV[4:0] + 16) *
+ *
+ * BUCK should be as close as possible to 5.2Mhz
+ * BUCK = PLL_VCO_CLK / (BUCKDIV[3:0] + 5)
+ *
+ * osc_in xtaldiv plldiv postdiv hclk_#
+ * 20Mhz 170 32 1 19.2Mhz
+ * 20Mhz 170 40 1 20Mhz
+ * 20Mhz 170 80 1 24Mhz
+ */
+ { 19200000, 170, 32, 1, 2, 3 },
+ { 20000000, 170, 40, 1, 3, 4 },
+ { 24000000, 170, 80, 1, 4, 8 },
+};
+
+struct tps68470_clkdata {
+ struct clk_hw clkout_hw;
+ struct regmap *regmap;
+ unsigned int clk_cfg_idx;
+};
+
+static int tps68470_clk_is_prepared(struct clk_hw *hw)
+{
+ struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+ int val;
+
+ if (regmap_read(clkdata->regmap, TPS68470_REG_PLLCTL, &val))
+ return 0;
+
+ return val & TPS68470_PLL_EN_MASK;
+}
+
+static int tps68470_clk_prepare(struct clk_hw *hw)
+{
+ struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+ unsigned int idx = clkdata->clk_cfg_idx;
+
+ regmap_write(clkdata->regmap, TPS68470_REG_BOOSTDIV, clk_freqs[idx].boostdiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_BUCKDIV, clk_freqs[idx].buckdiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_PLLSWR, TPS68470_PLLSWR_DEFAULT);
+ regmap_write(clkdata->regmap, TPS68470_REG_XTALDIV, clk_freqs[idx].xtaldiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_PLLDIV, clk_freqs[idx].plldiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV, clk_freqs[idx].postdiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_POSTDIV2, clk_freqs[idx].postdiv);
+ regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG2, TPS68470_CLKCFG2_DRV_STR_2MA);
+
+ regmap_write(clkdata->regmap, TPS68470_REG_PLLCTL,
+ TPS68470_OSC_EXT_CAP_DEFAULT << TPS68470_OSC_EXT_CAP_SHIFT |
+ TPS68470_CLK_SRC_XTAL << TPS68470_CLK_SRC_SHIFT);
+
+ regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1,
+ (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_A_SHIFT) |
+ (TPS68470_PLL_OUTPUT_ENABLE << TPS68470_OUTPUT_B_SHIFT));
+
+ regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL,
+ TPS68470_PLL_EN_MASK, TPS68470_PLL_EN_MASK);
+
+ /*
+ * The PLLCTL reg lock bit is set by the PMIC after approx. 4ms and
+ * does not indicate a true lock, so just wait 4 ms.
+ */
+ usleep_range(4000, 5000);
+
+ return 0;
+}
+
+static void tps68470_clk_unprepare(struct clk_hw *hw)
+{
+ struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+
+ /* Disable clock first ... */
+ regmap_update_bits(clkdata->regmap, TPS68470_REG_PLLCTL, TPS68470_PLL_EN_MASK, 0);
+
+ /* ... and then tri-state the clock outputs. */
+ regmap_write(clkdata->regmap, TPS68470_REG_CLKCFG1, 0);
+}
+
+static unsigned long tps68470_clk_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
+{
+ struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+
+ return clk_freqs[clkdata->clk_cfg_idx].freq;
+}
+
+/*
+ * This returns the index of the clk_freqs[] cfg with the closest rate for
+ * use in tps68470_clk_round_rate(). tps68470_clk_set_rate() checks that
+ * the rate of the returned cfg is an exact match.
+ */
+static unsigned int tps68470_clk_cfg_lookup(unsigned long rate)
+{
+ long diff, best_diff = LONG_MAX;
+ unsigned int i, best_idx = 0;
+
+ for (i = 0; i < ARRAY_SIZE(clk_freqs); i++) {
+ diff = clk_freqs[i].freq - rate;
+ if (diff == 0)
+ return i;
+
+ diff = abs(diff);
+ if (diff < best_diff) {
+ best_diff = diff;
+ best_idx = i;
+ }
+ }
+
+ return best_idx;
+}
+
+static long tps68470_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ unsigned int idx = tps68470_clk_cfg_lookup(rate);
+
+ return clk_freqs[idx].freq;
+}
+
+static int tps68470_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct tps68470_clkdata *clkdata = to_tps68470_clkdata(hw);
+ unsigned int idx = tps68470_clk_cfg_lookup(rate);
+
+ if (rate != clk_freqs[idx].freq)
+ return -EINVAL;
+
+ clkdata->clk_cfg_idx = idx;
+
+ return 0;
+}
+
+static const struct clk_ops tps68470_clk_ops = {
+ .is_prepared = tps68470_clk_is_prepared,
+ .prepare = tps68470_clk_prepare,
+ .unprepare = tps68470_clk_unprepare,
+ .recalc_rate = tps68470_clk_recalc_rate,
+ .round_rate = tps68470_clk_round_rate,
+ .set_rate = tps68470_clk_set_rate,
+};
+
+static const struct clk_init_data tps68470_clk_initdata = {
+ .name = TPS68470_CLK_NAME,
+ .ops = &tps68470_clk_ops,
+};
+
+static int tps68470_clk_probe(struct platform_device *pdev)
+{
+ struct tps68470_clk_platform_data *pdata = pdev->dev.platform_data;
+ struct tps68470_clkdata *tps68470_clkdata;
+ int ret;
+
+ tps68470_clkdata = devm_kzalloc(&pdev->dev, sizeof(*tps68470_clkdata),
+ GFP_KERNEL);
+ if (!tps68470_clkdata)
+ return -ENOMEM;
+
+ tps68470_clkdata->regmap = dev_get_drvdata(pdev->dev.parent);
+ tps68470_clkdata->clkout_hw.init = &tps68470_clk_initdata;
+ ret = devm_clk_hw_register(&pdev->dev, &tps68470_clkdata->clkout_hw);
+ if (ret)
+ return ret;
+
+ ret = devm_clk_hw_register_clkdev(&pdev->dev, &tps68470_clkdata->clkout_hw,
+ TPS68470_CLK_NAME, NULL);
+ if (ret)
+ return ret;
+
+ if (pdata) {
+ ret = devm_clk_hw_register_clkdev(&pdev->dev,
+ &tps68470_clkdata->clkout_hw,
+ pdata->consumer_con_id,
+ pdata->consumer_dev_name);
+ }
+
+ return ret;
+}
+
+static struct platform_driver tps68470_clk_driver = {
+ .driver = {
+ .name = TPS68470_CLK_NAME,
+ },
+ .probe = tps68470_clk_probe,
+};
+
+/*
+ * The ACPI tps68470 probe-ordering depends on the clk/gpio/regulator drivers
+ * registering before the drivers for the camera-sensors which use them bind.
+ * subsys_initcall() ensures this when the drivers are builtin.
+ */
+static int __init tps68470_clk_init(void)
+{
+ return platform_driver_register(&tps68470_clk_driver);
+}
+subsys_initcall(tps68470_clk_init);
+
+static void __exit tps68470_clk_exit(void)
+{
+ platform_driver_unregister(&tps68470_clk_driver);
+}
+module_exit(tps68470_clk_exit);
+
+MODULE_ALIAS("platform:tps68470-clk");
+MODULE_DESCRIPTION("clock driver for TPS68470 pmic");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/tps68470.h b/include/linux/mfd/tps68470.h
index ffe81127d91c..7807fa329db0 100644
--- a/include/linux/mfd/tps68470.h
+++ b/include/linux/mfd/tps68470.h
@@ -75,6 +75,17 @@
#define TPS68470_CLKCFG1_MODE_A_MASK GENMASK(1, 0)
#define TPS68470_CLKCFG1_MODE_B_MASK GENMASK(3, 2)
+#define TPS68470_CLKCFG2_DRV_STR_2MA 0x05
+#define TPS68470_PLL_OUTPUT_ENABLE 0x02
+#define TPS68470_CLK_SRC_XTAL BIT(0)
+#define TPS68470_PLLSWR_DEFAULT GENMASK(1, 0)
+#define TPS68470_OSC_EXT_CAP_DEFAULT 0x05
+
+#define TPS68470_OUTPUT_A_SHIFT 0x00
+#define TPS68470_OUTPUT_B_SHIFT 0x02
+#define TPS68470_CLK_SRC_SHIFT GENMASK(2, 0)
+#define TPS68470_OSC_EXT_CAP_SHIFT BIT(2)
+
#define TPS68470_GPIO_CTL_REG_A(x) (TPS68470_REG_GPCTL0A + (x) * 2)
#define TPS68470_GPIO_CTL_REG_B(x) (TPS68470_REG_GPCTL0B + (x) * 2)
#define TPS68470_GPIO_MODE_MASK GENMASK(1, 0)
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 06/11] platform/x86: int3472: Enable I2c daisy chain
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (4 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Hans de Goede
` (5 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
From: Daniel Scally <djrscally@gmail.com>
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>
---
.../x86/intel/int3472/intel_skl_int3472_tps68470.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c b/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c
index c05b4cf502fe..42e688f4cad4 100644
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c
+++ b/drivers/platform/x86/intel/int3472/intel_skl_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.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (5 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 06/11] platform/x86: int3472: Enable I2c daisy chain Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 14:12 ` Andy Shevchenko
2021-11-02 14:16 ` Andy Shevchenko
2021-11-02 9:49 ` [PATCH v5 08/11] platform/x86: int3472: Add get_sensor_adev_and_name() helper Hans de Goede
` (4 subsequent siblings)
11 siblings, 2 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
The intel_skl_int3472.ko module contains 2 separate drivers,
the int3472_discrete platform driver and the int3472_tps68470
I2C-driver.
These 2 drivers contain very little shared code, only
skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are
shared.
Split the module into 2 drivers, linking the little shared code
directly into both.
This will allow us to add soft-module dependencies for the
tps68470 clk, gpio and regulator drivers to the new
intel_skl_int3472_tps68470.ko to help with probe ordering issues
without causing these modules to get loaded on boards which only
use the int3472_discrete platform driver.
While at it also rename the .c and .h files to remove the
cumbersome intel_skl_int3472_ prefix.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Note git rename detection is failing for the new common.c but this is
just the old intel_skl_int3472_common.c with the driver registering
bits removed.
---
drivers/platform/x86/intel/int3472/Makefile | 9 +-
...lk_and_regulator.c => clk_and_regulator.c} | 2 +-
drivers/platform/x86/intel/int3472/common.c | 54 +++++++++
.../{intel_skl_int3472_common.h => common.h} | 3 -
...ntel_skl_int3472_discrete.c => discrete.c} | 28 ++++-
.../intel/int3472/intel_skl_int3472_common.c | 106 ------------------
...ntel_skl_int3472_tps68470.c => tps68470.c} | 23 +++-
7 files changed, 105 insertions(+), 120 deletions(-)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_clk_and_regulator.c => clk_and_regulator.c} (99%)
create mode 100644 drivers/platform/x86/intel/int3472/common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_common.h => common.h} (94%)
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_discrete.c => discrete.c} (93%)
delete mode 100644 drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
rename drivers/platform/x86/intel/int3472/{intel_skl_int3472_tps68470.c => tps68470.c} (86%)
diff --git a/drivers/platform/x86/intel/int3472/Makefile b/drivers/platform/x86/intel/int3472/Makefile
index 2362e04db18d..771e720528a0 100644
--- a/drivers/platform/x86/intel/int3472/Makefile
+++ b/drivers/platform/x86/intel/int3472/Makefile
@@ -1,5 +1,4 @@
-obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472.o
-intel_skl_int3472-y := intel_skl_int3472_common.o \
- intel_skl_int3472_discrete.o \
- intel_skl_int3472_tps68470.o \
- intel_skl_int3472_clk_and_regulator.o
+obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472_discrete.o \
+ intel_skl_int3472_tps68470.o
+intel_skl_int3472_discrete-y := discrete.o clk_and_regulator.o common.o
+intel_skl_int3472_tps68470-y := tps68470.o common.o
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
similarity index 99%
rename from drivers/platform/x86/intel/int3472/intel_skl_int3472_clk_and_regulator.c
rename to drivers/platform/x86/intel/int3472/clk_and_regulator.c
index 1700e7557a82..1cf958983e86 100644
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_clk_and_regulator.c
+++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
@@ -9,7 +9,7 @@
#include <linux/regulator/driver.h>
#include <linux/slab.h>
-#include "intel_skl_int3472_common.h"
+#include "common.h"
/*
* The regulators have to have .ops to be valid, but the only ops we actually
diff --git a/drivers/platform/x86/intel/int3472/common.c b/drivers/platform/x86/intel/int3472/common.c
new file mode 100644
index 000000000000..350655a9515b
--- /dev/null
+++ b/drivers/platform/x86/intel/int3472/common.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Author: Dan Scally <djrscally@gmail.com> */
+
+#include <linux/acpi.h>
+#include <linux/slab.h>
+
+#include "common.h"
+
+union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev, char *id)
+{
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ acpi_handle handle = adev->handle;
+ union acpi_object *obj;
+ acpi_status status;
+
+ status = acpi_evaluate_object(handle, id, NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ return ERR_PTR(-ENODEV);
+
+ obj = buffer.pointer;
+ if (!obj)
+ return ERR_PTR(-ENODEV);
+
+ if (obj->type != ACPI_TYPE_BUFFER) {
+ acpi_handle_err(handle, "%s object is not an ACPI buffer\n", id);
+ kfree(obj);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return obj;
+}
+
+int skl_int3472_fill_cldb(struct acpi_device *adev, struct int3472_cldb *cldb)
+{
+ union acpi_object *obj;
+ int ret;
+
+ obj = skl_int3472_get_acpi_buffer(adev, "CLDB");
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ if (obj->buffer.length > sizeof(*cldb)) {
+ acpi_handle_err(adev->handle, "The CLDB buffer is too large\n");
+ ret = -EINVAL;
+ goto out_free_obj;
+ }
+
+ memcpy(cldb, obj->buffer.pointer, obj->buffer.length);
+ ret = 0;
+
+out_free_obj:
+ kfree(obj);
+ return ret;
+}
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_common.h b/drivers/platform/x86/intel/int3472/common.h
similarity index 94%
rename from drivers/platform/x86/intel/int3472/intel_skl_int3472_common.h
rename to drivers/platform/x86/intel/int3472/common.h
index 714fde73b524..d14944ee8586 100644
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_common.h
+++ b/drivers/platform/x86/intel/int3472/common.h
@@ -105,9 +105,6 @@ struct int3472_discrete_device {
struct gpiod_lookup_table gpios;
};
-int skl_int3472_discrete_probe(struct platform_device *pdev);
-int skl_int3472_discrete_remove(struct platform_device *pdev);
-int skl_int3472_tps68470_probe(struct i2c_client *client);
union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev,
char *id);
int skl_int3472_fill_cldb(struct acpi_device *adev, struct int3472_cldb *cldb);
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
similarity index 93%
rename from drivers/platform/x86/intel/int3472/intel_skl_int3472_discrete.c
rename to drivers/platform/x86/intel/int3472/discrete.c
index e59d79c7e82f..d2e8a87a077e 100644
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -14,7 +14,7 @@
#include <linux/platform_device.h>
#include <linux/uuid.h>
-#include "intel_skl_int3472_common.h"
+#include "common.h"
/*
* 79234640-9e10-4fea-a5c1-b5aa8b19756f
@@ -332,7 +332,9 @@ static int skl_int3472_parse_crs(struct int3472_discrete_device *int3472)
return 0;
}
-int skl_int3472_discrete_probe(struct platform_device *pdev)
+static int skl_int3472_discrete_remove(struct platform_device *pdev);
+
+static int skl_int3472_discrete_probe(struct platform_device *pdev)
{
struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
struct int3472_discrete_device *int3472;
@@ -395,7 +397,7 @@ int skl_int3472_discrete_probe(struct platform_device *pdev)
return ret;
}
-int skl_int3472_discrete_remove(struct platform_device *pdev)
+static int skl_int3472_discrete_remove(struct platform_device *pdev)
{
struct int3472_discrete_device *int3472 = platform_get_drvdata(pdev);
@@ -411,3 +413,23 @@ int skl_int3472_discrete_remove(struct platform_device *pdev)
return 0;
}
+
+static const struct acpi_device_id int3472_device_id[] = {
+ { "INT3472", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, int3472_device_id);
+
+static struct platform_driver int3472_discrete = {
+ .driver = {
+ .name = "int3472-discrete",
+ .acpi_match_table = int3472_device_id,
+ },
+ .probe = skl_int3472_discrete_probe,
+ .remove = skl_int3472_discrete_remove,
+};
+module_platform_driver(int3472_discrete);
+
+MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI Discrete Device Driver");
+MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c b/drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
deleted file mode 100644
index 497e74fba75f..000000000000
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_common.c
+++ /dev/null
@@ -1,106 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/* Author: Dan Scally <djrscally@gmail.com> */
-
-#include <linux/acpi.h>
-#include <linux/i2c.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-
-#include "intel_skl_int3472_common.h"
-
-union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev, char *id)
-{
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- acpi_handle handle = adev->handle;
- union acpi_object *obj;
- acpi_status status;
-
- status = acpi_evaluate_object(handle, id, NULL, &buffer);
- if (ACPI_FAILURE(status))
- return ERR_PTR(-ENODEV);
-
- obj = buffer.pointer;
- if (!obj)
- return ERR_PTR(-ENODEV);
-
- if (obj->type != ACPI_TYPE_BUFFER) {
- acpi_handle_err(handle, "%s object is not an ACPI buffer\n", id);
- kfree(obj);
- return ERR_PTR(-EINVAL);
- }
-
- return obj;
-}
-
-int skl_int3472_fill_cldb(struct acpi_device *adev, struct int3472_cldb *cldb)
-{
- union acpi_object *obj;
- int ret;
-
- obj = skl_int3472_get_acpi_buffer(adev, "CLDB");
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- if (obj->buffer.length > sizeof(*cldb)) {
- acpi_handle_err(adev->handle, "The CLDB buffer is too large\n");
- ret = -EINVAL;
- goto out_free_obj;
- }
-
- memcpy(cldb, obj->buffer.pointer, obj->buffer.length);
- ret = 0;
-
-out_free_obj:
- kfree(obj);
- return ret;
-}
-
-static const struct acpi_device_id int3472_device_id[] = {
- { "INT3472", 0 },
- { }
-};
-MODULE_DEVICE_TABLE(acpi, int3472_device_id);
-
-static struct platform_driver int3472_discrete = {
- .driver = {
- .name = "int3472-discrete",
- .acpi_match_table = int3472_device_id,
- },
- .probe = skl_int3472_discrete_probe,
- .remove = skl_int3472_discrete_remove,
-};
-
-static struct i2c_driver int3472_tps68470 = {
- .driver = {
- .name = "int3472-tps68470",
- .acpi_match_table = int3472_device_id,
- },
- .probe_new = skl_int3472_tps68470_probe,
-};
-
-static int skl_int3472_init(void)
-{
- int ret;
-
- ret = platform_driver_register(&int3472_discrete);
- if (ret)
- return ret;
-
- ret = i2c_register_driver(THIS_MODULE, &int3472_tps68470);
- if (ret)
- platform_driver_unregister(&int3472_discrete);
-
- return ret;
-}
-module_init(skl_int3472_init);
-
-static void skl_int3472_exit(void)
-{
- platform_driver_unregister(&int3472_discrete);
- i2c_del_driver(&int3472_tps68470);
-}
-module_exit(skl_int3472_exit);
-
-MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI Device Driver");
-MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
similarity index 86%
rename from drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c
rename to drivers/platform/x86/intel/int3472/tps68470.c
index 42e688f4cad4..e95b0f50b384 100644
--- a/drivers/platform/x86/intel/int3472/intel_skl_int3472_tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -7,7 +7,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
-#include "intel_skl_int3472_common.h"
+#include "common.h"
#define DESIGNED_FOR_CHROMEOS 1
#define DESIGNED_FOR_WINDOWS 2
@@ -102,7 +102,7 @@ static int skl_int3472_tps68470_calc_type(struct acpi_device *adev)
return DESIGNED_FOR_WINDOWS;
}
-int skl_int3472_tps68470_probe(struct i2c_client *client)
+static int skl_int3472_tps68470_probe(struct i2c_client *client)
{
struct acpi_device *adev = ACPI_COMPANION(&client->dev);
struct regmap *regmap;
@@ -142,3 +142,22 @@ int skl_int3472_tps68470_probe(struct i2c_client *client)
return ret;
}
+
+static const struct acpi_device_id int3472_device_id[] = {
+ { "INT3472", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, int3472_device_id);
+
+static struct i2c_driver int3472_tps68470 = {
+ .driver = {
+ .name = "int3472-tps68470",
+ .acpi_match_table = int3472_device_id,
+ },
+ .probe_new = skl_int3472_tps68470_probe,
+};
+module_i2c_driver(int3472_tps68470);
+
+MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI TPS68470 Device Driver");
+MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
+MODULE_LICENSE("GPL v2");
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers
2021-11-02 9:49 ` [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Hans de Goede
@ 2021-11-02 14:12 ` Andy Shevchenko
2021-11-02 14:16 ` Andy Shevchenko
1 sibling, 0 replies; 43+ messages in thread
From: Andy Shevchenko @ 2021-11-02 14:12 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> The intel_skl_int3472.ko module contains 2 separate drivers,
> the int3472_discrete platform driver and the int3472_tps68470
> I2C-driver.
>
> These 2 drivers contain very little shared code, only
> skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are
> shared.
>
> Split the module into 2 drivers, linking the little shared code
> directly into both.
>
> This will allow us to add soft-module dependencies for the
> tps68470 clk, gpio and regulator drivers to the new
> intel_skl_int3472_tps68470.ko to help with probe ordering issues
> without causing these modules to get loaded on boards which only
> use the int3472_discrete platform driver.
>
> While at it also rename the .c and .h files to remove the
> cumbersome intel_skl_int3472_ prefix.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> Note git rename detection is failing for the new common.c but this is
> just the old intel_skl_int3472_common.c with the driver registering
> bits removed.
-M accepts a parameter (in percents) to set the threshold. Default is
something like ~70 (?). You may play with it and see when it starts
detecting the rename.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers
2021-11-02 9:49 ` [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Hans de Goede
2021-11-02 14:12 ` Andy Shevchenko
@ 2021-11-02 14:16 ` Andy Shevchenko
2021-11-02 14:24 ` Hans de Goede
1 sibling, 1 reply; 43+ messages in thread
From: Andy Shevchenko @ 2021-11-02 14:16 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> The intel_skl_int3472.ko module contains 2 separate drivers,
> the int3472_discrete platform driver and the int3472_tps68470
> I2C-driver.
>
> These 2 drivers contain very little shared code, only
> skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are
> shared.
>
> Split the module into 2 drivers, linking the little shared code
> directly into both.
>
> This will allow us to add soft-module dependencies for the
> tps68470 clk, gpio and regulator drivers to the new
> intel_skl_int3472_tps68470.ko to help with probe ordering issues
> without causing these modules to get loaded on boards which only
> use the int3472_discrete platform driver.
>
> While at it also rename the .c and .h files to remove the
> cumbersome intel_skl_int3472_ prefix.
...
> +union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev, char *id)
> +{
> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
> + acpi_handle handle = adev->handle;
> + union acpi_object *obj;
> + acpi_status status;
> +
> + status = acpi_evaluate_object(handle, id, NULL, &buffer);
> + if (ACPI_FAILURE(status))
> + return ERR_PTR(-ENODEV);
> +
> + obj = buffer.pointer;
> + if (!obj)
> + return ERR_PTR(-ENODEV);
> +
> + if (obj->type != ACPI_TYPE_BUFFER) {
> + acpi_handle_err(handle, "%s object is not an ACPI buffer\n", id);
> + kfree(obj);
I'm wondering if we should use more of the ACPI_FREE() calls as
opposed to ACPI_ALLOCATE_BUFFER. Ditto for all such cases.
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return obj;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers
2021-11-02 14:16 ` Andy Shevchenko
@ 2021-11-02 14:24 ` Hans de Goede
0 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 14:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
Hi,
On 11/2/21 15:16, Andy Shevchenko wrote:
> On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> The intel_skl_int3472.ko module contains 2 separate drivers,
>> the int3472_discrete platform driver and the int3472_tps68470
>> I2C-driver.
>>
>> These 2 drivers contain very little shared code, only
>> skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are
>> shared.
>>
>> Split the module into 2 drivers, linking the little shared code
>> directly into both.
>>
>> This will allow us to add soft-module dependencies for the
>> tps68470 clk, gpio and regulator drivers to the new
>> intel_skl_int3472_tps68470.ko to help with probe ordering issues
>> without causing these modules to get loaded on boards which only
>> use the int3472_discrete platform driver.
>>
>> While at it also rename the .c and .h files to remove the
>> cumbersome intel_skl_int3472_ prefix.
>
> ...
>
>> +union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev, char *id)
>> +{
>> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
>> + acpi_handle handle = adev->handle;
>> + union acpi_object *obj;
>> + acpi_status status;
>> +
>> + status = acpi_evaluate_object(handle, id, NULL, &buffer);
>> + if (ACPI_FAILURE(status))
>> + return ERR_PTR(-ENODEV);
>> +
>> + obj = buffer.pointer;
>> + if (!obj)
>> + return ERR_PTR(-ENODEV);
>> +
>> + if (obj->type != ACPI_TYPE_BUFFER) {
>> + acpi_handle_err(handle, "%s object is not an ACPI buffer\n", id);
>
>> + kfree(obj);
>
> I'm wondering if we should use more of the ACPI_FREE() calls as
> opposed to ACPI_ALLOCATE_BUFFER. Ditto for all such cases.
Basically the situation surrounding this is a mess, most code seems to
simply use plain kfree() which I find much more readable, but some
code indeed is using ACPI_FREE(), which I believe is really mostly
meant for internal use by the acpica code.
Eitherway until one of the ACPI maintainers clearly states
that we really should use ACPI_FREE() here I plan to stick with kfree()
because:
1. I find it much more readable.
2. AFAICT ACPI_FREE() is meant for acpica internal use
(basically it is part of the OS abstraction bits of acpica)
Regards,
Hans
^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH v5 08/11] platform/x86: int3472: Add get_sensor_adev_and_name() helper
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (6 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 09/11] platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell Hans de Goede
` (3 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
The discrete.c code is not the only code which needs to lookup the
acpi_device and device-name for the sensor for which the INT3472
ACPI-device is a GPIO/clk/regulator provider.
The tps68470.c code also needs this functionality, so factor this
out into a new get_sensor_adev_and_name() helper.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/intel/int3472/common.c | 28 +++++++++++++++++++
drivers/platform/x86/intel/int3472/common.h | 3 ++
drivers/platform/x86/intel/int3472/discrete.c | 22 +++------------
3 files changed, 35 insertions(+), 18 deletions(-)
diff --git a/drivers/platform/x86/intel/int3472/common.c b/drivers/platform/x86/intel/int3472/common.c
index 350655a9515b..77cf058e4168 100644
--- a/drivers/platform/x86/intel/int3472/common.c
+++ b/drivers/platform/x86/intel/int3472/common.c
@@ -52,3 +52,31 @@ int skl_int3472_fill_cldb(struct acpi_device *adev, struct int3472_cldb *cldb)
kfree(obj);
return ret;
}
+
+/* sensor_adev_ret may be NULL, name_ret must not be NULL */
+int skl_int3472_get_sensor_adev_and_name(struct device *dev,
+ struct acpi_device **sensor_adev_ret,
+ const char **name_ret)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ struct acpi_device *sensor;
+ int ret = 0;
+
+ sensor = acpi_dev_get_first_consumer_dev(adev);
+ if (!sensor) {
+ dev_err(dev, "INT3472 seems to have no dependents.\n");
+ return -ENODEV;
+ }
+
+ *name_ret = devm_kasprintf(dev, GFP_KERNEL, I2C_DEV_NAME_FORMAT,
+ acpi_dev_name(sensor));
+ if (!*name_ret)
+ ret = -ENOMEM;
+
+ if (ret == 0 && sensor_adev_ret)
+ *sensor_adev_ret = sensor;
+ else
+ acpi_dev_put(sensor);
+
+ return ret;
+}
diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
index d14944ee8586..53270d19c73a 100644
--- a/drivers/platform/x86/intel/int3472/common.h
+++ b/drivers/platform/x86/intel/int3472/common.h
@@ -108,6 +108,9 @@ struct int3472_discrete_device {
union acpi_object *skl_int3472_get_acpi_buffer(struct acpi_device *adev,
char *id);
int skl_int3472_fill_cldb(struct acpi_device *adev, struct int3472_cldb *cldb);
+int skl_int3472_get_sensor_adev_and_name(struct device *dev,
+ struct acpi_device **sensor_adev_ret,
+ const char **name_ret);
int skl_int3472_register_clock(struct int3472_discrete_device *int3472);
void skl_int3472_unregister_clock(struct int3472_discrete_device *int3472);
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index d2e8a87a077e..ff2bdbb8722c 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -363,19 +363,10 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev)
int3472->dev = &pdev->dev;
platform_set_drvdata(pdev, int3472);
- int3472->sensor = acpi_dev_get_first_consumer_dev(adev);
- if (!int3472->sensor) {
- dev_err(&pdev->dev, "INT3472 seems to have no dependents.\n");
- return -ENODEV;
- }
-
- int3472->sensor_name = devm_kasprintf(int3472->dev, GFP_KERNEL,
- I2C_DEV_NAME_FORMAT,
- acpi_dev_name(int3472->sensor));
- if (!int3472->sensor_name) {
- ret = -ENOMEM;
- goto err_put_sensor;
- }
+ ret = skl_int3472_get_sensor_adev_and_name(&pdev->dev, &int3472->sensor,
+ &int3472->sensor_name);
+ if (ret)
+ return ret;
/*
* Initialising this list means we can call gpiod_remove_lookup_table()
@@ -390,11 +381,6 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev)
}
return 0;
-
-err_put_sensor:
- acpi_dev_put(int3472->sensor);
-
- return ret;
}
static int skl_int3472_discrete_remove(struct platform_device *pdev)
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 09/11] platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (7 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 08/11] platform/x86: int3472: Add get_sensor_adev_and_name() helper Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data " Hans de Goede
` (2 subsequent siblings)
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell,
so that sensors which use the TPS68470 can find their clock.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v5:
- Add TPS68470_WIN_MFD_CELL_COUNT define
Changes in v4:
- Update the comment about the cell ordering
Changes in v2:
- Put the GPIO cell last because acpi_gpiochip_add() calls
acpi_dev_clear_dependencies() and the clk + regulators must
be ready when this happens.
---
drivers/platform/x86/intel/int3472/tps68470.c | 35 +++++++++++++++----
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index e95b0f50b384..05fcf35c1662 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -5,6 +5,7 @@
#include <linux/mfd/core.h>
#include <linux/mfd/tps68470.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/tps68470.h>
#include <linux/regmap.h>
#include "common.h"
@@ -12,17 +13,13 @@
#define DESIGNED_FOR_CHROMEOS 1
#define DESIGNED_FOR_WINDOWS 2
+#define TPS68470_WIN_MFD_CELL_COUNT 3
+
static const struct mfd_cell tps68470_cros[] = {
{ .name = "tps68470-gpio" },
{ .name = "tps68470_pmic_opregion" },
};
-static const struct mfd_cell tps68470_win[] = {
- { .name = "tps68470-gpio" },
- { .name = "tps68470-clk" },
- { .name = "tps68470-regulator" },
-};
-
static const struct regmap_config tps68470_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -105,10 +102,17 @@ static int skl_int3472_tps68470_calc_type(struct acpi_device *adev)
static int skl_int3472_tps68470_probe(struct i2c_client *client)
{
struct acpi_device *adev = ACPI_COMPANION(&client->dev);
+ struct tps68470_clk_platform_data clk_pdata = {};
+ struct mfd_cell *cells;
struct regmap *regmap;
int device_type;
int ret;
+ ret = skl_int3472_get_sensor_adev_and_name(&client->dev, NULL,
+ &clk_pdata.consumer_dev_name);
+ if (ret)
+ return ret;
+
regmap = devm_regmap_init_i2c(client, &tps68470_regmap_config);
if (IS_ERR(regmap)) {
dev_err(&client->dev, "Failed to create regmap: %ld\n", PTR_ERR(regmap));
@@ -126,9 +130,26 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
device_type = skl_int3472_tps68470_calc_type(adev);
switch (device_type) {
case DESIGNED_FOR_WINDOWS:
+ cells = kcalloc(TPS68470_WIN_MFD_CELL_COUNT, sizeof(*cells), GFP_KERNEL);
+ if (!cells)
+ return -ENOMEM;
+
+ /*
+ * The order of the cells matters here! The clk must be first
+ * because the regulator depends on it. The gpios must be last,
+ * acpi_gpiochip_add() calls acpi_dev_clear_dependencies() and
+ * the clk + regulators must be ready when this happens.
+ */
+ cells[0].name = "tps68470-clk";
+ cells[0].platform_data = &clk_pdata;
+ cells[0].pdata_size = sizeof(clk_pdata);
+ cells[1].name = "tps68470-regulator";
+ cells[2].name = "tps68470-gpio";
+
ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
- tps68470_win, ARRAY_SIZE(tps68470_win),
+ cells, TPS68470_WIN_MFD_CELL_COUNT,
NULL, 0, NULL);
+ kfree(cells);
break;
case DESIGNED_FOR_CHROMEOS:
ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (8 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 09/11] platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 14:34 ` Andy Shevchenko
2021-11-02 9:49 ` [PATCH v5 11/11] platform/x86: int3472: Deal with probe ordering issues Hans de Goede
2021-11-02 14:37 ` [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Andy Shevchenko
11 siblings, 1 reply; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
Pass tps68470_regulator_platform_data to the tps68470-regulator
MFD-cell, specifying the voltages of the various regulators and
tying the regulators to the sensor supplies so that sensors which use
the TPS68470 can find their regulators.
Since the voltages and supply connections are board-specific, this
introduces a DMI matches int3472_tps68470_board_data struct which
contains the necessary per-board info.
This per-board info also includes GPIO lookup information for the
sensor IO lines which may be connected to the tps68470 GPIOs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v5:
- Also pass regulator_init_data for the regulator used for the VCM
(Voice Coil Motor) used for the focus of the back-camera lens
---
drivers/platform/x86/intel/int3472/Makefile | 2 +-
drivers/platform/x86/intel/int3472/tps68470.c | 28 ++++
drivers/platform/x86/intel/int3472/tps68470.h | 25 ++++
.../x86/intel/int3472/tps68470_board_data.c | 134 ++++++++++++++++++
4 files changed, 188 insertions(+), 1 deletion(-)
create mode 100644 drivers/platform/x86/intel/int3472/tps68470.h
create mode 100644 drivers/platform/x86/intel/int3472/tps68470_board_data.c
diff --git a/drivers/platform/x86/intel/int3472/Makefile b/drivers/platform/x86/intel/int3472/Makefile
index 771e720528a0..cfec7784c5c9 100644
--- a/drivers/platform/x86/intel/int3472/Makefile
+++ b/drivers/platform/x86/intel/int3472/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_INTEL_SKL_INT3472) += intel_skl_int3472_discrete.o \
intel_skl_int3472_tps68470.o
intel_skl_int3472_discrete-y := discrete.o clk_and_regulator.o common.o
-intel_skl_int3472_tps68470-y := tps68470.o common.o
+intel_skl_int3472_tps68470-y := tps68470.o tps68470_board_data.o common.o
diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index 05fcf35c1662..49eea7bb98c1 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -9,6 +9,7 @@
#include <linux/regmap.h>
#include "common.h"
+#include "tps68470.h"
#define DESIGNED_FOR_CHROMEOS 1
#define DESIGNED_FOR_WINDOWS 2
@@ -102,6 +103,7 @@ static int skl_int3472_tps68470_calc_type(struct acpi_device *adev)
static int skl_int3472_tps68470_probe(struct i2c_client *client)
{
struct acpi_device *adev = ACPI_COMPANION(&client->dev);
+ const struct int3472_tps68470_board_data *board_data;
struct tps68470_clk_platform_data clk_pdata = {};
struct mfd_cell *cells;
struct regmap *regmap;
@@ -130,6 +132,12 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
device_type = skl_int3472_tps68470_calc_type(adev);
switch (device_type) {
case DESIGNED_FOR_WINDOWS:
+ board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
+ if (!board_data) {
+ dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
+ return -ENODEV;
+ }
+
cells = kcalloc(TPS68470_WIN_MFD_CELL_COUNT, sizeof(*cells), GFP_KERNEL);
if (!cells)
return -ENOMEM;
@@ -144,12 +152,20 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
cells[0].platform_data = &clk_pdata;
cells[0].pdata_size = sizeof(clk_pdata);
cells[1].name = "tps68470-regulator";
+ cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
+ cells[1].pdata_size = sizeof(struct tps68470_regulator_platform_data);
cells[2].name = "tps68470-gpio";
+ gpiod_add_lookup_table(board_data->tps68470_gpio_lookup_table);
+
ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
cells, TPS68470_WIN_MFD_CELL_COUNT,
NULL, 0, NULL);
kfree(cells);
+
+ if (ret)
+ gpiod_remove_lookup_table(board_data->tps68470_gpio_lookup_table);
+
break;
case DESIGNED_FOR_CHROMEOS:
ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
@@ -164,6 +180,17 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
return ret;
}
+static int skl_int3472_tps68470_remove(struct i2c_client *client)
+{
+ const struct int3472_tps68470_board_data *board_data;
+
+ board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
+ if (board_data)
+ gpiod_remove_lookup_table(board_data->tps68470_gpio_lookup_table);
+
+ return 0;
+}
+
static const struct acpi_device_id int3472_device_id[] = {
{ "INT3472", 0 },
{ }
@@ -176,6 +203,7 @@ static struct i2c_driver int3472_tps68470 = {
.acpi_match_table = int3472_device_id,
},
.probe_new = skl_int3472_tps68470_probe,
+ .remove = skl_int3472_tps68470_remove,
};
module_i2c_driver(int3472_tps68470);
diff --git a/drivers/platform/x86/intel/int3472/tps68470.h b/drivers/platform/x86/intel/int3472/tps68470.h
new file mode 100644
index 000000000000..cfd33eb62740
--- /dev/null
+++ b/drivers/platform/x86/intel/int3472/tps68470.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI TPS68470 PMIC platform data definition.
+ *
+ * Copyright (c) 2021 Red Hat Inc.
+ *
+ * Red Hat authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#ifndef _INTEL_SKL_INT3472_TPS68470_H
+#define _INTEL_SKL_INT3472_TPS68470_H
+
+struct gpiod_lookup_table;
+struct tps68470_regulator_platform_data;
+
+struct int3472_tps68470_board_data {
+ const char *dev_name;
+ struct gpiod_lookup_table *tps68470_gpio_lookup_table;
+ const struct tps68470_regulator_platform_data *tps68470_regulator_pdata;
+};
+
+const struct int3472_tps68470_board_data *int3472_tps68470_get_board_data(const char *dev_name);
+
+#endif
diff --git a/drivers/platform/x86/intel/int3472/tps68470_board_data.c b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
new file mode 100644
index 000000000000..20615c342875
--- /dev/null
+++ b/drivers/platform/x86/intel/int3472/tps68470_board_data.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI TPS68470 PMIC platform data definition.
+ *
+ * Copyright (c) 2021 Dan Scally <djrscally@gmail.com>
+ * Copyright (c) 2021 Red Hat Inc.
+ *
+ * Red Hat authors:
+ * Hans de Goede <hdegoede@redhat.com>
+ */
+
+#include <linux/dmi.h>
+#include <linux/gpio/machine.h>
+#include <linux/platform_data/tps68470.h>
+#include <linux/regulator/machine.h>
+#include "tps68470.h"
+
+static struct regulator_consumer_supply int347a_core_consumer_supplies[] = {
+ REGULATOR_SUPPLY("dvdd", "i2c-INT347A:00"),
+};
+
+static struct regulator_consumer_supply int347a_ana_consumer_supplies[] = {
+ REGULATOR_SUPPLY("avdd", "i2c-INT347A:00"),
+};
+
+static struct regulator_consumer_supply int347a_vcm_consumer_supplies[] = {
+ REGULATOR_SUPPLY("vdd", "i2c-INT347A:00-VCM"),
+};
+
+static struct regulator_consumer_supply int347a_vsio_consumer_supplies[] = {
+ REGULATOR_SUPPLY("dovdd", "i2c-INT347A:00"),
+};
+
+static const struct regulator_init_data surface_go_tps68470_core_reg_init_data = {
+ .constraints = {
+ .min_uV = 1200000,
+ .max_uV = 1200000,
+ .apply_uV = 1,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(int347a_core_consumer_supplies),
+ .consumer_supplies = int347a_core_consumer_supplies,
+};
+
+static const struct regulator_init_data surface_go_tps68470_ana_reg_init_data = {
+ .constraints = {
+ .min_uV = 2815200,
+ .max_uV = 2815200,
+ .apply_uV = 1,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(int347a_ana_consumer_supplies),
+ .consumer_supplies = int347a_ana_consumer_supplies,
+};
+
+static const struct regulator_init_data surface_go_tps68470_vcm_reg_init_data = {
+ .constraints = {
+ .min_uV = 2815200,
+ .max_uV = 2815200,
+ .apply_uV = 1,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(int347a_vcm_consumer_supplies),
+ .consumer_supplies = int347a_vcm_consumer_supplies,
+};
+
+static const struct regulator_init_data surface_go_tps68470_vsio_reg_init_data = {
+ .constraints = {
+ .min_uV = 1800600,
+ .max_uV = 1800600,
+ .apply_uV = 1,
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(int347a_vsio_consumer_supplies),
+ .consumer_supplies = int347a_vsio_consumer_supplies,
+};
+
+static const struct tps68470_regulator_platform_data surface_go_tps68470_pdata = {
+ .reg_init_data = {
+ [TPS68470_CORE] = &surface_go_tps68470_core_reg_init_data,
+ [TPS68470_ANA] = &surface_go_tps68470_ana_reg_init_data,
+ [TPS68470_VCM] = &surface_go_tps68470_vcm_reg_init_data,
+ [TPS68470_VSIO] = &surface_go_tps68470_vsio_reg_init_data,
+ },
+};
+
+static struct gpiod_lookup_table surface_go_tps68470_gpios = {
+ .dev_id = "i2c-INT347A:00",
+ .table = {
+ GPIO_LOOKUP("tps68470-gpio", 9, "reset", GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP("tps68470-gpio", 7, "powerdown", GPIO_ACTIVE_LOW)
+ }
+};
+
+static const struct int3472_tps68470_board_data surface_go_tps68470_board_data = {
+ .dev_name = "i2c-INT3472:05",
+ .tps68470_gpio_lookup_table = &surface_go_tps68470_gpios,
+ .tps68470_regulator_pdata = &surface_go_tps68470_pdata,
+};
+
+static const struct dmi_system_id int3472_tps68470_board_data_table[] = {
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Go"),
+ },
+ .driver_data = (void *)&surface_go_tps68470_board_data,
+ },
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Surface Go 2"),
+ },
+ .driver_data = (void *)&surface_go_tps68470_board_data,
+ },
+ { }
+};
+
+const struct int3472_tps68470_board_data *int3472_tps68470_get_board_data(const char *dev_name)
+{
+ const struct int3472_tps68470_board_data *board_data;
+ const struct dmi_system_id *match;
+
+ match = dmi_first_match(int3472_tps68470_board_data_table);
+ while (match) {
+ board_data = match->driver_data;
+ if (strcmp(board_data->dev_name, dev_name) == 0)
+ return board_data;
+
+ dmi_first_match(++match);
+ }
+
+ return NULL;
+}
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 9:49 ` [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data " Hans de Goede
@ 2021-11-02 14:34 ` Andy Shevchenko
2021-11-02 14:59 ` Hans de Goede
0 siblings, 1 reply; 43+ messages in thread
From: Andy Shevchenko @ 2021-11-02 14:34 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Pass tps68470_regulator_platform_data to the tps68470-regulator
> MFD-cell, specifying the voltages of the various regulators and
> tying the regulators to the sensor supplies so that sensors which use
> the TPS68470 can find their regulators.
>
> Since the voltages and supply connections are board-specific, this
> introduces a DMI matches int3472_tps68470_board_data struct which
> contains the necessary per-board info.
>
> This per-board info also includes GPIO lookup information for the
> sensor IO lines which may be connected to the tps68470 GPIOs.
...
> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
> + if (!board_data) {
> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
> + return -ENODEV;
It's fine to use dev_err_probe() for known error codes.
> + }
...
> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
Do we need casting?
...
> +#include <linux/dmi.h>
> +#include <linux/gpio/machine.h>
> +#include <linux/platform_data/tps68470.h>
> +#include <linux/regulator/machine.h>
string.h for strcmp() ?
kernel.h for ARRAY_SIZE() ?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 14:34 ` Andy Shevchenko
@ 2021-11-02 14:59 ` Hans de Goede
2021-11-02 15:52 ` Andy Shevchenko
2021-11-02 16:17 ` Sakari Ailus
0 siblings, 2 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 14:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
Hi,
On 11/2/21 15:34, Andy Shevchenko wrote:
> On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Pass tps68470_regulator_platform_data to the tps68470-regulator
>> MFD-cell, specifying the voltages of the various regulators and
>> tying the regulators to the sensor supplies so that sensors which use
>> the TPS68470 can find their regulators.
>>
>> Since the voltages and supply connections are board-specific, this
>> introduces a DMI matches int3472_tps68470_board_data struct which
>> contains the necessary per-board info.
>>
>> This per-board info also includes GPIO lookup information for the
>> sensor IO lines which may be connected to the tps68470 GPIOs.
>
> ...
>
>> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
>> + if (!board_data) {
>> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
>> + return -ENODEV;
>
> It's fine to use dev_err_probe() for known error codes.
>
>> + }
>
> ...
>
>> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
>
> Do we need casting?
Yes, the cast casts away a "const", the const is correct
since the data only ever gets read by the regulator driver,
but platform_data pointers are normally not const, so it
is either the cast, or loose the const on the definition
of the struct to which board_data->tps68470_regulator_pdata
points...
So not good choice here really, only chosing between bad
options and I picked the lets do the cast "least worse"
option (at least to me). I'm open to changing this.
> ...
>
>> +#include <linux/dmi.h>
>> +#include <linux/gpio/machine.h>
>> +#include <linux/platform_data/tps68470.h>
>> +#include <linux/regulator/machine.h>
>
> string.h for strcmp() ?
> kernel.h for ARRAY_SIZE() ?
Ack.
Regards,
Hans
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 14:59 ` Hans de Goede
@ 2021-11-02 15:52 ` Andy Shevchenko
2021-11-02 16:11 ` Hans de Goede
2021-11-02 16:17 ` Sakari Ailus
1 sibling, 1 reply; 43+ messages in thread
From: Andy Shevchenko @ 2021-11-02 15:52 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 2, 2021 at 4:59 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 11/2/21 15:34, Andy Shevchenko wrote:
> > On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
...
> >> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
> >> + if (!board_data) {
> >> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
> >> + return -ENODEV;
> >
> > It's fine to use dev_err_probe() for known error codes.
> >
> >> + }
> >
> > ...
> >
> >> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
> >
> > Do we need casting?
>
> Yes, the cast casts away a "const", the const is correct
> since the data only ever gets read by the regulator driver,
> but platform_data pointers are normally not const, so it
> is either the cast, or loose the const on the definition
> of the struct to which board_data->tps68470_regulator_pdata
> points...
>
> So not good choice here really, only chosing between bad
> options and I picked the lets do the cast "least worse"
> option (at least to me). I'm open to changing this.
Hmm... Okay, I was under the impression that MFD is using const for
that field...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 15:52 ` Andy Shevchenko
@ 2021-11-02 16:11 ` Hans de Goede
0 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 16:11 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
Hi,
On 11/2/21 16:52, Andy Shevchenko wrote:
> On Tue, Nov 2, 2021 at 4:59 PM Hans de Goede <hdegoede@redhat.com> wrote:
>> On 11/2/21 15:34, Andy Shevchenko wrote:
>>> On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> ...
>
>>>> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
>>>> + if (!board_data) {
>>>> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
>>>> + return -ENODEV;
>>>
>>> It's fine to use dev_err_probe() for known error codes.
>>>
>>>> + }
>>>
>>> ...
>>>
>>>> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
>>>
>>> Do we need casting?
>>
>> Yes, the cast casts away a "const", the const is correct
>> since the data only ever gets read by the regulator driver,
>> but platform_data pointers are normally not const, so it
>> is either the cast, or loose the const on the definition
>> of the struct to which board_data->tps68470_regulator_pdata
>> points...
>>
>> So not good choice here really, only chosing between bad
>> options and I picked the lets do the cast "least worse"
>> option (at least to me). I'm open to changing this.
>
> Hmm... Okay, I was under the impression that MFD is using const for
> that field...
Nope, I just double-checked and it is a plain "void *"
Regards,
Hans
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 14:59 ` Hans de Goede
2021-11-02 15:52 ` Andy Shevchenko
@ 2021-11-02 16:17 ` Sakari Ailus
2021-11-02 16:35 ` Hans de Goede
1 sibling, 1 reply; 43+ messages in thread
From: Sakari Ailus @ 2021-11-02 16:17 UTC (permalink / raw)
To: Hans de Goede
Cc: Andy Shevchenko, Rafael J . Wysocki, Mark Gross, Andy Shevchenko,
Wolfram Sang, Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 02, 2021 at 03:59:41PM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/2/21 15:34, Andy Shevchenko wrote:
> > On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Pass tps68470_regulator_platform_data to the tps68470-regulator
> >> MFD-cell, specifying the voltages of the various regulators and
> >> tying the regulators to the sensor supplies so that sensors which use
> >> the TPS68470 can find their regulators.
> >>
> >> Since the voltages and supply connections are board-specific, this
> >> introduces a DMI matches int3472_tps68470_board_data struct which
> >> contains the necessary per-board info.
> >>
> >> This per-board info also includes GPIO lookup information for the
> >> sensor IO lines which may be connected to the tps68470 GPIOs.
> >
> > ...
> >
> >> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
> >> + if (!board_data) {
> >> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
> >> + return -ENODEV;
> >
> > It's fine to use dev_err_probe() for known error codes.
> >
> >> + }
> >
> > ...
> >
> >> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
> >
> > Do we need casting?
>
> Yes, the cast casts away a "const", the const is correct
> since the data only ever gets read by the regulator driver,
> but platform_data pointers are normally not const, so it
> is either the cast, or loose the const on the definition
> of the struct to which board_data->tps68470_regulator_pdata
> points...
>
> So not good choice here really, only chosing between bad
> options and I picked the lets do the cast "least worse"
> option (at least to me). I'm open to changing this.
Maybe a comment explaining this briefly?
--
Sakari Ailus
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell
2021-11-02 16:17 ` Sakari Ailus
@ 2021-11-02 16:35 ` Hans de Goede
0 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 16:35 UTC (permalink / raw)
To: Sakari Ailus
Cc: Andy Shevchenko, Rafael J . Wysocki, Mark Gross, Andy Shevchenko,
Wolfram Sang, Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Kate Hsuan,
Linux Media Mailing List, linux-clk
Hi,
On 11/2/21 17:17, Sakari Ailus wrote:
> On Tue, Nov 02, 2021 at 03:59:41PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/2/21 15:34, Andy Shevchenko wrote:
>>> On Tue, Nov 2, 2021 at 11:50 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Pass tps68470_regulator_platform_data to the tps68470-regulator
>>>> MFD-cell, specifying the voltages of the various regulators and
>>>> tying the regulators to the sensor supplies so that sensors which use
>>>> the TPS68470 can find their regulators.
>>>>
>>>> Since the voltages and supply connections are board-specific, this
>>>> introduces a DMI matches int3472_tps68470_board_data struct which
>>>> contains the necessary per-board info.
>>>>
>>>> This per-board info also includes GPIO lookup information for the
>>>> sensor IO lines which may be connected to the tps68470 GPIOs.
>>>
>>> ...
>>>
>>>> + board_data = int3472_tps68470_get_board_data(dev_name(&client->dev));
>>>> + if (!board_data) {
>>>> + dev_err(&client->dev, "No board-data found for this laptop/tablet model\n");
>>>> + return -ENODEV;
>>>
>>> It's fine to use dev_err_probe() for known error codes.
>>>
>>>> + }
>>>
>>> ...
>>>
>>>> + cells[1].platform_data = (void *)board_data->tps68470_regulator_pdata;
>>>
>>> Do we need casting?
>>
>> Yes, the cast casts away a "const", the const is correct
>> since the data only ever gets read by the regulator driver,
>> but platform_data pointers are normally not const, so it
>> is either the cast, or loose the const on the definition
>> of the struct to which board_data->tps68470_regulator_pdata
>> points...
>>
>> So not good choice here really, only chosing between bad
>> options and I picked the lets do the cast "least worse"
>> option (at least to me). I'm open to changing this.
>
> Maybe a comment explaining this briefly?
Yes, I was thinking the same myself, I'll add this for the
next version (which I expect to be the final version).
Regards,
Hans
^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH v5 11/11] platform/x86: int3472: Deal with probe ordering issues
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (9 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data " Hans de Goede
@ 2021-11-02 9:49 ` Hans de Goede
2021-11-02 14:37 ` [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Andy Shevchenko
11 siblings, 0 replies; 43+ messages in thread
From: Hans de Goede @ 2021-11-02 9:49 UTC (permalink / raw)
To: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd
Cc: Hans de Goede, Len Brown, linux-acpi, platform-driver-x86,
linux-kernel, linux-i2c, Sakari Ailus, Kate Hsuan, linux-media,
linux-clk
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 this info missing from the ACPI tables on devices where
the int3472 driver is used, the int3472 MFD-cell drivers 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.
All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI
fw-node, so to work around these probe ordering issues the ACPI core /
i2c-code does not instantiate the I2C-clients for any ACPI devices
which have a _DEP dependency on an INT3472 ACPI device until all
_DEP-s are met.
This relies on acpi_dev_clear_dependencies() getting called by the driver
for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies()
call to the discrete.c probe code.
In the tps68470 case calling acpi_dev_clear_dependencies() is already done
by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell
(The GPIO cell is deliberately the last cell created to make sure the
clk + regulator cells are already instantiated when this happens).
However for proper probe ordering, the clk/regulator cells must not just
be instantiated the must be fully ready (the clks + regulators must be
registered with their subsystems).
Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for
the instantiated MFD-cells so that these are loaded before us and so
that they bind immediately when the platform-devs are instantiated.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Only call acpi_dev_clear_dependencies() in the discrete.c case, for the
tps68470 case this is already done by the acpi_gpiochip_add() for the
GPIO MFD cell.
---
drivers/platform/x86/intel/int3472/discrete.c | 1 +
drivers/platform/x86/intel/int3472/tps68470.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index ff2bdbb8722c..5b514fa01a97 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -380,6 +380,7 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev)
return ret;
}
+ acpi_dev_clear_dependencies(adev);
return 0;
}
diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c
index 49eea7bb98c1..5232dbcd8212 100644
--- a/drivers/platform/x86/intel/int3472/tps68470.c
+++ b/drivers/platform/x86/intel/int3472/tps68470.c
@@ -177,6 +177,11 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client)
return device_type;
}
+ /*
+ * No acpi_dev_clear_dependencies() here, since the acpi_gpiochip_add()
+ * for the GPIO cell already does this.
+ */
+
return ret;
}
@@ -210,3 +215,4 @@ module_i2c_driver(int3472_tps68470);
MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI TPS68470 Device Driver");
MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("pre: clk-tps68470 tps68470-regulator");
--
2.31.1
^ permalink raw reply related [flat|nested] 43+ messages in thread* Re: [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
` (10 preceding siblings ...)
2021-11-02 9:49 ` [PATCH v5 11/11] platform/x86: int3472: Deal with probe ordering issues Hans de Goede
@ 2021-11-02 14:37 ` Andy Shevchenko
11 siblings, 0 replies; 43+ messages in thread
From: Andy Shevchenko @ 2021-11-02 14:37 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Mark Gross, Andy Shevchenko, Wolfram Sang,
Mika Westerberg, Daniel Scally, Laurent Pinchart,
Mauro Carvalho Chehab, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Len Brown,
ACPI Devel Maling List, Platform Driver,
Linux Kernel Mailing List, linux-i2c, Sakari Ailus, Kate Hsuan,
Linux Media Mailing List, linux-clk
On Tue, Nov 2, 2021 at 11:49 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Here is v5 of my patch-set adding support for camera sensor connected to a
> TPS68470 PMIC on x86/ACPI devices.
No showstoppers observed, FWIW,
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> I'm quite happy with how this works now, so from my pov this is the final
> version of the device-instantiation deferral code / approach.
>
> ###
>
> 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, but on ACPI this info is missing.
>
> This series worksaround this by providing platform_data with the info to
> the TPS68470 clk/regulator MFD cells.
>
> Patches 1 - 2 deal with a probe-ordering problem this introduces,
> 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. See the patches
> for more details.
>
> Patch 3 adds a header file which adds tps68470_clk_platform_data and
> tps68470_regulator_platform_data structs. The futher patches depend on
> this new header file.
>
> Patch 4 + 5 add the TPS68470 clk and regulator drivers
>
> Patches 6 - 11 Modify the INT3472 driver which instantiates the MFD cells to
> provide the necessary platform-data.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2017-11-13 14:55 Amos Kalonzo
0 siblings, 0 replies; 43+ messages in thread
From: Amos Kalonzo @ 2017-11-13 14:55 UTC (permalink / raw)
Attn:
I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.
Best Regards
Amos Kalonzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2017-05-03 6:23 H.A
0 siblings, 0 replies; 43+ messages in thread
From: H.A @ 2017-05-03 6:23 UTC (permalink / raw)
To: Recipients
With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention..........
S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.
Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete.
HELINA .A ROBERTS
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply [flat|nested] 43+ messages in thread
* RE:
@ 2017-02-23 15:09 Qin's Yanjun
0 siblings, 0 replies; 43+ messages in thread
From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw)
How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which. Looking forward to read from you soon.
Qin's
______________________________
Sky Silk, http://aknet.kz
^ permalink raw reply [flat|nested] 43+ messages in thread
* (unknown),
@ 2013-12-21 16:48 Alex Barattini
2013-12-23 1:44 ` Aaron Lu
0 siblings, 1 reply; 43+ messages in thread
From: Alex Barattini @ 2013-12-21 16:48 UTC (permalink / raw)
To: linux-acpi
[1.] One line summary of the problem:
8086:0166 [Dell Inspiron 15R 5521] Impossible to adjust the screen backlight
[2.] Full description of the problem/report:
The change in the level of illumination of the screen, through the
corresponding option in the control panel, has no effect.
[3.] Keywords :
---------------
[4.] Kernel version (from /proc/version):
Linux version 3.13.0-031300rc3-generic (apw@gomeisa) (gcc version
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201312061335 SMP Fri Dec 6
18:37:23 UTC 2013
[5.] Output of Oops.. message (if applicable) with symbolic
information resolved (see Documentation/oops-tracing.txt)
-------------
[6.] A small shell script or example program which triggers the
problem (if possible)
-------------
[7.] Environment
Description: Ubuntu 13.10
Release: 13.10
[7.1.] Software (add the output of the ver_linux script here)
alex@alex-Inspiron-5521:/usr/src/linux-headers-3.13.0-031300rc3/scripts$
sh ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux alex-Inspiron-5521 3.13.0-031300rc3-generic #201312061335 SMP
Fri Dec 6 18:37:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Gnu C 4.8
Gnu make 3.81
binutils 2.23.52.20130913
util-linux 2.20.1
mount support
module-init-tools 9
e2fsprogs 1.42.8
pcmciautils 018
PPP 2.4.5
Linux C Library 2.17
Dynamic linker (ldd) 2.17
Procps 3.3.3
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.20
wireless-tools 30
Modules Loaded nls_utf8 isofs parport_pc ppdev rfcomm bnep
nls_iso8859_1 x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel
kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
aes_x86_64 uvcvideo lrw gf128mul arc4 joydev iwldvm videobuf2_vmalloc
glue_helper videobuf2_memops mac80211 videobuf2_core rts5139 i915
videodev ablk_helper cryptd dell_laptop dell_wmi dcdbas sparse_keymap
snd_hda_codec_hdmi snd_hda_codec_realtek drm_kms_helper snd_hda_intel
snd_hda_codec drm iwlwifi snd_hwdep snd_pcm snd_page_alloc
snd_seq_midi snd_seq_midi_event snd_rawmidi btusb snd_seq
snd_seq_device microcode snd_timer lp mei_me lpc_ich snd cfg80211
bluetooth parport psmouse mei video serio_raw i2c_algo_bit wmi
soundcore mac_hid ahci libahci r8169 mii
[7.2.] Processor information (from /proc/cpuinfo):
alex@alex-Inspiron-5521:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
stepping : 9
microcode : 0x17
cpu MHz : 1875.515
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 3591.92
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
stepping : 9
microcode : 0x17
cpu MHz : 1112.765
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 3591.92
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
stepping : 9
microcode : 0x17
cpu MHz : 1331.367
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 3591.92
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 58
model name : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
stepping : 9
microcode : 0x17
cpu MHz : 2486.250
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips : 3591.92
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[7.3.] Module information (from /proc/modules):
alex@alex-Inspiron-5521:~$ cat /proc/modules
nls_utf8 12557 1 - Live 0x0000000000000000
isofs 40285 1 - Live 0x0000000000000000
parport_pc 36962 0 - Live 0x0000000000000000
ppdev 17711 0 - Live 0x0000000000000000
rfcomm 74748 12 - Live 0x0000000000000000
bnep 19884 2 - Live 0x0000000000000000
nls_iso8859_1 12713 1 - Live 0x0000000000000000
x86_pkg_temp_thermal 14269 0 - Live 0x0000000000000000
intel_powerclamp 19031 0 - Live 0x0000000000000000
coretemp 17728 0 - Live 0x0000000000000000
kvm_intel 144426 0 - Live 0x0000000000000000
kvm 468147 1 kvm_intel, Live 0x0000000000000000
crct10dif_pclmul 14250 0 - Live 0x0000000000000000
crc32_pclmul 13160 0 - Live 0x0000000000000000
ghash_clmulni_intel 13259 0 - Live 0x0000000000000000
aesni_intel 55720 0 - Live 0x0000000000000000
aes_x86_64 17131 1 aesni_intel, Live 0x0000000000000000
uvcvideo 82247 0 - Live 0x0000000000000000
lrw 13323 1 aesni_intel, Live 0x0000000000000000
gf128mul 14951 1 lrw, Live 0x0000000000000000
arc4 12573 2 - Live 0x0000000000000000
joydev 17575 0 - Live 0x0000000000000000
iwldvm 243417 0 - Live 0x0000000000000000
videobuf2_vmalloc 13216 1 uvcvideo, Live 0x0000000000000000
glue_helper 14095 1 aesni_intel, Live 0x0000000000000000
videobuf2_memops 13362 1 videobuf2_vmalloc, Live 0x0000000000000000
mac80211 654078 1 iwldvm, Live 0x0000000000000000
videobuf2_core 40972 1 uvcvideo, Live 0x0000000000000000
rts5139 318332 0 - Live 0x0000000000000000 (C)
i915 816671 4 - Live 0x0000000000000000
videodev 139761 2 uvcvideo,videobuf2_core, Live 0x0000000000000000
ablk_helper 13597 1 aesni_intel, Live 0x0000000000000000
cryptd 20530 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live
0x0000000000000000
dell_laptop 18315 0 - Live 0x0000000000000000
dell_wmi 12681 0 - Live 0x0000000000000000
dcdbas 15017 1 dell_laptop, Live 0x0000000000000000
sparse_keymap 13890 1 dell_wmi, Live 0x0000000000000000
snd_hda_codec_hdmi 46898 1 - Live 0x0000000000000000
snd_hda_codec_realtek 61978 1 - Live 0x0000000000000000
drm_kms_helper 53224 1 i915, Live 0x0000000000000000
snd_hda_intel 57222 3 - Live 0x0000000000000000
snd_hda_codec 195017 3
snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel, Live
0x0000000000000000
drm 308397 5 i915,drm_kms_helper, Live 0x0000000000000000
iwlwifi 179643 1 iwldvm, Live 0x0000000000000000
snd_hwdep 13613 1 snd_hda_codec, Live 0x0000000000000000
snd_pcm 107140 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec, Live
0x0000000000000000
snd_page_alloc 18798 2 snd_hda_intel,snd_pcm, Live 0x0000000000000000
snd_seq_midi 13324 0 - Live 0x0000000000000000
snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
snd_rawmidi 30465 1 snd_seq_midi, Live 0x0000000000000000
btusb 28326 0 - Live 0x0000000000000000
snd_seq 66061 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000
microcode 23788 0 - Live 0x0000000000000000
snd_timer 30038 2 snd_pcm,snd_seq, Live 0x0000000000000000
lp 17799 0 - Live 0x0000000000000000
mei_me 18578 0 - Live 0x0000000000000000
lpc_ich 21163 0 - Live 0x0000000000000000
snd 73850 17 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_seq_midi,snd_rawmidi,snd_seq,snd_seq_device,snd_timer,
Live 0x0000000000000000
cfg80211 509407 3 iwldvm,mac80211,iwlwifi, Live 0x0000000000000000
bluetooth 411140 22 rfcomm,bnep,btusb, Live 0x0000000000000000
parport 42481 3 parport_pc,ppdev,lp, Live 0x0000000000000000
psmouse 104142 0 - Live 0x0000000000000000
mei 82671 1 mei_me, Live 0x0000000000000000
video 19859 1 i915, Live 0x0000000000000000
serio_raw 13462 0 - Live 0x0000000000000000
i2c_algo_bit 13564 1 i915, Live 0x0000000000000000
wmi 19363 1 dell_wmi, Live 0x0000000000000000
soundcore 12680 1 snd, Live 0x0000000000000000
mac_hid 13253 0 - Live 0x0000000000000000
ahci 30063 4 - Live 0x0000000000000000
libahci 32277 1 ahci, Live 0x0000000000000000
r8169 73299 0 - Live 0x0000000000000000
mii 13981 1 r8169, Live 0x0000000000000000
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
alex@alex-Inspiron-5521:~$ cat /proc/ioports
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC cmd
0070-0077 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-042f : ACPI GPE0_BLK
0430-0433 : iTCO_wdt
0450-0450 : ACPI PM2_CNT_BLK
0454-0457 : pnp 00:06
0458-047f : pnp 00:04
0460-047f : iTCO_wdt
0500-057f : pnp 00:04
0680-069f : pnp 00:04
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1000-100f : pnp 00:04
164e-164f : pnp 00:04
2000-2fff : PCI Bus 0000:01
2000-20ff : 0000:01:00.0
2000-20ff : r8169
3000-303f : 0000:00:02.0
3040-305f : 0000:00:1f.3
3060-307f : 0000:00:1f.2
3060-307f : ahci
3080-3087 : 0000:00:1f.2
3080-3087 : ahci
3088-308f : 0000:00:1f.2
3088-308f : ahci
3090-3093 : 0000:00:1f.2
3090-3093 : ahci
3094-3097 : 0000:00:1f.2
3094-3097 : ahci
fd60-fd63 : pnp 00:04
ffff-ffff : pnp 00:04
ffff-ffff : pnp 00:04
alex@alex-Inspiron-5521:~$ cat /proc/iomem
00000000-00000fff : reserved
00001000-00087fff : System RAM
00088000-000bffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000c3fff : PCI Bus 0000:00
000c4000-000c7fff : PCI Bus 0000:00
000c8000-000cbfff : PCI Bus 0000:00
000cc000-000cffff : PCI Bus 0000:00
000d0000-000d3fff : PCI Bus 0000:00
000d4000-000d7fff : PCI Bus 0000:00
000d8000-000dbfff : PCI Bus 0000:00
000dc000-000dffff : PCI Bus 0000:00
000e0000-000e3fff : PCI Bus 0000:00
000e4000-000e7fff : PCI Bus 0000:00
000e8000-000ebfff : PCI Bus 0000:00
000ec000-000effff : PCI Bus 0000:00
000f0000-000fffff : PCI Bus 0000:00
000f0000-000fffff : System ROM
00100000-1fffffff : System RAM
02000000-0277171d : Kernel code
0277171e-02d1bdbf : Kernel data
02e78000-02fdcfff : Kernel bss
20000000-201fffff : reserved
20000000-201fffff : pnp 00:0a
20200000-40003fff : System RAM
40004000-40004fff : reserved
40004000-40004fff : pnp 00:0a
40005000-a0baffff : System RAM
a0bb0000-a13affff : reserved
a13b0000-a9dbefff : System RAM
a9dbf000-aaebefff : reserved
aaebf000-aafbefff : ACPI Non-volatile Storage
aafbf000-aaffefff : ACPI Tables
aafff000-aaffffff : System RAM
ab000000-af9fffff : reserved
aba00000-af9fffff : Graphics Stolen Memory
afa00000-feafffff : PCI Bus 0000:00
afa00000-afa00fff : pnp 00:09
b0000000-bfffffff : 0000:00:02.0
b0000000-b0407fff : BOOTFB
c0000000-c03fffff : 0000:00:02.0
c0400000-c04fffff : PCI Bus 0000:01
c0400000-c0403fff : 0000:01:00.0
c0400000-c0403fff : r8169
c0404000-c0404fff : 0000:01:00.0
c0404000-c0404fff : r8169
c0500000-c05fffff : PCI Bus 0000:02
c0500000-c0501fff : 0000:02:00.0
c0500000-c0501fff : iwlwifi
c0600000-c060ffff : 0000:00:14.0
c0600000-c060ffff : xhci_hcd
c0610000-c0613fff : 0000:00:1b.0
c0610000-c0613fff : ICH HD audio
c0614000-c061400f : 0000:00:16.0
c0614000-c061400f : mei_me
c0615000-c06150ff : 0000:00:1f.3
c0617000-c06177ff : 0000:00:1f.2
c0617000-c06177ff : ahci
c0618000-c06183ff : 0000:00:1d.0
c0618000-c06183ff : ehci_hcd
c0619000-c06193ff : 0000:00:1a.0
c0619000-c06193ff : ehci_hcd
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : reserved
e0000000-efffffff : pnp 00:09
feb00000-feb03fff : reserved
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed10000-fed19fff : reserved
fed10000-fed17fff : pnp 00:09
fed18000-fed18fff : pnp 00:09
fed19000-fed19fff : pnp 00:09
fed1c000-fed1ffff : reserved
fed1c000-fed1ffff : pnp 00:09
fed1f410-fed1f414 : iTCO_wdt
fed20000-fed3ffff : pnp 00:09
fed90000-fed90fff : dmar0
fed91000-fed91fff : dmar1
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
ff000000-ff000fff : pnp 00:09
ffb80000-ffffffff : reserved
100000000-14f5fffff : System RAM
14f600000-14fffffff : RAM buffer
[7.5.] PCI information ('lspci -vvv' as root)
alex@alex-Inspiron-5521:~$ sudo lspci -vvv
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
Controller (rev 09)
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Dell Device 0597
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 48
Region 0: Memory at c0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at b0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 3000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00018 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at c0600000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000fee002f8 Data: 0000
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 (rev 04)
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory at c0614000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00378 Data: 0000
Kernel driver in use: mei_me
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at c0619000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 47
Region 0: Memory at c0610000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee003d8 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0
<64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive-
BWMgmt- ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=22
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB-
LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000c0400000-00000000c04fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Dell Device 0597
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 2 (rev c4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: c0500000-c05fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #1, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+ ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Dell Device 0597
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
Subsystem: Dell Device 0597
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at c0618000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC
Controller (rev 04)
Subsystem: Dell Device 0597
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: Dell Device 0597
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 44
Region 0: I/O ports at 3088 [size=8]
Region 1: I/O ports at 3094 [size=4]
Region 2: I/O ports at 3080 [size=8]
Region 3: I/O ports at 3090 [size=4]
Region 4: I/O ports at 3060 [size=32]
Region 5: Memory at c0617000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee00358 Data: 0000
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller (rev 04)
Subsystem: Dell Device 0597
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 0
Region 0: Memory at c0615000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 3040 [size=32]
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 05)
Subsystem: Dell Device 0597
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 43
Region 0: I/O ports at 2000 [size=256]
Region 2: Memory at c0404000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at c0400000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00318 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0
unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-,
Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 50-00-00-00-36-4c-e0-00
Kernel driver in use: r8169
02:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)
Subsystem: Intel Corporation Centrino Wireless-N 2230 BGN
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 46
Region 0: Memory at c0500000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee00398 Data: 0000
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 60-36-dd-ff-ff-cc-6b-6d
Kernel driver in use: iwlwifi
[7.6.] SCSI information (from /proc/scsi/scsi)
alex@alex-Inspiron-5521:~$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD10JPVT-75A Rev: 01.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: PLDS Model: DVD+-RW DU-8A5HH Rev: SD11
Type: CD-ROM ANSI SCSI revision: 05
Host: scsi6 Channel: 00 Id: 00 Lun: 00
Vendor: Generic- Model: xD/SD/M.S. Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 02
[7.7.] Other information that might be relevant to the problem (please
look in /proc and include all information that you think to be
relevant):
alex@alex-Inspiron-5521:~$ ls /proc
1 1372 1522 1827 2302 370 531 96 loadavg
10 1375 1523 1831 2312 371 54 97 locks
1053 1376 1524 1848 2314 376 56 acpi mdstat
1058 1381 1525 1856 24 377 57 asound meminfo
1063 1383 153 1858 2423 38 576 buddyinfo misc
1064 1386 154 1859 2427 386 58 bus modules
1068 1391 155 1863 2432 387 59 cgroups mounts
11 1396 1555 1885 2466 388 60 cmdline mtrr
1145 1397 157 189 25 39 61 consoles net
1149 1399 1574 1894 26 40 62 cpuinfo pagetypeinfo
1162 14 1579 19 2679 41 7 crypto partitions
1168 1406 1598 1900 2688 410 717 devices sched_debug
1185 1408 16 1901 2689 412 735 diskstats schedstat
1188 1443 160 1902 27 42 74 dma scsi
12 1464 1638 1908 2763 420 749 driver self
1209 1467 1639 1909 2766 43 752 execdomains slabinfo
1214 1469 1680 1930 2776 44 782 fb softirqs
1224 148 17 1938 28 45 796 filesystems stat
1225 149 172 1944 29 46 8 fs swaps
1239 1498 173 1965 297 466 822 interrupts sys
13 15 1785 2 3 47 824 iomem sysrq-trigger
1306 150 1787 20 304 476 831 ioports sysvipc
1310 1506 1788 2031 31 477 850 irq timer_list
1316 151 1789 2037 32 478 856 kallsyms timer_stats
1319 1510 1795 2054 33 49 860 kcore tty
1348 1511 18 21 34 5 865 key-users uptime
1351 1515 1800 22 341 50 870 kmsg version
1352 1517 1810 2213 35 51 872 kpagecount vmallocinfo
1354 1518 1814 2235 36 52 875 kpageflags vmstat
1368 152 1822 23 37 53 9 latency_stats zoneinfo
[X.] Other notes, patches, fixes, workarounds:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1261853
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH v3 7/8] ACPI, PCI: add hostbridge removal function
@ 2012-10-30 4:02 Bjorn Helgaas
2012-10-30 17:42 ` (unknown), Yinghai Lu
0 siblings, 1 reply; 43+ messages in thread
From: Bjorn Helgaas @ 2012-10-30 4:02 UTC (permalink / raw)
To: Taku Izumi; +Cc: linux-pci, linux-acpi, kaneshige.kenji, yinghai, jiang.liu
I think I'm missing patches 7/8 and 8/8 from this series. Can
you repost them to make sure I have the latest versions?
Note the comments below:
On Fri, Sep 28, 2012 at 06:46:27PM +0900, Taku Izumi wrote:
>
> Currently there's no PCI-related clean-up code
> in acpi_pci_root_remove() function.
> This patch introduces function for hostbridge removal,
> and brings back pci_stop_bus_devices() function.
>
> diff: rebased against current next
> updated according to Bjorn's comment
>
> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
> ---
> drivers/acpi/pci_bind.c | 7 +++++++
> drivers/acpi/pci_root.c | 6 ++++++
> drivers/pci/remove.c | 28 ++++++++++++++++++++++++++++
> include/acpi/acpi_drivers.h | 1 +
> include/linux/pci.h | 2 ++
> 5 files changed, 44 insertions(+)
>
> Index: Bjorn-next-0925-configchange/drivers/pci/remove.c
> ===================================================================
> --- Bjorn-next-0925-configchange.orig/drivers/pci/remove.c
> +++ Bjorn-next-0925-configchange/drivers/pci/remove.c
> @@ -111,3 +111,31 @@ void pci_stop_and_remove_bus_device(stru
> pci_remove_bus_device(dev);
> }
> EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
> +
> +void pci_stop_bus_devices(struct pci_bus *bus)
> +{
> + struct pci_dev *dev, *tmp;
> +
> + list_for_each_entry_safe_reverse(dev, tmp,
> + &bus->devices, bus_list) {
> + pci_stop_bus_device(dev);
> + }
> +
> +}
> +EXPORT_SYMBOL(pci_stop_bus_devices);
I'm hesitant to introduce pci_stop_bus_devices() again, particularly
when it is exported. The stop/remove split introduces the state where
devices are "stopped" but haven't been "removed" yet.
In this state, the driver .remove() method has been called, sysfs has
been cleaned up, and the struct device has been unregistered, but the
struct pci_dev itself still exists. Obviously, this state *must*
exist internally in the PCI core as we remove the PCI device.
The problem is that we have non-core code that *depends* on being
run while in this transitory state. I think this is a design mistake.
The code that depends on this state is basically just the stuff in the
acpi_pci_drivers list, namely, acpi_pci_hp_driver and acpi_pci_slot_driver.
I suspect that the main reason we have the acpi_pci_drivers list and the
whole acpi_pci_register_driver() infrastructure is so that these PCI
host bridge "sub-drivers" can be built as modules.
I don't think there's really any value in having these sub-drivers as
modules, and it leads to a lot of complication in the code. I'm pretty
sure that forcing them to be selected at build-time will let us make
things much simpler.
If we have to have pci_stop_bus_devices() as an interim measure, I can
live with it, but it doesn't need to be exported, does it?
> +void pci_remove_host_bridge(struct pci_host_bridge *bridge)
> +{
> + struct pci_bus *root = bridge->bus;
> + struct pci_dev *dev, *tmp;
> +
> + list_for_each_entry_safe_reverse(dev, tmp,
> + &root->devices, bus_list) {
> + pci_remove_bus_device(dev);
> + }
> +
> + pci_remove_bus(root);
> +
> + device_unregister(&bridge->dev);
> +}
> +EXPORT_SYMBOL(pci_remove_host_bridge);
> Index: Bjorn-next-0925-configchange/drivers/acpi/pci_root.c
> ===================================================================
> --- Bjorn-next-0925-configchange.orig/drivers/acpi/pci_root.c
> +++ Bjorn-next-0925-configchange/drivers/acpi/pci_root.c
> @@ -659,8 +659,10 @@ static int acpi_pci_root_remove(struct a
> {
> struct acpi_pci_root *root = acpi_driver_data(device);
> struct acpi_pci_driver *driver;
> + struct pci_host_bridge *bridge = to_pci_host_bridge(root->bus->bridge);
>
> mutex_lock(&acpi_pci_root_lock);
> + pci_stop_bus_devices(root->bus);
> list_for_each_entry(driver, &acpi_pci_drivers, node)
> if (driver->remove)
> driver->remove(root);
> @@ -668,6 +670,10 @@ static int acpi_pci_root_remove(struct a
> device_set_run_wake(root->bus->bridge, false);
> pci_acpi_remove_bus_pm_notifier(device);
>
> + acpi_pci_unbind_root(device);
> +
> + pci_remove_host_bridge(bridge);
> +
> list_del(&root->node);
> mutex_unlock(&acpi_pci_root_lock);
> kfree(root);
> Index: Bjorn-next-0925-configchange/include/linux/pci.h
> ===================================================================
> --- Bjorn-next-0925-configchange.orig/include/linux/pci.h
> +++ Bjorn-next-0925-configchange/include/linux/pci.h
> @@ -734,6 +734,8 @@ extern struct pci_dev *pci_dev_get(struc
> extern void pci_dev_put(struct pci_dev *dev);
> extern void pci_remove_bus(struct pci_bus *b);
> extern void pci_stop_and_remove_bus_device(struct pci_dev *dev);
> +extern void pci_stop_bus_devices(struct pci_bus *bus);
> +extern void pci_remove_host_bridge(struct pci_host_bridge *bridge);
> void pci_setup_cardbus(struct pci_bus *bus);
> extern void pci_sort_breadthfirst(void);
> #define dev_is_pci(d) ((d)->bus == &pci_bus_type)
> Index: Bjorn-next-0925-configchange/drivers/acpi/pci_bind.c
> ===================================================================
> --- Bjorn-next-0925-configchange.orig/drivers/acpi/pci_bind.c
> +++ Bjorn-next-0925-configchange/drivers/acpi/pci_bind.c
> @@ -118,3 +118,10 @@ int acpi_pci_bind_root(struct acpi_devic
>
> return 0;
> }
> +
> +void acpi_pci_unbind_root(struct acpi_device *device)
> +{
> + device->ops.bind = NULL;
> + device->ops.unbind = NULL;
> +}
> +
> Index: Bjorn-next-0925-configchange/include/acpi/acpi_drivers.h
> ===================================================================
> --- Bjorn-next-0925-configchange.orig/include/acpi/acpi_drivers.h
> +++ Bjorn-next-0925-configchange/include/acpi/acpi_drivers.h
> @@ -101,6 +101,7 @@ struct pci_bus;
>
> struct pci_dev *acpi_get_pci_dev(acpi_handle);
> int acpi_pci_bind_root(struct acpi_device *device);
> +void acpi_pci_unbind_root(struct acpi_device *device);
>
> /* Arch-defined function to add a bus to the system */
>
>
^ permalink raw reply [flat|nested] 43+ messages in thread* (unknown),
2012-10-30 4:02 [PATCH v3 7/8] ACPI, PCI: add hostbridge removal function Bjorn Helgaas
@ 2012-10-30 17:42 ` Yinghai Lu
2012-11-02 0:17 ` Rafael J. Wysocki
2012-11-06 5:03 ` Taku Izumi
0 siblings, 2 replies; 43+ messages in thread
From: Yinghai Lu @ 2012-10-30 17:42 UTC (permalink / raw)
To: Bjorn Helgaas, Len Brown, Taku Izumi, Jiang Liu
Cc: linux-pci, linux-acpi, Yinghai Lu
Subject: [PATCH resend 0/8] PCI, ACPI, x86: pci root bus hotplug support resources assign and remove path
1. add support for assign resource for hot add path.
2. stop and remove root bus during acpi root remove.
could get from
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-hotplug
Yinghai Lu (8):
PCI: Separate out pci_assign_unassigned_bus_resources()
PCI: Move pci_rescan_bus() back to probe.c
PCI: Move out pci_enable_bridges out of assign_unsigned_bus_res
PCI, ACPI: assign unassigned resource for hot add root bus
PCI: Add pci_stop/remove_root_bus()
PCI, ACPI: Make acpi_pci_root_remove stop/remove pci root bus
PCI, ACPI: delete root bus prt during hot remove path
PCI, ACPI: remove acpi_root_driver in reserse order
drivers/acpi/pci_root.c | 21 ++++++++++++++++++++-
drivers/pci/probe.c | 22 ++++++++++++++++++++++
drivers/pci/remove.c | 36 ++++++++++++++++++++++++++++++++++++
drivers/pci/setup-bus.c | 22 +---------------------
include/linux/pci.h | 3 +++
5 files changed, 82 insertions(+), 22 deletions(-)
--
1.7.7
^ permalink raw reply [flat|nested] 43+ messages in thread* Re:
2012-10-30 17:42 ` (unknown), Yinghai Lu
@ 2012-11-02 0:17 ` Rafael J. Wysocki
2012-11-05 22:27 ` Re: Bjorn Helgaas
2012-11-06 5:03 ` Taku Izumi
1 sibling, 1 reply; 43+ messages in thread
From: Rafael J. Wysocki @ 2012-11-02 0:17 UTC (permalink / raw)
To: Yinghai Lu
Cc: Bjorn Helgaas, Len Brown, Taku Izumi, Jiang Liu, linux-pci,
linux-acpi
Hi,
On Tuesday, October 30, 2012 10:42:37 AM Yinghai Lu wrote:
> Subject: [PATCH resend 0/8] PCI, ACPI, x86: pci root bus hotplug support resources assign and remove path
>
> 1. add support for assign resource for hot add path.
> 2. stop and remove root bus during acpi root remove.
>
>
> could get from
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-hotplug
>
> Yinghai Lu (8):
> PCI: Separate out pci_assign_unassigned_bus_resources()
> PCI: Move pci_rescan_bus() back to probe.c
> PCI: Move out pci_enable_bridges out of assign_unsigned_bus_res
> PCI, ACPI: assign unassigned resource for hot add root bus
> PCI: Add pci_stop/remove_root_bus()
> PCI, ACPI: Make acpi_pci_root_remove stop/remove pci root bus
> PCI, ACPI: delete root bus prt during hot remove path
> PCI, ACPI: remove acpi_root_driver in reserse order
>
> drivers/acpi/pci_root.c | 21 ++++++++++++++++++++-
> drivers/pci/probe.c | 22 ++++++++++++++++++++++
> drivers/pci/remove.c | 36 ++++++++++++++++++++++++++++++++++++
> drivers/pci/setup-bus.c | 22 +---------------------
> include/linux/pci.h | 3 +++
> 5 files changed, 82 insertions(+), 22 deletions(-)
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to the ACPI-related patches in this series.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
2012-11-02 0:17 ` Rafael J. Wysocki
@ 2012-11-05 22:27 ` Bjorn Helgaas
2012-11-05 22:49 ` Re: Yinghai Lu
0 siblings, 1 reply; 43+ messages in thread
From: Bjorn Helgaas @ 2012-11-05 22:27 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Yinghai Lu, Len Brown, Taku Izumi, Jiang Liu, linux-pci,
linux-acpi
On Thu, Nov 1, 2012 at 6:17 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> Hi,
>
> On Tuesday, October 30, 2012 10:42:37 AM Yinghai Lu wrote:
>> Subject: [PATCH resend 0/8] PCI, ACPI, x86: pci root bus hotplug support resources assign and remove path
>>
>> 1. add support for assign resource for hot add path.
>> 2. stop and remove root bus during acpi root remove.
>>
>>
>> could get from
>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-hotplug
>>
>> Yinghai Lu (8):
>> PCI: Separate out pci_assign_unassigned_bus_resources()
>> PCI: Move pci_rescan_bus() back to probe.c
>> PCI: Move out pci_enable_bridges out of assign_unsigned_bus_res
>> PCI, ACPI: assign unassigned resource for hot add root bus
>> PCI: Add pci_stop/remove_root_bus()
>> PCI, ACPI: Make acpi_pci_root_remove stop/remove pci root bus
>> PCI, ACPI: delete root bus prt during hot remove path
>> PCI, ACPI: remove acpi_root_driver in reserse order
>>
>> drivers/acpi/pci_root.c | 21 ++++++++++++++++++++-
>> drivers/pci/probe.c | 22 ++++++++++++++++++++++
>> drivers/pci/remove.c | 36 ++++++++++++++++++++++++++++++++++++
>> drivers/pci/setup-bus.c | 22 +---------------------
>> include/linux/pci.h | 3 +++
>> 5 files changed, 82 insertions(+), 22 deletions(-)
>
> Please feel free to add
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> to the ACPI-related patches in this series.
I applied these to my pci/yinghai-for-pci-root-bus-hotplug branch as
v3.8 material. They should appear in "next" tomorrow. Thanks!
^ permalink raw reply [flat|nested] 43+ messages in thread
* RE:
2012-10-30 17:42 ` (unknown), Yinghai Lu
2012-11-02 0:17 ` Rafael J. Wysocki
@ 2012-11-06 5:03 ` Taku Izumi
1 sibling, 0 replies; 43+ messages in thread
From: Taku Izumi @ 2012-11-06 5:03 UTC (permalink / raw)
To: 'Yinghai Lu'
Cc: linux-pci, linux-acpi, 'Bjorn Helgaas',
'Len Brown', 'Jiang Liu'
Reviewed and tested by Taku Izumi <izumi.taku@jp.fujitsu.com>
> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-owner@vger.kernel.org] On Behalf Of Yinghai Lu
> Sent: Wednesday, October 31, 2012 2:43 AM
> To: Bjorn Helgaas; Len Brown; Taku Izumi; Jiang Liu
> Cc: linux-pci@vger.kernel.org; linux-acpi@vger.kernel.org; Yinghai Lu
> Subject:
>
> Subject: [PATCH resend 0/8] PCI, ACPI, x86: pci root bus hotplug support resources assign and remove path
>
> 1. add support for assign resource for hot add path.
> 2. stop and remove root bus during acpi root remove.
>
>
> could get from
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-hotplug
>
> Yinghai Lu (8):
> PCI: Separate out pci_assign_unassigned_bus_resources()
> PCI: Move pci_rescan_bus() back to probe.c
> PCI: Move out pci_enable_bridges out of assign_unsigned_bus_res
> PCI, ACPI: assign unassigned resource for hot add root bus
> PCI: Add pci_stop/remove_root_bus()
> PCI, ACPI: Make acpi_pci_root_remove stop/remove pci root bus
> PCI, ACPI: delete root bus prt during hot remove path
> PCI, ACPI: remove acpi_root_driver in reserse order
>
> drivers/acpi/pci_root.c | 21 ++++++++++++++++++++-
> drivers/pci/probe.c | 22 ++++++++++++++++++++++
> drivers/pci/remove.c | 36 ++++++++++++++++++++++++++++++++++++
> drivers/pci/setup-bus.c | 22 +---------------------
> include/linux/pci.h | 3 +++
> 5 files changed, 82 insertions(+), 22 deletions(-)
>
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2011-05-01 13:35 lotto
0 siblings, 0 replies; 43+ messages in thread
From: lotto @ 2011-05-01 13:35 UTC (permalink / raw)
Send your Names*Address*Phone* to claim your 1,000,000 GBP awarded to
you.Reply to lotto_agent1@ymail.com for more info
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2010-09-28 12:23 Marc Ferland
0 siblings, 0 replies; 43+ messages in thread
From: Marc Ferland @ 2010-09-28 12:23 UTC (permalink / raw)
hey,
how are you?
Just received my Iphone 4G 16GB from this homepage, www.Benefits188.com
It's so cheaper but genuine, Wow. that's amazing. I like it very much!!
I paid it $690US couier charges included , They have some other
products. If you want to get one. you can check it out !
Regards,
Marc Ferland
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2010-07-17 2:41 SINOPEC OIL AND GAS COMPANY
0 siblings, 0 replies; 43+ messages in thread
From: SINOPEC OIL AND GAS COMPANY @ 2010-07-17 2:41 UTC (permalink / raw)
Dear winner,
We the SINOPEC OIL AND GAS COMPANY board of directors like to officially
congratulate you for the draw that was just held by our company which
featured you as the second place winner.Prizes won : Brand New 2010
Lamborghini Car new model and The Sum Of $570,000.00USD
(United State Dollars) cash.
FILL DETAILs BELOW;
Your Full Name : Address :Country :Phone number :Age :Gender :Occupation :
Yours,
Sinopec Oil And Gas Corp.
^ permalink raw reply [flat|nested] 43+ messages in thread
* RE:
@ 2010-06-05 3:47 MR PETER LUK
0 siblings, 0 replies; 43+ messages in thread
From: MR PETER LUK @ 2010-06-05 3:47 UTC (permalink / raw)
To: info
I have a business proposal to share with you.
^ permalink raw reply [flat|nested] 43+ messages in thread
* RE;
@ 2010-04-02 23:17 Mrs Claire page
0 siblings, 0 replies; 43+ messages in thread
From: Mrs Claire page @ 2010-04-02 23:17 UTC (permalink / raw)
I am Mrs Claire page,contact my lawyer(barlandon_watson@gala.net)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2005-11-15 9:20 yuki
0 siblings, 0 replies; 43+ messages in thread
From: yuki @ 2005-11-15 9:20 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
®«S«³«¿««g«¢«ú«è«
ª®ª®ª®ª®ª®ª®ª®ª®ª®
@@@@@@@@¤¤¤¤¤¤
http://www.checkcheck-zero.net/?id=pc120
üïï^Nïï
[óMM
zÌè^²ßõ
Ê^^®æÌo^{
Z^AhX^dbÔÌð·
j««ÆàÉ®S³¿ÅSIJp¸¯Ü·B
http://www.checkcheck-zero.net/?id=pc120
ÀSTCgé¾
EEEcªªªªªªªªªªªªªªªªªªªªªªªªª
u[[ÍX|T[TCgl©çÌL¿ÌÝÅ^cµÄ¨èÜ·B
»Ì×AST[rXð®S³¿ÅSIJp¸¯Ü·B
zÌèðßéûXÉÀSÆMðæêÉl¦ÈªçA
Cyɨg¢¸¯éT[rXðÚwµA
SÌT|[ģÅFlÉÁ½¨èTµð¨è`¢µÄ¨èÜ·B
ªªªªªªªªªªªªªªªªªªªªªªªªªcEEE
http://www.checkcheck-zero.net/?id=pc120
--
zMÛF
kissme_rej-OKxsdJkEjlFWk0Htik3J/w@public.gmane.org
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
^ permalink raw reply [flat|nested] 43+ messages in thread* Re:
@ 2005-07-05 23:28 =?ISO-2022-JP?B?GyRCJCpKdSU1ITwlQRsoQiA8b3Rha2FyYWdldHRlckB5YWhvby5jb20+?=
0 siblings, 0 replies; 43+ messages in thread
From: =?ISO-2022-JP?B?GyRCJCpKdSU1ITwlQRsoQiA8b3Rha2FyYWdldHRlckB5YWhvby5jb20+?= @ 2005-07-05 23:28 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
nkEqå¶ElÈÌvCx[gGb`ÉüI
ÞÌOKðàçÁÄBeII
¢«ÈèÌJüɬ·éÞ½¿BB
µ©àvCÉàüAÞÌ©ÂßéOÅ©mçÊj½¿ðó¯üêéÌq¥¥¥B
µ©µ¾ñ¾ñAÞ½¿ÌÌðõ´ªïÝÝnß饥¥
http://hamex.tv/index2.php?35
ÞÈOðmçÈ©Á½ÌqàAiÆÍá¤vCÉ©ªðYêÄõ´ðß饥¥B
flÈçÅÍÌvZūȢANVÉå»±Ôá¢ÈµÅ·BBB
»µÄÅãÍ¥¥¥
http://hamex.tv/index2.php?35
NSLSRJGIOJ
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2004-07-19 7:29 Mj
0 siblings, 0 replies; 43+ messages in thread
From: Mj @ 2004-07-19 7:29 UTC (permalink / raw)
To: Acpi-devel
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
------------------ Virus Warning Message (on the network)
Found virus WORM_BAGLE.AG in file Garry.com
The file Garry.com can not be moved because /var/quarantine/virus/virJWWjgUxMt: No space left on device.
This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.
---------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 53 bytes --]
[-- Attachment #3: Type: text/plain, Size: 179 bytes --]
------------------ Virus Warning Message (on the network)
Garry.com is removed from here because it contains a virus.
---------------------------------------------------------
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re:
@ 2004-07-19 4:53 Mj
0 siblings, 0 replies; 43+ messages in thread
From: Mj @ 2004-07-19 4:53 UTC (permalink / raw)
To: Acpi-devel
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
------------------ Virus Warning Message (on the network)
Found virus WORM_BAGLE.AG in file Dog.exe
The file Dog.exe can not be moved because /var/quarantine/virus/virAIFT6oWfZ: No space left on device.
This is a machine-generated message, please do not reply via e-mail. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770.
---------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 49 bytes --]
[-- Attachment #3: Type: text/plain, Size: 177 bytes --]
------------------ Virus Warning Message (on the network)
Dog.exe is removed from here because it contains a virus.
---------------------------------------------------------
^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <200402040504.i1454nSA026612@dcs-server4.cs.uiuc.edu>]
* Re:
@ 2003-01-03 8:43 hotdi-049YEbzBPRy2DcrEJY9i8Q
0 siblings, 0 replies; 43+ messages in thread
From: hotdi-049YEbzBPRy2DcrEJY9i8Q @ 2003-01-03 8:43 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
confirm 191616
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2021-11-25 15:03 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-02 9:48 [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Hans de Goede
2021-11-02 9:48 ` [PATCH v5 01/11] ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 device Hans de Goede
2021-11-02 9:48 ` [PATCH v5 02/11] i2c: acpi: Use acpi_dev_ready_for_enumeration() helper Hans de Goede
2021-11-02 9:48 ` [PATCH v5 03/11] platform_data: Add linux/platform_data/tps68470.h file Hans de Goede
2021-11-02 9:49 ` [PATCH v5 04/11] regulator: Introduce tps68470-regulator driver Hans de Goede
2021-11-02 9:49 ` [PATCH v5 05/11] clk: Introduce clk-tps68470 driver Hans de Goede
[not found] ` <163588780885.2993099.2088131017920983969@swboyd.mtv.corp.google.com>
2021-11-25 15:01 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 06/11] platform/x86: int3472: Enable I2c daisy chain Hans de Goede
2021-11-02 9:49 ` [PATCH v5 07/11] platform/x86: int3472: Split into 2 drivers Hans de Goede
2021-11-02 14:12 ` Andy Shevchenko
2021-11-02 14:16 ` Andy Shevchenko
2021-11-02 14:24 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 08/11] platform/x86: int3472: Add get_sensor_adev_and_name() helper Hans de Goede
2021-11-02 9:49 ` [PATCH v5 09/11] platform/x86: int3472: Pass tps68470_clk_platform_data to the tps68470-regulator MFD-cell Hans de Goede
2021-11-02 9:49 ` [PATCH v5 10/11] platform/x86: int3472: Pass tps68470_regulator_platform_data " Hans de Goede
2021-11-02 14:34 ` Andy Shevchenko
2021-11-02 14:59 ` Hans de Goede
2021-11-02 15:52 ` Andy Shevchenko
2021-11-02 16:11 ` Hans de Goede
2021-11-02 16:17 ` Sakari Ailus
2021-11-02 16:35 ` Hans de Goede
2021-11-02 9:49 ` [PATCH v5 11/11] platform/x86: int3472: Deal with probe ordering issues Hans de Goede
2021-11-02 14:37 ` [PATCH v5 00/11] Add support for X86/ACPI camera sensor/PMIC setup with clk and regulator platform data Andy Shevchenko
-- strict thread matches above, loose matches on Subject: below --
2017-11-13 14:55 Amos Kalonzo
2017-05-03 6:23 Re: H.A
2017-02-23 15:09 Qin's Yanjun
2013-12-21 16:48 (unknown), Alex Barattini
2013-12-23 1:44 ` Aaron Lu
2013-12-23 16:24 ` Re: Alex Barattini
2012-10-30 4:02 [PATCH v3 7/8] ACPI, PCI: add hostbridge removal function Bjorn Helgaas
2012-10-30 17:42 ` (unknown), Yinghai Lu
2012-11-02 0:17 ` Rafael J. Wysocki
2012-11-05 22:27 ` Re: Bjorn Helgaas
2012-11-05 22:49 ` Re: Yinghai Lu
2012-11-06 5:03 ` Taku Izumi
2011-05-01 13:35 lotto
2010-09-28 12:23 Re: Marc Ferland
2010-07-17 2:41 Re: SINOPEC OIL AND GAS COMPANY
2010-06-05 3:47 MR PETER LUK
2010-04-02 23:17 RE; Mrs Claire page
2005-11-15 9:20 yuki
2005-07-05 23:28 Re: =?ISO-2022-JP?B?GyRCJCpKdSU1ITwlQRsoQiA8b3Rha2FyYWdldHRlckB5YWhvby5jb20+?=
2004-07-19 7:29 Re: Mj
2004-07-19 4:53 Re: Mj
[not found] <200402040504.i1454nSA026612@dcs-server4.cs.uiuc.edu>
[not found] ` <200402040504.i1454nSA026612-X7uhcDA/9l0r6e4dAyNacUYNSvWw4lR0@public.gmane.org>
2004-02-04 5:04 ` Re: Design Patterns Source reflector
2003-01-03 8:43 Re: hotdi-049YEbzBPRy2DcrEJY9i8Q
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).