Return-path: Received: from mail-la0-f50.google.com ([209.85.215.50]:39447 "EHLO mail-la0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761232AbbBIVkc (ORCPT ); Mon, 9 Feb 2015 16:40:32 -0500 Received: by labgq15 with SMTP id gq15so16377840lab.6 for ; Mon, 09 Feb 2015 13:40:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20150118050741.31866.36490.stgit@114-36-241-182.dynamic.hinet.net> <20150118051111.31866.39208.stgit@114-36-241-182.dynamic.hinet.net> Date: Mon, 9 Feb 2015 13:40:30 -0800 Message-ID: (sfid-20150209_224038_448384_46D01C6F) Subject: Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620 From: Bjorn Andersson To: Andy Green Cc: netdev , Eugene Krasnikov , Kalle Valo , linux-wireless , wcn36xx , linux-arm-msm Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Feb 9, 2015 at 1:28 PM, Andy Green wrote: > On 10 February 2015 at 05:11, Bjorn Andersson wrote: >> On Feb 9, 2015 1:07 PM, "Andy Green" wrote: >>> >>> On 10 February 2015 at 01:54, Bjorn Andersson wrote: >>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green [..] >>> 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