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. 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. -- 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
