Re: [PATCH v2 1/3] dt-bindings: sound: Add CS42L84 codec

[James Calligeros <jcalligeros99@xxxxxxxxx>]

Hi all,

On Mon, Oct 21, 2024 at 02:26:32PM -0500, Rob Herring wrote:
> On Sun, Oct 20, 2024 at 12:47:31AM +1000, James Calligeros wrote:
> > CS42L84 is a headphone jack codec made by Cirrus Logic and seen in Apple
> > computer models starting with 2021 Macbook Pros. It is not a publicly
> > documented part. To a degree the part is similar to the public CS42L42.
> > (The L84 superseded L83 seen in earlier Apple models, and the L83 was
> > pretty much the same as L42.)
> 
> Why can't this be added to
> Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml?
> 
> I guess perhaps you don't know what the supplies look like? Do any of
> the custom properties apply?

I suppose the original thinking around creating a new binding was simply new 
driver, new chip, new binding. We also don't describe the power supply of the 
chip at all, as this is all handled by lower level firmware.

Some of the custom properties (e.g. tip sense debounce) should technically 
work if we teach the driver how to set them at probe time, however given that 
the chip is almost certainly never going to be used outside of the Apple 
Silicon context we went with static values that were first observed under macOS 
and then optimised once we had enough of a working stack to play around in 
Linux. The values that go into the registers for each property appear to be 
identical to CS42L42, so it should be possible to implement at least some of 
these properties if that is what is preferred.

On Tuesday 22 October 2024 8:15:50 AM AEST Mark Brown wrote:
> I don't know if the Cirrus people who are listed as maintainers of that
> binding might have concerns about doing things that acknowledge this
> particular part.

I suspect, based on the past behaviour of Apple vendors including Cirrus 
themselves, that they either won't or can't publicly acknowledge the existence 
of this chip. Given this, and the fact that the chip will almost certainly 
never be used on any other platform, it is probably better for everyone 
involved if we cut them out of the loop.

Regards,
James