Rockchip: add PineNote (rk817 + PDM microphone array)

Rockchip: add PineNote (rk817 + PDM microphone array)

[GitHub pull_request - opened]

alsa-project/alsa-ucm-conf pull request #844 was opened from cverorg:

The Pine64 PineNote pairs an rk817 codec with a four-microphone PDM array on a
second PCM. Nothing in the tree describes it, so the array is not offered as a
capture source at all — which is most of what makes the machine interesting,
since the four holes above the screen are otherwise unused by anything.

`Speaker` and `Mic1` are adapted from `Rockchip/rk817-sound`, which pairs the
same codec with the same mixer control names. `Mic2` is the array on
`hw:PineNote,1`: capture-only, four channels, and no mixer controls of its own,
because gain and routing for it are fixed in hardware.

The borrowed `If.1` block is kept verbatim, and the board's device tree explains
why it is right here rather than merely inherited: HPOL/HPOR feed the Speaker
Amp inputs, whose outputs feed `Internal Speakers`, which `pin-switches` turns
into the `Internal Speakers Switch` control. The mux has to sit on HP for the
speakers to make any sound.

### No Headphones device, on purpose

The board does have a headphone path — the codec's HPOL/HPOR go to a USB-C
audio/USB switch, and `arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi`
declares the widget for it. What it has no way to reach: the same file's
`usb-c-connector` node carries only a USB2 HS endpoint, with no audio mode and
no mode-switch or mux binding, and there is no jack detection anywhere in the
tree for `JackControl` to name. A `Headphones` device would be selectable,
silent and ungated. Worth revisiting if the connector gains an audio-mode
binding; I would rather leave it out than ship a device that does nothing.

### Validation

The alsa-info.sh dump this needs is submitted alongside as
alsa-project/alsa-tests#TESTS_PR, together with two validator fixes it needs to
run at all — a current dump is rejected before it is read, and one of the fixes
turns a `TypeError` into the error message the validator already had. With
those applied:

```
$ ./ucm.py --level 0 configs ../../../alsa-ucm-conf/ucm2 configs configs/Rockchip/PineNote.txt
$ echo $?
0
```

no errors, no warnings. The validator earned its keep on this one: it caught
`Mic Array` as an illegal device name, the `Mic`/`Mic2` mix, and two redundant
trailing `,0` PCM suffixes, all before a maintainer had to.

Checked on the hardware afterwards:

```
$ alsaucm -c PineNote set _verb HiFi list _devices
  0: Speaker
  1: Mic1
  2: Mic2
$ arecord -D hw:PineNote,1 -c 4 -r 48000 -f S16_LE -d 2 /tmp/t.wav
```

four live channels. I have the device and can re-run anything on request.

Request URL   : https://github.com/alsa-project/alsa-ucm-conf/pull/844
Patch URL     : https://github.com/alsa-project/alsa-ucm-conf/pull/844.patch
Repository URL: https://github.com/alsa-project/alsa-ucm-conf

Rockchip: add PineNote (rk817 + PDM microphone array)

[GitHub pull_request - edited]

alsa-project/alsa-ucm-conf pull request #844 was edited from cverorg:

The Pine64 PineNote pairs an rk817 codec with a four-microphone PDM array on a
second PCM. Nothing in the tree describes it, so the array is not offered as a
capture source at all — which is most of what makes the machine interesting,
since the four holes above the screen are otherwise unused by anything.

`Speaker` and `Mic1` are adapted from `Rockchip/rk817-sound`, which pairs the
same codec with the same mixer control names. `Mic2` is the array on
`hw:PineNote,1`: capture-only, four channels, and no mixer controls of its own,
because gain and routing for it are fixed in hardware.

The borrowed `If.1` block is kept verbatim, and the board's device tree explains
why it is right here rather than merely inherited: HPOL/HPOR feed the Speaker
Amp inputs, whose outputs feed `Internal Speakers`, which `pin-switches` turns
into the `Internal Speakers Switch` control. The mux has to sit on HP for the
speakers to make any sound.

### No Headphones device, on purpose

The board does have a headphone path — the codec's HPOL/HPOR go to a USB-C
audio/USB switch, and `arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi`
declares the widget for it. What it has no way to reach: the same file's
`usb-c-connector` node carries only a USB2 HS endpoint, with no audio mode and
no mode-switch or mux binding, and there is no jack detection anywhere in the
tree for `JackControl` to name. A `Headphones` device would be selectable,
silent and ungated. Worth revisiting if the connector gains an audio-mode
binding; I would rather leave it out than ship a device that does nothing.

### Validation

The alsa-info.sh dump this needs is submitted alongside as
alsa-project/alsa-tests#27, together with two validator fixes it needs to
run at all — a current dump is rejected before it is read, and one of the fixes
turns a `TypeError` into the error message the validator already had. With
those applied:

```
$ ./ucm.py --level 0 configs ../../../alsa-ucm-conf/ucm2 configs configs/Rockchip/PineNote.txt
$ echo $?
0
```

no errors, no warnings. The validator earned its keep on this one: it caught
`Mic Array` as an illegal device name, the `Mic`/`Mic2` mix, and two redundant
trailing `,0` PCM suffixes, all before a maintainer had to.

Checked on the hardware afterwards:

```
$ alsaucm -c PineNote set _verb HiFi list _devices
  0: Speaker
  1: Mic1
  2: Mic2
$ arecord -D hw:PineNote,1 -c 4 -r 48000 -f S16_LE -d 2 /tmp/t.wav
```

four live channels. I have the device and can re-run anything on request.

Request URL   : https://github.com/alsa-project/alsa-ucm-conf/pull/844
Patch URL     : https://github.com/alsa-project/alsa-ucm-conf/pull/844.patch
Repository URL: https://github.com/alsa-project/alsa-ucm-conf