question about alsa tracepoints and alsa debugging

[Bert Schiettecatte]

Hi Lars-Peter

> > occurs. The moment I start arecord, the console output from
> > speaker-test stops, so it's locked up by starting arecord.
> Are these implemented as two separate sound cards? If so I don't see how
> they could interfere with each other. There should not be any shared
> resources or locks between them at least on the ALSA side.

here are the definitions I've used in my driver - I had to translate
my old code from kernel 4.11 to using the new macros so not sure if
something got broken while doing that. I want my DAC and ADCs to be
one sound card device.

SND_SOC_DAILINK_DEFS(ak4458,
                     DAILINK_COMP_ARRAY(COMP_CPU("ff890000.i2s")),
                     DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "ak4458")),
                     DAILINK_COMP_ARRAY(COMP_PLATFORM("ff890000.i2s")));

SND_SOC_DAILINK_DEFS(ak5558,
                     DAILINK_COMP_ARRAY(COMP_CPU("audio-cpld")),
                     DAILINK_COMP_ARRAY(COMP_CODEC(NULL, "ak5558")),
                     DAILINK_COMP_ARRAY(COMP_PLATFORM("audio-cpld")));

enum {
        DAILINK_AK4458,
        DAILINK_AK5558,
};

static struct snd_soc_dai_link rockchip_ak4458_ak5558_dai[] = {
        [DAILINK_AK4458] = {
                        .name = "Audio out",
                        .ops = &rockchip_ak4458_dai_ops,
                        SND_SOC_DAILINK_REG(ak4458),
        },
        [DAILINK_AK5558] = {
                        .name = "Audio in",
                        .ops = &rockchip_ak5558_dai_ops,
                        SND_SOC_DAILINK_REG(ak5558),
        },
};

static struct snd_soc_card rockchip_ak4458_ak5558 = {
        .name           = "ak4458-ak5558-audio",
        .dai_link       = rockchip_ak4458_ak5558_dai,
        .num_links      = ARRAY_SIZE(rockchip_ak4458_ak5558_dai),
};

> If possible try to narrow this down a bit more, this will help to track
> this down. If this is a more general issue it is quite likely that this
> is a more recently introduced problem, otherwise others would have
> already run into it. Maybe try one of the stable kernels like v5.4.

I will play around with a few different versions to see what happens.

> To check if there is a locking issue somewhere compile your kernel with
> CONFIG_PROVE_LOCKING=y

do I need PROVE_RAW_LOCK_NESTING as well? what about PROVE_RCU and
PROVE_RCU_LIST ?

> Do both devices I2S and MMC use the same DMA? If so I could see things
> going wrong there since that would be shared resources in the DMA
> driver. If possible try to run the MMC driver without DMA and see what
> happens.

I think they both use DMA but I don't think the resources are shared,
from what I can tell. My version of dw_mmc.c is 99% the same code but
I just directly call my own callbacks in dw_mci_interrupt
instead of dealing with the tasklet or work stuff.

Thanks for helping!
Bert