patch "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA" added to tty tree

[Paul Walmsley]

On Sat, 4 Feb 2012, Woodruff, Richard wrote:

> There have been errata over time in this area. Several I hit were 
> updated at 3630 time. UART did get IER2 but I don't recall all details 
> for UART.  Probably that is not being used.

Govindraj sent an RFC patch a few days ago to add IER2, which is good, but 
we're still awaiting the followup patch for it.

> > From: Paul Walmsley [mailto:paul at pwsan.com]
> > Sent: Friday, February 03, 2012 7:00 PM
> 
> > What's particularly remarkable is that it looks like the UARTs will
> > idle-ack while their transmit FIFOs have data in them (!)
> 
> Generally a module can ACK its ICLK if it is not used internally. The 
> FCLK can push data out with out ICLK and is controlled separately always 
> (omap4 changed encoding, to optional clock). This allows interconnect to 
> idle during tx to save power. 

Yep, that's a good point.  Unfortunately the PER has a hardware sleep 
dependency with the CORE_L3 clockdomain on OMAP3... so I'm not sure how 
much power we'd be able to save.  Perhaps some: it appears that the UART3 
functional clock comes from the CORE_L4 clockdomain.  So it might be worth 
implementing some extra intelligence here.  The kernel code is disabling 
both the ICLK and the FCLK simultaneously, so that may not be optimal in 
this situation.

In the short-term, on the kernel side, we should just keep the PM runtime 
count non-zero when the UART is transmitting.  Since we can get an 
interrupt when the TX is done, or close to being done anyway, we can just 
disable the clocks at that point.  Not ideal, but should work.

> The trick is to ensure all module wakeup plumbing is enabled so a 
> functional tx irq will flow.  Audits last showed several drivers missing 
> steps (omap specific). Some drivers seemed to rely on static 
> dependencies or coincident neighbor activity to allow their functional 
> interrupt to flow... to many interdependent custom details... and yes 
> some errata.

Yeah.  I think we've got an acceptable workaround for the missing TX 
wakeup problem.  And we've got a somewhat unpleasant workaround for the 
missing RX timeout wakeup problem.   Now we just need to put together a 
strategy for the idle-during-TX problem...

> Anyway, even with all SOC specific wake bits you may lose the character 
> with latency of restart. Point I was raising was external chip hook can 
> not be neglected as its part of equation.

Indeed.

Thanks for the info -- it's always nice to see your posts on the lists --


- Paul