RE: [PATCH] [RFC] dmtimer library is very inefficient today

Woodruff, Richard
2008-03-19T20:04:20Z

Hi Kevin,

> "Woodruff, Richard" <r-woodruff2@ti.com> 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@ti.com>
>
> 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.