Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

[Bjorn Andersson <bjorn.andersson@sonymobile.com>]

On Thu 22 Oct 03:25 PDT 2015, yfw wrote:

> 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.


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