[linuxsh-dev] Re: [linux-sh:01328] Re: a patch for kernel/time.c

[YAEGASHI T. <yae...@rd...>]

Hi all,

In the article <ota...@th...>,
Jesper Skov <js...@re...> wrote:

> >>>>> "ebihara" == ebihara  <ebi...@si...> writes:
> 
> ebihara> hello all.  time.c didn't work well for detecting busclock
> ebihara> and moduleclock.  so i made a patch for 'time.c'. (sh3 only)
> 
> This is the wrong approach. Well, it may work for your board, but may
> mess up other boards.
> 
> I've just done a rewrite of the clock setup configuration in eCos,
> supporting 7707, 7708, 7709A and 7729. And let me tell you, it's
> seriously non-trivial to get right. And I have the benefit of being
> able to rely on a compile time configuration to get it right.

Long ago I wrote a patch for this issue for Linux/SH and post to
SourceForge.  But unfortunately it has been forgotten by people
and not yet incorporated with the kernel. :->

For your reference:
	http://www.geocrawler.com/archives/3/3076/2000/6/0/3870573/


> IMO it's a serious mistake that the CPUs don't include a version
> register of some sort so they can be properly identified at runtime
> [does anybody know of a non-documented version register, by any
> chance?]. Add to that some way to figure out which clock mode the CPU
> is configured to use, and it would actually be possible to compute all
> the magic at run time.

Agreed.


> As it is, the clock setup code in Linux needs a very careful
> rewrite. And no, I'm not volunteering just now :) Some rainy Sunday,
> maybe.
> 
> Btw, I know that David Woodhouse fixed something in the clock
> calibration code for SH. I'll try to get around to fishing out that
> patch some time this week and submit it for inclusion in the Linux/SH
> kernel.

The newer is the better.  I look forward to your path.

--
八重樫 剛史 <yae...@rd...>