Hi Sebastian,
> Am 04.05.2018 um 13:42 schrieb Sebastian Reichel <sre@xxxxxxxxxx>:
>
> [+cc Tony]
>
> Hi,
>
>> I think it does not need much more (if at all) than a gpio controller on
>> the OMAP3 chip (I think the clocks are active anyways for use by the other
>> UARTs).
>>
>> We had proposed years ago to reprogram the UART RX pin by pinmux-states
>> into an interrupt gpio but that was rejected because it was not general
>> enough and ugly in the device tree (an rx-gpios record where the rx-line
>> is already connected to the UART-rx).
>>
>> Then we did experiment with tapping the UART driver and finally the
>> serdev API was developed to solve this problem. Hence we use it now this
>> way.
>
> Having any UART active on OMAP results in the SoC not entering
> idle/off wasting energy. For normal (i.e. not connected to a peripheral)
> TTYs you can enable runtime autosuspend and configure the RX pin as
> wakeup interrupt. This will wakeup the TTY on incoming traffic, but you
> will lose the first few characters (since the serial device needs some
> time to wakeup). This is for example supported by the N900 uart3
> (debug uart):
>
> $ grep -A4 "&uart3 {" arch/arm/boot/dts/omap3-n900.dts
> &uart3 {
> interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
> pinctrl-names = "default";
> pinctrl-0 = <&uart3_pins>;
> };
>
> To get it working, you also need to enable autosuspend for the tty
> in userspace (echo 3000 /sys/class/tty/ttyS2/device/power/autosuspend_delay_ms).
> This is not enabled by default due to the character loss characteristic
> during wakeup.
>
> 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).
thanks for explaining this! We originally had similar thoughts when
proposing a w2sg0004 driver for the first time (years ago), but we can
not accept loosing characters...
Now, I could imagine a potential solution. The key situation why we keep
the serdev open and listening is if the driver did try to turn the module
off, but in fact did turn it on (because it was not in sync).
It should be possible to cover this by a timer that is started
in this case. If there is serdev data received after assuming the module
is turned off, the driver has detected the wrong case - and can safely
close the serdev until we want to have it powered on again.
If there is no response after turing off, the module power state is already
in sync and we can close the serdev as well - after the timeout (let's say
30 seconds). Then, the serdev UART can idle. We should open the serdev
and start this timer also in the probe function to catch an initially wrong
state.
But I think we should focus on the basics of this driver first. Then it can
be optimized later on.
BR and thanks,
Nikolaus
--
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
