Re: [PATCH 04/15] ASoC: SDCA: Pass device register map from IRQ alloc to handlers

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

On 9/8/25 14:56, Charles Keepax wrote:
> On Mon, Sep 08, 2025 at 01:49:43PM +0200, Pierre-Louis Bossart wrote:
>> On 9/5/25 16:31, Charles Keepax wrote:
>>> Store a copy of the device register map in the structure for the IRQ
>>> handlers. This will allow the individual IRQ handlers access to the
>>> device level register map if required.
>>
>> Sorry, not following how you plan on sharing access to regmap between
>> parent and child devices.
> 
> They all have a pointer to the device level register map, if some
> function or the device level is using it the regmap lock will be
> held and the others are block.

ok

>>> @@ -445,6 +445,9 @@ struct sdca_interrupt_info *sdca_irq_allocate(struct device *dev,
>>>  
>>>  	info->irq_chip = sdca_irq_chip;
>>>  
>>> +	for (i = 0; i < ARRAY_SIZE(info->irqs); i++)
>>> +		info->irqs[i].device_regmap = regmap;
>>> +
>>
>> Lost on this one as well. A child device could support multiple
>> interrupts, e.g. for buttons and jack, not sure why each interrupt
>> needs a separate pointer to the same identical information.
> 
> Most IRQs don't need custom handling so the core can handle those
> IRQs. In the case of custom IRQs the driver would register some
> private data structure that would contain necessary information
> for the handler such as regmaps. This array of interrupt
> structures is basically that private data. A pointer to this
> structure will be passed to the IRQ when it fires and it needs to
> contain all the stuff the IRQ handler needs, one of those things
> might be the device level register map.

I think I am still looking at interrupts with the standard non-SDCA interrupts in mind. In the existing SoundWire handling, all interrupts are handled one after the other in the same handler. The only case where we could customize the handler is for the 'vendor-defined' interrupt.

But for SDCA we are moving to a different design, aren't we? Each interrupt is handled separately with its own handler, either provided by the core or customized by a vendor, and that handler must be provided with enough context information to access registers. If that description is correct then yes no objection to this copy of the information.