[PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support

Chancel Liu posted 3 patches 1 week, 4 days ago
.../devicetree/bindings/sound/fsl,rpmsg.yaml         |  4 ++++
sound/soc/fsl/Kconfig                                |  1 +
sound/soc/fsl/imx-rpmsg.c                            | 12 ++++++++++++
3 files changed, 17 insertions(+)
[PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
Posted by Chancel Liu 1 week, 4 days ago
This series adds two features to the i.MX RPMSG ASoC card:
1. Headphone jack detection via GPIO: Introduce the "hp-det-gpios"
   device tree property and use simple_util_init_jack() to
   register a headphone jack with GPIO-based insertion detection.

2. driver_name assignment: Set driver_name on the snd_soc_card to
   "imx-audio-rpmsg", enabling userspace tools such as UCM to reliably
   identify the card by driver name regardless of the board-specific
   card name.

Changes in v2:
- Add Kconfig dependency on SND_SOC_SIMPLE_CARD_UTILS
- Moved headphone jack initialization from probe() to late_probe()
to avoid interaction issues with deferred probe

Chancel Liu (3):
  ASoC: dt-bindings: fsl,rpmsg: Add hp-det-gpios property
  ASoC: imx-rpmsg: Support headphone jack detection
  ASoC: imx-rpmsg: Set driver_name for snd_soc_card

 .../devicetree/bindings/sound/fsl,rpmsg.yaml         |  4 ++++
 sound/soc/fsl/Kconfig                                |  1 +
 sound/soc/fsl/imx-rpmsg.c                            | 12 ++++++++++++
 3 files changed, 17 insertions(+)

--
2.50.1
Re: [PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
Posted by Andrew Lunn 1 week, 4 days ago
On Thu, May 28, 2026 at 11:07:22AM +0900, Chancel Liu wrote:
> This series adds two features to the i.MX RPMSG ASoC card:
> 1. Headphone jack detection via GPIO: Introduce the "hp-det-gpios"
>    device tree property and use simple_util_init_jack() to
>    register a headphone jack with GPIO-based insertion detection.

I'm not familiar with ASoC, but have been in a long discussion about
RPMSG and GPIO....

I just want to confirm the GPIO you are talking about is a local GPIO?
You are not tunnelling the GPIO over RPMSG using some vendor protocol?

	Andrew
Re: [PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
Posted by Mark Brown 1 week, 4 days ago
On Thu, May 28, 2026 at 04:12:58PM +0200, Andrew Lunn wrote:
> On Thu, May 28, 2026 at 11:07:22AM +0900, Chancel Liu wrote:

> > This series adds two features to the i.MX RPMSG ASoC card:
> > 1. Headphone jack detection via GPIO: Introduce the "hp-det-gpios"
> >    device tree property and use simple_util_init_jack() to
> >    register a headphone jack with GPIO-based insertion detection.

> I'm not familiar with ASoC, but have been in a long discussion about
> RPMSG and GPIO....

> I just want to confirm the GPIO you are talking about is a local GPIO?
> You are not tunnelling the GPIO over RPMSG using some vendor protocol?

This is a GPIO accessed via gpiolib, the driver is for an audio
subsystem accessed via rpmsg.
Re: [PATCH v2 0/3] ASoC: imx-rpmsg: Add headphone jack detection and driver_name support
Posted by Andrew Lunn 1 week, 4 days ago
On Thu, May 28, 2026 at 03:18:05PM +0100, Mark Brown wrote:
> On Thu, May 28, 2026 at 04:12:58PM +0200, Andrew Lunn wrote:
> > On Thu, May 28, 2026 at 11:07:22AM +0900, Chancel Liu wrote:
> 
> > > This series adds two features to the i.MX RPMSG ASoC card:
> > > 1. Headphone jack detection via GPIO: Introduce the "hp-det-gpios"
> > >    device tree property and use simple_util_init_jack() to
> > >    register a headphone jack with GPIO-based insertion detection.
> 
> > I'm not familiar with ASoC, but have been in a long discussion about
> > RPMSG and GPIO....
> 
> > I just want to confirm the GPIO you are talking about is a local GPIO?
> > You are not tunnelling the GPIO over RPMSG using some vendor protocol?
> 
> This is a GPIO accessed via gpiolib, the driver is for an audio
> subsystem accessed via rpmsg.

Great, thanks.

When we eventually get GPIO over RPMSG, it should also just look like
a standard gpiolib GPIO. But we are not there yet, defining the one
protocol that all vendors must use, rather than each vendor doing
their own thing.

  Andrew