| 569617db | 11-Feb-2025 |
Sakari Ailus <[email protected]> |
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 <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 6718d42b | 09-Dec-2024 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 1dd0cb9c | 09-Dec-2024 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 53c5f7f6 | 04-Oct-2023 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>
show more ...
|
| 899c7b18 | 16-Jun-2023 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| ebeb3fff | 16-Jun-2023 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Daniel Scally <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| f1a58250 | 16-Jun-2023 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| d4381dcf | 16-Jun-2023 |
Hans de Goede <[email protected]> |
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 <[email protected]>
Tested-by: Hao Yao <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Daniel Scally <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
show more ...
|