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@xxxxxxxxx>
> > > >> ---
> > > >>  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