Re: ASoC Kernel 6.1: Query regarding dynamic dai link/dapm registration during bootup

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

 



Hi All,

Could you please share your input on previously asked query?.
We are waiting for response. Thanks in advance.

Regards,
Shalini M
________________________________
From: Shalini Manjunatha (Consultant) (QUIC) <quic_c_shalma@xxxxxxxxxxx>
Sent: Tuesday, October 29, 2024 11:35 PM
To: Vinod Koul <vkoul@xxxxxxxxxx>; Liam Girdwood <lgirdwood@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; Jaroslav Kysela <perex@xxxxxxxx>; Takashi Iwai <tiwai@xxxxxxxx>; Raghu Ballappa Bankapur (QUIC) <quic_rbankapu@xxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx <alsa-devel@xxxxxxxxxxxxxxxx>; linux-sound@xxxxxxxxxxxxxxx <linux-sound@xxxxxxxxxxxxxxx>; Shalini Manjunatha (Consultant) (QUIC) <quic_c_shalma@xxxxxxxxxxx>
Cc: Krishna Kishor Jha (QUIC) <quic_kkishorj@xxxxxxxxxxx>
Subject: ASoC Kernel 6.1: Query regarding dynamic dai link/dapm registration during bootup

Hi All,

On kernel6.1 based Qualcomm target for automotive platform based on Android U, we have a feature early services to launch certain early apps at early init of android bootup cycle. Hence in order to launch early chime sound of audio at early init of android boot up cycle, we need to load all required audio kernel modules at early init stage in order to get sound card registered.

We have certain KPI goals for every early apps to get completed within lesser duration so that we can achieve final KPI goal of android boot complete as per the target specification.

In this journey, while optimizing the sound card registration through machine driver probe to achieve lower KPI for audio early chime sound, we find that for early chime launch we required only selected pcm front end dai links only.

Hence if we keep FE dai link structure in our machine driver with only required items for early chime, overall sound card registrations gets completed within 200msec from the time it starts, which is a very good KPI number to achieve.

So we were trying out code change to split overall FE dai link structure into two, one for early chime and another for all other required dai link's, then some how we need to register early chime related dai link during early init so that sound card registration process gets completed quickly, later stage we want to dynamically load all other FE dai links.

Could you please help us to suggest on how can we achieve this?. Is there any possible way out to avoid static FE dai link registration for all required ones from machine driver during machine driver probe, instead register only limited list of dai links.

Later can we dynamically register the dai links in order to get PCM devices entries created based on use case.

Currently we have this API devm_snd_soc_register_card() being called with snd_soc_card parameter which has all possible FE dai links populated at once.

Queries:
1) can we register sound card twice during bootup, once with limited dai links and next with all required ones?
2) can we register dai links/dapm dynamically based on use case requriement?
3) If it is possible, could you share any reference from any other vendor who is able to achieve the same?.

Regards,
Shalini M



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux