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

[yfw]

Hi Bjorn,

On 2015/8/27 2:57, Bjorn Andersson wrote:
> 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?
>
Thanks a lot for the information.

Regards
Yin, Fengwei

> Regards,
> Bjorn
>