On Tue, Jun 19, 2007 at 08:22:59PM +0400, Sergei Shtylyov wrote: > From: Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> > Date: Tue, 19 Jun 2007 20:22:59 +0400 > To: vagabon.xyz@xxxxxxxxx > Cc: Atsushi Nemoto <anemo@xxxxxxxxxxxxx>, ralf@xxxxxxxxxxxxxx, > macro@xxxxxxxxxxxxxx, linux-mips@xxxxxxxxxxxxxx > Subject: Re: [PATCH 3/5] Deforest the function pointer jungle in the time > code. > Content-Type: text/plain; charset=us-ascii; format=flowed > > Atsushi Nemoto wrote: > > >>What do you mean by "pnx8550 can have customized copy of cp0_hpt > >>routines" ? Do you mean that it should copy the whole clock event > >>driver ? > > >>It seems to me that using cp0 hpt as a clock event only is a valid > >>usage... > > >Well, I thought the customized cp0 clockevent codes (custom > >.set_next_event routine is needed anyway, isn't it?) would be small > >enough. But I did not investigate deeply. If generic cp0 hpt can > >handle this beast without much bloating, it would be great. > > IMO, the generic code should only have the standard MIPS count/compare > support and let the platform code to initialize it if it choses so and also > register its own specific clock[source|event] devices if it choses so -- > i.e *not* what the current clocksource code does... For practically every type of timer there are reasons why it is may be undesierable such as being configured in a way that makes it undesirable or unusable, unpredictable clock changes and more. So in practice only the platform specific code can drive the initialization of all timer devices and interrupts which reduces the generic code to sort of a library and driver collection. Ralf
