Re: [PATCH v2 1/3] ASoC: dt-bindings: rk3308-codec: describe detection and ADC routing

[Xing Zheng <zhengxing@rock-chips.com>]

Hi Krzysztof,

On 11/4/26 21:10, Krzysztof Kozlowski wrote:
> On Sun, Nov 01, 2026 at 12:41:47PM +0800, Xing Zheng wrote:
>> Describe the optional detect-GRF phandle and named interrupt resources
>> used by the B/C headphone detector. Retain the legacy interrupt order
>> and index-based lookup when names are absent. Document the detector
>> disable and reversed-jack properties and their resource dependencies.
>>
>> Describe the ADC stereo-group routing consumed by the codec driver.
>> Require four unique group IDs in the range 0-3, in I2S2 SDI order,
>> matching the driver's validation. Leave GRF routing unchanged when
>> the property is absent.
>>
>> Extend the example with headphone-detection resources and ADC routing.
>> Keep machine-driver amplifier GPIOs and debug interfaces outside this
>> codec binding.
>>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
>> ---
>> Changes in v2:
>> - Retain the original detection descriptions and legacy IRQ ordering.
>> - Keep the binding change in its own patch before the codec change.
>>
>>   .../bindings/sound/rockchip,rk3308-codec.yaml | 55 +++++++++++++++++++
>>   1 file changed, 55 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
>> index 2cf229a076f0..60c6140dc5df 100644
>> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
>> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3308-codec.yaml
>> @@ -36,6 +36,49 @@ properties:
>>       description:
>>         Phandle to the General Register Files (GRF)
>>   
>> +  rockchip,detect-grf:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      Phandle to the detection GRF used for headphone insertion and
>> +      removal interrupts on codec revisions B and C.
>> +
>> +  interrupts:
>> +    description:
>> +      Keep the legacy interrupt order. If interrupt-names is omitted,
> What is legacy interrupt order? There are no interrupts here, so how
> could there be anything legacy?
You are right. This ordering came from the downstream BSP, not from
an existing upstream binding. There is no upstream compatibility
requirement for it, and calling it "legacy" here was misleading.
>> +      the driver uses the second interrupt for B/C headphone detection.
>> +    items:
>> +      - description: Legacy codec headphone detection interrupt
>> +      - description: Detection GRF headphone interrupt for revisions B and C
>> +
>> +  interrupt-names:
>> +    items:
>> +      - const: codec
>> +      - const: hpdet
> Why same device has both GRF to detect headphones and interrupts?
In the proposed B/C detector implementation, the detect-GRF phandle
provides access to the detector's configuration, status and interrupt
acknowledgement registers. The hpdet IRQ notifies the driver of an
event, after which it reads and acknowledges the status through that
regmap. These are register access and event notification for the same
detector, rather than two independent detection mechanisms.

Separately, the two-interrupt layout was copied from the downstream
DT. The proposed driver only requests hpdet (or index 1 without names)
and skips detector setup on revision A; it does not use the first
"codec" IRQ. Retaining that layout merely for downstream index
compatibility was not a sufficient justification for a new binding.
>> +
>> +  rockchip,no-hp-det:
>> +    type: boolean
>> +    description: Disable the internal headphone detector.
>> +
>> +  rockchip,hp-jack-reversed:
>> +    type: boolean
>> +    description: Reverse the headphone detection polarity.
>> +
>> +  rockchip,adc-grps-route:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    description: |
>> +      ADC stereo-group mapping to the four I2S2 SDI inputs. Each entry
>> +      selects the ADC group connected to the corresponding SDI input,
>> +      in SDI0 through SDI3 order. Group IDs 0 through 3 represent
>> +      MIC1/MIC2, MIC3/MIC4, MIC5/MIC6 and MIC7/MIC8 respectively.
>> +      All four groups must appear exactly once. For example, <1 2 3 0>
>> +      connects groups 1, 2, 3 and 0 to SDI0, SDI1, SDI2 and SDI3.
>> +      If omitted, the GRF routing is left unchanged.
>> +    minItems: 4
>> +    maxItems: 4
>> +    uniqueItems: true
>> +    items:
>> +      enum: [ 0, 1, 2, 3 ]
> Why are all the rockchip properties before clocks, not next to other
> rockchip properties? What logic drives this placement?
There was no good reason for that placement. The vendor properties
should be grouped consistently with the other rockchip properties,
with the standard interrupt properties kept separate.
>> +
>>     clocks:
>>       items:
>>         - description: clock for TX
>> @@ -72,6 +115,12 @@ properties:
>>   
>>       enum: [ 50, 55, 60, 65, 70, 75, 80, 85 ]
> Best regards,
> Krzysztof
>
I am putting this series on hold while I investigate playback and
capture problems observed on our EVB with upstream codec changes
backported to our downstream 6.12 kernel.

Before these backports, sound/soc/codecs/rk3308_codec.c and .h matched
the upstream versions at 2ba2d17170f9 ("ASoC: codecs: rk3308: fix
building without CONFIG_OF"). On top of that codec baseline, I applied
the following upstream commits:

   2d8a091725e6 ASoC: codecs: rk3308: convert to snd_soc_dapm_xxx()
   0c55552b5f5e ASoC: codecs: rk33*: use .auto_selectable_formats
   157f7cba77a9 ASoC: codecs: rk3308: add support for codec revision B

I also backported a1c99b6097af ("ASoC: soc-component: add
snd_soc_component_to_dapm()") for the DAPM accessor used by the
converted driver. These are upstream commit IDs; the rest of the
kernel remains based on downstream 6.12.

I have not yet determined whether the playback and capture issues
are in the upstream driver or in the backport/integration.

I will rework any necessary changes against the current upstream base
and validate playback and capture on the EVB before resubmitting.
Depending on the remaining scope, I will send either a revised v3 of
this series or a separate, focused patch or series. In either case,
the submission will start a new thread and reference the earlier
series where relevant.

Any binding changes retained in a future submission will address your
comments above and include the relevant hardware justification.

Thanks again for your time.

Best Regards
Xing Zheng