drm/i915: Initialise min/max frequencies before updating RPS registers

The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.

Reorder the calling sequences to be correct, and remove the then
unrequired clamping from inside set_rps(). And for a bonus, fix the bug
of calling gen6_set_rps() from Valleyview.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Kill vlv_update_rps_cur_delay()

Polling to make sure the current GPU frequency matches the last
requested frequency should not be necessay, and if there's some
throttling involved, the two might not match anyway.

Since we're still seeing this trigger occasionally, and it just
introduces a rather pointless 10 ms delay, it seems like better
to kill it off.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Use clamp_t() when limiting cur_delay

Make the cur_delay limiting code a bit less prone to typo errors
by using clamp_t().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/vlv: Rename VLV DPIO register to be more structure to match configdb document.

Some VLV PHY/PLL DPIO registers have group/lane/channel access.  Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document.  Rename those registers based on the configdb for easy
cross references, and without the need to check the offset in the header
file.

New format is as following.

<platform name>_<DPIO component><optional lane #>_DW<dword # in the
doc>_<optional channel #>

For example,

VLV_PCS_DW0 - Group access to PCS for lane 0 to 3 for PCS DWORD 0.
VLV_PCS01_DW0_CH0 - PCS access to lane 0/1, channel 0 for PCS DWORD 0.

Another example is

VLV_TX_DW0 - Group access to TX lane 0 to 3 for TX DWORD 0
VLV_TX0_DW0 - Refer to TX Lane 0 access only for TX DWORD 0.

There is no functional change on this patch.

v2: Rebase based on previous patch change.
v3: There may be configdb different version that document the start DW
differently. Add a comment to clarify.  Fix up some mismatch start DW
for second PLL block. (Ville)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Make AGP support optional

We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So make AGP support optional. As before, we will
fail the i915 init for UMS and gen3 KMS the same as before if
intel_agp isn't around.

intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going
to save that for a later cleaning.

At least my gen2 still works with the patch and CONFIG_AGP=n.

v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/vlv: Make the vlv_dpio_read/vlv_dpio_write more PHY centric

vlv_dpio_read/write should be describe more in PHY centric instead of
display controller centric.
Create a enum dpio_channel for channel index and enum dpio_phy for PHY
index.  This should better to gather for upcoming platform.

v2: Rebase the code based on
drm/i915/vlv: Fix typo in the DPIO register define.

v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro
DPIO_PHY, and remove unrelated change. (Ville)

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: tune reset dmesg output a bit

We don't want any ERROR for simulated gpu hangs, otoh printing the
error code when the reset failed for real should be interesting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71333
lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: add i915_reset_count

reset_counter will be incremented twice per successful
reset. Odd values mean reset is in progress and even values
mean that reset has completed.

Reset status ioctl introduced in following commit
needs to deliver global reset count to userspace so
use reset_counter to derive the actual reset count
for the gpu

Note that reset in progress is enough to increment
the counter.

v2: wedged equals reset in progress (Daniel Vetter)

v3: Fixed stale comments (Damien Lespiau)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: add i915_get_reset_stats_ioctl

This ioctl returns reset stats for specified context.

The struct returned contains context loss counters.

reset_count:    all resets across all contexts
batch_active:   active batches lost on resets
batch_pending:  pending batches lost on resets

v2: get rid of state tracking completely and deliver only counts. Idea
    from Chris Wilson.

v3: fix commit message

v4: default context handled inside i915_gem_context_get_hang_stats

v5: reset_count only for priviledged process

v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson)

v7: context hang stats never returns NULL

v8: rebased on top of reworked context hang stats
    DRM_RENDER_ALLOW for ioctl

v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: clean up backlight conditional build

I've always felt the backlight device conditional build has been all
backwards. Make it feel right.

Gently move things towards connector based stuff while at it.

There should be no functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make backlight info per-connector

Move from dev_priv to connector->panel. We still don't allow multiple
sysfs interfaces, though.

There should be no functional changes, except for a slight reordering of
connector backlight and sysfs destroy calls. (This change happens now
that the backlight device is actually per-connector, even though the
destroy calls became per-connector earlier.)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make asle notifications update backlight on all connectors

ALthough usually there's only one connector that supports backlight,
this also finds the correct connector. Before, we only updated the
connector on pipe A, which might not be the one with backlight. (This
only made a difference on BYT.)

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: handle backlight through chip specific functions

The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split the code up into chip
specific functions.

There should be no functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: drop duplicate ggtt vma list add in setup_global_gtt

Preallocated objects will already have been added to the vma_list when
creating their ggtt vma entry, and coincidentally also marked as holding
a ggtt mapping. Repeating the vma_list manipulation when setting up the
ggtt after preallocation is a recipe for an unhappy kernel.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use the improve commit message suggest by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix gen2-gen3 backlight set

Citing Jani's response to Imre's question in the review discussion:

> According to the gen2/3 bspec I have, the correct mask is
> BACKLIGHT_DUTY_CYCLE_MASK_PNV only in case of IS_PINEVIEW(dev), for
> everything else it's BACKLIGHT_DUTY_CYCLE_MASK.

What you say is correct, but we've treated all gen2/3 similar to PNV
since

commit ca88479c1c3b7b1a9f94320745f5331e1de77f80
Author: Keith Packard <keithp@keithp.com>
Date:   Fri Nov 18 11:09:24 2011 -0800

    drm/i915: Treat pre-gen4 backlight duty cycle value consistently

i.e. we only use the high 15 bits for all gen2/3. For non-PNV this just
means the lowest bit is always zero. For PNV the lowest bit has a
different meaning in both the PWM freq and duty cycle fields.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Make the commit message less empty.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: vlv does not have pipe field in backlight registers

It has per pipe registers.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: move backlight level setting in enable/disable to hooks

This allows more flexibility in the ordering of the register writes, and
lets us drop level setting altogether as necessary on a per platform
basis.

For gen2-gen3, this is the only thing that happens in enable/disable.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: use the initialized backlight max value instead of reading it

We now have the max backlight value cached. Use it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: debug print on backlight register

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: check i915_get_reset_stats_ioctl args

Insist that flags and pad fields are zero, so that
we can safely extend the interface in future.

Testcase: igt/gem_reset_stats/params

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>