From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967876AbdEWNti (ORCPT ); Tue, 23 May 2017 09:49:38 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.162]:22315 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965985AbdEWNt3 (ORCPT ); Tue, 23 May 2017 09:49:29 -0400 X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcecEarQROEYabkiUo6mSAGQ+qKID4oI1jv7g== X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth From: "H. Nikolaus Schaller" In-Reply-To: Date: Tue, 23 May 2017 15:49:17 +0200 Cc: Mark Rutland , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Tony Lindgren , Russell King , Thierry Reding , Jonathan Cameron , Maxime Ripard , Jarkko Sakkinen , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap , Discussions about the Letux Kernel , kernel@pyra-handheld.com, Marcel Holtmann Message-Id: <889E8F7F-FC0F-490E-B924-D04D9F4D3402@goldelico.com> References: <78B1501A-B9AD-4C6E-A481-26F647AA2BCE@goldelico.com> <0D94BEA0-F98D-48F6-9DDC-99F932AE7834@goldelico.com> To: Rob Herring X-Mailer: Apple Mail (2.3124) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v4NDnmmo008983 Hi Rob, > Am 23.05.2017 um 15:10 schrieb Rob Herring : > > +Marcel Good! > > On Tue, May 23, 2017 at 7:48 AM, H. Nikolaus Schaller wrote: >> Hi Rob, >> >>> Am 23.05.2017 um 14:28 schrieb Rob Herring : >>> >>> On Tue, May 23, 2017 at 12:43 AM, H. Nikolaus Schaller >>> wrote: >>>> Hi Rob, >>>> >>>>> Am 23.05.2017 um 04:26 schrieb Rob Herring : >>>>> >>>>> On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller wrote: >>>>>> Since our proposed API was not acceptable and the new serdev API has arrived in 4.11 kernels, >>>>>> we finally took the challenge to update the w2sg and w2cbw drivers to use the serdev API. >>>>>> >>>>>> The approach is to write a "man in the middle" driver which is on one side a serdev client >>>>>> which directly controls the UART where the device is connected to and on the other side >>>>>> presents a new tty port so that user-space software can talk to the chips as if they would >>>>>> directly talk to the UART of the SoC (e.g. ttyO1). This is similar to connecting to a remote >>>>>> serial device e.g. through USB (ttyACM) or Bluetooth UART profiles. >>>>>> >>>>>> For example gpsd or hciattach expect a /dev/tty they can control (flow control, baud rate >>>>>> etc.). >>>>> >>>>> I understand from the prior discussion why you want to pass the data >>>>> thru for gps, but why do you need to do that for BT? >>>> >>>> Because we otherwise can't turn on power when /dev/ttyBT0 is opened and turn off when it >>>> is closed. I.e. it should not be powered unless someone does a hciattach /dev/ttyBT0. And it >>>> should be turned off by a killall hciattach. >>> >>> Still, you can do power control within BT HCI drivers. >> >> We do not use any driver for bluetooth. We just start hciattach on demand. >> And afaik there is no plugin mechanism for adding power control to hciattach. > > You don't need hciattach. All userspace has to do for kernel BT > drivers is "hciconfig hci0 up|down". Hm. Well: root@letux:~# hciconfig hci0 up Can't get device info: No such device root@letux:~# I wonder how I can tell hciconfig about the UART port if not by running hciattach /dev/ttyBT0? > >> Or do you have a link to what you think about? > > Look at the nokia BT or TI (HCI_LL) BT drivers. Those both have f/w > downloading and some GPIO controls. Given that this module is based on > Marvell chipset, I'd expect you need to add serdev support to > hci_mrvl.c. The w2cb003 has a Marvell WiFi (libertas) but a CSR Bluetooth side. It has built-in firmware and already talks serial HCI over simple UART right after power-on. This is why our serdev driver has no firmware download. > >>> You wouldn't be >>> limited to just open/close, but can handle suspend/resume as well. >> >> Well, it does not look as if we need more than open/close since suspend/resume >> is already handled by the regulator driver. We just need to keep it powered off >> if there is no user-space client. > > Okay. > > Rob BR, Nikolaus