On Wed, May 09, 2018 at 07:05:50AM -0700, Tony Lindgren wrote: > * Johan Hovold <johan@xxxxxxxxxx> [180509 09:20]: > > On Tue, May 08, 2018 at 05:56:08PM +0200, Sebastian Reichel wrote: > > > I think using open/close for runtime pm is good enough for GPS, > > > since it regularly sends data and draws lots of power anyways. > > > But devices, that have an out-of-band wakeup signal can do proper > > > runtime PM of the serial port without loosing characters. > > > > Yeah, there may be some applications where this is possible. And this is > > not the case for GPS, but not just because of a generally higher power > > consumption, but due to the fact that we cannot afford having the first > > message in every report burst be dropped. > > Well most of the phone implementations use one or two out of band > GPIOs to first wake the UART before any data is sent. For serdev > this can be called from the serdev consumer write function for TX. > For RX, the serdev consumer needs to implement an interrupt handler > and wake up the parent UART before serdev RX. Right, but the client driver would then wake the parent controller when expecting RX, while waking its own (serial-attached) device when wanting to do TX. Just for the record, we also cleared this up here: https://marc.info/?l=linux-kernel&m=152604434504868&w=2 > > > Note, that OMAP does not reach deep idle states with active > > > serial port. This is not acceptable for low power devices. > > > > Sure, but note that OMAP is the only serial driver which currently > > implements this kind of aggressive runtime PM (besides a couple of > > usb-serial drivers). This means that a serdev driver can never rely on > > this being the case, and therefore needs to be restrictive about how > > long the port is kept open if it cares about power at all. > > Well by default we don't allow lossy UART. It needs to be manually > configured via /sys for the timeout. With serdev, this can all be > done with no /sys configuration needed for the cases with GPIO > wake irqs :) Indeed, but serdev client drivers must also work with serial drivers which do not implement this kind of aggressive runtime PM, and then the only way to save power is to close the port when not in use. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
