Date: Wed, 12 May 2004 17:46:42 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Takanori Watanabe <takawata@init-main.com> Cc: jhb@freebsd.org Subject: Re: PERFORCE change 52156 for review Message-ID: <20040512174010.L85042@root.org> In-Reply-To: <200405130033.i4D0Xsa8020201@sana.init-main.com> References: <200405130033.i4D0Xsa8020201@sana.init-main.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 May 2004, Takanori Watanabe wrote: > In message <20040512163137.T84786@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@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 > > pci1->video0->acpi_video0 > +>drm0(or nvidia0) > +>dpms0 > +>fb0 > ..... 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. legacy mode: legacy0 cpu0 (implemented in legacy.c) speedstep0 acpi mode: acpi0 cpu0 (implemented in acpi_cpu.c) acpi_perf0 speedstep0 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 > >implemented. > > 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 device. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040512174010.L85042>