Re: [PATCH 1/7] ASoC: SDCA: Factor out jack handling into new c file

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 12/10/25 17:31, Charles Keepax wrote:
> On Tue, Dec 09, 2025 at 12:00:24PM +0000, Pierre-Louis Bossart wrote:
>>> +	switch (val) {
>>> +	case SDCA_DETECTED_MODE_DETECTION_IN_PROGRESS:
>>> +	case SDCA_DETECTED_MODE_JACK_UNKNOWN:
>>> +		reg = SDW_SDCA_CTL(interrupt->function->desc->adr,
>>> +				   interrupt->entity->id,
>>> +				   SDCA_CTL_GE_SELECTED_MODE, 0);
>>> +
>>> +		/*
>>> +		 * Selected mode is not normally marked as volatile register
>>> +		 * (RW), but here force a read from the hardware. If the
>>> +		 * detected mode is unknown we need to see what the device
>>> +		 * selected as a "safe" option.
>>> +		 */
>>> +		regcache_drop_region(interrupt->function_regmap, reg, reg);
>>> +
>>> +		ret = regmap_read(interrupt->function_regmap, reg, &val);
>>> +		if (ret) {
>>> +			dev_err(dev, "failed to re-check selected mode: %d\n", ret);
>>> +			return ret;
>>> +		}
>>
>> The detected_mode is reported by hardware and copied into the
>> selected_mode, but that's not the end of it.
>> We should capture with at least a comment that the intent of
>> the SDCA design was to let the user or additional vendor-specific
>> override the selected mode. If/when we have to deal with the
>> complicated multi-jack topologies it'll be required.
> 
> So the theory is we are already supporting this. The jack handler
> here will report the "safe" accessory type returned by the device.
> But the detected mode and selected mode are exposed as ALSA
> controls to user-space, so if the user wants to adjust the
> accessory type they can just set the selected mode control. If
> vendors want to do in driver vendor magic they will need to
> register their own IRQ handler for the detected mode control, but
> we provide for that through the sdca_irq_request() API.

Sounds good, thanks for the clarification.