Ville Syrjälä [Tue, 25 Jun 2013 11:16:34 +0000 (14:16 +0300)]
Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"
The PIPECONF color range bit doesn't appear to be effective, on HDMI
outputs at least. The color range bit in the port register works though,
so let's use it.
I have not yet verified whether the PIPECONF bit works on DP outputs.
Ville Syrjälä [Fri, 14 Jun 2013 11:02:52 +0000 (14:02 +0300)]
drm/i915: Fix VLV PLL LPF coefficients for DAC
The current PLL settings produce a rather unstable picture when
I hook up a VLV to my HP ZR24w display via a VGA cable.
According to VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9, we should
use the the same LPF coefficients for DAC as we do for HDMI and RBR DP.
And indeed that seems to cure the shivers.
v2: Add the name of the relevant document to the commit message
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>
Ville Syrjälä [Tue, 25 Jun 2013 18:38:11 +0000 (21:38 +0300)]
drm/i915: Jump to at least RPe on VLV when increasing the GPU frequency
If the current GPU frquency is below RPe, and we're asked to increase
it, just go directly to RPe. This should provide better performance
faster than letting the frequency trickle up in response to the up
threshold interrupts.
For now just do it for VLV, since that matches quite closely how VLV
used to operate when the rps delayed timer kept things at RPe always.
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>
Ville Syrjälä [Tue, 25 Jun 2013 18:38:10 +0000 (21:38 +0300)]
drm/i915: Don't increase the GPU frequency from the delayed VLV rps timer
There's little point in increasing the GPU frequency from the delayed
rps work on VLV. Now when the GPU is idle, the GPU frequency actually
keeps dropping gradually until it hits the minimum, whereas previously
it just ping-ponged constantly between RPe and RPe-1.
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>
Ville Syrjälä [Tue, 25 Jun 2013 16:21:06 +0000 (19:21 +0300)]
drm/i915: GEN6_RP_INTERRUPT_LIMITS doesn't seem to exist on VLV
I can't find GEN6_RP_INTERRUPT_LIMITS (0xA014) anywhere in VLV docs.
Reading it always returns zero from what I can tell, and eliminating
it doesn't seem to make any difference to the behaviour of the system.
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>
Ville Syrjälä [Tue, 25 Jun 2013 16:21:02 +0000 (19:21 +0300)]
drm/i915: Don't wait for Punit after each freq change on VLV
It seems that even though Punit reports the frequency change to have
been completed, it still reports the old frequency in the status
register for some time.
So rather than polling for Punit to complete the frequency change after
each request, poll before. This gets rid of the spurious "Punit overrode
GPU freq" messages.
This also lets us continue working while Punit is performing the actual
frequency change. As a result, openarena demo088-test1 timedemo average
fps is increased by ~5 fps, and the slowest frame duration is reduced
by ~25%.
The sysfs cur_freq file always reads the current frequency from Punit
anyway, so having rps.cur_delay be slightly off at times doesn't matter.
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>
Chris Wilson [Tue, 25 Jun 2013 16:26:45 +0000 (17:26 +0100)]
drm/i915: Detect invalid scanout pitches
Report back the user error of attempting to setup a CRTC with an invalid
framebuffer pitch. This is trickier than it should be as on gen4, there
is a restriction that tiled surfaces must have a stride less than 16k -
which is less than the largest supported CRTC size.
v2: Fix the limits for gen3
v3: Move check into intel_framebuffer_init() and fix VLV limits. (vsyrjala)
v4: Use idiomatic '>=' for generation checks
References: https://bugs.freedesktop.org/show_bug.cgi?id=65099 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Tue, 25 Jun 2013 09:06:52 +0000 (11:06 +0200)]
drm/i915: don't scream into dmesg when a modeset fails
There are legit cases, e.g. when userspace asks for something
impossible. So tune it down to debug output like we do with all other
userspace-triggerable warnings.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111#c5 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Rebased.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 24 Jun 2013 19:33:28 +0000 (21:33 +0200)]
drm/i915: Fix up sdvo hpd pins for i965g/gm
Bspec seems to be full of lies, at least it disagress with reality:
Two systems corrobated that SDVO hpd bits are the same as on gen3.
v2: Update comment a bit.
Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Alex Fiestas <afiestas@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 7 Jun 2013 13:03:50 +0000 (16:03 +0300)]
drm/i915: fix build warning on format specifier mismatch
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville)
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 24 Jun 2013 16:32:36 +0000 (18:32 +0200)]
drm/i915: tune down DIDL warning about too many outputs
Nothing the user (nor we) really can do about this, but upsets a nice
quiet boot.
Note that this happens mostly on SDVs where OEMs obviously haven't had
a chance yet to appropriately trim the output list.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988 Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Amend commit message a bit to clarify a question from Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4
("drm/i915: create compact dma scatter lists for gem objects") makes
certain assumptions about the under laying DMA API that are not always
correct.
On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup
I see:
[drm:intel_pipe_set_base] *ERROR* pin & fence failed
[drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
Bit of debugging traced it down to dma_map_sg failing (in
i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB).
That unfortunately are sizes that the SWIOTLB is incapable of handling -
the maximum it can handle is a an entry of 512KB of virtual contiguous
memory for its bounce buffer. (See IO_TLB_SEGSIZE).
Previous to the above mention git commit the SG entries were of 4KB, and
the code introduced by above git commit squashed the CPU contiguous PFNs
in one big virtual address provided to DMA API.
This patch is a simple semi-revert - were we emulate the old behavior
if we detect that SWIOTLB is online. If it is not online then we continue
on with the new compact scatter gather mechanism.
An alternative solution would be for the the '.get_pages' and the
i915_gem_gtt_prepare_object to retry with smaller max gap of the
amount of PFNs that can be combined together - but with this issue
discovered during rc7 that might be too risky.
Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rui Guo [Wed, 19 Jun 2013 13:10:23 +0000 (21:10 +0800)]
drm/i915: Fix PCH detect with multiple ISA bridges in VM
In some virtualized environments (e.g. XEN), there is irrelevant ISA bridge in
the system. To work reliably, we should scan trhough all the ISA bridge
devices and check for the first match, instead of only checking the first one.
Signed-off-by: Rui Guo <firemeteor@users.sourceforge.net>
[danvet: Fixup conflict with the num_pch_pll removal. And add
subsystem header to the commit message headline.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:27 +0000 (17:27 -0300)]
drm/i915: fix the "ghost eDP" encoder unwind path
Because calling intel_dp_encoder_destroy inside
intel_edp_init_connector is just wrong. This is the initialization
path, so we should properly unwind all the initialization through the
whole caller stack.
On the intel_dp_encoder_destroy function we do the following:
1 - Call i2c_del_adapter
2 - Call drm_encoder_cleanup
3 - If edp:
3.1 - Cancel panel_vdd_work
3.2 - Call ironlake_panel_vdd_of_sync
4 - Free the encoder
And here is how we unwind each specific step:
1 - We have intel_dp_init_connector -> intel_dp_i2c_init ->
i2c_dp_aux_add_bus -> i2c_add_adapter, so we call
i2c_del_dapter at intel_dp_init_connector
2 - Call it in the same function that called drm_encoder_init
3 - Call it in the same function that called INIT_DELAYED_WORK
4 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:26 +0000 (17:27 -0300)]
drm/i915: fix the "ghost eDP" connector unwind path
Because calling intel_dp_destroy inside intel_edp_init_connector is
just wrong. This is the initialization path, so we should properly
unwind all the initialization through the whole caller stack.
On the intel_dp_destroy function we do the following:
1 - Free edid if it exists
2 - Call intel_panel_fini in case it's eDP
3 - Call drm_sysfs_connector_remove
4 - Call drm_connector_cleanup
5 - Free the connector
And here is how we unwind each specific step:
1 - No need as we still didn't assign anything
2 - No need as we still didn't call intel_panel_init
3 - Call it in the same function that called drm_sysfs_connector_add
4 - Call it in the same function that called drm_connector_init
5 - Free it in the same function that allocated it
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:25 +0000 (17:27 -0300)]
drm/i915: propagate errors from intel_dp_init_connector
In case we detect a "ghost eDP", intel_edp_init_connector frees both
the connector and encoder and then returns. On Haswell, intel_ddi_init
then tries to use the freed encoder on the HDMI initialization path
since the following commit:
commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 10 23:28:35 2013 +0200
drm/i915: don't setup hdmi for port D edp in ddi_init
So now on intel_ddi_init we check for the "ghost eDP" case and return
without trying to initialize HDMI. This way we won't try to read the
freed "intel_encoder" struct in the next "if" statement.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Wed, 12 Jun 2013 20:27:23 +0000 (17:27 -0300)]
drm/i915: don't check encoder at DP connector destroy()
By the time we call intel_dp_destroy (which destroys the connector)
the encoder may have been destroyed already, so if we use it we may be
reading some free memory. That happens in drm_mode_config_cleanup()
and also inside intel_dp_init_connector() when we detect a ghost eDP.
I also hope this may solve some random memory bugs.
Reported by kmemcheck.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was rearming the workqueue with a 0 timeout, causing
a WARN_ON, and possible loop.
Daniel writes:
"I've looked a bit into this and I think we need to have a separate
work struct for recovering these lost hotplug events since the
continuous self-rearming case is a real risk (e.g. if a connector
flip-flops all the time). At least I don't see a sane way to block out
re-arming with the current code in a simple way. So reverting the
offender seems like the right thing and I'll go back to the drawing
board for 3.12."
YoungJun Cho [Wed, 26 Jun 2013 01:21:42 +0000 (10:21 +0900)]
drm/prime: add return check for dma_buf_fd
The dma_buf_fd() can return error when it fails to prepare fd,
so the dma_buf needs to be put.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Seung-Woo Kim [Wed, 26 Jun 2013 01:21:41 +0000 (10:21 +0900)]
drm/prime: reorder drm_prime_add_buf_handle and remove prototype
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Wed, 26 Jun 2013 01:21:40 +0000 (10:21 +0900)]
drm/prime: fix to put an exported dma_buf for adding handle failure
When drm_prime_add_buf_handle() returns failure for an exported
dma_buf, the dma_buf was already allocated and its refcount was
increased, so it needs to be put.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Joonyoung Shim [Wed, 19 Jun 2013 06:03:05 +0000 (15:03 +0900)]
drm/prime: support to cache mapping
The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.
[airlied: rebased on top of other prime changes] Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Mon, 24 Jun 2013 07:40:53 +0000 (16:40 +0900)]
drm/prime: replace NULL with error value in drm_prime_pages_to_sg
Instead of NULL, error value is casted with ERR_PTR() for
drm_prime_pages_to_sg() and IS_ERR_OR_NULL() macro is replaced
with IS_ERR() macro for drm_gem_map_dma_buf().
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Mon, 24 Jun 2013 06:34:21 +0000 (15:34 +0900)]
drm/prime: fix to check return of dma_map_sg in prime helper
The dma_map_sg(), in map_dma_buf callback operation of prime helper,
can return 0 when it fails to map, so it needs to release related
resources.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
YoungJun Cho [Wed, 26 Jun 2013 23:39:58 +0000 (08:39 +0900)]
drm/gem: add mutex lock when using drm_gem_mmap_obj
The drm_gem_mmap_obj() has to be protected with dev->struct_mutex,
but some caller functions do not. So it adds mutex lock to missing
callers and adds assertion to check whether drm_gem_mmap_obj() is
called with mutex lock or not.
Signed-off-by: YoungJun Cho <yj44.cho@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
cli->mutex was inverted with reservations, and multiple reservations were
used without a ticket, fix both. This commit had to be done after the previous
commit, because otherwise ttm_eu_* calls would use a different seqno counter..
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/ttm: make ttm reservation calls behave like reservation calls
This commit converts the source of the val_seq counter to
the ww_mutex api. The reservation objects are converted later,
because there is still a lockdep splat in nouveau that has to
resolved first.
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both will get a pointer
to a struct reservation_object, which has to be reserved before
anything is done with the contents of the dma-buf.
Changes since v1:
- Fix locking issue in ticket_reserve, which could cause mutex_unlock
to be called too many times.
Changes since v2:
- All fence related calls and members have been taken out for now,
what's left is the bare minimum to be useful for ttm locking conversion.
Changes since v3:
- Removed helper functions too. The documentation has an example
implementation for locking. With the move to ww_mutex there is no
need to have much logic any more.
drm/ast: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/mgag200: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/cirrus: do not attempt to acquire a reservation while in an interrupt handler
Mutexes should not be acquired in interrupt context. While the trylock
fastpath is arguably safe on all implementations, the slowpath
unlock path definitely isn't. This fixes the following lockdep splat:
drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.
Having nouveau builtin would still allow ACPI_VIDEO to be used as external module
if some of the deps for acpi_video have not been met, which would result in a linking
failure. Solve this by selecting all dependencies as well.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/nouveau: complain loudly if buffer is pinned during destruction
Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 28 Jun 2013 00:53:23 +0000 (10:53 +1000)]
Merge branch 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux into drm-next
This is the pull request for radeon for 3.11. Highlights include:
- Support for CIK (Sea Islands) asics: 3D, compute, UVD
- DPM (Dynamic Power Management) support for 6xx-SI
- ASPM support for 6xx-SI
- Assorted bug fixes
* 'drm-next-3.11' of git://people.freedesktop.org/~agd5f/linux: (168 commits)
drm/radeon/SI: fix TDP adjustment in set_power_state
drm/radeon/NI: fix TDP adjustment in set_power_state
drm/radeon: fix endian issues in atombios dpm code
drm/radeon/dpm: fix UVD clock setting on SI
drm/radeon/dpm: fix UVD clock setting on cayman
drm/radeon/dpm: add support for setting UVD clock on rv6xx
drm/radeon/dpm: add support for setting UVD clock on rs780
drm/radeon: fix typo in ni_print_power_state
drm/radeon: fix typo in cik_select_se_sh()
drm/radeon/si: fix typo in function name
drm/radeon/dpm: fix typo in setting uvd clock
drm/radeon/dpm: add dpm_set_power_state failure output (si)
add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_set_power_state failure output (7xx-ni)
drm/radeon/dpm: add dpm_enable failure output (si)
drm/radeon/dpm: add dpm_enable failure output (7xx-ni)
drm/radeon/kms: add dpm support for SI (v7)
drm/radeon: switch SI to use radeon_ucode.h
drm/radeon: add SI to r600_is_internal_thermal_sensor()
drm/radeon/dpm/rs780: properly catch errors in dpm setup
...
Dave Airlie [Thu, 27 Jun 2013 23:50:34 +0000 (09:50 +1000)]
Merge tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Last 3.11 feature pull. I have a few odds bits and pieces and fixes in my
queue, I'll sort them out later on to see what's for 3.11-fixes and what's
for 3.12. But nothing to hold this here up imo.
Highlights:
- more hangcheck work from Mika and Chris to prepare for arb robustness
- trickle feed fixes from Ville
- first parts of the shared pch pll rework, with some basic hw state
readout and cross-checking (this shuts up the confused pch pll refcount
WARN that Linus just recently forwarded)
- Haswell audio power well support from Wang Xingchao (alsa bits acked by
Takashi)
- some cleanups and asserts sprinkling around the plane/gamma enabling
sequence from Ville
- more gtt refactoring from Ben
- clear up the adjusted->mode vs. pixel clock vs. port clock confusion
- 30bpp support, this time for real hopefully
* tag 'drm-intel-next-2013-06-18' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits)
drm/i915: remove a superflous semi-colon
drm/i915: Kill useless "Enable panel fitter" comments
drm/i915: Remove extra "ring" from error message
drm/i915: simplify the reduced clock handling for pch plls
drm/i915: stop killing pfit on i9xx
drm/i915: explicitly set up PIPECONF (and gamma table) on haswell
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
drm/i915: set up PIPECONF explicitly on ilk-ivb
drm/i915: find guilty batch buffer on ring resets
drm/i915: store ring hangcheck action
drm/i915: add batch bo to i915_add_request()
drm/i915: change i915_add_request to macro
drm/i915: add i915_gem_context_get_hang_stats()
drm/i915: add struct i915_ctx_hang_stats
drm/i915: Try harder to disable trickle feed on VLV
drm/i915: fix up pch pll enabling for pixel multipliers
drm/i915: hw state readout and cross-checking for shared dplls
drm/i915: WARN on lack of shared dpll
drm/i915: split up intel_modeset_check_state
drm/i915: extract readout_hw_state from setup_hw_state
...
Alex Deucher [Tue, 25 Jun 2013 21:56:16 +0000 (17:56 -0400)]
drm/radeon/kms: add dpm support for SI (v7)
This adds dpm support for SI asics. This includes:
- dynamic engine clock scaling
- dynamic memory clock scaling
- dynamic voltage scaling
- dynamic pcie gen1/gen2/gen3 switching
- power containment
- shader power scaling
Set radeon.dpm=1 to enable.
v2: enable hainan support, rebase
v3: guard acpi stuff
v4: fix 64 bit math
v5: fix 64 bit div harder
v6: fix thermal interrupt check noticed by Jerome
v7: attempt fix state enable
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Thu, 27 Jun 2013 23:29:04 +0000 (09:29 +1000)]
Merge branch 'drm/for-next' of git://anongit.freedesktop.org/tegra/linux into drm-next
These changes are mostly minor fixes to things introduced in 3.10. The
biggest chunk is updates to the host1x firewall which checks job
submissions from userspace and wasn't working properly. All other
patches are mostly one-liners. Nothing new or too exciting this time
around.
* 'drm/for-next' of git://anongit.freedesktop.org/tegra/linux:
gpu: host1x: Rework CPU syncpoint increment
gpu: host1x: Fix client_managed type
gpu: host1x: Fix memory access in syncpt request
gpu: host1x: Copy gathers before verification
gpu: host1x: Don't reset firewall between gathers
gpu: host1x: Check reloc table before usage
gpu: host1x: Check INCR opcode correctly
drm/tegra: Remove DRIVER_BUS_PLATFORM from driver_features
drm/tegra: Fix return value
drm/tegra: Include header drm/drm.h
MAINTAINERS: Update Tegra DRM entry
drm/tegra: fix error return code in gr2d_submit()
drm/tegra: fix missing unlock on error
drm/tegra: Honor pixel-format changes
drm/tegra: Explicitly set irq_enabled
drm/tegra: Don't disable unused planes
Alex Deucher [Fri, 22 Mar 2013 19:59:10 +0000 (15:59 -0400)]
drm/radeon/dpm: validate voltages against dispclk requirements
Validate the voltages against the voltage requirements of the
dispclk. We currently don't adjust the disp clock so it never
changes, but we need to filter out voltage levels that are too
low none the less.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>