[PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Dongcheng Yan]

Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
being received. On the host side this is wired to a GPIO for polling or
interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
lt6911uxe and lt6911uxc.

The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
here as well.

Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
---
 drivers/platform/x86/intel/int3472/common.h   | 1 +
 drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
index 51b818e62a25..4593d567caf4 100644
--- a/drivers/platform/x86/intel/int3472/common.h
+++ b/drivers/platform/x86/intel/int3472/common.h
@@ -23,6 +23,7 @@
 #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
 #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
 #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
+#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
 
 #define INT3472_PDEV_MAX_NAME_LEN				23
 #define INT3472_MAX_SENSOR_GPIOS				3
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 394975f55d64..efa3bc7af193 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
 		*con_id = "privacy-led";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
 		break;
+	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
+		*con_id = "hpd";
+		*gpio_flags = GPIO_ACTIVE_HIGH;
+		break;
 	case INT3472_GPIO_TYPE_POWER_ENABLE:
 		*con_id = "avdd";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
@@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
  * 0x0b Power enable
  * 0x0c Clock enable
  * 0x0d Privacy LED
+ * 0x13 Hotplug detect
  *
  * There are some known platform specific quirks where that does not quite
  * hold up; for example where a pin with type 0x01 (Power down) is mapped to
@@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 	switch (type) {
 	case INT3472_GPIO_TYPE_RESET:
 	case INT3472_GPIO_TYPE_POWERDOWN:
+	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
 		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
 		if (ret)
 			err_msg = "Failed to map GPIO pin to sensor\n";

base-commit: 4d1e8c8f11c611db5828e4bae7292bc295eea8ef
-- 
2.34.1

[PATCH v3 2/2] media: i2c: change lt6911uxe irq_gpio name to "hpd"

[Dongcheng Yan]

Lt6911uxe is used in IPU6 / x86 platform, worked with an out-of-tree
int3472 patch and upstream intel/ipu6 before. It is only used on ACPI
platforms till now and there are no devicetree bindings for this
driver.

The upstream int3472 driver uses "hpd" instead of "readystat" now.
this patch updates the irq_gpio name to "hpd" accordingly, so that
mere users can now use the upstream version directly without relying
on out-of-tree int3472 pin support.

The new name "hpd" (Hotplug Detect) aligns with common naming
conventions used in other drivers(like adv7604) and documentation.

Fixes: e49563c3be09d4 ("media: i2c: add lt6911uxe hdmi bridge driver")
Cc: stable@vger.kernel.org
Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
---
 drivers/media/i2c/lt6911uxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/lt6911uxe.c b/drivers/media/i2c/lt6911uxe.c
index c5b40bb58a37..24857d683fcf 100644
--- a/drivers/media/i2c/lt6911uxe.c
+++ b/drivers/media/i2c/lt6911uxe.c
@@ -605,10 +605,10 @@ static int lt6911uxe_probe(struct i2c_client *client)
 		return dev_err_probe(dev, PTR_ERR(lt6911uxe->reset_gpio),
 				     "failed to get reset gpio\n");
 
-	lt6911uxe->irq_gpio = devm_gpiod_get(dev, "readystat", GPIOD_IN);
+	lt6911uxe->irq_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
 	if (IS_ERR(lt6911uxe->irq_gpio))
 		return dev_err_probe(dev, PTR_ERR(lt6911uxe->irq_gpio),
-				     "failed to get ready_stat gpio\n");
+				     "failed to get hpd gpio\n");
 
 	ret = lt6911uxe_fwnode_parse(lt6911uxe, dev);
 	if (ret)
-- 
2.34.1

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[kernel test robot]

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support
Link: https://lore.kernel.org/stable/20250425104331.3165876-1-dongcheng.yan%40intel.com

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Yan, Dongcheng]

Hi reviewers,

I'm sorry for that I forget to rm cc:stable@vger.kernel.org in maillist

Best Regards,
Dongcheng

On 4/25/2025 6:43 PM, Dongcheng Yan wrote:
> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> being received. On the host side this is wired to a GPIO for polling or
> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> lt6911uxe and lt6911uxc.
> 
> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> here as well.
> 
> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> ---
>  drivers/platform/x86/intel/int3472/common.h   | 1 +
>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> index 51b818e62a25..4593d567caf4 100644
> --- a/drivers/platform/x86/intel/int3472/common.h
> +++ b/drivers/platform/x86/intel/int3472/common.h
> @@ -23,6 +23,7 @@
>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
>  
>  #define INT3472_PDEV_MAX_NAME_LEN				23
>  #define INT3472_MAX_SENSOR_GPIOS				3
> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> index 394975f55d64..efa3bc7af193 100644
> --- a/drivers/platform/x86/intel/int3472/discrete.c
> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>  		*con_id = "privacy-led";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>  		break;
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> +		*con_id = "hpd";
> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> +		break;
>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
>  		*con_id = "avdd";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>   * 0x0b Power enable
>   * 0x0c Clock enable
>   * 0x0d Privacy LED
> + * 0x13 Hotplug detect
>   *
>   * There are some known platform specific quirks where that does not quite
>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>  	switch (type) {
>  	case INT3472_GPIO_TYPE_RESET:
>  	case INT3472_GPIO_TYPE_POWERDOWN:
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
>  		if (ret)
>  			err_msg = "Failed to map GPIO pin to sensor\n";
> 
> base-commit: 4d1e8c8f11c611db5828e4bae7292bc295eea8ef

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Hans de Goede]

Hi,

On 25-Apr-25 12:43, Dongcheng Yan wrote:
> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> being received. On the host side this is wired to a GPIO for polling or
> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> lt6911uxe and lt6911uxc.
> 
> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> here as well.
> 
> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>

Thanks, patch looks good to me:

Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



> ---
>  drivers/platform/x86/intel/int3472/common.h   | 1 +
>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> index 51b818e62a25..4593d567caf4 100644
> --- a/drivers/platform/x86/intel/int3472/common.h
> +++ b/drivers/platform/x86/intel/int3472/common.h
> @@ -23,6 +23,7 @@
>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
>  
>  #define INT3472_PDEV_MAX_NAME_LEN				23
>  #define INT3472_MAX_SENSOR_GPIOS				3
> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> index 394975f55d64..efa3bc7af193 100644
> --- a/drivers/platform/x86/intel/int3472/discrete.c
> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>  		*con_id = "privacy-led";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>  		break;
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> +		*con_id = "hpd";
> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> +		break;
>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
>  		*con_id = "avdd";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>   * 0x0b Power enable
>   * 0x0c Clock enable
>   * 0x0d Privacy LED
> + * 0x13 Hotplug detect
>   *
>   * There are some known platform specific quirks where that does not quite
>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>  	switch (type) {
>  	case INT3472_GPIO_TYPE_RESET:
>  	case INT3472_GPIO_TYPE_POWERDOWN:
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
>  		if (ret)
>  			err_msg = "Failed to map GPIO pin to sensor\n";
> 
> base-commit: 4d1e8c8f11c611db5828e4bae7292bc295eea8ef

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Sakari Ailus]

Hi Dongcheng,

On Fri, Apr 25, 2025 at 06:43:30PM +0800, Dongcheng Yan wrote:
> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> being received. On the host side this is wired to a GPIO for polling or
> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> lt6911uxe and lt6911uxc.
> 
> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> here as well.
> 
> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>

Thanks for the update.

Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>

-- 
Regards,

Sakari Ailus

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]

On Fri, 25 Apr 2025, Dongcheng Yan wrote:

> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> being received. On the host side this is wired to a GPIO for polling or
> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> lt6911uxe and lt6911uxc.
> 
> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> here as well.
> 
> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> ---
>  drivers/platform/x86/intel/int3472/common.h   | 1 +
>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> index 51b818e62a25..4593d567caf4 100644
> --- a/drivers/platform/x86/intel/int3472/common.h
> +++ b/drivers/platform/x86/intel/int3472/common.h
> @@ -23,6 +23,7 @@
>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
>  
>  #define INT3472_PDEV_MAX_NAME_LEN				23
>  #define INT3472_MAX_SENSOR_GPIOS				3
> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> index 394975f55d64..efa3bc7af193 100644
> --- a/drivers/platform/x86/intel/int3472/discrete.c
> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>  		*con_id = "privacy-led";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>  		break;
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> +		*con_id = "hpd";
> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> +		break;
>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
>  		*con_id = "avdd";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>   * 0x0b Power enable
>   * 0x0c Clock enable
>   * 0x0d Privacy LED
> + * 0x13 Hotplug detect
>   *
>   * There are some known platform specific quirks where that does not quite
>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>  	switch (type) {
>  	case INT3472_GPIO_TYPE_RESET:
>  	case INT3472_GPIO_TYPE_POWERDOWN:
> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
>  		if (ret)
>  			err_msg = "Failed to map GPIO pin to sensor\n";

I was informed about existance of this patch through an off-band channel 
(as I was not among receipients). In future, please include all relevant 
maintainers and MLs as receipients as indicated by 
scripts/get_maintainers.pl.

This may go through a media tree,

Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>


-- 
 i.

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Yan, Dongcheng]

Hi Ilpo,

On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> 
>> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
>> being received. On the host side this is wired to a GPIO for polling or
>> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
>> lt6911uxe and lt6911uxc.
>>
>> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
>> here as well.
>>
>> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
>> ---
>>  drivers/platform/x86/intel/int3472/common.h   | 1 +
>>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
>> index 51b818e62a25..4593d567caf4 100644
>> --- a/drivers/platform/x86/intel/int3472/common.h
>> +++ b/drivers/platform/x86/intel/int3472/common.h
>> @@ -23,6 +23,7 @@
>>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
>>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
>>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
>> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
>>  
>>  #define INT3472_PDEV_MAX_NAME_LEN				23
>>  #define INT3472_MAX_SENSOR_GPIOS				3
>> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
>> index 394975f55d64..efa3bc7af193 100644
>> --- a/drivers/platform/x86/intel/int3472/discrete.c
>> +++ b/drivers/platform/x86/intel/int3472/discrete.c
>> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>>  		*con_id = "privacy-led";
>>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>>  		break;
>> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
>> +		*con_id = "hpd";
>> +		*gpio_flags = GPIO_ACTIVE_HIGH;
>> +		break;
>>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
>>  		*con_id = "avdd";
>>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>>   * 0x0b Power enable
>>   * 0x0c Clock enable
>>   * 0x0d Privacy LED
>> + * 0x13 Hotplug detect
>>   *
>>   * There are some known platform specific quirks where that does not quite
>>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
>> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>>  	switch (type) {
>>  	case INT3472_GPIO_TYPE_RESET:
>>  	case INT3472_GPIO_TYPE_POWERDOWN:
>> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
>>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
>>  		if (ret)
>>  			err_msg = "Failed to map GPIO pin to sensor\n";
> 
> I was informed about existance of this patch through an off-band channel 
> (as I was not among receipients). In future, please include all relevant 
> maintainers and MLs as receipients as indicated by 
> scripts/get_maintainers.pl.
> 
> This may go through a media tree,
> 
> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> 

Thanks a lot and sorry for the trouble caused by me.

Thanks,
Dongcheng

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Sakari Ailus]

Hi Dongcheng, Ilpo,

On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
> Hi Ilpo,
> 
> On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> > On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> > 
> >> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> >> being received. On the host side this is wired to a GPIO for polling or
> >> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> >> lt6911uxe and lt6911uxc.
> >>
> >> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> >> here as well.
> >>
> >> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> >> ---
> >>  drivers/platform/x86/intel/int3472/common.h   | 1 +
> >>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
> >>  2 files changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> >> index 51b818e62a25..4593d567caf4 100644
> >> --- a/drivers/platform/x86/intel/int3472/common.h
> >> +++ b/drivers/platform/x86/intel/int3472/common.h
> >> @@ -23,6 +23,7 @@
> >>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
> >>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
> >>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> >> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
> >>  
> >>  #define INT3472_PDEV_MAX_NAME_LEN				23
> >>  #define INT3472_MAX_SENSOR_GPIOS				3
> >> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> >> index 394975f55d64..efa3bc7af193 100644
> >> --- a/drivers/platform/x86/intel/int3472/discrete.c
> >> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> >> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> >>  		*con_id = "privacy-led";
> >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> >>  		break;
> >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> >> +		*con_id = "hpd";
> >> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> >> +		break;
> >>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
> >>  		*con_id = "avdd";
> >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> >> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> >>   * 0x0b Power enable
> >>   * 0x0c Clock enable
> >>   * 0x0d Privacy LED
> >> + * 0x13 Hotplug detect
> >>   *
> >>   * There are some known platform specific quirks where that does not quite
> >>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> >> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> >>  	switch (type) {
> >>  	case INT3472_GPIO_TYPE_RESET:
> >>  	case INT3472_GPIO_TYPE_POWERDOWN:
> >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> >>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
> >>  		if (ret)
> >>  			err_msg = "Failed to map GPIO pin to sensor\n";
> > 
> > I was informed about existance of this patch through an off-band channel 
> > (as I was not among receipients). In future, please include all relevant 
> > maintainers and MLs as receipients as indicated by 
> > scripts/get_maintainers.pl.

Hans used to handle these previously and I think that's why you weren't
cc'd.

> > 
> > This may go through a media tree,
> > 
> > Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>

Thank you!

> > 
> > 
> 
> Thanks a lot and sorry for the trouble caused by me.

No worries.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 4245 bytes --]

On Wed, 2 Jul 2025, Sakari Ailus wrote:

> Hi Dongcheng, Ilpo,
> 
> On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
> > Hi Ilpo,
> > 
> > On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> > > On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> > > 
> > >> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> > >> being received. On the host side this is wired to a GPIO for polling or
> > >> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> > >> lt6911uxe and lt6911uxc.
> > >>
> > >> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> > >> here as well.
> > >>
> > >> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> > >> ---
> > >>  drivers/platform/x86/intel/int3472/common.h   | 1 +
> > >>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
> > >>  2 files changed, 7 insertions(+)
> > >>
> > >> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> > >> index 51b818e62a25..4593d567caf4 100644
> > >> --- a/drivers/platform/x86/intel/int3472/common.h
> > >> +++ b/drivers/platform/x86/intel/int3472/common.h
> > >> @@ -23,6 +23,7 @@
> > >>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
> > >>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
> > >>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> > >> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
> > >>  
> > >>  #define INT3472_PDEV_MAX_NAME_LEN				23
> > >>  #define INT3472_MAX_SENSOR_GPIOS				3
> > >> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> > >> index 394975f55d64..efa3bc7af193 100644
> > >> --- a/drivers/platform/x86/intel/int3472/discrete.c
> > >> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> > >> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > >>  		*con_id = "privacy-led";
> > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >>  		break;
> > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > >> +		*con_id = "hpd";
> > >> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >> +		break;
> > >>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
> > >>  		*con_id = "avdd";
> > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > >> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > >>   * 0x0b Power enable
> > >>   * 0x0c Clock enable
> > >>   * 0x0d Privacy LED
> > >> + * 0x13 Hotplug detect
> > >>   *
> > >>   * There are some known platform specific quirks where that does not quite
> > >>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> > >> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > >>  	switch (type) {
> > >>  	case INT3472_GPIO_TYPE_RESET:
> > >>  	case INT3472_GPIO_TYPE_POWERDOWN:
> > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > >>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
> > >>  		if (ret)
> > >>  			err_msg = "Failed to map GPIO pin to sensor\n";
> > > 
> > > I was informed about existance of this patch through an off-band channel 
> > > (as I was not among receipients). In future, please include all relevant 
> > > maintainers and MLs as receipients as indicated by 
> > > scripts/get_maintainers.pl.
> 
> Hans used to handle these previously and I think that's why you weren't
> cc'd.

I understand I'm relatively new to this and changes such as this can be 
easily missed for relatively long time. However, it won't explain why 
pdx86 ML was not included.

Usually it's an indication of using fragile patch sending routine if the 
get_maintainers.pl provided receipients are not factored in at least 
semi-automatically at the time of sending, and ends up easily missing 
necessary receipients. So my suggestion is the original submitter looks 
into the process used at the moment of sending the patches out.

-- 
 i.

> > > This may go through a media tree,
> > > 
> > > Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> Thank you!
> 
> > > 
> > > 
> > 
> > Thanks a lot and sorry for the trouble caused by me.
> 
> No worries.
> 
> 

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Sakari Ailus]

On Wed, Jul 02, 2025 at 02:09:04PM +0300, Ilpo Järvinen wrote:
> On Wed, 2 Jul 2025, Sakari Ailus wrote:
> 
> > Hi Dongcheng, Ilpo,
> > 
> > On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
> > > Hi Ilpo,
> > > 
> > > On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> > > > On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> > > > 
> > > >> Typically HDMI to MIPI CSI-2 bridges have a pin to signal image data is
> > > >> being received. On the host side this is wired to a GPIO for polling or
> > > >> interrupts. This includes the Lontium HDMI to MIPI CSI-2 bridges
> > > >> lt6911uxe and lt6911uxc.
> > > >>
> > > >> The GPIO "hpd" is used already by other HDMI to CSI-2 bridges, use it
> > > >> here as well.
> > > >>
> > > >> Signed-off-by: Dongcheng Yan <dongcheng.yan@intel.com>
> > > >> ---
> > > >>  drivers/platform/x86/intel/int3472/common.h   | 1 +
> > > >>  drivers/platform/x86/intel/int3472/discrete.c | 6 ++++++
> > > >>  2 files changed, 7 insertions(+)
> > > >>
> > > >> diff --git a/drivers/platform/x86/intel/int3472/common.h b/drivers/platform/x86/intel/int3472/common.h
> > > >> index 51b818e62a25..4593d567caf4 100644
> > > >> --- a/drivers/platform/x86/intel/int3472/common.h
> > > >> +++ b/drivers/platform/x86/intel/int3472/common.h
> > > >> @@ -23,6 +23,7 @@
> > > >>  #define INT3472_GPIO_TYPE_CLK_ENABLE				0x0c
> > > >>  #define INT3472_GPIO_TYPE_PRIVACY_LED				0x0d
> > > >>  #define INT3472_GPIO_TYPE_HANDSHAKE				0x12
> > > >> +#define INT3472_GPIO_TYPE_HOTPLUG_DETECT			0x13
> > > >>  
> > > >>  #define INT3472_PDEV_MAX_NAME_LEN				23
> > > >>  #define INT3472_MAX_SENSOR_GPIOS				3
> > > >> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> > > >> index 394975f55d64..efa3bc7af193 100644
> > > >> --- a/drivers/platform/x86/intel/int3472/discrete.c
> > > >> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> > > >> @@ -191,6 +191,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > > >>  		*con_id = "privacy-led";
> > > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > > >>  		break;
> > > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > > >> +		*con_id = "hpd";
> > > >> +		*gpio_flags = GPIO_ACTIVE_HIGH;
> > > >> +		break;
> > > >>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
> > > >>  		*con_id = "avdd";
> > > >>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> > > >> @@ -221,6 +225,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
> > > >>   * 0x0b Power enable
> > > >>   * 0x0c Clock enable
> > > >>   * 0x0d Privacy LED
> > > >> + * 0x13 Hotplug detect
> > > >>   *
> > > >>   * There are some known platform specific quirks where that does not quite
> > > >>   * hold up; for example where a pin with type 0x01 (Power down) is mapped to
> > > >> @@ -290,6 +295,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
> > > >>  	switch (type) {
> > > >>  	case INT3472_GPIO_TYPE_RESET:
> > > >>  	case INT3472_GPIO_TYPE_POWERDOWN:
> > > >> +	case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
> > > >>  		ret = skl_int3472_map_gpio_to_sensor(int3472, agpio, con_id, gpio_flags);
> > > >>  		if (ret)
> > > >>  			err_msg = "Failed to map GPIO pin to sensor\n";
> > > > 
> > > > I was informed about existance of this patch through an off-band channel 
> > > > (as I was not among receipients). In future, please include all relevant 
> > > > maintainers and MLs as receipients as indicated by 
> > > > scripts/get_maintainers.pl.
> > 
> > Hans used to handle these previously and I think that's why you weren't
> > cc'd.
> 
> I understand I'm relatively new to this and changes such as this can be 
> easily missed for relatively long time. However, it won't explain why 
> pdx86 ML was not included.
> 
> Usually it's an indication of using fragile patch sending routine if the 
> get_maintainers.pl provided receipients are not factored in at least 
> semi-automatically at the time of sending, and ends up easily missing 
> necessary receipients. So my suggestion is the original submitter looks 
> into the process used at the moment of sending the patches out.

I just posted v4, to the appropriate recipients I hope. Another int3472
conflicted with v3.

-- 
Regards,

Sakari Ailus

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Andy Shevchenko]

On Wed, Jul 02, 2025 at 01:53:36PM +0300, Sakari Ailus wrote:
> On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
> > On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
> > > On Fri, 25 Apr 2025, Dongcheng Yan wrote:

...

> > > I was informed about existance of this patch through an off-band channel 
> > > (as I was not among receipients). In future, please include all relevant 
> > > maintainers and MLs as receipients as indicated by 
> > > scripts/get_maintainers.pl.
> 
> Hans used to handle these previously and I think that's why you weren't
> cc'd.

There are two maintainers of this subsystem and both should be included, no?
At least I have my own script [1] to send patches and it gives a good heuristics
of who to include and not. I believe it might give better result then I don't
know how derived Cc list in this series.

[1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 1/2] platform/x86: int3472: add hpd pin support

[Yan, Dongcheng]

Hi Andy,

On 7/2/2025 7:48 PM, Andy Shevchenko wrote:
> On Wed, Jul 02, 2025 at 01:53:36PM +0300, Sakari Ailus wrote:
>> On Wed, Jul 02, 2025 at 06:23:19PM +0800, Yan, Dongcheng wrote:
>>> On 7/2/2025 6:19 PM, Ilpo Järvinen wrote:
>>>> On Fri, 25 Apr 2025, Dongcheng Yan wrote:
> 
> ...
> 
>>>> I was informed about existance of this patch through an off-band channel 
>>>> (as I was not among receipients). In future, please include all relevant 
>>>> maintainers and MLs as receipients as indicated by 
>>>> scripts/get_maintainers.pl.
>>
>> Hans used to handle these previously and I think that's why you weren't
>> cc'd.
> 
> There are two maintainers of this subsystem and both should be included, no?

I'm sorry that I didn't even know the rules of to/cc before this. I just
choose some of maintainers randomly indicated by get_maintainers.pl as
"to" and choose some as "cc". I will read the document carefully to
avoid such problems from happening again.

> At least I have my own script [1] to send patches and it gives a good heuristics
> of who to include and not. I believe it might give better result then I don't
> know how derived Cc list in this series.
> 
> [1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh
> 
good script to me, give a try next time.

Thanks,
Dongcheng