+Marcel On Tue, May 23, 2017 at 7:48 AM, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> wrote: > Hi Rob, > >> Am 23.05.2017 um 14:28 schrieb Rob Herring <robh+dt@xxxxxxxxxx>: >> >> On Tue, May 23, 2017 at 12:43 AM, H. Nikolaus Schaller >> <hns@xxxxxxxxxxxxx> wrote: >>> Hi Rob, >>> >>>> Am 23.05.2017 um 04:26 schrieb Rob Herring <robh+dt@xxxxxxxxxx>: >>>> >>>> On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> 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". > 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
