| 30359c23 | 25-Jul-2025 |
Hans de Goede <hansg@kernel.org> |
platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 ms
On HP laptops with an ov08x40 sensor the 25 ms delay coming from Intel's
out of tree drivers is not enough. Testing has confirme
platform/x86: int3472: Increase ov08x40 handshake GPIO delay to 45 ms
On HP laptops with an ov08x40 sensor the 25 ms delay coming from Intel's
out of tree drivers is not enough. Testing has confirmed that 45 ms does
work.
Add a quirk to the int3472_gpio_map[] to increase the delay to 45 ms to fix
probing of the ov08x40 sensor failing on these laptops.
Note this only impacts laptops which actually use an ov08x40 sensor with
a handshake GPIO.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2333331
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250725215259.402796-4-hansg@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| f11f8948 | 25-Jul-2025 |
Hans de Goede <hansg@kernel.org> |
platform/x86: int3472: Rework regulator enable-time handling
Instead of hardcoding the regulator enable-time for INT3472_GPIO_TYPE-
POWER_ENABLE and -HANDSHAKE, make int3472_get_con_id_and_polarity(
platform/x86: int3472: Rework regulator enable-time handling
Instead of hardcoding the regulator enable-time for INT3472_GPIO_TYPE-
POWER_ENABLE and -HANDSHAKE, make int3472_get_con_id_and_polarity()
set the enable-time.
This will allow overriding the enable time through quirks in
the int3472_gpio_map[].
Signed-off-by: Hans de Goede <hansg@kernel.org>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20250725215259.402796-3-hansg@kernel.org
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
show more ...
|
| 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 ...
|