[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <889E8F7F-FC0F-490E-B924-D04D9F4D3402@goldelico.com>
Date: Tue, 23 May 2017 15:49:17 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Rob Herring <robh+dt@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>,
BenoƮt Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.com>,
Russell King <linux@...linux.org.uk>,
Thierry Reding <treding@...dia.com>,
Jonathan Cameron <jic23@...nel.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-omap <linux-omap@...r.kernel.org>,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [RFC 0/3] misc: new serdev based drivers for w2sg00x4 GPS module and w2cbw003 wifi/bluetooth
Hi Rob,
> Am 23.05.2017 um 15:10 schrieb Rob Herring <robh+dt@...nel.org>:
>
> +Marcel
Good!
>
> On Tue, May 23, 2017 at 7:48 AM, H. Nikolaus Schaller <hns@...delico.com> wrote:
>> Hi Rob,
>>
>>> Am 23.05.2017 um 14:28 schrieb Rob Herring <robh+dt@...nel.org>:
>>>
>>> On Tue, May 23, 2017 at 12:43 AM, H. Nikolaus Schaller
>>> <hns@...delico.com> wrote:
>>>> Hi Rob,
>>>>
>>>>> Am 23.05.2017 um 04:26 schrieb Rob Herring <robh+dt@...nel.org>:
>>>>>
>>>>> On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller <hns@...delico.com> 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@...ux:~# hciconfig hci0 up
Can't get device info: No such device
root@...ux:~#
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
Powered by blists - more mailing lists