Re: [PATCH v2 0/6] Add audio support for QCS6490 RubikPi3

[Hongyang Zhao]

On Wed, Jul 15, 2026 at 10:02:49PM +0800, Hongyang Zhao wrote:
> > Add audio support for the Thundercomm RubikPi3 board based on QCS6490.
> >
> > RubikPi3 uses AudioReach/GPR on the ADSP. An ES8316 codec connected to
> > primary MI2S provides headset playback, headset capture and jack
> > detection. The LT9611 bridge connected to quaternary MI2S provides HDMI
> > audio playback.
> >
> > The series first documents the existing ES8316 jack-detect inversion
> > property and adds a board-specific Qualcomm sound-card compatible. A
> > generic Qualcomm headset helper is then added for codecs which implement
> > component jack detection but are not connected through a WCD codec DMA
> > link.
> >
> > The sc8280xp machine driver board data is converted to a per-DAI
> > representation. This allows each backend to select its own DAI format,
> > clock programming and jack setup. RubikPi3 uses this to drive the ES8316
> > with a 19.2 MHz MCLK and to avoid unsupported sysclk programming on the
> > LT9611 HDMI link.
> >
> > The final patch describes the two audio paths, clocks, pin control,
> > codec power and jack-detect wiring in the RubikPi3 device tree.
> >
> > This series is based on next-20260710 and depends on Rafi's
> > q6apm-lpass-dais MI2S clock control series and Neil's q6prm MCLK clock
> > ID patch:
> >
> > Depends-on: https://lore.kernel.org/all/20260714145250.2473461-1-mohammad.rafi.shaik@xxxxxxxxxxxxxxxx/
> > Depends-on: https://lore.kernel.org/all/20251008-topic-sm8x50-next-hdk-i2s-v2-1-6b7d38d4ad5e@xxxxxxxxxx/
>
> That's RFC with comments, so why do you send your patchset knowing IT
> CANNOT BE merged?
>
> Last days Mark complained, Rob complained, sure, we can ignore
> maintainers, but just stop for a second and think: what can we do with
> your patchset? Really, what can we do?
>
> Best regards,
> Krzysztof

Hi Krzysztof,

You are right. I missed the RFC tag on Neil's series and misunderstood
the status of that dependency.

In v1 I carried Neil's MCLK clock-ID patch. I changed this to a
Depends-on reference in v2 because I did not want to resend somebody
else's work without coordination. I now understand that this still
leaves the RubikPi series non-actionable while the dependency remains
an RFC.

Please consider this series withdrawn. I will coordinate with Neil
about the MCLK clock-ID change and wait until the prerequisite work is
in a mergeable state before sending another revision.

Sorry for wasting your and the other maintainers' review time.

Best regards,
Hongyang