Hi, * Woodruff, Richard <r-woodruff2@xxxxxx> [080307 01:34]: > Hi, > > While looking at ARM based MP3 it was noted by one of the teams here > that a large amount of time was being spent in the dmtimer API > functions. This was throwing off load estimates. This causes an > increase in power which is not wanted. Thanks to Nourredine for > pointing this out. > > In looking at the code it seems to be doing a couple inefficient things. > > -1- First issue I see is sets the interface in non-posted mode. This > has the effect that the accessing device can be stalled until the access > takes. This will make a 600MHz OMAP3 potentially wait until the 32KHz > functional clock is able to take the change. This is not good. > > -2- In this mode it also is making unneeded register accesses to the > write pending register. The write pending register is supposed to be > used in posted mode, not non-posted. > > This interface should be improved to operate in posted mode. If posting > behavior is needed then a dm_timer_sync() command should be added. > Right now sync'ing after every register write is not necessary and waits > a lot of time. When it is in posted mode you write and forget at the > ARM. You do still need to dump the data out onto a 166MHz interconnect > but that is better than to a 32KHz one. > > Right now with dynamic tick the timer is reconfigured a quite a bit and > it cost is a lot of time restart. If dynamic tick is off there is much > less waste. > > * Posted mode does have a draw back in that you can't write to the same > register twice before the previous one completes. Some simple tracking > or an audit of usage can be made which cuts the cost greatly. For > something like the system ticker there is only 1 user anyway so it > shouldn't be hard to extend the register write to just add a sync > parameter at the end. > > Any comments? Earlier OS ports which were done use posted and they work > fine. Yeah, I agree. We should be able to optimize at least the GPT0 writes into just few instructions as it's done for every timer interrupt. > Regards, > Richard W. > > One side note is the code only enables the wake up function for GPT1. > This seems wrong also. You almost always want all devices which should > be able to generate an interrupt to generate a wake up event. If you > don't do this you might wait for the dynamic tick interval before > recognizing an event when you are in interconnect clock stop. You do > have to clear status else you will miss chip retention, but this is well > worth the trivial extra work in power savings. Sure, that makes sense. Got any patches around? Tony -- 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
