PERFORCE change 52156 for review

[Takanori Watanabe]

In message <20040512174010.L85042 at root.org>, Nate Lawson wrote:
>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 DPM
>S
>> >> > 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 w
>ork
>> >> 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 dev
>ice
>> >.
>> >> 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 arc
>hs
>> >> 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.

In this case, pci1 and its children know ACPI handle, if 
ACPI vga extension is appeard in the name space tree.
You will see this by devinfo(8) with -v option. So the 
role of video0 driver is manage child drivers.
All request may forwarded to the grand parent.


>> >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.

XFree86 has x86 emulator to use vga bios for initializing in other
archtecture.