On Sun, 5 Feb 2012 17:57:40 +0000 "Woodruff, Richard" <r-woodruff2@xxxxxx> wrote: > > > From: Russell King - ARM Linux [mailto:linux@xxxxxxxxxxxxxxxx] > > Sent: Sunday, February 05, 2012 10:03 AM > > To: Woodruff, Richard > > > On Sun, Feb 05, 2012 at 03:37:21PM +0000, Woodruff, Richard wrote: > > > [x] What is acceptable depends is not black and white. Is there some > > > QOS mapping which can be set per channel which allows runtime PM to > > > pick a best chose (which may allow for loss and frame issues)?. > > > > What you're asking is whether there's anything in the kernel which can > > predict when the next character is to arrive. > > No, this was not the comment's intent. > > > But, the fact of the matter is that deriving the UART clocks from a PLL > > which takes a finite time to lock, and the PLL is shut down during runtime > > PM _is_ _going_ _to_ _cause_ _problems_. There is absolutely no getting > > away from that. > > Yes this is one of the issues to be worked around. > > > Let's take your modem example. Modems today would typically be used with > > some IP based protocol, probably PPP based. Incoming traffic on IP is > > entirely unpredictable. You wouldn't know when the next character would > > be received. > > > > One solution to this is to transmit an 0xff character before your real > > data to ensure that your end is awake and properly synchronized... > > This approach as you say has issues. This is solved in different ways for modems. > > <sleep>My observation is modem software which many talk over ppp over ip over serial of some sort (might be uart, might be usb), will send a command to the modem to go into a low power mode. Now you can cut clocks with out hurting modem and getting SOC power. > > <wake>When some event happens at modem or processor (timer near beacon or other) the modem or apps processor can signal the other with some wake event (maybe over gpio) which then puts system in a state where it can receive data in trusted manner. > > The modem channel driver try's to inform kernel about entering/exiting modes to set expectation. I think the correct way to "inform the kernel" would be with the 'CREAD' c_cflag in termios. Clearing it indicates that we don't expect to read which would allow the UART to go to sleep. When the GPIO interrupt arrives, we would use termios to set CREAD and then start talking to the modem. However it is easy to imagine situations where this wouldn't be enough. A fairly obvious way to wake a sleeping serial connection is with a 'break'. I have a GPS which can be put to sleep and then woken by sending a 'break'. Similarly the OMAP uart can reliably receive a break when asleep, but cannot reliably receive any other input. Though maybe if BRKINT is set in c_iflag, then we could still receive a break even when CREAD is clear. Then clearing CREAD would be enough to allow low-power mode. > > > So, go ahead with having PM drop random characters if you want, but don't > > expect anyone in their right mind to accept broken workarounds to the > > kernel serial driver to try to drop maybe 16 characters or more at a time > > on the floor when a framing error occurs just because the PM is broken. > > No character was dropped in modem example. On the UART-to-Debug console it may be ok to drop a character. Ether needs a coordination hook. I don't think it is really OK to drop chars on the UART-to-Debug console. However it is OK to drop the BAUD rate to 57600 where we can wake up in time for to catch the first bit. So if you want power saving, drop the console buad rate. So I would suggest: - remove the autosuspend timeouts - allow runtime_pm to shutdown the device when it is not open, or when rate is 57600 or below, or when 'CREAD' is clear - keep runtime_pm active whenever there are bytes in the output queue or fifo The only case that wouldn't support is when a device will wake up the SOC by sending a non-break character which it is OK to receive corrupted. The tty would have to be in !CREAD for that to happen, and then there would be no way for the app to know that a non-break character was received. Would it be reasonable to treat any input while CREAD is clear as a break? NeilBrown
Attachment:
signature.asc
Description: PGP signature
