Hi, * Johan Hovold <johan@xxxxxxxxxx> [180507 03:03]: > On Fri, May 04, 2018 at 01:42:13PM +0200, Sebastian Reichel wrote: > > > Having said all of this, serdev does not yet support runtime PM (at > > all). Tony is currently looking into it. Fortunately serdev allows > > us to enable runtime PM by default (once implemented), since we know > > the remote side and can (hopefully) avoid losing characters (i.e. > > with sideband wakeup gpios). > > I'm not sure we want generic runtime-pm support for the controllers in > the sense that the slave device state is always reflected by the serial > controller. Similar as for i2c and spi, we really only want to keep the > controller active when we are doing I/O, but we may want to keep a > client active for longer. Yeah i2c seems to do the right thing where the bus takes care of runtime PM. > Take the u-blox driver in this series for example. As I'm using runtime > PM to manage device power, user-space can chose to prevent the receiver > from runtime suspending in order to avoid lengthy (re-)acquisition times > in setups without a backup battery (by means of the power/control > attribute). Sorry I don't seem to have that one, care to paste the subject line of that patch? > Note that serdev not enabling runtime pm for controllers is roughly > equivalent to setting the .ignore_children flag, which is what we do for > i2c and spi controller, and possibly what we want here too. We currently don't idle serdev at all even if not in use. What I noticed is if I have these in my .config: CONFIG_SERIAL_DEV_BUS=y CONFIG_SERIAL_DEV_CTRL_TTYPORT=y And no hci_serdev.ko driver loaded, then the 8250 port still stays active and there are no sysfs entries to idle it. Are you seeing this with your series? Regards, Tony -- 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
