Re: Question about struct snd_soc_dai() :: cpu_dai->codec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jul 30 2016 05:41, Takashi Iwai wrote:
>> That still seems a bit fancy hardware :)
>>
>> If we can reasonably support this, I am for it. But not making stuff
>> overtly complex...
> 
> Yes, we don't have to overreact to a dream immediately now.

As I wrote at first, my question is a sidetrack. So you can still
continue the discussion for loadable ALSA SoC part.

In my understanding, one of the aim of ALSA SoC part is to reuse drivers
of audio IPs, typically hardware ADC/DAC (so-called 'codec'). To achieve
this, the ideas of 'DAI' and 'link' are introduced for better
abstraction, additionally to historical 'card' and 'components'.

In a point of 'reuse of codes', I cannot imagine what Lars said for USB
devices, then post the questions.

> We should consider whether it can be shifted to the card-level instead
> before worrying too much about hot-unplug of an ASoC component.  Then
> the whole story becomes far easier.
>
> And, the suppress_bind_attrs flag I suggested is only to suppress the
> sysfs bind/unbind, and doesn't mean to prohibit hotplug itself via the
> bus driver.

In my opinion, the relationship between DAI driver and codec or
component driver is not described as relationship between kernel
modules. The issue cannot be resolved by dependency of loadable modules
and we need to manage the relationship of loaded modules somewhere. In
this meaning, I can understand the idea which Mr.Morimoto described.

But I think it's logically difficult to manage state of sound card; e.g.
disconnect. When one sound card instance consists of instances of
several 'DAI', 'Codecs' and 'Components' (this 'component' is not in
ALSA core contexts[1]) and we try to unload one of them, then which
state the card should be assigned to? Or no 'Codecs' drivers are loaded,
then which state should be assigned to the card?

Additionally, when old Codec driver is unloaded and new Codec driver is
loaded, then what should we do for corresponding PCM character devices
are? Currently, once snd_card_regsiter() is called, we cannot
insert/delete ALSA components such like PCM.


[1] For the context, please refer to 'Writing an ALSA driver'.
http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch02s03.html#basic-flow-constructor-create-other


Regards

Takashi Sakamoto



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux