[prev in list] [next in list] [prev in thread] [next in thread]
List: dragonfly-users
Subject: Re: loading i915 with two graphics cards
From: "karu.pruun" <karu.pruun () gmail ! com>
Date: 2016-08-19 13:11:07
Message-ID: CADdF=MJc7UsaaY0i1FqbQHjnGtGSNUv3ZK=5=jetdEDnw=seTw () mail ! gmail ! com
[Download RAW message or body]
Thanks for all the information and links. I had a look at the linux driver
apple-gmux.c, and tried to write a simple DragonFly kernel module that
switches off the gmux. However, I'm stuck with the attachment of the gmux
device: probing via acpi works fine, but I'm not able to allocate IO ports.
The gmux controller is at the LPC bus:
---
LPC
---
pciconf -lv:
isab0@pci0:0:31:0: . . .
vendor = 'Intel Corporation'
device = 'HM55 Chipset LPC Interface Controller'
class = bridge
subclass = PCI-ISA
---
----
GMUX
----
devinfo -rv | grep GMUX:
unknown pnpinfo _HID=APP000B _UID=0 at handle=\_SB_.PCI0.LPCB.GMUX
---
It seems devices attached to LPC bus can be treated as isa devices:
https://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008733.html
I tried to follow the logic of similar drivers, e.g. acpi_ec, which seems
to sit at the same bus (if I understand it correctly that the handle says
it's located at the LPC bus?):
acpi_ec0 pnpinfo . . . handle=\_SB_.PCI0.LPCB.EC__
The acpi_ec probe part is done with roughly:
---
sys/dev/acpica/acpi_ec.c:
---
acpi_ec_probe(. . .)
{
. . .
ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids)
. . .
}
---
and that works fine for gmux too. Then attach() calls bus_alloc_resource():
---
sys/dev/acpica/acpi_ec.c:
---
acpi_ec_attach(. . .)
{
. . .
res = bus_alloc_resource_any(sc->ec_dev, SYS_RES_IOPORT,
&sc->ec_data_rid, RF_ACTIVE);
. . .
}
---
But that same call returns a NULL pointer for gmux. Where have I gone
wrong?
Cheers
Peeter
--
On Thu, Aug 4, 2016 at 5:28 PM, Pedro Andrés Aranda Gutiérrez <
paaguti@gmail.com> wrote:
> BTW, there was some code around in the switcher and in mackintosh lists on
> this. File was something like gmux.c
>
>
>
> On 28 Jul 2016, at 11:45, Francois Tigeot <ftigeot@wolfpond.org> wrote:
>
> > On Thu, Jul 28, 2016 at 10:49:26AM +0200, Pedro Andres Aranda Gutierrez
> wrote:
> >> Similar problem here with an ASUS with nVidia Optimus... So it's not Mac
> >> specific...
> >
> > Well, in a way it is.
> >
> > If I'm not mistaken, most Optimus devices have their video outputs
> directly
> > connected to the Intel GPU so it's just a matter of disabling the NVidia
> one.
> >
> > On at least some Macbook models, the video output are connected to a
> third
> > chip, and this chip must also be told to talk exclusively to the Intel
> GPU at
> > boot time first.
> >
> > --
> > Francois Tigeot
>
>
[Attachment #3 (text/html)]
<div dir="ltr"><div>Thanks for all the information and links. I had a look at the \
linux driver apple-gmux.c, and tried to write a simple DragonFly kernel module that \
switches off the gmux. However, I'm stuck with the attachment of the gmux device: \
probing via acpi works fine, but I'm not able to allocate IO ports. The gmux \
controller is at the LPC \
bus:</div><div><br></div><div>---</div><div>LPC</div><div>---</div><div>pciconf -lv: \
</div><div><br></div><div>isab0@pci0:0:31:0: . . . </div><div> vendor = 'Intel \
Corporation'</div><div> device = 'HM55 Chipset LPC Interface \
Controller'</div><div> class = bridge</div><div> subclass = \
PCI-ISA</div><div>---</div><div><br></div><div>----</div><div>GMUX</div><div>----</div><div>devinfo \
-rv | grep GMUX:</div><div><br></div><div>unknown pnpinfo _HID=APP000B _UID=0 at \
handle=\_SB_.PCI0.LPCB.GMUX</div><div>---</div><div><br></div><div>It seems devices \
attached to LPC bus can be treated as isa devices: </div><div><br></div><div><a \
href="https://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008733.html">ht \
tps://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008733.html</a></div><div><br></div><div>I \
tried to follow the logic of similar drivers, e.g. acpi_ec, which seems to sit at the \
same bus (if I understand it correctly that the handle says it's located at the \
LPC bus?): </div><div><br></div><div>acpi_ec0 pnpinfo . . . \
handle=\_SB_.PCI0.LPCB.EC__</div><div><br></div><div>The acpi_ec probe part is done \
with roughly: </div><div><br></div><div>---</div><div>sys/dev/acpica/acpi_ec.c:</div><div>---</div><div><br></div><div>acpi_ec_probe(. \
. .)</div><div>{</div><div> . . .</div><div><br></div><div> \
ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids)</div><div><br></div><div> . . \
. </div><div>}</div><div>---</div><div><br></div><div>and that works fine for gmux \
too. Then attach() calls bus_alloc_resource(): \
</div><div><br></div><div>---</div><div>sys/dev/acpica/acpi_ec.c:</div><div>---</div><div><br></div><div>acpi_ec_attach(. \
. .)</div><div>{</div><div><br></div><div> . . .</div><div><br></div><div> \
res = bus_alloc_resource_any(sc->ec_dev, SYS_RES_IOPORT,</div><div><span class="" \
style="white-space:pre"> </span>&sc->ec_data_rid, \
RF_ACTIVE);</div><div><br></div><div> . . \
.</div><div>}</div><div>---</div><div><br></div><div>But that same call returns a \
NULL pointer for gmux. Where have I gone wrong? \
</div><div><br></div><div><br></div><div>Cheers</div><div><br></div><div>Peeter</div><div><br></div><div>--</div><div><br></div><div><br></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 5:28 PM, \
Pedro Andrés Aranda Gutiérrez <span dir="ltr"><<a \
href="mailto:paaguti@gmail.com" target="_blank">paaguti@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">BTW, there was some code around in the switcher and in \
mackintosh lists on this. File was something like gmux.c<br> <div class="HOEnZb"><div \
class="h5"><br> <br>
<br>
On 28 Jul 2016, at 11:45, Francois Tigeot <<a \
href="mailto:ftigeot@wolfpond.org">ftigeot@wolfpond.org</a>> wrote:<br> <br>
> On Thu, Jul 28, 2016 at 10:49:26AM +0200, Pedro Andres Aranda Gutierrez \
wrote:<br> >> Similar problem here with an ASUS with nVidia Optimus... So \
it's not Mac<br> >> specific...<br>
><br>
> Well, in a way it is.<br>
><br>
> If I'm not mistaken, most Optimus devices have their video outputs \
directly<br> > connected to the Intel GPU so it's just a matter of disabling \
the NVidia one.<br> ><br>
> On at least some Macbook models, the video output are connected to a third<br>
> chip, and this chip must also be told to talk exclusively to the Intel GPU \
at<br> > boot time first.<br>
><br>
> --<br>
> Francois Tigeot<br>
<br>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic