[patch 0/4] Hot Dock/Undock support

[patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

This series of patches is against the -mm kernel, and will enable
docking station support.  It is an early patch, but still pretty 
functional, so I think it's worthwhile to include at this point.
For some laptops, it's necessary to use the pci=assign-busses kernel 
parameter, because some _DCK methods will attempt to assign bus numbers
to the dock bridge (incorrectly).

Supported Features:
* Hot Dock/Undock via hardware control
* Enumeration of PCI Devices on Dock Station (Hot Add/Remove) via pci 

Not Supported Yet (but will be with laptops with sane dsdts):
* _EJD, _EDL support for devices that aren't enumerable
* hot add of devices other than PCI devices (such as the serial/lpt etc).
* More thorough testing needs to be done for everything, but especially
  video, as I've not even begun to worry about that.

All docking events are handled by the acpiphp driver.  For docking,
the acpiphp driver will call the _DCK acpi method, and then insert
the docking bridge and all the pci devices behind the dock bridge.
This is in conflict with some acpi platform drivers (ibm_acpi) that already
attempt to implement a limited form of docking support only for that platform.
You may not use both drivers at the same time right now.  This is a generic
docking solution that should work for all docking stations, not just IBM,
although I tested it on an IBM docking station exclusively, because that's
all I've got right now. 

Right now devices that are not on enumerable buses (or on the PCI bus at all) 
will not be discovered by acpiphp.  Your mileage will vary on any devices 
other than PCI.  This is because in many cases, there are extra hardware 
configuration steps that need to occur after the _DCK method (because they 
really should have been done in the _DCK method but were not).  Even with PCI 
devices, you may find that some things don't work properly, because there 
was some extra configuration step that needed to occur that didn't get done 
as part of _DCK.  For example, included in this patch series is a quirk for the
IBM Dock Station II, which seemed to need the cardbus controller interrupts
tied together, but this didn't get done with any of the laptops I tested
with.  I've not yet been able to determine what needs to be done to the 
USB controller on the T30 or T41 to make it discover the USB hub on the
docking station, although this works fine on the T20, and also I hear on
the T42, although I've not tested the T42 myself.  

You may also find that as soon as you call _DCK, everything is
broken.  For example, on the T30 laptop I tested, the _DCK method would set
the dock bridge's parent secondary bus number to zero, even if it should
have been something other than zero.  This specific case is handled in
the acpiphp driver in the post_dock_fixups() routine, but this may need to
be changed for the future if it starts to get out of hand. 

There is a workaround right now in this patch for a problem with acpi, where
the acpi thread that notifies acpiphp of the dock event will deadlock while
executing the _DCK method.  I've managed to avoid trying to solve this 
problem for now by spawning a separate thread to handle the _DCK, but 
eventually this will be addressed when I'm brave enough. 

Please comment on these patches, and test if you have a docking station
available.  When you find problems, if you would like me to debug them,
please load the acpiphp driver with the debug param (modprobe acpiphp debug=1),
and send me the output of dmesg -s 100000 as well as lspci -vv -x -n with
the laptop booted in the station, and then the output after booting out
of the station and attempting to dock, as well as a copy of your disassembled
dsdt.  Make sure you have PCI debugging enabled, and debugging enabled for
whatever device you are having issues with.  This should be a good starting 
point.

Kristen

Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

> This series of patches is against the -mm kernel, and will enable
> docking station support.  It is an early patch, but still pretty 
> functional, so I think it's worthwhile to include at this point.

They seem to be in 2.6.16-rc1-mm1 patch, good.

> Supported Features:
> * Hot Dock/Undock via hardware control
> * Enumeration of PCI Devices on Dock Station (Hot Add/Remove) via pci 
> 
> Not Supported Yet (but will be with laptops with sane dsdts):
> * _EJD, _EDL support for devices that aren't enumerable
> * hot add of devices other than PCI devices (such as the serial/lpt etc).
> * More thorough testing needs to be done for everything, but especially
>   video, as I've not even begun to worry about that.
...
> Please comment on these patches, and test if you have a docking station
> available.  When you find problems, if you would like me to debug them,
> please load the acpiphp driver with the debug param (modprobe
> acpiphp debug=1),

I'll try to test them and write some small docking HOWTO (or maybe
force you to write it :-). This is not exactly easy to setup...
								Pavel
-- 
Thanks, Sharp!

Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

> This series of patches is against the -mm kernel, and will enable
> docking station support.  It is an early patch, but still pretty 
> functional, so I think it's worthwhile to include at this point.
> For some laptops, it's necessary to use the pci=assign-busses kernel 
> parameter, because some _DCK methods will attempt to assign bus numbers
> to the dock bridge (incorrectly).

On thinkpad X32: I selected

CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
CONFIG_HOTPLUG_PCI_ACPI=y
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_ACPI_IBM=y

Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is
empty. I then inserted machine into dock, and locked it:

root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
root@amd:/sys/bus/pci/slots# ls
root@amd:/sys/bus/pci/slots#

...still empty. What am I doing wrong?
								Pavel
-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

On Wed, 2006-01-18 at 14:04 +0100, Pavel Machek wrote:
> Hi!
> 
> > This series of patches is against the -mm kernel, and will enable
> > docking station support.  It is an early patch, but still pretty 
> > functional, so I think it's worthwhile to include at this point.
> > For some laptops, it's necessary to use the pci=assign-busses kernel 
> > parameter, because some _DCK methods will attempt to assign bus numbers
> > to the dock bridge (incorrectly).
> 
> On thinkpad X32: I selected
> 
> CONFIG_HOTPLUG_PCI=y
> # CONFIG_HOTPLUG_PCI_FAKE is not set
> # CONFIG_HOTPLUG_PCI_COMPAQ is not set
> # CONFIG_HOTPLUG_PCI_IBM is not set
> CONFIG_HOTPLUG_PCI_ACPI=y
> # CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
> # CONFIG_HOTPLUG_PCI_CPCI is not set
> # CONFIG_HOTPLUG_PCI_SHPC is not set
> CONFIG_ACPI_IBM=y
> 
> Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is
> empty. I then inserted machine into dock, and locked it:
> 
> root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
> root@amd:/sys/bus/pci/slots# ls
> root@amd:/sys/bus/pci/slots#
> 
> ...still empty. What am I doing wrong?
> 								Pavel

You may not use the ibm_acpi driver at the same time as the acpiphp
driver for docking.  This is because the ibm_acpi driver also tries to
handle the dock event notification, and doesn't actually do any
hotplugging of the devices.  So, you want to set that config option to
N.  What you are doing above is actually writing to the ibm_acpi driver.
I didn't provide a way to do undocking via software. I just use the
button on the dock station.  You should however, see something
in /sys/bus/pci/slots - can you scan your dmesg to make sure that the
acpiphp driver is running?  You might run it as a module and enable
debugging:

modprobe acpiphp debug=1

This way we can see if it finds your dock slot and registers the notify
handler.

Thanks for testing!

Kristen

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

> > > This series of patches is against the -mm kernel, and will enable
> > > docking station support.  It is an early patch, but still pretty 
> > > functional, so I think it's worthwhile to include at this point.
> > > For some laptops, it's necessary to use the pci=assign-busses kernel 
> > > parameter, because some _DCK methods will attempt to assign bus numbers
> > > to the dock bridge (incorrectly).
> > 
> > On thinkpad X32: I selected
...
> > Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is
> > empty. I then inserted machine into dock, and locked it:
> > 
> > root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
> > root@amd:/sys/bus/pci/slots# ls
> > root@amd:/sys/bus/pci/slots#
> > 
> > ...still empty. What am I doing wrong?
> 
> You may not use the ibm_acpi driver at the same time as the acpiphp
> driver for docking.  This is because the ibm_acpi driver also tries to
> handle the dock event notification, and doesn't actually do any
> hotplugging of the devices.  So, you want to set that config option to
> N.  What you are doing above is actually writing to the ibm_acpi
> driver.

Done.

> I didn't provide a way to do undocking via software. I just use the
> button on the dock station.  You should however, see something
> in /sys/bus/pci/slots - can you scan your dmesg to make sure that the
> acpiphp driver is running?  You might run it as a module and enable
> debugging:
> 
> modprobe acpiphp debug=1
> 
> This way we can see if it finds your dock slot and registers the notify
> handler.

Result is:

root@amd:/data/l/linux-mm/drivers/pci/hotplug# insmod acpiphp.ko debug=1
insmod: error inserting 'acpiphp.ko': -1 No such device
root@amd:/data/l/linux-mm/drivers/pci/hotplug# dmesg | tail -3
Failure of coda_cnode_make for root: error -19
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_glue: Total 0 slots
root@amd:/data/l/linux-mm/drivers/pci/hotplug#

Should I have CONFIG_HOTPLUG_PCI_ACPI_IBM set?

								Pavel

-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

On Wed, 2006-01-18 at 20:45 +0100, Pavel Machek wrote:
> Hi!
> 
> > > > This series of patches is against the -mm kernel, and will enable
> > > > docking station support.  It is an early patch, but still pretty 
> > > > functional, so I think it's worthwhile to include at this point.
> > > > For some laptops, it's necessary to use the pci=assign-busses kernel 
> > > > parameter, because some _DCK methods will attempt to assign bus numbers
> > > > to the dock bridge (incorrectly).
> > > 
> > > On thinkpad X32: I selected
> ...
> > > Recompiled, rebooted with machine out of dock. /sys/bus/pci/slots/ is
> > > empty. I then inserted machine into dock, and locked it:
> > > 
> > > root@amd:/sys/bus/pci/slots# echo dock > /proc/acpi/ibm/dock
> > > root@amd:/sys/bus/pci/slots# ls
> > > root@amd:/sys/bus/pci/slots#
> > > 
> > > ...still empty. What am I doing wrong?
> > 
> > You may not use the ibm_acpi driver at the same time as the acpiphp
> > driver for docking.  This is because the ibm_acpi driver also tries to
> > handle the dock event notification, and doesn't actually do any
> > hotplugging of the devices.  So, you want to set that config option to
> > N.  What you are doing above is actually writing to the ibm_acpi
> > driver.
> 
> Done.
> 
> > I didn't provide a way to do undocking via software. I just use the
> > button on the dock station.  You should however, see something
> > in /sys/bus/pci/slots - can you scan your dmesg to make sure that the
> > acpiphp driver is running?  You might run it as a module and enable
> > debugging:
> > 
> > modprobe acpiphp debug=1
> > 
> > This way we can see if it finds your dock slot and registers the notify
> > handler.
> 
> Result is:
> 
> root@amd:/data/l/linux-mm/drivers/pci/hotplug# insmod acpiphp.ko debug=1
> insmod: error inserting 'acpiphp.ko': -1 No such device
> root@amd:/data/l/linux-mm/drivers/pci/hotplug# dmesg | tail -3
> Failure of coda_cnode_make for root: error -19
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> acpiphp_glue: Total 0 slots
> root@amd:/data/l/linux-mm/drivers/pci/hotplug#
> 
> Should I have CONFIG_HOTPLUG_PCI_ACPI_IBM set?
> 
> 								Pavel
> 


Hum, I don't think so (but maybe someone else knows for sure), I thought
that driver was specifically for a certain kind of IBM server, not an
IBM laptop.  It looks like from this output that the acpiphp is not
recognizing any hotplug capable devices on your laptop.  I believe that
this is defined by acpiphp as a slot which is "ejectable", meaning
contains an ACPI method called _EJ0.  I think we should take a look at
your dsdt to make sure that it seems reasonable, and also perhaps you
could send the output of lspci -vv -x with the laptop booted in the dock
just to see what kind of dock bridge you have and make sure everything
seems like it should work.  Please send the disassembled output of your
dsdt - if you've never done it before, instructions for doing this can
be found here: 
http://acpi.sourceforge.net/dsdt/index.php

thanks!
Kristen

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Matthew Garrett]

On Wed, Jan 18, 2006 at 01:06:09PM -0800, Kristen Accardi wrote:

> Hum, I don't think so (but maybe someone else knows for sure), I thought
> that driver was specifically for a certain kind of IBM server, not an
> IBM laptop.  It looks like from this output that the acpiphp is not
> recognizing any hotplug capable devices on your laptop.  I believe that
> this is defined by acpiphp as a slot which is "ejectable", meaning
> contains an ACPI method called _EJ0.  

To the best of my knowledge, the X-series docking station doesn't 
contain any PCI devices. It's an extension of the IDE bus plus some 
broken out serial, parallel, USB and so on. I'd expect driver support 
for it to just require supporting the dock object and calling its eject 
routine when the user hits the eject button.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

On St 18-01-06 21:47:09, Matthew Garrett wrote:
> On Wed, Jan 18, 2006 at 01:06:09PM -0800, Kristen Accardi wrote:
> 
> > Hum, I don't think so (but maybe someone else knows for sure), I thought
> > that driver was specifically for a certain kind of IBM server, not an
> > IBM laptop.  It looks like from this output that the acpiphp is not
> > recognizing any hotplug capable devices on your laptop.  I believe that
> > this is defined by acpiphp as a slot which is "ejectable", meaning
> > contains an ACPI method called _EJ0.  
> 
> To the best of my knowledge, the X-series docking station doesn't 
> contain any PCI devices. It's an extension of the IDE bus plus some 
> broken out serial, parallel, USB and so on. I'd expect driver support 
> for it to just require supporting the dock object and calling its eject 
> routine when the user hits the eject button.

My docking station (there are two different versions of them,
"regular" and "port extender") certainly contains PCI device. I
installed hp100 network card into it :-).

							Pavel

-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

> Hum, I don't think so (but maybe someone else knows for sure), I thought
> that driver was specifically for a certain kind of IBM server, not an
> IBM laptop.  It looks like from this output that the acpiphp is not
> recognizing any hotplug capable devices on your laptop.  I believe that
> this is defined by acpiphp as a slot which is "ejectable", meaning
> contains an ACPI method called _EJ0.  I think we should take a look at
> your dsdt to make sure that it seems reasonable, and also perhaps you
> could send the output of lspci -vv -x with the laptop booted in the dock
> just to see what kind of dock bridge you have and make sure everything
> seems like it should work.  Please send the disassembled output of your
> dsdt - if you've never done it before, instructions for doing this can
> be found here: 
> http://acpi.sourceforge.net/dsdt/index.php

I sent verbose lspci and acpidump via private email. Regular lspci
looks like: (booted in dock but now undocked, sorry).

pavel@amd:~$ lspci
0000:00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
0000:00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
0000:00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
0000:00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
0000:00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
0000:00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
0000:00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
0000:00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
0000:00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
0000:00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
0000:02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
0000:02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02)
0000:02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev
03)
0000:02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
0000:02:03.0 ffff: Texas Instruments PCI2032 PCI Docking Bridge (rev ff)
0000:09:00.0 ffff: Hewlett-Packard Company J2585B HP 10/100VG PCI LAN Adapter (rev ff)
0000:09:01.0 ffff: Silicon Image, Inc. PCI0648 (rev ff)
0000:09:02.0 ffff: Texas Instruments PCI1420 (rev ff)
0000:09:02.1 ffff: Texas Instruments PCI1420 (rev ff)

The ffff: lines are probably what is contained inside the dock.

Device GDCK looks like dock to my untrained eye. Unfortunately its
type is IBM0079... ...

Ahha, and ibm_acpi.c agrees with me.

IBM_HANDLE(dock, root, "\\_SB.GDCK",    /* X30, X31, X40 */

        Scope (\_SB)
        {
            Device (GDCK)
            {
                Name (_HID, EisaId ("IBM0079"))
                Name (_CID, 0x150CD041)
                Method (_STA, 0, NotSerialized)
                {
...
                Method (_DCK, 1, NotSerialized)
                {
                    Store (0x00, Local0)
                    If (LEqual (GGID (), 0x03))
                    {
                        Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
                    }

                    Return (Local0)
                }

                Method (_EJ0, 1, NotSerialized)
                {
                    If (LEqual (GGID (), 0x03))
                    {
                        \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
                    }

                    If (LEqual (GGID (), 0x00))
                    {
                        \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
                    }
                }
....

Hope this helps.
						Pavel
-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

On Wed, 2006-01-18 at 23:23 +0100, Pavel Machek wrote:
<snip>
> Device GDCK looks like dock to my untrained eye. Unfortunately its
> type is IBM0079... ...
> 
> Ahha, and ibm_acpi.c agrees with me.
> 
> IBM_HANDLE(dock, root, "\\_SB.GDCK",    /* X30, X31, X40 */
> 
>         Scope (\_SB)
>         {
>             Device (GDCK)
>             {
>                 Name (_HID, EisaId ("IBM0079"))
>                 Name (_CID, 0x150CD041)
>                 Method (_STA, 0, NotSerialized)
>                 {
> ...
>                 Method (_DCK, 1, NotSerialized)
>                 {
>                     Store (0x00, Local0)
>                     If (LEqual (GGID (), 0x03))
>                     {
>                         Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
>                     }
> 
>                     If (LEqual (GGID (), 0x00))
>                     {
>                         Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
>                     }
> 
>                     Return (Local0)
>                 }
> 
>                 Method (_EJ0, 1, NotSerialized)
>                 {
>                     If (LEqual (GGID (), 0x03))
>                     {
>                         \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
>                     }
> 
>                     If (LEqual (GGID (), 0x00))
>                     {
>                         \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
>                     }
>                 }
> ....
> 
> Hope this helps.
> 						Pavel


so the problem that I see is that this dsdt defines two separate dock
devices, one outside the scope of pci, and one within it.  The one
outside the scope of pci defines the _EJ0 and _DCK methods.  So, when
acpiphp loads, it scans the pci slots for ejectable slots, finds none
(because _EJ0 is defined in the dock device that is outside the scope of
pci) and exits.  This dsdt is different from the others I've used in
that most of them define all methods related to docking under the actual
dock bridge (within the scope of pci).  perhaps some acpi people can
shed some light on the best way to handle this - otherwise I'm sure I
can hack something up that will be less than acceptable :).

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Dmitry Torokhov]

On 1/18/06, Kristen Accardi <kristen.c.accardi@intel.com> wrote:
> On Wed, 2006-01-18 at 23:23 +0100, Pavel Machek wrote:
> <snip>
> > Device GDCK looks like dock to my untrained eye. Unfortunately its
> > type is IBM0079... ...
> >
> > Ahha, and ibm_acpi.c agrees with me.
> >
> > IBM_HANDLE(dock, root, "\\_SB.GDCK",    /* X30, X31, X40 */
> >
> >         Scope (\_SB)
> >         {
> >             Device (GDCK)
> >             {
> >                 Name (_HID, EisaId ("IBM0079"))
> >                 Name (_CID, 0x150CD041)
> >                 Method (_STA, 0, NotSerialized)
> >                 {
> > ...
> >                 Method (_DCK, 1, NotSerialized)
> >                 {
> >                     Store (0x00, Local0)
> >                     If (LEqual (GGID (), 0x03))
> >                     {
> >                         Store (\_SB.PCI0.LPC.EC.SDCK (Arg0), Local0)
> >                     }
> >
> >                     If (LEqual (GGID (), 0x00))
> >                     {
> >                         Store (\_SB.PCI0.PCI1.DOCK.DDCK (Arg0), Local0)
> >                     }
> >
> >                     Return (Local0)
> >                 }
> >
> >                 Method (_EJ0, 1, NotSerialized)
> >                 {
> >                     If (LEqual (GGID (), 0x03))
> >                     {
> >                         \_SB.PCI0.LPC.EC.SEJ0 (Arg0)
> >                     }
> >
> >                     If (LEqual (GGID (), 0x00))
> >                     {
> >                         \_SB.PCI0.PCI1.DOCK.DEJ0 (Arg0)
> >                     }
> >                 }
> > ....
> >
> > Hope this helps.
> >                                               Pavel
>
>
> so the problem that I see is that this dsdt defines two separate dock
> devices, one outside the scope of pci, and one within it.  The one
> outside the scope of pci defines the _EJ0 and _DCK methods.  So, when
> acpiphp loads, it scans the pci slots for ejectable slots, finds none
> (because _EJ0 is defined in the dock device that is outside the scope of
> pci) and exits.  This dsdt is different from the others I've used in
> that most of them define all methods related to docking under the actual
> dock bridge (within the scope of pci).  perhaps some acpi people can
> shed some light on the best way to handle this - otherwise I'm sure I
> can hack something up that will be less than acceptable :).
>

ACPI has (had?) a braindamage - it drops devices that do not present
when initially scanning ACPI namespace. So if you boot undocked - too
bad. Driver won't ever see your docking station.

--
Dmitry

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

> > > Hope this helps.
> > >                                               Pavel
> >
> >
> > so the problem that I see is that this dsdt defines two separate dock
> > devices, one outside the scope of pci, and one within it.  The one
> > outside the scope of pci defines the _EJ0 and _DCK methods.  So, when
> > acpiphp loads, it scans the pci slots for ejectable slots, finds none
> > (because _EJ0 is defined in the dock device that is outside the scope of
> > pci) and exits.  This dsdt is different from the others I've used in
> > that most of them define all methods related to docking under the actual
> > dock bridge (within the scope of pci).  perhaps some acpi people can
> > shed some light on the best way to handle this - otherwise I'm sure I
> > can hack something up that will be less than acceptable :).
> >
> 
> ACPI has (had?) a braindamage - it drops devices that do not present
> when initially scanning ACPI namespace. So if you boot undocked - too
> bad. Driver won't ever see your docking station.

I think I booted docked....

-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

On Wed, 2006-01-18 at 14:51 +0000, Pavel Machek wrote:
> Hi!
> 
> > > > Hope this helps.
> > > >                                               Pavel
> > >
> > >
> > > so the problem that I see is that this dsdt defines two separate dock
> > > devices, one outside the scope of pci, and one within it.  The one
> > > outside the scope of pci defines the _EJ0 and _DCK methods.  So, when
> > > acpiphp loads, it scans the pci slots for ejectable slots, finds none
> > > (because _EJ0 is defined in the dock device that is outside the scope of
> > > pci) and exits.  This dsdt is different from the others I've used in
> > > that most of them define all methods related to docking under the actual
> > > dock bridge (within the scope of pci).  perhaps some acpi people can
> > > shed some light on the best way to handle this - otherwise I'm sure I
> > > can hack something up that will be less than acceptable :).
> > >
> > 
> > ACPI has (had?) a braindamage - it drops devices that do not present
> > when initially scanning ACPI namespace. So if you boot undocked - too
> > bad. Driver won't ever see your docking station.
> 
> I think I booted docked....
> 

Yeah, that's not the problem here.  The problem is that I assumed that
all _DCK methods would be defined under the actual pci dock bridge
device.  It seems that was a bad assumption.  I am redoing this patch so
as to not assume that anymore.  I'll repost it as soon as I'm done with
a little bit of testing.

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Hi!

There's a bug in error handling:

int __init acpiphp_glue_init(void)
{
        int num = 0;

        acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
                        ACPI_UINT32_MAX, find_root_bridges, &num,
NULL);

        if (num <= 0)
                return -1;
        else
                acpi_pci_register_driver(&acpi_pci_hp_driver);

        return 0;
}

You register driver here, but if acpiphp_get_num_slots() returns 0
later, you return -ENODEV, aborting load of driver, but without
undergistering that driver. It oopses after a while. Same problem if
init_slots() returns error.

								Pavel
-- 
Thanks, Sharp!

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Kristen Accardi]

On Wed, 2006-01-18 at 21:42 +0100, Pavel Machek wrote:
> Hi!
> 
> There's a bug in error handling:
> 
> int __init acpiphp_glue_init(void)
> {
>         int num = 0;
> 
>         acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
>                         ACPI_UINT32_MAX, find_root_bridges, &num,
> NULL);
> 
>         if (num <= 0)
>                 return -1;
>         else
>                 acpi_pci_register_driver(&acpi_pci_hp_driver);
> 
>         return 0;
> }
> 
> You register driver here, but if acpiphp_get_num_slots() returns 0
> later, you return -ENODEV, aborting load of driver, but without
> undergistering that driver. It oopses after a while. Same problem if
> init_slots() returns error.
> 
> 								Pavel

This one needs some more thought on how to fix, because I'm not certain
if we have the code in place to back out of this once we find root
bridges that exist.  it might be easy, but it might not be. 

Re: [Pcihpd-discuss] Re: [patch 0/4] Hot Dock/Undock support

[Pavel Machek]

Few cleanups for acpiphp_glue, and spelling fix in warning. It still
does not use consistent function definitions, but lets pretentd it is
to fit into 80 columns.

Signed-off-by: Pavel Machek <pavel@suse.cz>

--- clean-mm/drivers/pci/hotplug/acpiphp_glue.c	2006-01-18 12:52:02.000000000 +0100
+++ linux-mm/drivers/pci/hotplug/acpiphp_glue.c	2006-01-18 22:09:08.000000000 +0100
@@ -91,14 +94,12 @@
 	acpi_handle tmp;
 
 	status = acpi_get_handle(handle, "_ADR", &tmp);
-	if (ACPI_FAILURE(status)) {
+	if (ACPI_FAILURE(status))
 		return 0;
-	}
 
 	status = acpi_get_handle(handle, "_EJ0", &tmp);
-	if (ACPI_FAILURE(status)) {
+	if (ACPI_FAILURE(status))
 		return 0;
-	}
 
 	return 1;
 }
@@ -470,7 +473,7 @@
 			dbg("%s: _STA evaluation failure\n", __FUNCTION__);
 			return 0;
 		}
-		if ((tmp & ACPI_STA_FUNCTIONING) == 0)
+		if (!(tmp & ACPI_STA_FUNCTIONING))
 			/* don't register this object */
 			return 0;
 	}
@@ -503,12 +508,12 @@
 		return 0;
 	}
 
 	/* search P2P bridges under this host bridge */
 	status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
 				     find_p2p_bridge, pci_bus, NULL);
 
 	if (ACPI_FAILURE(status))
-		warn("find_p2p_bridge faied (error code = 0x%x)\n",status);
+		warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
 
 	return 0;
 }
@@ -587,7 +593,7 @@
 	}
 }
 
-static struct pci_dev * get_apic_pci_info(acpi_handle handle)
+static struct pci_dev *get_apic_pci_info(acpi_handle handle)
 {
 	struct acpi_pci_id id;
 	struct pci_bus *bus;
@@ -891,8 +897,8 @@
  * this slot and return the one that represents the given
  * pci_dev structure.
  */
-static struct acpiphp_func * get_func(struct acpiphp_slot *slot,
-					struct pci_dev *dev)
+static struct
+acpiphp_func *get_func(struct acpiphp_slot *slot, struct pci_dev *dev)
 {
 	struct list_head *l;
 	struct acpiphp_func *func;
@@ -912,8 +918,7 @@
 /** acpiphp_max_busnr - find the max reserved busnr for this bus
  *  @bus: the bus to scan
  */
-static unsigned char
-acpiphp_max_busnr(struct pci_bus *bus)
+static unsigned char acpiphp_max_busnr(struct pci_bus *bus)
 {
 	struct list_head *tmp;
 	unsigned char max, n;
@@ -1476,9 +1481,9 @@
 	if (is_root_bridge(handle)) {
 		acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
 				handle_hotplug_event_bridge, NULL);
-			(*count)++;
+		(*count)++;
 	}
-	return AE_OK ;
+	return AE_OK;
 }
 
 static struct acpi_pci_driver acpi_pci_hp_driver = {


-- 
Thanks, Sharp!