Porting FM Radio Driver


Hi all,

I ported the FM radio driver [1] to a more recent and close to upstream kernel (Linaro 4.4), but I have a hard time using it.

Some commands never gets a reply, some others get a reply with an error status (usually 0x0c, which is translated by the driver as ‘-EBUSY’), and some works (actually, only HCI_FM_GET_RECV_CONF_CMD work without failure of all the commands I’ve tested so far).

Does anyone have info on the init sequence of the radio or any information that could help me get the driver in a working state?

[1] https://source.codeaurora.org/quic/la/kernel/msm-4.4/tree/drivers/media/radio/radio-iris.c?h=LA.BR.1.2.4-00310-8x16.0




As far as I recall FM radio wasn’t really tested on Android. Were you able to get FM working on Android before you started the forward port?


I did not check personaly, but other members of the team did and assured me that it worked as expected. I’m currently looking at the Android FM app (https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/fm/), but it doesnt seem to do any magic. I’ll keep searching and testing.


I’ve managed to found an init sequence that allows the radio to tune in a channel (not sure what data I’m getting yet, but I have a TUNE_STATUS event).

Here is the sequence I execute and the results I get with that:

disable receiver   -> TIMEOUT
enable receiver    -> TIMEOUT
initialise_recv()  -> OK
set_freq()         -> OK, and I get tune status event after that
disable receiver   -> OK (after 5s)
enable receiver    -> TIMEOUT

If I don’t do the enable receiver step, subsequent calls fail. I think under some conditions, one might get a reply to the enable receiver command but as there are not public documentation available, I’ll focus on the audio paths from now on.


Hi Damien,

I did take a quick glance at the FM driver while working on SMD, BT and WiFi but I was worried that there might be a dependency on some state of the audio DSP, and never tried.

Have you managed to make any further progress?



Hi Bjorn,

I kept this task as a background task so it hasn’t moved very fast. First I considered porting recent Srinivas’ patches for the QDSP6v2 to the kernel we are using, but it’s too big of a job. It seems from the documentation that the WCNSS and the DSP share their samples through the cMEM, so the other option I’m currently investigating is to read these samples from the cMEM in the FM driver. I could read the buffer address and size (via the WCSS_A_FM_FM_BUFFER_* registers), but I did not check if the application processor could read the cMEM yet.

Even if the cMEM is readable by the driver, the interrupt that is triggered when the FIFO reaches a certain threshold seems to be connected directly to the audio DSP. It doesn’t seem to be routable to the application processor, so a thread or a workqueue should be used to fetch the data on a regular basis.

That’s where I am at. Do you have plans for his feature?



Hi Damien,

Thanks for the update. We have not been discussing FM radio support before, so there are no active plans to support this feature.

It does sound plausible to grab the frames out of cMEM, but I think it would be a better idea to follow through on DSP-based audio; it should be a reasonable amount of work once it’s concluded for 8996. We will discuss this in our team during the upcoming Linaro Connect.

PS. It sounds like you’re aiming to support this in a product of yours, if so, please do let Qualcomm know your intention and interest in this feature - for planning purposes.