hybrid-graphics-linux team mailing list archive

[Albert Vilella <avilella@xxxxxxxxx>]

yes, the first implementation of acpi_call has no parameter passing...
it would be great to have that implemented and allow for more testing.

On Sat, Jul 24, 2010 at 12:31 PM, Durango. <durango8113@xxxxxxxxxxxx> wrote:
> Thanks Albert
>
> This is true ,but beware the DSDT may be buggy ,you can compare it with the
> windows one ( different compiler)
> or do the dsdt dump and recompile to see any errors ,on my N61 i have some
> errors and warnings .
>
> We need the acpi_call module to accept parameters as this will further
> testing on the optimus systems ,as there
> are calls to the DSM ( eg 0x86 or 0x89 ) which can be passed to the
> acpi_call module for ease ,this would enable
> us to also try to trigger the MUX with the arguments,ie and possibly grab
> the LCDD,this is from my files on the N61.
>
> If (LEqual (\_SB.PCI0.GFX0.HGAP, 0x02))
>             {
>                 Notify (\_SB.PCI0.GFX0.LCDD, 0x86)
>                 Notify (LCDD, 0x86)
>
> Currently this module is parameter-less ,see file comments ,for example if
> you could have acpi_call accept
> parameters for your K52 you could parse the Store values in the line instead
> of typing something like
> echo $(($arg0x00)) > /proc/acpi/call  ,which doesnt work even after normal
> GFX call .
>
> Asus.K52Jc.DSDT.dsl:11035:                    Store (0x00,
> \_SB.PCI0.GFX0.DSM2)
>
>
> If i get time to finsh this and some dsdt fixes ,hopefully to enable the
> nvidia card to post and be the primary
> card via a modified dsdt .
>
> I will let you know and post any hard progress ,as this is possible .
>
> # Snip of Windoze Information -
>
> Windows has the intel card using the nvidia drivers and the intel drivers
> are loaded by the nvidia card also,
> for the optimus operation ,they both utilise a common IGDM*** intel windows
> module with a dumx screen
> ,similiar to a screen function in nix or a headless X .
>
> Cheers
>
>
>
>
> On 07/24/2010 01:23 AM, Albert Vilella wrote:
>
> Just to let people know, it seems like some of the optimus-enabled
> laptops also have a _DSM method, linked to a DSM2 stub:
>
> grep DSM *.dsl -Rin | grep -e K52 -e U30
> Asus.K52Jc.DSDT.dsl:10549:                Name (DSM2, 0x00)
> Asus.K52Jc.DSDT.dsl:10550:                Name (DSM5, 0x00)
> Asus.K52Jc.DSDT.dsl:10593:                Method (_DSM, 4, NotSerialized)
> Asus.K52Jc.DSDT.dsl:10635:                                    Or
> (DSM2, 0x10, DSM2)
> Asus.K52Jc.DSDT.dsl:10636:                                    Return (DSM2)
> Asus.K52Jc.DSDT.dsl:10750:
>            Store (DSM5, Local0)
> Asus.K52Jc.DSDT.dsl:11019:                    Store (Local0,
> \_SB.PCI0.GFX0.DSM2)
> Asus.K52Jc.DSDT.dsl:11035:                    Store (0x00,
> \_SB.PCI0.GFX0.DSM2)
> Asus.K52Jc.DSDT.dsl:21106:        Method (_DSM, 4, NotSerialized)
> Asus.K52Jc.DSDT.dsl:21108:            Return (\_SB.PCI0.GFX0._DSM
> (Arg0, Arg1, Arg2, Arg3))
> Asus.K52Jc.DSDT.dsl:21600:
> Return (\_SB.PCI0.GFX0._DSM (MUID, REVI, SFNC, SARG))
> DSDT_Asus_U30JC.dsl:10669:                Name (DSM2, 0x00)
> DSDT_Asus_U30JC.dsl:10670:                Name (DSM5, 0x00)
> DSDT_Asus_U30JC.dsl:10713:                Method (_DSM, 4, NotSerialized)
> DSDT_Asus_U30JC.dsl:10755:                                    Or
> (DSM2, 0x10, DSM2)
> DSDT_Asus_U30JC.dsl:10756:                                    Return (DSM2)
> DSDT_Asus_U30JC.dsl:10870:
>            Store (DSM5, Local0)
> DSDT_Asus_U30JC.dsl:11139:                    Store (Local0,
> \_SB.PCI0.GFX0.DSM2)
> DSDT_Asus_U30JC.dsl:11155:                    Store (0x00,
> \_SB.PCI0.GFX0.DSM2)
> DSDT_Asus_U30JC.dsl:21433:        Method (_DSM, 4, NotSerialized)
> DSDT_Asus_U30JC.dsl:21435:            Return (\_SB.PCI0.GFX0._DSM
> (Arg0, Arg1, Arg2, Arg3))
> DSDT_Asus_U30JC.dsl:21932:
> Return (\_SB.PCI0.GFX0._DSM (MUID, REVI, SFNC, SARG))
>
> Not sure if the patch is supposed to do anything for them, though.
>
> On Fri, Jul 23, 2010 at 8:25 AM, octagonhead <octagonhead@xxxxxxxxx> wrote:
>
>
> Forgot to mention that this is running on a UL30VT,
> and there is not so much as a flicker from the screen when manipulating the
> switch file
>
> On 10-07-23 12:14 AM, octagonhead wrote:
>
>   Here is the result of my running this kernel with this patch applied
> Note that I used the ubuntu-provided linux-source package of 2.6.35-rc5
> rather
> than the vanilla kernel,
> So please let me know if this is expected to not work,
>
> the switcheroo interface is created:
>
> /sys/kernel/debug/vgaswitcheroo# cat switch
> 0:+:Pwr:0000:00:02.0
> 1: :Pwr:0000:01:00.0
>
> Here are the results of the switching commands I tried:
>
> /sys/kernel/debug/vgaswitcheroo# echo DIGD > switch
> vga_switcheroo: client 0 refused switch
> vga_switcheroo: setting delayed switch to client 0
>
> /sys/kernel/debug/vgaswitcheroo# echo DDIS > switch
> vga_switcheroo: client 0 refused switch
> vga_switcheroo: setting delayed switch to client 1
>
> /sys/kernel/debug/vgaswitcheroo# echo OFF > switch
>
> ^^^this seems to work, causing the nouveau driver to unload
> (but not removing the nvidia PCI device nor reducing power consumption
> according
> to powertop),
> but usually causes a kernel freeze after about a minute
>
> dmesg is attached, with kernel trace at the end
>
> ...
> Anyone wishing to make use of my kernel image may find an Ubuntu package at
> one
> of these urls:
> (sub-arch is Core-Duo/Xeon, all other config options are based of a stock
> Ubuntu
> kernel)
>
> http://rapidshare.com/files/408536337/linux-image-2.6.35-rc5_CustomDebugNV.01_amd64.deb
> or
> http://hotfile.com/dl/56924631/1202d13/linux-image-2.6.35-rc5_CustomDebugNV.01_amd64.deb.html
>
> Please run this command post installing or this kernel will fail to boot! :
> # mkinitramfs -k 2.6.35-rc5 -o /boot/initrd.img-2.6.35-rc5
>
> (sorry, im too lazy to properly include the initrd or create a PPA at this
> point :)
>
>
> On 10-07-19 04:11 PM, Dave Airlie wrote:
>
>
> Okay first attempt at a patch is
>
>
> http://people.freedesktop.org/~airlied/scratch/0001-nouveau-mux-switching-test-patch-1.patch
>
> Applies on top of current Linus tree, a dmesg from a pre-optimus
> machine with hybrid enabled should let me see the current state of the
> toggle,
> and if you are feeling brave you shuold be able to toggle the mux, so
> it might flip from intel to nothing, and flip back or it might do
> nothing.
>
> stuff should be logged in dmesg.
>
> Dave.
>
> On Sat, Jul 17, 2010 at 6:45 PM, Dave Airlie<airlied@xxxxxxxxx>  wrote:
>
>
> So I'd really like to finish the _DSM support in nouveau so we can
> actually switch the GPU over on the non-optimus systems.
>
> There are two things left to do:
>
> a) figure out what values to pass the DSM method to trigger the MUX,
> It looks like method 0x5 is the one to trigger the mux switch but I've
> no idea yet what values to pass it to trigger the mux switch.
>
> b) figure out how to get the LVDS DDC lines and make nouveau find the
> panel, at the moment it fails to find the panel when booted and intel
> is in control.
>
> looking at (a) I expect we could pass a bunch of values to the ACPI
> method possibly using acpi_call to switch the mux and switch it back,
>
> It looks like passing 0 will return the current toggle status, then
> its a matter of working out which of the top bits are doing what,
>
>  From reading one DSDT I can see,
>
> if bit 31 set, then bit 30 is some sort of notify, then bits 25,26,27
> are used to work out some values stored in a TOGF
>
> otherwise bit 24 is used for something, then bits 12,13,14, and 3,2,1,
> and it stores some values for CRT/LCD/TVout, which may again be
> toggles.
>
> If someone with the hardware and can use acpi_call it would be nice to
> try and map out some of these things, at least initially a value that
> will turn the Intel LCD off and back on.
>
> The DSDT I'm using at the moment is attached to bug 16403.
>
> Dave.
>
>
>
> _______________________________________________
> Mailing list:https://launchpad.net/~hybrid-graphics-linux
> Post to     :hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx
> Unsubscribe :https://launchpad.net/~hybrid-graphics-linux
> More help   :https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~hybrid-graphics-linux
> Post to     : hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
> More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~hybrid-graphics-linux
> Post to     : hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
> More help   : https://help.launchpad.net/ListHelp
>
>
>