re: UltraSPARC III/IIe cpufreq drivers, please test
matthew green <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
> > this seems like a problems. what we really want to happen here > > is for every actual schizo (which i think means, say, every time > > we have a PCI-A leaf), we need to find the matching CPU for this > > schizo and hook them together. > > > > ie, given a normal booted system that has no special cf_units: > > > > schizo0 -> cpu0 > > schizo1 -> nothing > > schizo2 -> cpu1 > > schizo3 -> nothing > > That was my first question... CPU frequency is set by schizo (or > psycho) ESTAR register. Thus, schizo_get_cpufreq() has to access to > schizo_softc struct associated to its CPU. Only solution I have found is > to add a pointer in cpu_info struct to associated schizo. > > In schizo_setup_cpufreq(), > cpu_lookup(device_unit(dev))->sc = sc is wrong, but I have no idea to > fix it. Any idea ? this is some what tricky. ideally, it should be derived from the cpu device, and that should find and talk to the schizo device that controls it. that might mean we need to add a config_interrupts() call for this, so that we can find the relevant schizo device. the right way to find this mapping is probably pretty ugly and will involving matching addresses between the CPUs and the schizos. i haven't looked at the details to see what it might potentially mean. the only other cpufreq-style device i'm familiar with that is detached from the cpu proper is the old P4-style speed step, so perhaps it would be a good place to look for ideas. oh, maybe not. it only has one device to choose from and uses a static 'softc' pointer. so don't look there :) .mrg.