"ext Woodruff, Richard" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
