drm/radeon: Clean up errors in radeon_atpx_handler.c

Fix the following errors reported by checkpatch:

ERROR: open brace '{' following function definitions go on the next line

Signed-off-by: GuoHua Chen <chenguohua_716@163.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Revert "drm/radeon: Prefer dev_* variant over printk"

Usage of container_of is wrong here.
struct acpi_device *adev = container_of(handle, struct acpi_device, handle)

This reverts commit cbd0606e6a776bf2ba10d4a6957bb7628c0da947.

References: https://gitlab.freedesktop.org/drm/amd/-/issues/2744
Cc: Guchun Chen <guchun.chen@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Bert Karwatzki <spasswolf@web.de>
Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
Cc: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Prefer dev_* variant over printk

Changed from pr_err/info to dev_* variants so that
we get better debug info when there are multiple GPUs
in the system.

Fixes: 09edeb4c1680 ("drm/radeon: Prefer pr_err/_info over printk")
Suggested-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Prefer pr_err/_info over printk

Fixes the following checkpatch.pl:

WARNING: printk() should include KERN_<LEVEL> facility level

Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Fix missing prototypes in radeon_atpx_handler.c

Fixes the following gcc with W=1:

drivers/gpu/drm/radeon/radeon_atpx_handler.c:64:6: warning: no previous prototype for ‘radeon_has_atpx’ [-Wmissing-prototypes]
64 | bool 4(void) {
| ^~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:68:6: warning: no previous prototype for ‘radeon_has_atpx_dgpu_power_cntl’ [-Wmissing-prototypes]
68 | bool radeon_has_atpx_dgpu_power_cntl(void) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:72:6: warning: no previous prototype for ‘radeon_is_atpx_hybrid’ [-Wmissing-prototypes]
72 | bool radeon_is_atpx_hybrid(void) {
| ^~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:77:6: warning: no previous prototype for ‘radeon_atpx_dgpu_req_power_for_displays’ [-Wmissing-prototypes]
77 | bool radeon_atpx_dgpu_req_power_for_displays(void) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:596:6: warning: no previous prototype for ‘radeon_register_atpx_handler’ [-Wmissing-prototypes]
596 | void radeon_register_atpx_handler(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:614:6: warning: no previous prototype for ‘radeon_unregister_atpx_handler’ [-Wmissing-prototypes]
614 | void radeon_unregister_atpx_handler(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/radeon/radeon_atpx_handler.c:159: warning: expecting prototype for radeon_atpx_validate_functions(). Prototype was for radeon_atpx_validate() instead

Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 191

Based on 1 normalized pattern(s):

licensed under gplv2

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 99 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Steve Winslow <swinslow@gmail.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190528170027.163048684@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/radeon: fix radeon_atpx_get_client_id()'s return type

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: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

gpu: drm: amd/radeon: Convert printk(KERN_<LEVEL> to pr_<level>

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: Joe Perches <joe@perches.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix check for port PM availability

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

drm/radeon: fix power state when port pm is unavailable (v2)

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=98505
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: <stable@vger.kernel.org> # 4.8+
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/atpx: check for ATIF dGPU wake for display events support

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: Alex Deucher <alexander.deucher@amd.com>

Revert "drm/radeon: work around lack of upstream ACPI support for D3cold"

This reverts commit bdfb76040068d960cb9e226876be8a508d741c4a.

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

drm/radeon: init atpx at switcheroo register time v2

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=115321
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Peter Wu <peter@lekensteyn.nl>

drm/radeon: work around lack of upstream ACPI support for D3cold

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: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/atpx: track whether if this is a hybrid graphics platform

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: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/atpx: drop forcing of dGPU power control

Now that we handle this correctly, there is no need to force
it.

Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/atpx: add a query for ATPX dGPU power control

The runtime pm sequence is different depending on whether or
not the platform supports ATPX dGPU power control.

Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add a delay after ATPX dGPU power off

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: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: clean up atpx power control handling

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: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: disable power control on hybrid laptops

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: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: print a message if ATPX dGPU power control is missing

It will help identify problematic boards.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"

This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1.

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

drm/radeon: disable runtime pm on PX laptops without dGPU power control

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: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

vga_switcheroo: Add handler flags infrastructure

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=61115
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/2b0d93ed6e511ca09e95e45e0b35627f330fabce.1452525860.git.lukas@wunner.de

vga_switcheroo: Constify vga_switcheroo_handler

vga_switcheroo_client_ops has always been declared const since its
introduction with 26ec685ff9d9 ("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: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/radeon: Spell vga_switcheroo consistently

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: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

ACPIPHP / radeon / nouveau: Remove acpi_bus_no_hotplug()

Revert parts of f244d8b623da ("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: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Rajat Jain <rajatxjain@gmail.com>

drm/radeon: fix ATPX detection on non-VGA GPUs

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: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com

drm/radeon: fix runpm handling on APUs (v4)

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=72701

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: print the supported atpx function mask

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: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug

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: bbd34fcdd1b2 (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=64891
Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk>
Reported-and-tested-by: <madcatx@atlas.cz>
Reported-and-tested-by: Joaquí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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+

ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro

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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node

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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

drm/radeon: add runtime PM support (v2)

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: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: properly validate the atpx interface

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=53111

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix ATPX function documentation

Fix a copy&pasted documentation.

Signed-off-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix ATPX regression in acpi rework

Copy and paste typo in the apci rework.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=49351

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>

drm/radeon: fix ATPX function documentation

The ATPX code no longer handles ATRM.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: radeon: fix printk format warning

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: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: document radeon_atpx_handler.c (v2)

v2: rebase updates

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: reorganize ATPX support (v2)

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

v2: rebase fixes

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: update ATPX verify interface handling (v2)

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

v2: rework due to tree changes

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add new AMD ACPI header and update relevant code (v2)

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: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: split ATRM support out from the ATPX handler (v3)

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: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix use after free in ATRM bios reading code.

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

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

drm/radeon: finish getting bios earlier

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: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: fix invalid memory access in radeon_atrm_get_bios()

At a boot time I observed following bug:

BUG: unable to handle kernel paging request at ffff8800a4244000
IP: [<ffffffff81275b5b>] memcpy+0xb/0x120
PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+)
mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi
joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc
loop btrfs

Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046 /AMD CRB
RIP: 0010:[<ffffffff81275b5b>] [<ffffffff81275b5b>] memcpy+0xb/0x120
RSP: 0018:ffff8800aa72db00 EFLAGS: 00010246
RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087
RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8
RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec
R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000
R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800
FS: 00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000)
Stack:
ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28
ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020
ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000
Call Trace:
[<ffffffffa04e7c7b>] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
[<ffffffff8113cbef>] ? kmalloc_order_trace+0x3f/0xb0
[<ffffffffa04a9298>] radeon_get_bios+0x68/0x2f0 [radeon]
[<ffffffffa04c7a30>] rv770_init+0x40/0x280 [radeon]
[<ffffffffa047d740>] radeon_device_init+0x560/0x600 [radeon]
[<ffffffffa047ef4f>] radeon_driver_load_kms+0xaf/0x170 [radeon]
[<ffffffffa043cdde>] drm_get_pci_dev+0x18e/0x2c0 [drm]
[<ffffffffa04e7e95>] radeon_pci_probe+0xad/0xb5 [radeon]
[<ffffffff81296c5f>] local_pci_probe+0x5f/0xd0
[<ffffffff81297418>] pci_device_probe+0x88/0xb0
[<ffffffff813417aa>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff813418d8>] really_probe+0x68/0x180
[<ffffffff81341be5>] driver_probe_device+0x45/0x70
[<ffffffff81341cb3>] __driver_attach+0xa3/0xb0
[<ffffffff81341c10>] ? driver_probe_device+0x70/0x70
[<ffffffff813400ce>] bus_for_each_dev+0x5e/0x90
[<ffffffff8134172e>] driver_attach+0x1e/0x20
[<ffffffff81341298>] bus_add_driver+0xc8/0x280
[<ffffffff813422c6>] driver_register+0x76/0x140
[<ffffffff812976d6>] __pci_register_driver+0x66/0xe0
[<ffffffffa043d021>] drm_pci_init+0x111/0x120 [drm]
[<ffffffff8133c67a>] ? vga_switcheroo_register_handler+0x3a/0x60
[<ffffffffa0229000>] ? 0xffffffffa0228fff
[<ffffffffa02290ec>] radeon_init+0xec/0xee [radeon]
[<ffffffff810002f2>] do_one_initcall+0x42/0x180
[<ffffffff8109d8d2>] sys_init_module+0x92/0x1e0
[<ffffffff815407a9>] system_call_fastpath+0x16/0x1b
Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 <f3> 48
a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
RIP [<ffffffff81275b5b>] memcpy+0xb/0x120
RSP <ffff8800aa72db00>
CR2: ffff8800a4244000
---[ end trace fcffa1599cf56382 ]---

Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
on my system it can return 2048 bytes chunk, so pass the length of
retrieved chunk to memcpy(), not the length of the recieving buffer.

Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon/kms: ATPX switcheroo fixes

When we switch the display mux, also switch
the i2c mux. Also use the start and finish
methods to let the sbios know that the switch
is happening.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=35398

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

vga_switcheroo: fix build on platforms with no ACPI

radeon was always including the atpx code unnecessarily, also core
switcheroo was including acpi headers.

Signed-off-by: Dave Airlie <airlied@redhat.com>

vga_switcheroo: initial implementation (v15)

Many new laptops now come with 2 gpus, one to be used for low power
modes and one for gaming/on-ac applications. These GPUs are typically
wired to the laptop panel and VGA ports via a multiplexer unit which
is controlled via ACPI methods.

4 combinations of systems typically exist - with 2 ACPI methods.
Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
ATI/ATI - some ASUS - use ATPX ACPI Method
Intel/Nvidia - - use _DSM ACPI method
Nvidia/Nvidia - - use _DSM ACPI method.

TODO:
This patch adds support for the ATPX method and initial bits
for the _DSM methods that need to written by someone with
access to the hardware.
Add a proper non-debugfs interface - need to get some proper
testing first.

v2: add power up/down support for both devices
on W500 puts i915/radeon into D3 and cuts power to radeon.

v3: redo probing methods, no DMI list, drm devices call to
register with switcheroo, it tries to find an ATPX method on
any device and once there is two devices + ATPX it inits the
switcher.

v4: ATPX msg handling using buffers - should work on more machines

v5: rearchitect after more mjg59 discussion - move ATPX handling to
radeon driver.

v6: add file headers + initial nouveau bits (to be filled out).

v7: merge delayed switcher code.

v8: avoid suspend/resume of gpu that is off

v9: rearchitect - mjg59 is always right. - move all ATPX code to
radeon, should allow simpler DSM also proper ATRM handling

v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv

v11: fix bug in resuming Intel for 2nd time.

v12: start fixing up nvidia code blindly.

v13: blindly guess at finishing nvidia code

v14: remove radeon audio hacks - fix up intel resume more like upstream

v15: clean up printks + remove unnecessary igd/dis pointers

mount debugfs

/sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
+ 2 cards.

DIS - immediate change to discrete
IGD - immediate change to IGD
DDIS - delayed change to discrete
DIGD - delayed change to IGD
ON - turn on not in use
OFF - turn off not in use

Tested on W500 (Intel/ATI) and T500 (Intel/ATI)

Signed-off-by: Dave Airlie <airlied@redhat.com>