PERFORCE change 52156 for review
nate at root.org
Wed May 12 17:46:43 PDT 2004
On Thu, 13 May 2004, Takanori Watanabe wrote:
> In message <20040512163137.T84786 at root.org>, Nate Lawson wrote:
> >On Mon, 10 May 2004, John Baldwin wrote:
> >> On Saturday 08 May 2004 12:15 am, Nate Lawson wrote:
> >> > On Mon, 3 May 2004, John Baldwin wrote:
> >> > > http://perforce.freebsd.org/chv.cgi?CH=52156
> >> > >
> >> > > Change 52156 by jhb at jhb_slimer on 2004/05/03 12:10:39
> >> > >
> >> > > Bah, revert accidental submits. Neither of these worked on my
> >> > > laptop, though the acpi_video one does work for some people and
> >> > > might should be committed.
> >> > >
> >> > > Affected files ...
> >> > >
> >> > > .. //depot/projects/power/sys/dev/acpica/acpi_video.c#4 edit
> >> > > .. //depot/projects/power/sys/isa/vga_isa.c#5 edit
> >> >
> >> > The DPMS stuff should go in a different device driver than acpi_video. It
> >> > is a MI driver that implements only the standard ACPI interfaces. DPMS is
> >> > probed separately and should be in a separate driver. You can have DPMS
> >> > without ACPI too.
> >> I know. My laptop doesn't have a device that acpi_video attaches to and it
> >> needs DPMS. You can see I tried adding it to vga_isa.c and that didn't work
> >> either. I have a start on a vgapci(4) driver that would attach to PCI
> >> devices that have the right class and subclass. It would then have drm0,
> >> agp0 (for Intel onboard graphics), and I guess a dpms0 or vesa0 child device
> >> That's trickier. Partly because the only info I can find on DPMS, is to use
> >> the BIOS to do it via vm86, which is very i386-only. Maybe there will be a
> >> dpms0 child and the default on x86 can be to attach the VESA version, but
> >> chip-specific drivers with a probe of 0 can be written for use on all archs
> >> if the DPMS frobbing really is chip specific.
> >I think DPMS should be a separate driver, not under the video driver.
> I think that acpi_video itself should not be under acpi directry.
> We may have to make attach any numbers of video drivers for a video
> device, like
> +>drm0(or nvidia0)
You bring up a problem that I've been having also. When I commit the ACPI
performance states driver, it needs to be able to get an ACPI handle. My
solution to this is to have multiple drivers with the same name. Only the
acpi one will supply a handle to the processor object.
cpu0 (implemented in legacy.c)
cpu0 (implemented in acpi_cpu.c)
In the legacy case, acpi_perf's probe method will be called but it will
return ENXIO because the non-acpi cpu0 will always return NULL for the
ACPI_HANDLE ivar. It's kind of lame because it requires two different
drivers to implement the same ivars but it's the only way I could figure
out to allow both non-acpi and acpi-based cpufreq drivers attach.
> >There is DPMS on Sparc, for example, although I don't know how it is
> Should we have to imprement machine independent in-kernel VM86
> by emulating real mode x86? This will be needed for especially
> amd64/ia32e, which inherits many assets from ia32.
I thought DPMS on sparc was through openfirmware or some other non-x86
More information about the p4-projects