| d4860025 | 07-May-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: For mt9m114 sensors map powerdown to powerenable
mt9m114 atomisp designs declare both reset and powerdown pins in their
GPIO type DSM, but the mt9m114 only has a reset pin. Th
platform/x86: int3472: For mt9m114 sensors map powerdown to powerenable
mt9m114 atomisp designs declare both reset and powerdown pins in their
GPIO type DSM, but the mt9m114 only has a reset pin. The powerdown pin
seems to control the regulators suppyling power to the sensor and
the privacy LED.
Add a mapping of powerdown to powerenable for the mt9m114 for this.
While at is also add a comment to document the ov7251 mapping.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250507184737.154747-6-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 ...
|
| 1cfa1bb9 | 07-May-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Export int3472_discrete_parse_crs()
At the moment the atomisp has duplicate code for parsing Intel camera
sensor GPIOS and calling the special 79234640-9e10-4fea-a5c1-b5aa8b19
platform/x86: int3472: Export int3472_discrete_parse_crs()
At the moment the atomisp has duplicate code for parsing Intel camera
sensor GPIOS and calling the special 79234640-9e10-4fea-a5c1-b5aa8b19756f
_DSM to get the GPIO type and map it to the sensor.
Export int3472_discrete_parse_crs() so that the atomisp driver can reuse
the INT3472 code for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250507184737.154747-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 ...
|
| 1e5d088a | 07-May-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Stop using devm_gpiod_get()
The intent is to re-use the INT3472 code for parsing Intel camera sensor
GPIOs and mapping them to the sensor for the atomisp driver, which
current
platform/x86: int3472: Stop using devm_gpiod_get()
The intent is to re-use the INT3472 code for parsing Intel camera sensor
GPIOs and mapping them to the sensor for the atomisp driver, which
currently has duplicate code.
On atomisp devices there is no special INT3472 ACPI device, instead
the Intel _DSM to get the GPIO type is part of the ACPI device for
the sensor itself.
To deal with this the mapping is done from ipu_bridge_init() instead of
from a platform-device probe() function, there is no device to tie
the lifetime of the gpiod_get() calls done by the INT3472 code to.
Switch from devm_gpiod_get() to plain gpiod_get() + explicit gpiod_put()
calls, to prepare for the code being re-used in the atomisp driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250507184737.154747-3-hdegoede@redhat.com
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| 4d1e8c8f | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Debug log when remapping pins
Debug log when remapping a pin/function because of a int3472_gpio_map[]
match.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Han
platform/x86: int3472: Debug log when remapping pins
Debug log when remapping a pin/function because of a int3472_gpio_map[]
match.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-10-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 ...
|
| c5d03932 | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Add handshake pin support
New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12
pin defined in the INT3472 sensor companion device which describes
the sen
platform/x86: int3472: Add handshake pin support
New Intel Meteor Lake based laptops with IPU6 cameras have a new type 0x12
pin defined in the INT3472 sensor companion device which describes
the sensor's GPIOs.
This pin is primarily used on designs with a Lattice FPGA chip which is
capable of running the sensor independently of the main CPU for features
like presence detection. This pin needs to be driven high to make the FPGA
run the power-on sequence of the sensor. After driving the pin high,
the FPGA "firmware" needs 25ms to complete the power-on sequence.
Add support for this modelling the handshake pin as a GPIO driven "dvdd"
regulator with a 25 ms enable time. This model was chosen because:
1. Sensor chips don't have a handshake pin, so we need to abstract this
in some way which does not require modification to the sensor drivers,
sensor drivers using the bulk-regulator API to get avdd + vddio + dvdd
is normal. So this will work to get the right value set to the handshake
pin without requiring sensor driver modifications.
2. Sensors typically wait only a small time for the sensor to power-on
after de-asserting reset. Not the 25ms the Lattice chip requires.
Using the regulator framework's enable_time allows hiding the need for
this delay from the sensor drivers.
Link: https://lore.kernel.org/platform-driver-x86/59f672c3-6d87-4ec7-9b7f-f44fe2cce934@redhat.com/
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2341731
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-9-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 ...
|
| 4455dcf5 | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Prepare for registering more than 1 GPIO regulator
Prepare the discrete code for registering more than 1 GPIO regulator.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed
platform/x86: int3472: Prepare for registering more than 1 GPIO regulator
Prepare the discrete code for registering more than 1 GPIO regulator.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-8-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 ...
|
| ccda394e | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Avoid GPIO regulator spikes
Avoid the GPIO controlling the avdd regulator being driven low or high
for a very short time leading to spikes by adding an enable delay of 2 ms
an
platform/x86: int3472: Avoid GPIO regulator spikes
Avoid the GPIO controlling the avdd regulator being driven low or high
for a very short time leading to spikes by adding an enable delay of 2 ms
and a minimum off to on delay of also 2 ms.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-7-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 ...
|
| 033234bd | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Make regulator supply name configurable
This is a preparation patch for registering multiple regulators, which
requires a different supply-name for each regulator. Make supply
platform/x86: int3472: Make regulator supply name configurable
This is a preparation patch for registering multiple regulators, which
requires a different supply-name for each regulator. Make supply-name
a parameter to skl_int3472_register_regulator() and use con-id to set it
so that the existing int3472_gpio_map remapping can be used with it.
Since supply-name is a parameter now, drop the fixed
skl_int3472_regulator_map_supplies[] array and instead add lower- and
upper-case mappings of the passed-in supply-name to the regulator.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-6-hdegoede@redhat.com
[ij: GPIO_SUPPPLY_NAME_LENGTH -> GPIO_SUPPLY_NAME_LENGTH]
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| 38ff83a3 | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Rework AVDD second sensor quirk handling
Rework the discrete quirk handling to use a quirks struct which is
pointed to by a dmi_system_id table, rather then having a dmi_syste
platform/x86: int3472: Rework AVDD second sensor quirk handling
Rework the discrete quirk handling to use a quirks struct which is
pointed to by a dmi_system_id table, rather then having a dmi_system_id
table per type of quirk.
This is a preparation patch for adding support for multiple regulators,
where not all regulators might be shared between sensors.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-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 ...
|
| b6d3d739 | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Drop unused gpio field from struct int3472_gpio_regulator
The gpio field in struct int3472_gpio_regulator is only briefly used to
store the GPIO in skl_int3472_register_regula
platform/x86: int3472: Drop unused gpio field from struct int3472_gpio_regulator
The gpio field in struct int3472_gpio_regulator is only briefly used to
store the GPIO in skl_int3472_register_regulator(). Instead just store
the GPIO directly into cfg.ena_gpiod an drop the gpio field.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-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 ...
|
| ea890cdd | 17-Apr-2025 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Stop setting a supply-name for GPIO regulators
The supply_name field is not mandatory and is supposed to be set to
the name of another regulator when it is known that the regu
platform/x86: int3472: Stop setting a supply-name for GPIO regulators
The supply_name field is not mandatory and is supposed to be set to
the name of another regulator when it is known that the regulator being
registered is supplied by that other regulator.
Having a regulator supplying the regulator which is being registered does
not apply to the INT3472 GPIO regulator, stop setting a supply_name.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: David Heidelberg <david@ixit.cz> # Dell Latitude 9440
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250417111337.38142-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 ...
|
| 569617db | 11-Feb-2025 |
Sakari Ailus <sakari.ailus@linux.intel.com> |
platform/x86: int3472: Call "reset" GPIO "enable" for INT347E
The DT bindings for ov7251 specify "enable" GPIO (xshutdown in
documentation) but the int3472 indiscriminately provides this as a "reset
platform/x86: int3472: Call "reset" GPIO "enable" for INT347E
The DT bindings for ov7251 specify "enable" GPIO (xshutdown in
documentation) but the int3472 indiscriminately provides this as a "reset"
GPIO to sensor drivers. Take this into account by assigning it as "enable"
with active high polarity for INT347E devices, i.e. ov7251. "reset" with
active low polarity remains the default GPIO name for other devices.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250211072841.7713-3-sakari.ailus@linux.intel.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| cc115abc | 09-Dec-2024 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Debug log the sensor name
Debug log the sensor name to make it easier to figure out which INT3472
device is associated with which sensor.
Signed-off-by: Hans de Goede <hdegoe
platform/x86: int3472: Debug log the sensor name
Debug log the sensor name to make it easier to figure out which INT3472
device is associated with which sensor.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241209220522.25288-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 ...
|
| 6718d42b | 09-Dec-2024 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Fix skl_int3472_handle_gpio_resources() return value
The INT3472 code never wants a copy of the ACPI resource to be added
to the list-head passed to acpi_dev_get_resources().
platform/x86: int3472: Fix skl_int3472_handle_gpio_resources() return value
The INT3472 code never wants a copy of the ACPI resource to be added
to the list-head passed to acpi_dev_get_resources().
Make skl_int3472_handle_gpio_resources() always return -errno or 1.
Also update the inaccurate comment about the return value.
skl_int3472_handle_gpio_resources() was already returning 1 in the case
of not a GPIO resource or invalid _DSM return and not -EINVAL / -ENODEV
as the comment claimed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241209220522.25288-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 ...
|
| 1dd0cb9c | 09-Dec-2024 |
Hans de Goede <hdegoede@redhat.com> |
platform/x86: int3472: Make "pin number mismatch" message a debug message
It seems that Windows is only using the ACPI GPIO resources and never
looks at the part of the _DSM return value which encod
platform/x86: int3472: Make "pin number mismatch" message a debug message
It seems that Windows is only using the ACPI GPIO resources and never
looks at the part of the _DSM return value which encodes the pin number.
For example on a Terra Pad 1262 v2 the following messages are printend:
int3472-discrete INT3472:01: reset \_SB.GPI0 pin number mismatch _DSM 103 resource 359
int3472-discrete INT3472:01: powerdown \_SB.GPI0 pin number mismatch _DSM 207 resource 335
int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 101 resource 357
Notice for the 2 reset pins that the _DSM value is off by 256, this is
caused by there only being 8 bits reserved in the _DSM return value for
the pin-number.
As for the powerdown pin, testing has shown that the pin-number 335 from
the ACPI GPIO resource is correct and the _DSM value is bogus.
Lower the warning about these mismatches to a debug message and only
look at the lower 8 bits of the GPIO resource pin numbers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241209220522.25288-2-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 ...
|
| 1bda29ae | 22-Aug-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
platform/x86: int3472: Use str_high_low()
Use str_high_low() rather than open coding.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@li
platform/x86: int3472: Use str_high_low()
Use str_high_low() rather than open coding.
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240822130722.1261891-5-andriy.shevchenko@linux.intel.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| 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 ...
|