Sound-open-firmware November 2019

sound-open-firmware@alsa-project.org

4 participants
5 discussions

[Sound-open-firmware] Converting a non BE to BE inside soc_check_tplg_fes
by Daniel Baluta 26 Nov '19

26 Nov '19

Hi all, I am trying how a non-BE link is converted to a BE link inside soc_check_tplg_fes. soc_check_tplg_fes => for all components that have ignore_machine setup to card name => dai_link->platforms->name = component->name; => dai_link->no_pcm = 1; But the thing is that the link is a true non-DPCM link, than fields like dpcm_playback/dpcm_capture are not set and playback/record substreams are no created. The question is: is this supposed to be working with non-DPCM links?

3 4

[Sound-open-firmware] Headers circular dependency
by Paul Olaru 21 Nov '19

21 Nov '19

As I was trying to turn the main macros (spin_lock, spin_lock_irq and the others) from <spinlock.h> I have uncovered the fact that <sof/spinlock.h> includes <sof/drivers/interrupt.h> and <sof/drivers/interrupt.h> includes <sof/spinlock.h>, which means that for every C file that includes either of them one of the two will not see the declarations of the other. Is this circular dependency actually real? Right now I have issues with interrupt_global_disable - it does an implicit declaration in <spinlock.h> due to <interrupt.h> being included first (or only) within some C files. If I try to include <arch/spinlock.h> from <sof/interrupt.h> I only get the error for "this file shouldn't be included from outside of sof/spinlock.h", but if I try to hack it to believe it's from there I get no further errors. I will submit a pull request displaying that soon (hopefully today) but I need feedback on whether this is the best approach. I mean the cyclic dependency is real because <sof/interrupt.h> needs to use spinlock_t but <sof/spinlock.h> requires several things from <sof/interrupt.h> so I believe it needs to be fixed even if the macros from <sof/spinlock.h> are left as macros.

1 0

[Sound-open-firmware] Stack alignment issues with XCC?
by Paul Olaru 20 Nov '19

20 Nov '19

Hello, I'm trying to begin doing all my builds with XCC for testing and, besides one issue where I need to manually insert stack alignment code in the IRQ handling function for the DMA domain it seems to work. Also, if I align the stack within my IRQ_STEER handler it remains aligned for the domain handler just fine. My question is, why within irq_handler (see src/drivers/imx/interrupt.c, function begins around line 275) the stack is not aligned? Did you also encounter this issue on other platforms? And is there any good solution other than that bit of inline assembly that just force-aligns the stack pointer when entering the cascaded IRQ handler? Without this code I seem to get panics with an alignment exception, the address pointing within an Interrupt stack and epc0 not being correct (I think I need to investigate that as well but that's a low-priority issue). Compiler version for reference (in case there is a known issue I'm not aware of): xt-xcc -v xt-xcc version 11.0.4 Thread model: single

2 6

[Sound-open-firmware] Handling DAI clocks in SOF
by Daniel Baluta 14 Nov '19

14 Nov '19

Hi all, I am asking your opinion on how to better handle clocks / pinctrl configuration in SOF for IMX. As far as I know Intel platforms deal with this stuff on Firmware side. Unfortunately for IMX this cannot be done easily. The interface on touching resources (clocks, pinctrl) in i.MX8/i.MX8X uses a separate dedicated core (M4) named System Controller. Linux kernel has a mechanism implemented to communicate with this SC and to request for clock operations (enable, disable, set rate etc). So, would you see it fit to create (on Linux kernel side) dummy DAI drivers which just take care of resource configuration? thanks, Daniel.

2 1

[Sound-open-firmware] How to figure out the direction when dai_config is called?
by Paul Olaru 11 Nov '19

11 Nov '19

On the i.MX platform, the SAI and ESAI DAIs require the direction (whether it's playback or capture) to be able to correctly decide which DMA channel is to be used (the channels differ between playback and capture). I have just made a simple modification to the pipeline to also have a record pipeline on the ESAI and I'm getting an error due to attempting to request channel 7 (Playback) twice. It seems that dai_config is called twice within the same IPC request (once for each instance of the DAI) and in both cases with the same direction too. What would be the best approach with this one? I have attached the diff with my current attempt to adding that record pipeline. Perhaps something is wrong with that?

2 4

2023

2022

2021

2020

2019

2018

2017

2016

Sound-open-firmware November 2019