[PATCH 0/4] ROCK 4D audio enablement

[PATCH 0/4] ROCK 4D audio enablement

[Nicolas Frattaroli]

The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
no mic) and a headset (i.e., with mic). After some searching, it appears
that the closest we can get to modelling this is by sending a particular
switch input event.

So this series modifies the adc-keys bindings, extends the adc-keys
driver to allow sending other input types as well, and then adds the
analog and HDMI audio nodes to ROCK 4D's device tree.

It should be noted that analog capture from the TRRS jack currently
results in completely digitally silent audio for me, i.e. no data other
than 0xFF. There's a few reasons why this could happen, chief among them
that my SAI driver is broken or that the ES8328 codec driver is once
again broken. The DAPM routes when graphed out look fine though. So the
DTS part is correct, and I can fix the broken capture in a separate
follow-up patch that doesn't have to include DT people.

Another possibility is that my phone headset, despite being 4 rings and
having a little pin hole at the back of the volume doodad, does not
actually have a microphone, but in that case I'd still expect some noise
in the PCM. Maybe it's just shy.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Nicolas Frattaroli (4):
      dt-bindings: input: adc-keys: allow linux,input-type property
      Input: adc-keys - support types that aren't just keyboard keys
      arm64: dts: rockchip: add analog audio to ROCK 4D
      arm64: dts: rockchip: add HDMI audio on ROCK 4D

 .../devicetree/bindings/input/adc-keys.yaml        |  3 +
 arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts    | 98 ++++++++++++++++++++++
 drivers/input/keyboard/adc-keys.c                  | 16 +++-
 3 files changed, 113 insertions(+), 4 deletions(-)
---
base-commit: c6a68d8f7b81a6ce8962885408cc2d0c1f8b9470
change-id: 20250627-rock4d-audio-cfc07f168a08

Best regards,
-- 
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

[PATCH 1/4] dt-bindings: input: adc-keys: allow linux,input-type property

[Nicolas Frattaroli]

adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
property. This makes it impossible to model devices that have ADC inputs
that should generate switch events.

Add the property to the binding with the same default as gpio-keys.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 Documentation/devicetree/bindings/input/adc-keys.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/adc-keys.yaml b/Documentation/devicetree/bindings/input/adc-keys.yaml
index 7aa078dead37816294732501e1983ab869f38311..e372ebc23d1651d73ef3749a56d54872067037b5 100644
--- a/Documentation/devicetree/bindings/input/adc-keys.yaml
+++ b/Documentation/devicetree/bindings/input/adc-keys.yaml
@@ -42,6 +42,9 @@ patternProperties:
 
       linux,code: true
 
+      linux,input-type:
+        default: 1  # EV_KEY
+
       press-threshold-microvolt:
         description:
           Voltage above or equal to which this key is considered pressed. No

-- 
2.50.0

Re: [PATCH 1/4] dt-bindings: input: adc-keys: allow linux,input-type property

[Heiko Stübner]

Am Montag, 30. Juni 2025, 12:19:24 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
> property. This makes it impossible to model devices that have ADC inputs
> that should generate switch events.
> 
> Add the property to the binding with the same default as gpio-keys.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  Documentation/devicetree/bindings/input/adc-keys.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.yaml b/Documentation/devicetree/bindings/input/adc-keys.yaml
> index 7aa078dead37816294732501e1983ab869f38311..e372ebc23d1651d73ef3749a56d54872067037b5 100644
> --- a/Documentation/devicetree/bindings/input/adc-keys.yaml
> +++ b/Documentation/devicetree/bindings/input/adc-keys.yaml
> @@ -42,6 +42,9 @@ patternProperties:
>  
>        linux,code: true
>  
> +      linux,input-type:
> +        default: 1  # EV_KEY
> +

having both adc- and gpio-keys behave the same in that regard makes a lot
of sense, and the addition matches gpio-keys.yaml, so

Reviewed-by: Heiko Stuebner <heiko@sntech.de>

>        press-threshold-microvolt:
>          description:
>            Voltage above or equal to which this key is considered pressed. No
> 
> 

[PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys

[Nicolas Frattaroli]

Instead of doing something like what gpio-keys is doing, adc-keys
hardcodes that all keycodes must be of type EV_KEY.

This limits the usefulness of adc-keys, and overcomplicates the code
with manual bit-setting logic.

Instead, refactor the code to read the linux,input-type fwnode property,
and get rid of the custom bit setting logic, replacing it with
input_set_capability instead. input_report_key is replaced with
input_event, which allows us to explicitly pass the type.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/input/keyboard/adc-keys.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
index f1753207429db02ce6510e5ec0da9b24d9edb61d..339dd4d4a0842108da2c6136b1e0098cd1f6a3cd 100644
--- a/drivers/input/keyboard/adc-keys.c
+++ b/drivers/input/keyboard/adc-keys.c
@@ -19,12 +19,14 @@
 struct adc_keys_button {
 	u32 voltage;
 	u32 keycode;
+	u32 type;
 };
 
 struct adc_keys_state {
 	struct iio_channel *channel;
 	u32 num_keys;
 	u32 last_key;
+	u32 last_type;
 	u32 keyup_voltage;
 	const struct adc_keys_button *map;
 };
@@ -35,6 +37,7 @@ static void adc_keys_poll(struct input_dev *input)
 	int i, value, ret;
 	u32 diff, closest = 0xffffffff;
 	int keycode = 0;
+	u32 type = EV_KEY;
 
 	ret = iio_read_channel_processed(st->channel, &value);
 	if (unlikely(ret < 0)) {
@@ -46,6 +49,7 @@ static void adc_keys_poll(struct input_dev *input)
 			if (diff < closest) {
 				closest = diff;
 				keycode = st->map[i].keycode;
+				type = st->map[i].type;
 			}
 		}
 	}
@@ -54,13 +58,14 @@ static void adc_keys_poll(struct input_dev *input)
 		keycode = 0;
 
 	if (st->last_key && st->last_key != keycode)
-		input_report_key(input, st->last_key, 0);
+		input_event(input, st->last_type, st->last_key, 0);
 
 	if (keycode)
-		input_report_key(input, keycode, 1);
+		input_event(input, type, keycode, 1);
 
 	input_sync(input);
 	st->last_key = keycode;
+	st->last_type = type;
 }
 
 static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
@@ -93,6 +98,10 @@ static int adc_keys_load_keymap(struct device *dev, struct adc_keys_state *st)
 			return -EINVAL;
 		}
 
+		if (fwnode_property_read_u32(child, "linux,input-type",
+					     &map[i].type))
+			map[i].type = EV_KEY;
+
 		i++;
 	}
 
@@ -156,9 +165,8 @@ static int adc_keys_probe(struct platform_device *pdev)
 	input->id.product = 0x0001;
 	input->id.version = 0x0100;
 
-	__set_bit(EV_KEY, input->evbit);
 	for (i = 0; i < st->num_keys; i++)
-		__set_bit(st->map[i].keycode, input->keybit);
+		input_set_capability(input, st->map[i].type, st->map[i].keycode);
 
 	if (device_property_read_bool(dev, "autorepeat"))
 		__set_bit(EV_REP, input->evbit);

-- 
2.50.0

Re: [PATCH 2/4] Input: adc-keys - support types that aren't just keyboard keys

[Heiko Stübner]

Am Montag, 30. Juni 2025, 12:19:25 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> Instead of doing something like what gpio-keys is doing, adc-keys
> hardcodes that all keycodes must be of type EV_KEY.
> 
> This limits the usefulness of adc-keys, and overcomplicates the code
> with manual bit-setting logic.
> 
> Instead, refactor the code to read the linux,input-type fwnode property,
> and get rid of the custom bit setting logic, replacing it with
> input_set_capability instead. input_report_key is replaced with
> input_event, which allows us to explicitly pass the type.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  drivers/input/keyboard/adc-keys.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
> index f1753207429db02ce6510e5ec0da9b24d9edb61d..339dd4d4a0842108da2c6136b1e0098cd1f6a3cd 100644
> --- a/drivers/input/keyboard/adc-keys.c
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -19,12 +19,14 @@
>  struct adc_keys_button {
>  	u32 voltage;
>  	u32 keycode;

nit: consistency ... the above is still "keycode"
Naming things "code" like in gpio-keys might make sense maybe?
Though I guess, it could also just be needless churn

> +	u32 type;
>  };
>  
>  struct adc_keys_state {
>  	struct iio_channel *channel;
>  	u32 num_keys;
>  	u32 last_key;

^^ same

I'v checked that the function transistions 
- __set_bit -> input_set_capability
- input_report_key -> input_event

do the right thing,

Reviewed-by: Heiko Stuebner <heiko@sntech.de>

[PATCH 3/4] arm64: dts: rockchip: add analog audio to ROCK 4D

[Nicolas Frattaroli]

The RADXA ROCK 4D, like many other Rockchip-based boards, uses an ES8388
analog audio codec. On the production version of the board, the codec's
LOUT1 and ROUT1 pins are tied to the headphone jack, whereas pins LOUT2
and ROUT2 lead to a non-populated speaker amplifier that itself leads to
a non-populated speaker jack. The schematic is still haunted by the
ghosts of those symbols, but it clearly marks them as "NC".

The 3.5mm TRRS jack has its microphone ring (and ground ring) wired to
the codec's LINPUT1 and RINPUT1 pins for differential signalling.

Furthermore, it uses the SoCs ADC to detect whether the inserted cable
is of headphones (i.e., no microphone), or a headset (i.e., with
microphone). The way this is done is that the ADC input taps the output
of a 100K/100K resistor divider that divides the microphone ring pin
that's pulled up to 3.3V.

There is no ADC level difference between a completely empty jack and one
with a set of headphones (i.e., ones that don't have a microphone)
connected. Consequently headphone insertion detection isn't something
that can be done.

Add the necessary codec and audio card nodes. The non-populated parts,
i.e. LOUT2 and ROUT2, are not modeled at all, as they are not present on
the hardware.

Also, add an adc-keys node for the headset detection, which uses an
input type of EV_SW with the SW_MICROPHONE_INSERT keycode. Below the
220mV pressed voltage level of our SW_MICROPHONE_INSERT switch, we also
define a button that emits a KEY_RESERVED code, which is there to model
this part of the voltage range as not just being extra legroom for the
button above it, but actually a state that is encountered in the real
world, and should be recognised as a valid state for the ADC range to be
in so that no "closer" ADC button is chosen.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 90 +++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
index 6756403111e704cad42f6674d5ab55eb0306f1e3..4d4b8ababd2436b82515443b029916b3c786dba1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/leds/common.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/pwm/pwm.h>
@@ -37,6 +38,31 @@ hdmi_con_in: endpoint {
 		};
 	};
 
+	es8388_sound: es8388-sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		simple-audio-card,mclk-fs = <256>;
+		simple-audio-card,name = "On-board Analog ES8388";
+		simple-audio-card,widgets = "Microphone", "Headphone Mic",
+					    "Headphone", "Headphone";
+		simple-audio-card,routing = "Headphone", "LOUT1",
+					    "Headphone", "ROUT1",
+					    "Left PGA Mux", "Differential Mux",
+					    "Differential Mux", "LINPUT1",
+					    "Differential Mux", "RINPUT1",
+					    "LINPUT1", "Headphone Mic",
+					    "RINPUT1", "Headphone Mic";
+
+		simple-audio-card,cpu {
+			sound-dai = <&sai1>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&es8388>;
+			system-clock-frequency = <12288000>;
+		};
+	};
+
 	leds: leds {
 		compatible = "gpio-leds";
 		pinctrl-names = "default";
@@ -57,6 +83,37 @@ user-led {
 		};
 	};
 
+	saradc_keys: adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 3>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <3000000>;
+		poll-interval = <100>;
+
+		/*
+		 * During insertion and removal of a regular set of headphones,
+		 * i.e. one without a microphone, the voltage level briefly
+		 * dips below the 220mV of the headset connection switch.
+		 * By having a button definition with a KEY_RESERVED signal
+		 * between 0 to 220, we ensure no driver implementation thinks
+		 * that the closest thing to 0V is 220mV so clearly there must
+		 * be a headset connected.
+		 */
+
+		button-headset-disconnected {
+			label = "Headset Microphone Disconnected";
+			linux,code = <KEY_RESERVED>;
+			press-threshold-microvolt = <0>;
+		};
+
+		button-headset-connected {
+			label = "Headset Microphone Connected";
+			linux,code = <SW_MICROPHONE_INSERT>;
+			linux,input-type = <EV_SW>;
+			press-threshold-microvolt = <220000>;
+		};
+	};
+
 	vcc_12v0_dcin: regulator-vcc-12v0-dcin {
 		compatible = "regulator-fixed";
 		regulator-always-on;
@@ -639,6 +696,25 @@ hym8563: rtc@51 {
 	};
 };
 
+&i2c3 {
+	status = "okay";
+
+	es8388: audio-codec@10 {
+		compatible = "everest,es8388", "everest,es8328";
+		reg = <0x10>;
+		clocks = <&cru CLK_SAI1_MCLKOUT_TO_IO>;
+		AVDD-supply = <&vcca_3v3_s0>;
+		DVDD-supply = <&vcc_3v3_s0>;
+		HPVDD-supply = <&vcca_3v3_s0>;
+		PVDD-supply = <&vcc_3v3_s0>;
+		assigned-clocks = <&cru CLK_SAI1_MCLKOUT_TO_IO>;
+		assigned-clock-rates = <12288000>;
+		#sound-dai-cells = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sai1m0_mclk>;
+	};
+};
+
 &mdio0 {
 	rgmii_phy0: ethernet-phy@1 {
 		compatible = "ethernet-phy-ieee802.3-c22";
@@ -687,6 +763,20 @@ usb_host_pwren: usb-host-pwren {
 	};
 };
 
+&sai1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sai1m0_lrck
+		     &sai1m0_sclk
+		     &sai1m0_sdi0
+		     &sai1m0_sdo0>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_pldo2_s0>;
+	status = "okay";
+};
+
 &sdmmc {
 	bus-width = <4>;
 	cap-mmc-highspeed;

-- 
2.50.0

Re: [PATCH 3/4] arm64: dts: rockchip: add analog audio to ROCK 4D

[Cristian Ciocaltea]

On 6/30/25 1:19 PM, Nicolas Frattaroli wrote:
> The RADXA ROCK 4D, like many other Rockchip-based boards, uses an ES8388
> analog audio codec. On the production version of the board, the codec's
> LOUT1 and ROUT1 pins are tied to the headphone jack, whereas pins LOUT2
> and ROUT2 lead to a non-populated speaker amplifier that itself leads to
> a non-populated speaker jack. The schematic is still haunted by the
> ghosts of those symbols, but it clearly marks them as "NC".
> 
> The 3.5mm TRRS jack has its microphone ring (and ground ring) wired to
> the codec's LINPUT1 and RINPUT1 pins for differential signalling.
> 
> Furthermore, it uses the SoCs ADC to detect whether the inserted cable
> is of headphones (i.e., no microphone), or a headset (i.e., with
> microphone). The way this is done is that the ADC input taps the output
> of a 100K/100K resistor divider that divides the microphone ring pin
> that's pulled up to 3.3V.
> 
> There is no ADC level difference between a completely empty jack and one
> with a set of headphones (i.e., ones that don't have a microphone)
> connected. Consequently headphone insertion detection isn't something
> that can be done.
> 
> Add the necessary codec and audio card nodes. The non-populated parts,
> i.e. LOUT2 and ROUT2, are not modeled at all, as they are not present on
> the hardware.
> 
> Also, add an adc-keys node for the headset detection, which uses an
> input type of EV_SW with the SW_MICROPHONE_INSERT keycode. Below the
> 220mV pressed voltage level of our SW_MICROPHONE_INSERT switch, we also
> define a button that emits a KEY_RESERVED code, which is there to model
> this part of the voltage range as not just being extra legroom for the
> button above it, but actually a state that is encountered in the real
> world, and should be recognised as a valid state for the ADC range to be
> in so that no "closer" ADC button is chosen.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

Enabled CONFIG_SND_SOC_ES8328_I2C and confirm playback works fine:

    $ speaker-test -D hw:ES8388,0 -F S16_LE -c 2 -t wav

Unfortunately the recording doesn't seem to be functional:

    $ arecord -D hw:ES8388,0 -f S16_LE -c 2 -r 48000 -d 5 -V stereo /tmp/test.wav
    Recording WAVE '/tmp/test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
                                    +00%|00%+

    $ aplay -D hw:ES8388,0 /tmp/test.wav

However, the headset plug detection works correctly:

    $ evtest
    No device specified, trying to scan all of /dev/input/event*
    Available devices:
    /dev/input/event0:	Logitech USB Receiver
    /dev/input/event1:	Logitech USB Receiver Mouse
    /dev/input/event2:	Logitech USB Receiver Consumer Control
    /dev/input/event3:	Logitech USB Receiver System Control
    /dev/input/event4:	adc-keys
    Select the device event number [0-4]: 4
    Input driver version is 1.0.1
    Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
    Input device name: "adc-keys"
    Supported events:
      Event type 0 (EV_SYN)
      Event type 1 (EV_KEY)
      Event type 5 (EV_SW)
        Event code 4 (SW_MICROPHONE_INSERT) state 0
    Properties:
    Testing ... (interrupt to exit)
    Event: time 1751449448.185340, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
    Event: time 1751449448.185340, -------------- SYN_REPORT ------------
    Event: time 1751449448.289477, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 0
    Event: time 1751449448.289477, -------------- SYN_REPORT ------------
    Event: time 1751449449.329482, type 5 (EV_SW), code 4 (SW_MICROPHONE_INSERT), value 1
    Event: time 1751449449.329482, -------------- SYN_REPORT ------------

Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

[PATCH 4/4] arm64: dts: rockchip: add HDMI audio on ROCK 4D

[Nicolas Frattaroli]

Much like the Sige5, the ROCK 4D also has an HDMI port, so is capable of
providing HDMI audio output as well.

Enable the SoC's hdmi_sound card, and also enable the SoC audio
controller (sai6) that feeds into it.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
index 4d4b8ababd2436b82515443b029916b3c786dba1..70bc6f909ec0843607c2705ee9f73b0ba521a977 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts
@@ -322,6 +322,10 @@ hdmi_out_con: endpoint {
 	};
 };
 
+&hdmi_sound {
+	status = "okay";
+};
+
 &hdptxphy {
 	status = "okay";
 };
@@ -772,6 +776,10 @@ &sai1m0_sdi0
 	status = "okay";
 };
 
+&sai6 {
+	status = "okay";
+};
+
 &saradc {
 	vref-supply = <&vcca1v8_pldo2_s0>;
 	status = "okay";

-- 
2.50.0

Re: [PATCH 4/4] arm64: dts: rockchip: add HDMI audio on ROCK 4D

[Cristian Ciocaltea]

On 6/30/25 1:19 PM, Nicolas Frattaroli wrote:
> Much like the Sige5, the ROCK 4D also has an HDMI port, so is capable of
> providing HDMI audio output as well.
> 
> Enable the SoC's hdmi_sound card, and also enable the SoC audio
> controller (sai6) that feeds into it.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

This worked as expected on my ROCK 4D board after enabling
CONFIG_SND_SOC_ROCKCHIP_SAI, hence

Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>

Re: (subset) [PATCH 0/4] ROCK 4D audio enablement

[Heiko Stuebner]

On Mon, 30 Jun 2025 12:19:23 +0200, Nicolas Frattaroli wrote:
> The ROCK 4D uses an ADC input to distinguish between a headphone (i.e.,
> no mic) and a headset (i.e., with mic). After some searching, it appears
> that the closest we can get to modelling this is by sending a particular
> switch input event.
> 
> So this series modifies the adc-keys bindings, extends the adc-keys
> driver to allow sending other input types as well, and then adds the
> analog and HDMI audio nodes to ROCK 4D's device tree.
> 
> [...]

Applied, thanks!

[4/4] arm64: dts: rockchip: add HDMI audio on ROCK 4D
      commit: b78165281b25b676ed3e4f71610228984222d214

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>