Re: flush_icache_range

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Thu, 02 Jun 2005 23:37:36 +0200, "Menyhart, Zoltan" <Zoltan.Menyhart@free.fr> said:

  Zoltan> I propose to round down "start_address" to be stride size aligned.

Sounds reasonable.

  >> As for setup.c: I'd get rid of LOG_2_I_CACHE_STRIDE_SIZE and just
  >> initialize log_2_i_cache_stride_size to 5 (there is no point in
  >> initializing it with a random & useless value).

  Zoltan> "log_2_i_cache_stride_size" is not initialized to any stride
  Zoltan> size, it calculates the min. value.  Should
  Zoltan> "pal_cache_config_info" fail, you need something useful to
  Zoltan> be able to boot up.

  Zoltan> I 'd rather keep "LOG_2_I_CACHE_STRIDE_SIZE", I like speaking names.
  Zoltan> Perhaps "LOG_2_DEFAULT_I_CACHE_STRIDE_SIZE" would be even better :-)

Sure.  The canonical way in Linux to say "log2" is "shift", so perhaps:

  DEFAULT_I_CACHE_STRIDE_SHIFT

?

  >> Also, I think you should do take the minimum of _all_ cache-levels,
  >> not just level 1 (yes, I also have a hard time imagining a system
  >> where the higher level has a smaller stride, but I don't think there
  >> is anything that prevents such a system).

  Zoltan> Well, things are getting complicated :-) I can add it...
  Zoltan> I've got a concern about the "unique_caches" returned by
  Zoltan> "pal_cache_summary()".  Let's assume that

  Zoltan> unique_caches - cache_levels = 2

  Zoltan> I could not find anything making sure that we've got in this
  Zoltan> case L1I and L2I, and not L1I and L3I (feeding through the
  Zoltan> unified L2). Yes, I know there is no such a CPU (at the
  Zoltan> moment) but the PAL spec. does not exclude it :-)

I don't think it matters whether you pick up the stride from an
i-cache or a unified cache.  As long as you take the minimum stride,
it will work correctly.

	--david