On 6/19/07, Sergei Shtylyov <sshtylyov@xxxxxxxxxxxxx> wrote:
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...
And this is _exactly_ what the new patch 5/5 I sent yesteday does and
what I suggested to DEC and PNX5550 thing...
Please have a look to it (if you have time of course) at:
http://marc.info/?l=linux-mips&m=118217055927261&w=2
CP0 count/compare support is handled in arch/mips/kernel/hpt-cp0.c new
file. Therefore it can be compiled or not easily. And it lets the
platform code initialize it if it wants to. So we can easily now see
which platform is using what, and get rid of the ugly thing in generic
time code trying to detect which hpt the platform is trying to use.
The main issue with this approach is that we need to update a lot of
board code which is a pain because it's currently hard to guess what
it does and platform maintainers seem to be really busy to help in
this area...
Thanks
--
Franck
