The method struct vga_switcheroo_handler::get_client_id() is defined
as returning an 'enum vga_switcheroo_client_id' but the implementation
in this driver, radeon_atpx_get_client_id(), returns an 'int'.

Fix this by returning 'enum vga_switcheroo_client_id' in this driver too.
Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
o Neaten a few macros now using pr_<level>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The ATPX method does not always exist on the dGPU, it may be located at
the iGPU. The parent device of the iGPU is the root port for which
bridge_d3 is false. This accidentally enables the legacy PM method which
conflicts with port PM and prevented the dGPU from powering on.

Ported from amdgpu commit:
drm/amdgpu: fix check for port PM availability
from Peter Wu.

Fixes: d3ac31f3 (drm/radeon: fix power state when port pm is unavailable (v2))
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Peter Wu <peter@lekensteyn.nl>
Cc: <stable@vger.kernel.org> # 4.8+

When PCIe port PM is not enabled (system BIOS is pre-2015 or the
pcie_port_pm=off parameter is set), legacy ATPX PM should still be
marked as supported. Otherwise the GPU can fail to power on after
runtime suspend. This affected a Dell Inspiron 5548.

Ideally the BIOS date in the PCI core is lowered to 2013 (the first year
where hybrid graphics platforms using power resources was introduced),
but that seems more risky at this point and would not solve the
pcie_port_pm=off issue.

v2: agd: fix typo

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505Signed-off-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # 4.8+
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Some ATPX laptops implement special circuitry to generate
display hotplug events via ACPI when the dGPU is powered off.
Check if this is supported.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit bdfb7604.

Now that d3cold is upstream, there is no more need for this workaround.

If we do it at enable time, it's too late for the feature
checks.

v2: drop .init setting as per Peter's comments

bug: https://bugzilla.kernel.org/show_bug.cgi?id=115321Reviewed-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Peter Wu <peter@lekensteyn.nl>

Until Dave's patch to support the new hybrid gfx ACPI method goes
upstream, we can fallback to the old ATPX method which seems to
still work.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

hybrid graphics in this case refers to systems which use the new
platform d3 cold ACPI methods as opposed to ATPX for dGPU power
control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Now that we handle this correctly, there is no need to force
it.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The runtime pm sequence is different depending on whether or
not the platform supports ATPX dGPU power control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

ATPX dGPU power control requires a 200ms delay between
power off and on.  This should fix dGPU failures on
resume from power off.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The presence of the power control method should be determined
via the presence of the method in function 0.  However, some
sbioses only set the appropriate bits in function 1 so use
then to override a missing power control function.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Windows 10 (and some 8.1) systems use standardized
ACPI calls for hybrid laptops to control dGPU power.
Detect those cases and disable the AMD specific ATPX
power control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It will help identify problematic boards.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit e64c952e.

ATPX is the ACPI method for controlling AMD PowerXpress laptops.
There are flags to indicate which methods are supported.  If
the dGPU power down flag is not supported, the driver needs to
implement the dGPU power down manually.  We had previously
always forced the driver to assume the ATPX dGPU power down
was present, but this causes problems on boards where it is
not, leading to GPU hangs when attempting to power down the
dGPU.  Manual dGPU power down is not currently supported in
the Linux driver.  Some laptops indicate that the ATPX
dGPU power down method is not present, but it actually
apparently is.  I'm not sure if this is a bios bug and it should
be set or if there is a reason it was unset and the method should
not be used.  This is not an issue on other OSes since both the
ATPX and the manual driver power down methods are supported.

This is apparently fairly widespread, so just revert for now.

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=115321
https://bugzilla.kernel.org/show_bug.cgi?id=116581
https://bugzilla.kernel.org/show_bug.cgi?id=116251

Cc: stable@vger.kernel.org

Some PX laptops don't provide an ACPI method to control dGPU power.  On
those systems, the driver is responsible for handling the dGPU power
state.  Disable runtime PM on them until support for this is implemented.
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Allow handlers to declare their capabilities and allow clients to
obtain that information. So far we have these use cases:

* If the handler is able to switch DDC separately, clients need to
  probe EDID with drm_get_edid_switcheroo(). We should allow them
  to detect a capable handler to ensure this function only gets
  called when needed.

* Likewise if the handler is unable to switch AUX separately, the active
  client needs to communicate link training parameters to the inactive
  client, which may then skip the AUX handshake and set up its output
  with these pre-calibrated values (DisplayPort specification v1.1a,
  section 2.5.3.3). Clients need a way to recognize such a situation.

The flags for the radeon_atpx_handler and amdgpu_atpx_handler are
initially set to 0, this can later on be amended with
  handler_flags |= VGA_SWITCHEROO_CAN_SWITCH_DDC;
when a ->switch_ddc callback is added.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by: NLukas Wunner <lukas@wunner.de>
    [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina  15"]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de

vga_switcheroo_client_ops has always been declared const since its
introduction with 26ec685f ("vga_switcheroo: Introduce struct
vga_switcheroo_client_ops").

Do so for vga_switcheroo_handler as well.

 drivers/gpu/drm/amd/amdgpu/amdgpu.ko:
   6 .rodata       00009888
- 19 .data         00001f00
+ 19 .data         00001ee0
 drivers/gpu/drm/nouveau/nouveau.ko:
   6 .rodata       000460b8
  17 .data         00018fe0
 drivers/gpu/drm/radeon/radeon.ko:
-  7 .rodata       00030944
+  7 .rodata       00030964
- 21 .data         0000d6a0
+ 21 .data         0000d678
 drivers/platform/x86/apple-gmux.ko:
-  7 .rodata       00000140
+  7 .rodata       00000160
- 11 .data         000000e0
+ 11 .data         000000b8

Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Revert parts of f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA
switcheroo problem related to hotplug").

A previous commit 5493b31f0b55 ("PCI: Add pci_ignore_hotplug() to ignore
hotplug events for a device") added equivalent functionality implemented in
a different way for both acpiphp and pciehp.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NRajat Jain <rajatxjain@gmail.com>

Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA.  This
properly detects ATPX on those laptops.

Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com

Don't try and runtime suspend the APU in PX systems.  We
only want to power down the dGPU.

v2: fix harder
v3: fix stupid typo
v4: consolidate runpm enablement to a single flag

bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=75127
https://bugzilla.kernel.org/show_bug.cgi?id=72701Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Print the supported functions mask in addition to
the version.  This is useful in debugging PX
problems since we can see what functions are available.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcd (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891Reported-and-tested-by: NMike Lothian <mike@fireburn.co.uk>
Reported-and-tested-by: <madcatx@atlas.cz>
Reported-and-tested-by: NJoaquín Aramendía <samsagax@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+

Since DEVICE_ACPI_HANDLE() is now literally identical to
ACPI_HANDLE(), replace it with the latter everywhere and drop its
definition from include/acpi.h.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

This hooks radeon up to the runtime PM system to enable
dynamic power management for secondary GPUs in switchable
and powerxpress laptops.

v2: agd5f: clean up, add module parameter
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some bioses don't set the function mask correctly
which caused required functions to be disabled.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=53111Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fix a copy&pasted documentation.
Signed-off-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Copy and paste typo in the apci rework.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=49351Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>

The ATPX code no longer handles ATRM.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'

[airlied: Alex had others fixed already, except for atpx one]
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

v2: rebase updates
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

- rework the acpi execute code
- User proper parameters for ATPX functions

v2: rebase fixes
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Verify the ATPX interface and track what ATPX functions
are available for future use.

v2: rework due to tree changes
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Add a new header that defines the AMD ACPI interface used
for laptops, PowerXpress, and chipset specific functionality
and update the current code to use it.

Todo:
- properly verify the ACPI interfaces
- hook up and handle ACPI notifications
- make PX code more robust
- implement PCIe Gen and width switching using ACPI

v2: fix typo in header
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are systems that use ATRM, but not ATPX.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265

V2: fix #ifdefs as per Greg's comments
V3: fix it harder
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=45503

Reported-and-Debugged-by: mlambda@gmail.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

Return a number of bytes read in radeon_atrm_get_bios_chunk() and
properly check this value in radeon_atrm_get_bios().
If radeon_atrm_get_bios_chunk() read less bytes then were requested,
it means that it finished reading bios data.

Prior to this patch, condition in radeon_atrm_get_bios() was always
equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false,
thus radeon_atrm_get_bios() was trying to read past the bios data
wasting boot time.

On my lenovo ideapad u455 laptop this patch drops bios reading time
from ~5.5s to ~1.5s.
Signed-off-by: NIgor Murzov <e-mail@date.by>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>