Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620

On Mon, Feb 9, 2015 at 1:28 PM, Andy Green [off-list ref] wrote:

On 10 February 2015 at 05:11, Bjorn Andersson [off-list ref] wrote:

quoted

On Feb 9, 2015 1:07 PM, "Andy Green" [off-list ref] wrote:

quoted

On 10 February 2015 at 01:54, Bjorn Andersson [off-list ref] wrote:

quoted

On Sat, Jan 17, 2015 at 9:11 PM, Andy Green [off-list ref]

[..]

quoted

quoted

At that point I think a nice solution would be a donation of time from
guys who specialize in wcn for a living to come and hand out a pony or
two...

I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
and remoteproc-tz) so that people with the domain knowledge can go in and
make it work well.

[..]

Can I ask if smdtty will also appear?  I uplevelled and hacked smdtty
a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
wcn3620 BT working stably for BT keyboard + mouse and even ad2p.

However the hack bound together smdtty ch2 + 3 in smdtty driver and
made it understand about the missing hci protocol byte... this is far
from reasonable for upstream, but it works like the 3.10 except needs
no special bluez / userland treatment.  So I'm curious if no smdtty
how the split smd hci / acl link in firmware will appear coherently to
userspace as a normal uart.

I'm not entirely sure how we're to proceed with this one.

In msm-3.4 with BlueZ the kernel has a driver named hci_smd, that
consumes the two channels and register with the hci core.

In msm-3.10 Qualcomm have dropped this, because they are running
bluedroid which instead consumes the two smd channels in userspace
(through the smd_pkt driver).

We need smd_pkt for modem related matters anyways, so on that we can
run bluedroid and we could bring in hci_smd for use with BlueZ. But
then we would have to configure the kernel based on what stack we want
to run on top.

So we should probably look into userspace and try to consolidate
things there before deciding where to take this.

Regards,
Bjorn