On 02/17/2016 05:31 PM, Vaibhav Agarwal wrote:
On 17 February 2016 at 13:55, Mengdong Lin <mengdong.lin@xxxxxxxxxxxxxxx> wrote:
On 02/17/2016 01:52 PM, Mengdong Lin wrote:
On 02/15/2016 10:22 PM, Lars-Peter Clausen wrote:
Can you outline how exactly that would work?
Thanks,
- Lars
In Agarwal's use case, it seems a removable codec driver can be
registered after the sound card is registered. And the Pandaboard
machine driver need to add new BE links brought by the new codec
component, which will further trigger probing of the codec components.
How can the machine driver know a new codec component is registered
automatically?
Can we add a notification ops like "new_component" to a soc card?
A machine driver can implement this ops. So when a new component is
registered to the ASoC core, all instantiated soc cards can get notified
and the machine driver can check if the new component brings some new
links to the soc card in this ops. e.g. the Pandaboard machine driver
can add new BE links for the new codec.
Thanks
Mengdong
Sorry, I missed the case that the codec component can be still be registered
before the machine driver register the card. In this situation, the machine
driver cannot get the notification.
Yes, the codec component can be registered before the sound card
registration or even later. All we need is, to add & bind DAI link to
an already registered/active soc card dynamically.
Also, w.r.t .new_component() callback approach proposed, it can be a
good solution assuming any device would have limited no. of soc cards
registered (with support for dynamic codec modules). In this case, can
a client codec choose to which soc card, it can register DAI links?
Maybe we should not let a client codec driver choose the soc card, but
let the machine driver (owner of the soc card) to specify a removable codec.
Since the codec driver is generic and can be used for many machines so I
feel we should avoid adding too machine-specific code to it (e.g. the
soc card name) as much as possible.
I think the machine driver can understand all use cases for a platform,
including static or removable connections between the SOC and codecs. So
it's able to specify the removable codec and the codec DAIs needed by
the machine, as well as these removable links. Please correct me if my
understanding is wrong.
I wonder if the machine driver can still predefine these links but flag them
as "dynamically_registered". For such links, asoc core will not abort
instantiating the card, i.e. the sound card will be created even if these
links are not bound because lack of some DAIs (e.g. the DAIs of the codec
component not registered yet).
Pre-defining links can be a good idea, but honestly, I'm not convinced
with that. Since, I can have N no. of codec modules to be added
dynamically. And each may have different number of DAIs, corresponding
to which I can have different no. of DAI links.
Do you mean the machine driver has no idea about these removal codecs?
And could you share more info about the removal codec in your use case?
If we let the codec driver to add the links, there is gap: a dai link
needs info from both cpu (soc) side and codec side. A generic codec
driver only knows the codec info, but has no idea about the cpu side or
the connection between the codec & cpu. E.g. a codec may have 2 i2s
interface, but maybe only 1 is connected to the soc.
Then when the missing component is added, the ASOC core will automatically
check these the unbound links and bind them. When the component is
unregistered, ASoC will try to remove the affected links and then remove the
components.
I would prefer defining & binding DAI links at the same time as I
mentioned above. Similarly, cleanup all resources during removal path.
Thus we may not need add new APIs or let the machine driver monitor when the
codec component is registered.
My original idea was:
Let machine driver export APIs to register/unregister DAI links to its
registered card. Now, client codec driver can use those exported APIs
to register DAI link with the card.
In case codec driver is supposed to register dynamically, during probe
itself it can use machine driver APIs to register relevant DAI links.
And in case codec driver is already registered, a separate mechanism
can be used to register relevant DAI link using machine driver's
exposed API.
Is it unavoidable to define a private API of a machine driver and let a
generic codec driver call this API to add/remove BE DAI links?
If it's really unavoidable, maybe this machine API can just let the
codec driver to add/remove codec DAIs. And the machine driver can decide
by itself what links to add/remove for the soc card by ASoC API. Maybe
you could extend the existing API snd_soc_add_dai_link() for your case.
But IMHO I hope we can avoid this. So I suggested let machine driver
define some 'removable' links and ASoC core can bind/unbind them
automatically with the registration/unregistration of the codec
component. I think most of your code for ASoC core can still be reused.
Thanks
Mengdong
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
