5ccf9873 | 04-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Switch to devm_get_gpiod()
Switch to devm_get_gpiod() for discrete GPIOs for clks / regulators / LEDs and let devm do the cleanup for us.
Reviewed-by: Andy Shevchenko <andriy
platform/x86: int3472: Switch to devm_get_gpiod()
Switch to devm_get_gpiod() for discrete GPIOs for clks / regulators / LEDs and let devm do the cleanup for us.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-5-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
53c5f7f6 | 04-Oct-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Stop using gpiod_toggle_active_low()
Use the new skl_int3472_gpiod_get_from_temp_lookup() helper to get a gpio to pass to register_gpio_clock(), skl_int3472_register_regulator
platform/x86: int3472: Stop using gpiod_toggle_active_low()
Use the new skl_int3472_gpiod_get_from_temp_lookup() helper to get a gpio to pass to register_gpio_clock(), skl_int3472_register_regulator() and skl_int3472_register_pled().
This removes all use of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions.
Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20231004162317.163488-4-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
5cad1285 | 04-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helper
Add a new skl_int3472_gpiod_get_from_temp_lookup() helper.
This is a preparation patch for removing usage of the depre
platform/x86: int3472: Add new skl_int3472_gpiod_get_from_temp_lookup() helper
Add a new skl_int3472_gpiod_get_from_temp_lookup() helper.
This is a preparation patch for removing usage of the deprecated gpiod_toggle_active_low() and acpi_get_and_request_gpiod() functions.
[hdegoede@redhat.com] use the new skl_int3472_fill_gpiod_lookup() helper
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231004162317.163488-3-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
899c7b18 | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Log a warning if the pin-numbers don't match
The INT3472 discrete code assumes that the ACPI GPIO resources are in the same order as the pin-info _DSM entries.
The
platform/x86: int3472: discrete: Log a warning if the pin-numbers don't match
The INT3472 discrete code assumes that the ACPI GPIO resources are in the same order as the pin-info _DSM entries.
The returned pin-info includes the pin-number in bits 15-8. Add a check that this matches with the ACPI GPIO resource pin-number in case the assumption is not true with some ACPI tables.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-7-hdegoede@redhat.com
show more ...
|
45eaf2e2 | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Use FIELD_GET() on the GPIO _DSM return value
Add defines for the various fields encoded in the GPIO _DSM integer return value and then use FIELD_GET() to get field
platform/x86: int3472: discrete: Use FIELD_GET() on the GPIO _DSM return value
Add defines for the various fields encoded in the GPIO _DSM integer return value and then use FIELD_GET() to get field values.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-6-hdegoede@redhat.com
show more ...
|
ebeb3fff | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Add alternative "AVDD" regulator supply name
Add an "AVDD" regulator supply name alias to the supply-map which gets registered for the INT3472 GPIO regulator.
This
platform/x86: int3472: discrete: Add alternative "AVDD" regulator supply name
Add an "AVDD" regulator supply name alias to the supply-map which gets registered for the INT3472 GPIO regulator.
This is necessary for the ov2680 driver which expects "AVDD" rather then "avdd". Updating the ov2680 driver to use "avdd" is not possible because that will break compatibility with existing DT / DTB files.
Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230616172132.37859-5-hdegoede@redhat.com
show more ...
|
f1a58250 | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Add support for 1 GPIO regulator shared between 2 sensors
On the Lenovo Miix 510-12IKB there is 1 GPIO regulator, with its GPIO listed in the INT3472 device belongin
platform/x86: int3472: discrete: Add support for 1 GPIO regulator shared between 2 sensors
On the Lenovo Miix 510-12IKB there is 1 GPIO regulator, with its GPIO listed in the INT3472 device belonging to the OV5648 back sensor. But this regulator also needs to be enabled for the OV2680 front sensor to work.
Add support to skl_int3472_register_regulator() to add supply map entries pointing to both sensors based on a DMI quirk table which gives the dev_name part of the supply map for the second sensor (the sensor without the GPIO listed in its matching INT3472 ACPI device).
Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-4-hdegoede@redhat.com
show more ...
|
d4381dcf | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Remove sensor_config-s
Currently the only 2 sensor_config-s both specify "avdd" as supply-id.
The INT3472 device is going to be the only supplier of a regulator for
platform/x86: int3472: discrete: Remove sensor_config-s
Currently the only 2 sensor_config-s both specify "avdd" as supply-id.
The INT3472 device is going to be the only supplier of a regulator for the sensor device.
So there is no chance of collisions with other regulator suppliers and it is undesirable to need to manually add new entries to int3472_sensor_configs[] for each new sensor module which uses a GPIO regulator.
Instead just always use "avdd" as supply-id when registering the GPIO regulator.
If necessary for specific sensor drivers then other supply-ids can be added as aliases in the future, adding aliases will be safe since INT3472 will be the only regulator supplier for the sensor.
Cc: Bingbu Cao <bingbu.cao@intel.com> Tested-by: Hao Yao <hao.yao@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Link: https://lore.kernel.org/r/20230616172132.37859-3-hdegoede@redhat.com
show more ...
|
b52798a8 | 16-Jun-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: discrete: Drop GPIO remapping support
The only sensor driver which needs GPIO remapping support is the ov2680 driver and ACPI enumeration support + other necessary changes to
platform/x86: int3472: discrete: Drop GPIO remapping support
The only sensor driver which needs GPIO remapping support is the ov2680 driver and ACPI enumeration support + other necessary changes to the ov2680 driver were never upstreamed.
A new series updating the ov2680 driver is pending upstream now and in this series the ov2680 driver is patched to look for "powerdown" as con-id, instead of relying on GPIO remapping in the int3472 code, so the GPIO remapping is no longer necessary.
Tested-by: Hao Yao <hao.yao@intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230616172132.37859-2-hdegoede@redhat.com
show more ...
|
aeaee158 | 12-Jun-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
platform/x86: int3472: Switch back to use struct i2c_driver's .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new()
platform/x86: int3472: Switch back to use struct i2c_driver's .probe()
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230612073902.840435-4-u.kleine-koenig@pengutronix.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
b919540a | 08-Feb-2023 |
Arnd Bergmann <arnd@arndb.de> |
platform/x86: int3472/discrete: add LEDS_CLASS dependency
int3472 now fails to link when the LED support is disabled:
x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int
platform/x86: int3472/discrete: add LEDS_CLASS dependency
int3472 now fails to link when the LED support is disabled:
x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_register_pled': led.c:(.text+0xf4): undefined reference to `led_classdev_register_ext' x86_64-linux-ld: led.c:(.text+0x131): undefined reference to `led_add_lookup' x86_64-linux-ld: drivers/platform/x86/intel/int3472/led.o: in function `skl_int3472_unregister_pled': led.c:(.text+0x16b): undefined reference to `led_remove_lookup' x86_64-linux-ld: led.c:(.text+0x177): undefined reference to `led_classdev_unregister'
Add an explicit Kconfig dependency.
Fixes: 5ae20a8050d0 ("platform/x86: int3472/discrete: Create a LED class device for the privacy LED") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230208163658.2129009-1-arnd@kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
23d18a20 | 04-Feb-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472/discrete: Drop unnecessary obj->type == string check
acpi_evaluate_dsm_typed() already verifies the type is the requested type, so this error check is a no-op, drop it.
Signed
platform/x86: int3472/discrete: Drop unnecessary obj->type == string check
acpi_evaluate_dsm_typed() already verifies the type is the requested type, so this error check is a no-op, drop it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230204110223.54625-1-hdegoede@redhat.com
show more ...
|
7a88de31 | 27-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472/discrete: Get the polarity from the _DSM entry
According to: https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.pat
platform/x86: int3472/discrete: Get the polarity from the _DSM entry
According to: https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.patch
Bits 31-24 of the _DSM pin entry integer value codes the active-value, that is the actual physical signal (0 or 1) which needs to be output on the pin to turn the sensor chip on (to make it active).
So if bits 31-24 are 0 for a reset pin, then the actual value of the reset pin needs to be 0 to take the chip out of reset. IOW in this case the reset signal is active-high rather then the default active-low.
And if bits 31-24 are 0 for a clk-en pin then the actual value of the clk pin needs to be 0 to enable the clk. So in this case the clk-en signal is active-low rather then the default active-high.
IOW if bits 31-24 are 0 for a pin, then the default polarity of the pin is inverted.
Add a check for this and also propagate this new polarity to the clock registration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-6-hdegoede@redhat.com
show more ...
|
8cf0e541 | 27-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472/discrete: Move GPIO request to skl_int3472_register_clock()
Move the requesting of the clk-enable GPIO to skl_int3472_register_clock() (and move the gpiod_put to unregister).
platform/x86: int3472/discrete: Move GPIO request to skl_int3472_register_clock()
Move the requesting of the clk-enable GPIO to skl_int3472_register_clock() (and move the gpiod_put to unregister).
This mirrors the GPIO handling in skl_int3472_register_regulator() and allows removing skl_int3472_map_gpio_to_clk() from discrete.c.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-5-hdegoede@redhat.com
show more ...
|
5ae20a80 | 27-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472/discrete: Create a LED class device for the privacy LED
On some systems, e.g. the Lenovo ThinkPad X1 Yoga gen 7 and the ThinkPad X1 Nano gen 2 there is no clock-enable pin, tri
platform/x86: int3472/discrete: Create a LED class device for the privacy LED
On some systems, e.g. the Lenovo ThinkPad X1 Yoga gen 7 and the ThinkPad X1 Nano gen 2 there is no clock-enable pin, triggering the: "No clk GPIO. The privacy LED won't work" warning and causing the privacy LED to not work.
Fix this by modeling the privacy LED as a LED class device rather then integrating it with the registered clock.
Note this relies on media subsys changes to actually turn the LED on/off when the sensor's v4l2_subdev's s_stream() operand gets called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://lore.kernel.org/r/20230127203729.10205-4-hdegoede@redhat.com
show more ...
|