Re: [alsa-devel] Question about struct snd_soc_dai() :: cpu_dai->codec

[Lars-Peter Clausen <lars@metafoo.de>]

On 07/28/2016 10:42 PM, Takashi Iwai wrote:
> On Thu, 28 Jul 2016 22:33:31 +0200,
> Lars-Peter Clausen wrote:
>>
>> On 07/28/2016 05:46 AM, Vinod Koul wrote:
>>> On Wed, Jul 27, 2016 at 10:22:41PM +0200, Takashi Iwai wrote:
>>>> On Wed, 27 Jul 2016 20:22:33 +0200,
>>>> Mark Brown wrote:
>>>>>
>>>>> On Wed, Jul 27, 2016 at 08:11:49PM +0200, Takashi Iwai wrote:
>>>>>
>>>>>> I'm wondering whether it's a better option to block the unbind
>>>>>> behavior, either in driver base (allowing to return an error) or in
>>>>>> the sound side (waiting in remove() until the sane point). 
>>>>>
>>>>> That's certainly going to be a lot easier and part of the reason it's
>>>>> never been looked at much is that (unlike USB) there's very little
>>>>> reason why an ASoC sound card would ever be hotplugged - even in
>>>>> development these days the normal development flow involves rebooting.
>>>
>>> I agree, it makese no sense for devices to be hotplugged. And for
>>> developement flows people can do rmmond and insmod. That works fine!
>>
>> I don't agree. In my opinion hot-plug is an essential feature of a
>> modern device driver framework and if ASoC wants to claim to fall in
>> this category we ought to support it. Hotplug is something that always
>> pops up sooner or later. E.g. if someone puts a ASoC supported CODEC on
>> a hot-pluggable device (maybe USB) we don't want to duplicate the code,
>> but be able to reuse.
>>
>> One area that e.g. requires hot-plug/-unplug and were ASoC supported
>> devices are used is embedded development boards that support shields and
>> devicetree overlays. Like e.g. RPI and similar.
>>
>> The reason why we don't support hot-unplug in ASoC at the moment is
>> because it is not trivial to implement and nobody has cared enough yet.
>>
>> But if somebody wants to and has the resources to implement this we
>> should not discourage this.
>>
>> I'd very much prefer to have proper hot-plug support instead of
>> prohibiting unbinding even on systems that do not require hot-plug
>> support normally. It's a much cleaner solution.
> 
> Well, but hot-unplugging only a component like codec would be needed
> in a real scenario?  It's a different story from the hotplug in the
> card level.

With overlays I'm not sure if we can control the remove order. So the
component might be removed before the card complex.