Re: CVS commit: src

[nia <nia%NetBSD.org@localhost>]

On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote:
> this doesn't seem like the right design.  we have cpus
> already that have multiple frequency domains, so this
> doesn't work with that setup, so attempt to use it as a
> general method for estd etc seems limited and thsu not
> the right method.
> 
> eg, rk3399 systems have .cpu0 and .cpu4 domains for the
> 4 slow and 2 fast cores it has, and they have both
> separate controls as well as list of available freqs:
> 
> machdep.cpufreq.cpu0.target = 1416
> machdep.cpufreq.cpu0.current = 1416
> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408
> machdep.cpufreq.cpu4.target = 1800
> machdep.cpufreq.cpu4.current = 1800
> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408
>

yeah, i'm aware of this, my intent was really only to normalize
the variables that didn't have multi-cpu-domain support (since
those are already normalized as rk3399)

do you think we should use the same variable and tie things to
under cpu0 when there isn't support for scaling independent CPUs?

> additionally, if we are going to design a "good" API for
> this, it should publish things outside of "machdep".
> i'd go with hw.cpufreq probbaly.
> 
> (i didn't look, but it sure would be annoying if the old
> nodes that have existed for over a decade were changed
> and any other 3rd party code or scrip tis now broken.)

i actually picked this name because it was already in use and
thus already checked by estd.

i agree it should go outside machdep, but i didn't want
to break existing code.