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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
