Return-path: Received: from mail-qc0-f181.google.com ([209.85.216.181]:43470 "EHLO mail-qc0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761247AbbBIWBS (ORCPT ); Mon, 9 Feb 2015 17:01:18 -0500 Received: by mail-qc0-f181.google.com with SMTP id p6so9585112qcv.12 for ; Mon, 09 Feb 2015 14:01:17 -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: Tue, 10 Feb 2015 06:01:17 +0800 Message-ID: (sfid-20150209_230126_214943_9A7BFB71) Subject: Re: [PATCH 6/7] net: wireless: wcn36xx: remove powersaving for wcn3620 From: Andy Green To: Bjorn Andersson 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 10 February 2015 at 05:40, Bjorn Andersson wrote: > 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. I understand, although it's a shame to make a whole new protocol in bluez when it's just the normal protocol with a byte trimmed at the start of a block. It can work with stock distro bluez out of the box if the kernel binds the channels. The hci_smd thing sounds okay, maybe he can be a module and Android / bluedroid just doesn't have the module in the rootfs, traditional Linux gets the module and udev inserts him. -Andy > Regards, > Bjorn