Hi, On Fri, Aug 19, 2016 at 12:38:08PM +0100, One Thousand Gnomes wrote: > There are also some other slight complications when you look at > real world implementations. Android devices tend to keep the GPS > in userspace so most of them can't use some magic extra API but > just drive GPIO lines via the sysfs GPIO interface. Most Android > doesn't use the kernel BT stack either. I don't get the reasoning for this one. What has it to do with an in-kernel API? People are also using libusb or doing i2c/spi from userspace. Nevertheless we have an in-kernel API for those. > Quite a few Android and other embedded devices also do power > management by shutting off the UART, routing the rx line to an > edge triggered GPIO and on the interrupt flipping the UART back > on and losing the first byte, picking a protocol that can recover > from it. > > Your model doesn't I think cover that, although I am somewhat at a > loss as to how to do that nicely! On OMAP this is supported by the serial driver via runtime PM and wakeirq. Actually my usecase for the API (bluetooth on Nokia N900, N950, N9), there is an extra GPIO for the power management (high = uart should be able to receive sth., low = uart can sleep). For this I can just disable the wakeirq in the UART by not adding it to DT and instead runtime manage it from the uart_dev child device. While we are on that topic: The omap-serial driver does not enable runtime PM by default, since it does not know if the remote side is ok with loosing the first byte(s). One is expected to enable it using the sysfs API. But I think it should be safe to enable runtime PM for the serial device in uart_dev_connect(). Due to the child device it will still be kept disabled, except when the uart_dev also implements runtime_pm. -- Sebastian
Attachment:
signature.asc
Description: PGP signature
