"ext Woodruff, Richard" <r-woodruff2@xxxxxx> writes:
> Hi,
>
>> > static void serial8250_stop_tx(struct uart_port *port)
>> > @@ -1268,6 +1276,15 @@ static void serial8250_start_tx(struct u
>> > up->acr &= ~UART_ACR_TXDIS;
>> > serial_icr_write(up, UART_ACR, up->acr);
>> > }
>> > +#ifdef CONFIG_OMAP3_PM
>> > + {
>> > + /* Don't advertise partial idle else TX irqs will
>> not be seen */
>> > + /* Alternative is to set kernel timer at fifo drain
>> rate */
>> > + unsigned int tmp;
>> > + tmp = (serial_in(up, UART_OMAP_SYSC) & 0x7) | (1 <<
>> 3);
>> > + serial_out(up, UART_OMAP_SYSC, tmp); /* no-idle */
>> > + }
>> > +#endif
>>
>> I tried this quickly. This doesn't work alone. At least if we want
>> working serial-console. Problem with this is that when entering char
>> to console to wake-up omap. First character is lost and then no "echo"
>> happens and serial8250_start_tx is not called. I think this will need
>> some timeout anyway which is started when uart rx|iopad wakeup
>> happens.
>
> Yes that is true.
>
> In reference code it is dealt with and rationalized. This was an issue last year in the old code and will be this year in this newer code.
>
> * CDP code employs an activity check which can gate idle. The disruption was bothersome and gave a bad impression (even if its just a debug port). It also interfered at times with existing functional tests which depended on console (either getting all characters or reasonable performance).
>
> The current check will: On activity raise a cpuidle bus master
> activity failure for some number of seconds. This allows normal
> typing for extended periods. It does this by marking UART function
> IRQs with a time stamp and it checks internal state to make sure
> RX/TX engine is not busy or has queued data waiting.
Isn't this exactly what is done in "Added sleep support to UART" patch
in workaround patch set?
>
> This activity assertion will gate the usage of C states where its F-CLOCK is cut. At the same time its natural wake up events are enabled (along with the above hack as the tx events are not currenly hooked into the wakeup logic).
>
> When OFF/RET mode is selected IO pad is enabled for the port wakeup.
I have seen this in CDP reference code. Is there some specific reason
why this is enabled dynamically in code?
>
> ** The end effect is typing and input/output are good. However, if you stop interacting for greater than the time out you will loose your 1st character. This is unavoidable as the machine doesn't re-start fast enough to not loose the start bit (wakeup/DPLL relock).
>
> It doesn't take much code to do this today. But with out it the console is not very useable when PM is enabled _AND_ being effective. As I mentioned initially, having the UART problem in a sense is a good milestone as it shows you are starting to hit the big power states very often.
>
> Regards,
> Richard W.
--
Jouni Högander
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
