Hi Kevin, > "Woodruff, Richard" <r-woodruff2@xxxxxx> writes: > > > Here is a patch to look at it. Seems to work for me. It adds the use > > of posting for the timer. Previously, every write could lock the > > requestor for almost 3x32KHz cycles. This now only synchronizes before > > writes and reads instead of after them and it does it on a register per > > register basis. Doing it this way there is some chance to hide some of > > the sync latency. It also removes some needless reads when non-posted > > mode is there. > > > > The code probably would be a little smaller if a wpost[256] were used. > > Probably the structure comes in on the cache line read so it is not like > > its adding so much with the ARM running in the hundreds of MHz range. > > > > Signed-off-by: Richard Woodruff <r-woodruff2@xxxxxx> > > I confirm that this indeed works and noticably reduces latency in > proramming the timers. I'm running it along with the latency tracer > which is part of the -rt patch, and have verified that this is no > longer as noticable of a source of latency. Great. Thanks for the verification. I was expecting the same based on lauterbach trace information. > WRT the code, any reason you removed the 'static' and 'inline' from > the read function? I had removed it along the way after getting some recursive inline call. I think those issues are fixed. It might be they can go back in. As the function grew in it might be the inline is not wanted. If it is only called inside the dmtimer code then the static can go back in. > Also, a few CodingStyle issues should be cleaned up: > > like: > > - if(timer->posted) > + if (timer->posted) Ok, I can fix that. > and upstream folks tend dislike the polling loops like this: > > while(condition); > > and prefer the semicolon on its own line to be clear that the loop is > indeed doing nothing. > > while(condition) > ; Ok. I can fix that. Regards, Richard W. -- 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
