Hi Rob,
Am 23.05.2017 um 15:10 schrieb Rob Herring robh+dt@kernel.org:
+Marcel
Good!
On Tue, May 23, 2017 at 7:48 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Rob,
Am 23.05.2017 um 14:28 schrieb Rob Herring robh+dt@kernel.org:
On Tue, May 23, 2017 at 12:43 AM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Rob,
Am 23.05.2017 um 04:26 schrieb Rob Herring robh+dt@kernel.org:
On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller hns@goldelico.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@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