hda: how to implement component master_unbind?

[Lucas De Marchi]

On Thu, Dec 19, 2024 at 04:00:08PM +0200, Kai Vehmanen wrote:
>Hi,
>
>On Fri, 13 Dec 2024, Lucas De Marchi wrote:
>
>> Thanks Kai to pointing me to this thread, trying to revive it.
>> Also adding dri-devel as it may be relevant there and Maarten who worked
>> on the xe integration recently
>
>ack, given fresh wave of bugs this year (even if these are all (?) bugs
>triggered in test configurations), probably warrants another look.
>
>[1) prevent/block the unbind if audio device is busy]
>> and there's no way to block unbind from the pci level neither, so this
>> is not really possible. There's nothing blocking someone to unplug the
>> card if it's on a hotplug-capable bus and/or someone calling
>>
>> 	# echo 0000:00:02.0 > /sys/module/xe/drivers/pci:xe/unbind
>>
>> to tell the module to unbind from the device. If that involves multiple
>
>Ack, I think we can put this option to rest.
>
>[unbind the ALSA card]
>> yeah, since it depends on the i915/xe side to power up the display
>> engine, I think handling that esssentially the same as a hotplug would
>> be ideal
>[...]
>> I'm not yet very familar with the sound side and checking if something changed
>> from when this thread started: for cards that can't work without the
>> other component, would it be hard to escalate that event to handle it
>> the same as a hotplug? Because from this thread it seems usb/pci hotplug
>> is already available.
>
>I don't think much has changed. I think this is (still) a doable option,
>but just requires effort put in (which so far has not happened). I think
>the problem can be roughly divided in two categories:
>
>1) discrete graphics - controller on discrete PCI device
>
>Here the problem is more acute (as may affect register accesses done from
>audio driver), but potentially also easier to fix. There is a single
>driver (snd-hda-intel) to handle this case in ALSA and the sound card
>created only exposes the HDMI/DP PCMs, so if graphics side unbinds,
>disconnecting the ALSA card seems ok as well. The open I have is how do we
>recreate the ALSA card. Audio driver probe is triggered by attach of the
>PCI device, but here the PCI device is not unplugged, just unbound by one
>of the drivers. But doesn't sound like a unique problem to audio, so I'm
>sure there's some example solution to follow.

since we are using include/linux/component.h, i915-display will call
component_del() on unbind, which should trigger all components to be
unbound - snd should release all the references it holds to display
power.

once we add back the i915/xe side with component_add() it should
complete the aggregate driver and bind again all sides.

Lucas De Marchi

>
>2) integrated display codecs
>
>The regular laptop case is a bit more iffy as there are more audio drivers
>using the display codec driver stack (each need support), and in most
>cases, the ALSA card is a mix of HDMI/DP but also internal codec and
>speaker PCMs. If we use the card disconnect infra in ALSA (i.e. same infra
>as USB hotplug), this means display unbind will not just disconnect the
>HDMI/DP PCM device, but alsl the interal audio codec and speakers. And
>there's a bigger issue how we reenumerate the full card again.
>
>I think the longterm solution is to move the HDMI/DP PCMs to their own
>ALSA card. We in fact some work going on to this direction in the SOF
>driver, but it's far from complete, and we are not sure whether we can
>change the existing platforms to use this approach (as changing the card
>topologies will be visible to user-space as well and potentially break
>stuff).
>
>I did file a bug to track this in SOF
>https://github.com/thesofproject/linux/issues/5276 .
>
>Br, Kai