Enabling DAPM for Dummy DAIs
Hi Mark/Takashi,
We're using the Dummy DAI and dummy component for the nocodec mode in the SOF driver and we noticed that there are no DAPM power status updates for the widgets because there are no output/input widgets in the Dummy component. Adding these widgets in the dummy component wont help either because we explicitly skip adding widgets for the Dummy component in the core.
But it would be very useful for us to debug PM issue if we could have the DAPM power updates for the widgets in topology. Reverting the change that implemented the check for skipping the dummy component probe (ASoC: core: Don't probe the component which is dummy) would not be advisable because it will be used by multiple cards and will lead to the same issue again.
More details about the issue can be found here: https://github.com/thesofproject/linux/issues/1987
What would your recommendation be to get around this problem in SOF? Thanks for your help.
Thanks, Ranjani
On Thu, Aug 13, 2020 at 05:21:40PM +0000, Sridharan, Ranjani wrote:
Hi Mark/Takashi,
Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to.
What would your recommendation be to get around this problem in SOF? Thanks for your help.
Actively using the dummy CODEC at runtime isn't a great idea at the best of times, things would be a lot easier if you used something with actual audio paths for testing - as far as I can see the issue is that you've told the system that there's nothing connected which is reasonably being interpreted as there being no need to power anything on. If you intend this to represent an actual connection it would be better to use a simple CODEC with no software control rather than something that explicitly means there is nothing connected.
On Fri, 2020-08-14 at 13:37 +0100, Mark Brown wrote:
On Thu, Aug 13, 2020 at 05:21:40PM +0000, Sridharan, Ranjani wrote:
Hi Mark/Takashi,
Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to.
What would your recommendation be to get around this problem in SOF? Thanks for your help.
Actively using the dummy CODEC at runtime isn't a great idea at the best of times, things would be a lot easier if you used something with actual audio paths for testing - as far as I can see the issue is that you've told the system that there's nothing connected which is reasonably being interpreted as there being no need to power anything on. If you intend this to represent an actual connection it would be better to use a simple CODEC with no software control rather than something that explicitly means there is nothing connected.
Thanks, Mark. But I am still confused by what you mean by a simple codec here. Would this simple codec be registered by the SOF platform driver?
Thanks, Ranjani
On Mon, Aug 17, 2020 at 05:45:59PM +0000, Sridharan, Ranjani wrote:
Thanks, Mark. But I am still confused by what you mean by a simple codec here. Would this simple codec be registered by the SOF platform driver?
Any CODEC driver that doesn't require software control. I have no idea what would register something with the whole probing situation you have - ideally you'd just be able to use the actual configuration of the board you're on. Given you're already registering platform devices for things not described in ACPI whatever does that is probably the right place.
participants (2)
-
Mark Brown -
Sridharan, Ranjani