On Thu 22 Oct 03:25 PDT 2015, yfw wrote:Yes. I meant this remoteproc-wcnss driver. Will you try to upstream it?
Hi Bjorn,[..]
On 2015/9/22 1:52, Bjorn Andersson wrote:
I have a question: Do you have plan to add the nob to trigger wcnss firmware
downloading which is also common for wifi and BT?
In caf the wcnss driver is actually two drivers intermingled;
* a SMD client driver, responsible for pushing NV, something related to
calibration, some power properties and so on
* a platform_driver implementing the wcnss specifics of the PIL through
some hooks and providing the knob to trigger the PIL.
The first driver is related to the "OS" running on the wcnss, so that
should follow the life cycle of the SMD channel "WCNSS_CTRL". This is
what this patch provides - it loads the NV every time the wcnss core is
booted.
For the second part, I strongly believe that the PIL implementation
should deal with the specifics (e.g. regulator handling and
xo_calibration), rather than having a piece bolted on elsewhere - so
that's in the remoteproc-wcnss driver.
The firmware file could be put to initrd. That should allow wcn wifi driver
Left is a mechanism to trigger the thing to boot and shutdown. One
potential solution would be to have the module_init/exit call
rproc_boot/shutdown from the WiFi & BT drivers. That way if one loads
the wcn36xx driver, the core is booted. This would also fit quite nicely
for other things - e.g. load the ALSA driver to trigger the ADSP
loading.
The problem here is that we're then forced to either have a method of
deferring the rproc_boot() until the firmware is available or we always
must compile these drivers as kernel modules. This because the
file system isn't there during boot to provide the firmware.
We do have the same thing in e.g. the Broadcom WiFi/BT solution and
there seems to be discussions related to this.
So for now, I punted and put a knob in the wcnss remoteproc driver.
Regards,
Bjorn