[PATCH 2/7] wcn36xx: get chip type from platform ops

[Bjorn Andersson]

On Tue 25 Aug 22:47 PDT 2015, yfw wrote:

> Hi Bjorn,
> 
> On 2015/6/10 6:34, Bjorn Andersson wrote:
> >On Mon, Jun 8, 2015 at 12:01 AM, yfw <fengwei.yin at linaro.org> wrote:
> >>Hi Eugene,
> >>
> >>On 2015/6/1 16:06, Eugene Krasnikov wrote:
> >>>
> >>>Do you think it will be difficult to get get_chip_type on all platforms?
> >>>
> >>There is no input from this mail list. I suppose it's OK to change it? And
> >>what do you think about other changes? Are they ready for merging? Thanks.
> >>
> >
> >Sorry for not responding sooner.
> >
> >Based on my suggested smd patches (that I'm about to resend), the
> >wcn36xx driver would become a smd client driver, probed by the
> >WLAN_CTRL channel coming up. The driver would be identified based on a
> >compatible string (like most other drivers).
> >
> >With all prerequisites in mainline, and the lack of board files, I
> >think we should simply drop the "platform glue" part from wcn36xx and
> >simply interface with the new smd code directly.
> >
> >wcn36xx is one of the drivers that I've used to test my smd code with,
> >so I have these patches "ready". I've gotten some minor comments on
> >the current patchset, so I will resend it shortly and as that settles
> >I intend to send my wcn36xx patches for adapting to the new interface.
> >
> Any update on this change? Thanks.
> 

arm-soc picked up the smem & smd patches for 4.3, so we're making
progress.

I'm adding some finishing touches before sending out smsm and smp2p,
will send those out as soon as that's completed (likely this week).

This will give us the required pieces for implementing PIL.


Once the prima/pronto comes up a series of SMD channels are registered,
the wcn36xx driver attaches to "WLAN_CTRL". Two other channels comes up,
"IPCRTR" and "WCNSS_CTRL", (I believe) both representing the
prima/pronto rather than any particular function of the chip.

If ether of these doesn't have a driver attached wcn36xx will fail to
bring up the interface.


The driver for WCNSS_CTRL is quite straight forward, configures some
properties and loads the nv binary - it seems odd that we should send
the nv both to WCNSS_CTRL and WLAN_CTRL and on my machine (msm8974 with
wcn3680) I can omit the call to wcn36xx_smd_load_nv() without seeing any
obvious regression - the other way around gives me issues with starting
the wcn36xx interface.

We (Sony) have reworked the driver for IPCRTR and will be posting this
on LKML shortly. An alternative would be to have a stub driver, as the
pronto does not require responses, just that the SMD channel comes up.

So I think this sums up the status:
SMEM - in 4.3
SMD - in 4.3
REGULATORS - in 4.3
SMSM - on LKML this week, needed for controlling DMA engine(?)
SMP2P - on LKML this week, needed for PIL
RPROC-TZ-PIL - work ongoing(?)
WCNSS_CTRL - need to investigate how to proceed, maybe add what I have
	     to staging for now?
IPCRTR - hopefully on LKML within 2-3 weeks, maybe try to get the stub
	 driver into staging while we work on this?

Regards,
Bjorn