[Linux-Xtensa] Re: [patch 0/8] xtensa: s6000 & s6105 - Git Repo Pulled; will try to merge early next week and get back to ya.

linux-xtensa at linux-xtensa.org linux-xtensa at linux-xtensa.org
Mon Mar 16 03:27:33 PDT 2009


On Fri, Mar 13, 2009 at 02:42:43AM -0700, Piet Delaney wrote:
> Johannes Weiner wrote:
> >On Wed, Mar 11, 2009 at 05:44:45PM -0700, Piet Delaney wrote:
> >>Johannes Weiner wrote:
> >>>Hi,
> >>>
> >>>here is the core series of our s6000 port.
> >>>
> >>>First comes the nommu patch.  Right now we use CONFIG_MMU for
> >>>everything that separates the S6000 from existing ports, memorywise.
> >>>This is a lot easier and can still be broken up by newer ports when
> >>>they have requirements with finer granularity.  Furthermore, we have
> >>>only this one nommu box here, so we couldn't test an MMU architecture
> >>>and therefor not say for sure we didn't break anything ;)
> >>Perhaps you have a pointer to a git repository with your changes
> >>that I can clone from.
> >
> >http://git.opensource.emlix.com/cgi-bin/gitweb.cgi?p=kernel/xtensa/linux-2.6.git;a=summary
> 
> Great, I Pulled it earlier this evening. A bit slow over the Atlantic,
> having a common cached version might be worthwhile.

Ah, sorry.  http is also slower than the git protocol, I think.

> >It's based on 2.6.29-rc7 and then some.  The base is not terribly good
> >chosen but we didn't want to go back to .29 and since it's so late in
> >the release cycle -rc7 should be quite stable as well.
> >
> >>I can make sure the LX60 and LX200 didn't break. We have a
> >>number of bug fixes and new support for SMP and a new MMU
> >>that we expect to ready for prime time soon. I'd prefer to
> >>use git to test your changes and doing the merge.
> >
> >Yeah, it's much easier that way.  Thanks for the testing, we really
> >appreciate it!
> 
> I got one of the S6000 Demo boards, do you have anything on
> how to get linux running on the board. Chris Jones is talking
> to Stretch about SDK's that I likely need. Any suggestions
> or recommendations?

We use e2factory (e2factory.org) to build an image, but you need
something to get it on the box.  Do you already have a way?

> I'll likely merge with your repo and test for regressions
> early next week. We might need to discuss with Marc the
> replacement with the generic timer code. I was Wondering
> about the reason for this change and if we will lose High
> Resolution Timer running at variable intervals to save power
> is effected. I need to study this area more.

I did the conversion to the clocksource interface out of interest, it
is not part of our Stretch work.

It shouldn't interfer with hres timers, in fact, I think it's a
necessity for them.

Quoting kernel/time/Kconfig:

	config HIGH_RES_TIMERS
		bool "High Resolution Timer Support"
		depends on GENERIC_TIME && GENERIC_CLOCKEVENTS

The next step is probably to implement the ccompare register as clock
event device.

> Once I merge with your code and it works I'd like to
> post it to our website and you let me know if you see
> any regressions on your side with the S6000 or if you
> find any of the changes inappropriate for going upstream.

Okay, great.

> >>How about I add accounts for you, Oskar, and Daniel and
> >>we use the repo(s) as a staging site to test each other's changes
> >>before passing them upstream to Christian and Linus.
> >
> >I'm all for synchronizing our work but either way to do that is fine.
> >We can pull from each other or just share a central repository.
> >
> >Of course, the latter would prevent us from stomping on each other's
> >feet.  We don't want to break stuff horribly and make your life hard.
> 
> After this first round of changes I think we will know how best to
> optimize for the future.

Yep.

> >And code doesn't just appear in your repository, we would write an
> >explicit pull request email for a set of fixes or new features and
> >then you can look over the changes before you merge them into your
> >tree, and give synchronous feedback, criticism and comments.  Just
> >like upstream works.
> 
> Sounds fine.
> 
> >
> >What do you think?
> 
> So far you changes looks like they will have only minor
> interference with SMP and V3 MMU changes we have made. I
> need to understand the GENERIC_TIME config change more.
> If you could explain it a bit it would probably save
> me a bit of time understanding the impact. Looks like current
> functionality won't be effected. Worried about High Resolution
> Timer support that Marc has plained for the future to save
> power while idle.

Every architecture used to implement get/settimeofday manually.  Now,
this is all handled in generic code, you only need to provide this
generic code with a description of how to get a measure of time in
nanoseconds.  These descriptions are called clocksources.  I use the
ccount register for that, the kernel can then deduce from it the
monotonic and the wallclock time.

Architectures not yet converted use the jiffies clocksource by
default.  The jiffies variable will be updated once every clocktick.
So right now, the granularity of the time on xtensa is the tick rate
(several ccount increments until == ccompare) while with my changes,
the granularity of time is that of ONE ccount register increment.

The jiffies clocksource implementation is in kernel/time/jiffies.c.

With the clockEVENT infrastructure, the timer interrupt does not do
much on its own but calls into generic code.  Generic code can use the
clockevent descriptor to program the next timer interrupt dynamically
(if the clockevent device supports it, ccompare does) which can reduce
wake-ups drastically.  Because our clocksource doesn't rely on regular
ticks anymore, the ticks don't have to occur for measuring time.

As described above, I think the conversion is actually essential for
having hres timers.

> Maxim and I were busy this afternoon sorting out a uclibc
> Buildroot problem with 2.6.17 headers. Hope to get merged
> with your changes early next week and get back to ya.

Okay, sounds great.

	Hannes


More information about the linux-xtensa mailing list