Insmod not working on the ASoC Machine Driver

Hi, I am trying to build a Machine driver as mentioned in my other post. I have modified the ASoC Machine Driver L4T/nvidia/sound/soc/tegra-alt/machine_drivers/tegra_machine_driver_mobile.c according to the steps mentioned here. I have also successfully built a .ko module for the machine driver, but when I do an insmod in my Xavier Board, the following error shows up:

insmod: ERROR: could not insert module snd-soc-tegra-machine-driver-mobile.ko: Device or resource busy

And the dmesg output:

[   70.153255] Error: Driver 'tegra-asoc:' is already registered, aborting...

Kindly help me solve this issue.

Thanks,
Abhigyan

You should probably stick to the original thread, but is this really the device tree entry beginning? It looks like you actually used a legitimate address if I read the text above it, but naming the node with a NULL address may be an issue if it isn’t just a typo in the thread.

spi@0 {

My thought is that this means something is already bound to the address named.

Hi, here I am talking about the ASoC machine driver “L4T/nvidia/sound/soc/tegra-alt/machine_drivers/tegra_machine_driver_mobile.c”. I have built it as a loadable kernel module and when I try to do insmod for the module, the errors mentioned above shows up. So I am wondering how to solve this error.

Thanks,
Abhigyan

I could not answer, but if a device is not plug-n-play (i.e., the device cannot “self report” its address and arguments), then it would depend on the device tree being correct for finding the physical address of the device. If “busy”, then that address already has something going on, but I have no way to say if it is that device not being named correctly, or whether it is an address conflict with another device, or if no hardware even exists at that address. What I can guarantee is that if the device tree makes the software believe the address is “0x0” (which is what I think you’d see from “spi@0 {”), then this is incorrect.

Hi abhigyan,

If you are modifying the machine driver, suggest to not change it as loadable kernel module (i.e build it as part of kernel) and flash the kernel partition as per the instruction in L4T development guide (link1, link2)

Thanks

Hi atalambedu,

Can you please tell me why it is so?

Is the machine driver already built into the kernel for which I see the error mentioned above?

Thanks,
Abhigyan

I cannot completely answer, but realize that often the driver is in fact already there. The device tree can make the driver succeed or fail. Imagine a “hello world” program which has as its only job to echo the argument passed to it to the output…one would not write a new “hello world” application for every possible argument passed. The device tree is the argument passed and is why the driver itself does not need to be rewritten for other variations of the same hardware which would merely be some “rearrangement” of that chipset.

Note about this:

…it means the driver is already there in a state where you cannot add the driver twice. If the driver is not working correctly, then it is likely (though not guaranteed) because the tree passed to it is not correct.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.