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. Basically we would like to have a power control automatic like it exists for many other devices. Since the BT chip is described as a serdev by DT, we see no other means than to pass data through the serdev driver. We had looked into the line discipline approach but it makes a lot of problems. The first one is that registering a new system-wide ldesc number is required. Next we do not see how to make a serdev driver (as it seems to be required by the DT) to register a different ldesc. > >> Here is the result of our first hack which is working as a demo on GTA04 devices (and the >> w2cbw driver can also be used to control a GTA04 variant with WL1837). >> >> Since it is just a demo hack, the code is not yet cleaned up, nor does it completely pass >> check-patch, nor follows 100% the coding styles. And certainly has some bugs. >> >> The most significant issue is that calling tty_port_register_device() inside of the >> serdev probe() function makes the serdev probe() function to be entered a second >> time. This does not lead to big problems since we currently have minor = 0 >> and this makes the second call assume the device is not available. >> >> But we have no idea why this happens and how it can be prevented. > > Johan's fixes may help there, but it is intended to be temporary to > have a separate API for registering tty ports with or without serdev. Ah, would that mean something like a tty_port_register_device_without_serdev()? Do you have a reference to his fixes? BR and thanks, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
