tidy up radeon_asic struct.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König<christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

That naming seems to make more sense, since we not
only want to run PM4 rings with it.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Split counting of emited fences out of power
management into a seperate function.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Replace cp, cp1 and cp2 members with just an array
of radeon_cp structs.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Give all asic and radeon_ring_* functions a
radeon_cp parameter, so they know the ring to work with.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For supporting multiple CP ring buffers, async DMA
engines and UVD.  We still need a way to synchronize
between engines.

v2 initialize unused fence driver ring to avoid issue in
   suspend/unload
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Better fix it before this obvious typo spreads even more.
Signed-off-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The new power tables need to be handled differently when setting
up the profiles.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Need to add vddci setting to pm init as well as
resume.  Fixes hangs on load on some boards.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=38754Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

The rest of the code is already in place.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Change vddci as well as vddc when changing power modes
on evergreen/ni.  Also, properly set vddci on boot up
for ni cards.  The vbios only sets the limited clocks
and voltages on boot until the mc ucode is loaded.  This
should fix stability problems on some btc cards.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is needed for setting voltages other than vddc.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Throw an error if someone tries to fill this with
wrong data, instead of simply ignoring the input.
Now you get:

echo hello >/sys/../power_method
-bash: echo: write error: Invalid argument
Signed-off-by: NThomas Renninger <trenn@suse.de>
CC: Alexander.Deucher@amd.com
CC: dri-devel@lists.freedesktop.org
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We previously used a static array, but some new systems
had more states then we had array space, so dynamically
allocate space based on the number of states in the vbios.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33851Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some fixes to the thermal sensor code:
- handle negative numbers
- properly handle temp calculation on different asics
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The vbios only partially initializes the memory controller on
NI, so now we need to load the MC ucode in the driver and set
the default clocks once the ucode is loaded.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

NI chips no longer load the MC ucode in the asic_init sequence so
the asic comes up in a basic mode with low engine/memory clocks and
a voltage.  Once the MC ucode is loaded by the driver the card
can be programmed to it's proper default clocks and voltage.  As such
the default clocks in the firmware info table as the post clocks, not
the default running clocks.  Track the default post clocks and default
running clocks separately to handle this.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

With cmwq, there's no reason for radeon to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.

Because radeon_driver_irq_uninstall_kms() may be called from
unsleepable context, the work items can't be flushed from there.
Instead, init and flush from radeon_irq_kms_init/fini().

While at it, simplify canceling/flushing of rdev->pm.dynpm_idle_work.
Always initialize and sync cancel instead of being unnecessarily smart
about it.
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

This patch adds new functions for use by the drm core:

.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.

It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work and is shared across drivers.

.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().

The function is also used by the dynamic gpu reclocking
code to determine when it is safe to reclock inside vblank.

For that purpose radeon_pm_in_vbl() is modified to
accomodate a small change in the function prototype of
the radeon_get_crtc_scanoutpos() which is hooked up to
.get_scanout_position().

This code has been tested on AVIVO hardware, a RV530
(ATI Mobility Radeon X1600) in a Intel Core-2 Duo MacBookPro
and some R600 variant (FireGL V7600) in a single cpu
AMD Athlon 64 PC.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon_pm_in_vbl() didn't report in vblank status accurately. Make
it a wrapper around radeon_get_crtc_scanoutpos() which corrects for
biases, so it reports accurately.

radeon_pm_in_vbl() will only report in_vbl if all active crtc's
are currently inside vblank.

agd5f: use rdev->num_crtc rather than hardcoding the crtc count
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I missed this one in the i2c unification patch.  This
is handled in the core radeon i2c code now.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we aren't changing the power state, no need to take
locks and schedule fences, etc.

There seem to be lock ordering issues in the CP and
fence code in some cases; see bug 29140 below.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29140
Possibly also:
https://bugzilla.kernel.org/show_bug.cgi?id=16581Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Smatch complained that the ERR_PTR from hwmon_device_register() wasn't
handled.  I added some error handling in radeon_hwmon_init() to silence
the warning.

Unfortunately errors from radeon_pm_init() aren't handled so this
doesn't really make a difference beyond silencing the warning.

Also I changed DRM_ERROR() to dev_err() which is the new preferred
method.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This migrates a bunch of DRM_DEBUG->DRM_DEBUG_KMS so we can get more modesetting related info without all the other ioctl handling easily.

Also the PM code moves to DRM_DEBUG_DRIVER mostly.
Signed-off-by: NDave Airlie <airlied@redhat.com>

rv6xx/rv7xx/evergreen families supported; older asics did
not have an internal thermal sensor.

Note, not all oems use the internal thermal sensor, so it's
only exposed in cases where it is used.

Note also, that most laptops use an oem specific ACPI solution for
GPU thermal information rather than using the internal thermal
sensor directly.

v2: export millidegrees celsius, use hwmon device properly.
v3: fix Kconfig
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix incorrectly reporting 'default' power profile, when it is set to 'mid'.
Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DRM / radeon / KMS: Fix hibernation regression related to radeon PM (was: Re: [Regression, post-2.6.34] Hibernation broken on machines with radeon/KMS and r300)

There is a regression from 2.6.34 related to the recent radeon power
management changes, caused by attempting to cancel a delayed work
item that's never been scheduled.  However, the code as is has some
other issues potentially leading to visible problems.

First, the mutex around cancel_delayed_work() in radeon_pm_suspend()
doesn't really serve any purpose, because cancel_delayed_work() only
tries to delete the work's timer.  Moreover, it doesn't prevent the
work handler from running, so the handler can do some wrong things if
it wins the race and in that case it will rearm itself to do some
more wrong things going forward.  So, I think it's better to wait for
the handler to return in case it's already been queued up for
execution.  Also, it should be prevented from rearming itself in that
case.

Second, in radeon_set_pm_method() the cancel_delayed_work() is not
sufficient to prevent the work handler from running and queing up
itself for the next run (the failure scenario is that
cancel_delayed_work() returns 0, so the handler is run, it waits on
the mutex and then rearms itself after the mutex has been released),
so again the work handler should be prevented from rearming itself in
that case..

Finally, there's a potential deadlock in radeon_pm_fini(), because
cancel_delayed_work_sync() is called under rdev->pm.mutex, but the
work handler tries to acquire the same mutex (if it wins the race).

Fix the issues described above.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

debug only

agd5f: rebased
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

agd5f: rebased
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

track the current voltage level and avoid setting it
if the requested voltage is already set.

v2: check voltage type before checking current voltage
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds an additional profile, mid, to the pm profile
code which takes the place of the old low profile.  The default
behavior remains the same, e.g., auto profile now selects between
mid and high profiles based on power source, however, you can now
manually force the low profile which was previously only available
as a dpms off state.  Enabling the low profile when the displays
are on has been known to cause display corruption in some cases.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- don't rest the power state in pm_init()
We already boot up to the default power state.  Note this
patch relies on:
drm/radeon/kms/pm: patch default power state with default clocks/voltages on r6xx+
To make sure the default power state matches the boot up state.

- In the pm resume path asic init will have set the power state
back to the default so reset the tracking state values.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

PM attemps to unmap objects that aren't actually mapped into userspace ever,
so just don't bother unmapping them at this point, since all you are doing
is nothing. We should be making sure all access to these objects are locked in
kernel space instead. In theory the VRAM gart table is already done, and both
the shaders and stolen vga memory blocks are never accessed at runtime.

fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16127Reported-by: NJure Repnic <jlp.bugs@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

- wait for vbl for both profile and dynpm
- unify profile and dynpm code paths more
- call pm_misc before of after clocks to make
sure voltage is changed in the proper order.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

print an error if these fail.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

- Separate dynpm and profile based power management methods.  You can select the pm method
  by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
- Expose basic 4 profile in profile method
  "default" - default clocks
  "auto" - select between low and high based on ac/dc state
  "low" - DC, low power mode
  "high" - AC, performance mode
  The current base profile is "default", but it should switched to "auto" once we've tested
  on more systems.  Switching the state is a matter of echoing the requested profile to
  power_profile in sysfs.  The lowest power states are selected automatically when dpms turns
  the monitors off in all states but default.
- Remove dynamic fence-based reclocking for the moment.  We can revisit this later once we
  have basic pm in.
- Move pm init/fini to modesetting path.  pm is tightly coupled with display state.  Make sure
  display side is initialized before pm.
- Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
- Remove dynpm module option.  It's now selectable via sysfs.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The lowest power states often cause display problems, so only enable
them when all displays are off.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>