it looks like we accidentally inverted the check that the command
parser should only run when the driver enables some form of PPGTT.
Testcase: igt/gem_exec_parse Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Also drop the comment right above, all production vlv now
have hw ppgtt enabled.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Deepak S [Thu, 18 Sep 2014 13:21:50 +0000 (18:51 +0530)]
drm/i915/vlv: Remove check for Old Ack during forcewake
Based on the HW team inputs. We can should not wait for the old ack,
Waiting for old ack might fail, when other forcewake came before the
present one is desserted.
for example, if forcewake bit 0 was set and before it could get cleared
forcewake bit 1 got set, HW eventually clear bit 0, when the bit 1
is cleared. i.e, bit 1 is still sent then forcewake bit 0 will still be
set.
Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add comment Ville requested.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 12:55:31 +0000 (14:55 +0200)]
drm/i915: Clarify uncore.lock locking
Only one place looked in need of a bit of polish: hsw_restore_lcpll.
It's used by the runtime pm code and hence is always called from
process context. No irq flag saving required.
Another thing I've stumbled over is that we might need to add a
raw forcewake_get/put helpers which don't grab a runtime pm reference
but just check that the device isn't suspended - we have this duplicated
in the execlist code, too.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 12:55:29 +0000 (14:55 +0200)]
drm/i915: Clarify irq_lock locking, special cases
Grab bag for all the special cases:
- i9xx_check_fifo_underruns is only called from crtc_enable hooks,
i.e. process context.
- i915_enable_asle_pipestat is only called from interrupt postinstall
hooks. So again process context.
- gen8_irq_power_well_post_enable is called from the runtime pm code,
which again means process context.
- The open-coded hpd_irq_setup loop in _thaw is also running in process
context.
So for all of them the plain _irq variant is sufficient.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 12:55:28 +0000 (14:55 +0200)]
drm/i915: Clarify irq_lock locking, irq handlers
irq handlers always run with interrupts locally disabled, so
plain spinlocks is all we need. I've also reviewed again that they
all follow the _irq_handler postfix convention.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
->detect callbacks are only ever called from process context, and
there's no fancy nesting going on here. So plain _irq spinlock
variants is what we want.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 12:55:24 +0000 (14:55 +0200)]
drm/i915: Clarify gpu_error.lock locking
i915_capture_error_state can be called from all kinds of contexts, so
needs the full irqsave dance. But the other two places to grab and
release the error state are only called from process context. So
simplify them to the plaine _irq spinlock versions to clarify the
locking semantics.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we tackle the functions also called from interrupt handlers.
- intel_check_page_flip is exclusively called from irq handlers, so a
plain spin_lock is all we need. In i915_irq.c we have the convention
to give all such functions an _irq_handler postfix, but that would
look strange and als be a bit a misleading name. I've opted for a
WARN_ON(!in_irq()) instead.
- The other two places left are called both from interrupt handlers
and from our reset work, so need the full irqsave dance. Annotate
them with a short comment.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 12:55:22 +0000 (14:55 +0200)]
drm/i915: Clarify event_lock locking, process context
It's good practice to use the more specific versions for irq save
spinlocks both as executable documentation and to enforce saner
design. The _irqsave version really should only be used if the calling
context is unknown and there's a good reason to call a function from
all kinds of places.
This is the first step whice replaces all occurances of _irqsave in
process context with the simpler irq disable/enable variants. We don't
have any funky spinlock nesting going on, especially since the
event_lock is the outermost of the irq/vblank related spinlocks.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 14 Aug 2014 19:04:37 +0000 (22:04 +0300)]
drm/i915: Move vblank enable earlier and disable later
We changed to an interrupt based vblank wait (as opposed to polling)
in:
commit 44bd93a3d367913d883be6abba9a6e51a53c4e90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 25 23:36:44 2014 +0200
drm/i915: Use generic vblank wait
However we already had vblank waits on the wrong side of
drm_vblank_{on,off}() calls due to various workarounds, so now we get
a warning more or less every time we do a modeset, and we fail to
wait for the vblank like we should.
Move the drm_vblank_{on,off}() calls back out from
intel_crtc_{enable,disable}_planes() so that all of these vblank waits
return to proper operation. Also move the cxsr wait a bit earlier so
that we can keep the encoder disable after we've turned off vblanks.
Moving stuff out from the plane enable/disable functions seems
preferrable to moving the workaround stuff in since the workarounds are
required only on specific platforms.
While at it switch over to the drm_crtc_ variants of the vblank on/off
functions.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82525
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82490 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 10:36:02 +0000 (12:36 +0200)]
drm/i915: Use generic vblank wait
This has the upside that it will no longer steal interrupts from the
interrupt handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
v2: Adjust to the new names.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Mon, 15 Sep 2014 09:38:57 +0000 (11:38 +0200)]
drm/i915: Fix irq checks in ring->irq_get/put functions
Yet another place that wasn't properly transformed when implementing
SOix. While at it convert the checks to WARN_ON on gen5+ (since we
don't have UMS potentially doing stupid things on those platforms).
And also add the corresponding checks to the put functions (again with
a WARN_ON) for gen5+.
v2: Drop the WARNINGS in the irq_put functions (including the existing
one for vebox), Chris convinced me that they're not that terribly
useful.
v3: Don't forget about execlist code.
Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Imre Deak [Mon, 8 Sep 2014 12:21:09 +0000 (15:21 +0300)]
drm/i915: vlv: fix display IRQ enable/disable
We want to enable/disable display IRQs only if global i915 IRQs are
enabled. To check the latter it's not enough to consult the DRM
dev->irq_enabled flag, since runtime PM can disable/enable IRQs
and it won't adjust this flag only the i915 specific
dev_priv->pm._irqs_disabled flag. Fix this by using the proper
intel_irqs_enabled() helper instead.
Fortunately this didn't cause an actual problem since even if we enabled
display IRQs too early (before enabling global i915 IRQs) the
VLV_MASTER_IER would still be clear masking all IRQs.
Ville Syrjälä [Fri, 12 Sep 2014 17:53:33 +0000 (20:53 +0300)]
drm/i915: Only set CURSOR_PIPE_CSC_ENABLE when cursor is enabled
It seems cleaner if we keep CURCNTR at 0 when the cursor is disabled,
so don't set the CURSOR_PIPE_CSC_ENABLE bit unless the cursor is
enabled.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 12 Sep 2014 17:53:32 +0000 (20:53 +0300)]
drm/i915: Move the cursor_base setup to i{845, 9xx}_update_cursor()
To make the code a bit more undestandable move the
intel_crtc->cursor_base assignment into the low level update cursor
routines. That's were we compare the current value with the new one
so immediately seeing that it gets assigned only afterwards helps
one to understand that it gets assigned only after the comparison.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 12 Sep 2014 13:18:13 +0000 (15:18 +0200)]
drm/i915: Drop get/put_pages for scratch page
While discussing/reviewing __GFP_MOVEABLE behaviour and interactions
with our various page allocations on irc Chris brought up that the
scratch page isn't allocated as moveable, but we still grab/put a
reference to lock it in place. Which is unecessary.
So drop that.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
v2: take Ville's comments
- move comment along with the pin_and_fence call
- check for error before calling i915_gem_track_fb
- move old_obj != obj to an upper if condition
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: split intel_primary_plane_setplane() into check() and commit()
As a preparation for atomic updates we need to split the code to check
everything we are going to commit first. This patch starts the work to
split intel_primary_plane_setplane() into check() and commit() parts.
More work is expected on this to get a better split of the two steps.
Ideally the commit() step should never fail.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: split intel_cursor_plane_update() into check() and commit()
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
The commit part can still fail, but that should be solved in another
upcoming patch.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: split intel_update_plane into check() and commit()
Due to the upcoming atomic modesetting feature we need to separate
some update functions into a check step that can fail and a commit
step that should, ideally, never fail.
This commit splits intel_update_plane() and its commit part can still
fail due to the fb pinning procedure.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Michel Thierry [Fri, 5 Sep 2014 13:13:16 +0000 (14:13 +0100)]
drm/i915: Enable full PPGTT on gen7
Use full PPGTT as the default option in gen7.
Note that aliasing PPGTT is the default option for gen8 (see
HAS_PPGTT) since we're still fighting troubles around context
switching and execlists.
This may well come back to bite me later.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
[danvet: Explain that gen8 full ppgtt is blocked on execlists for
now.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 11 Sep 2014 07:43:48 +0000 (08:43 +0100)]
drm/i915: Match GTT space sanity checker with implementation
If we believe that the device can cross cache domains in its prefetcher
(i.e. we allow neighbouring pages in different domains), we don't supply
a color_adjust callback. Use the presence of this callback to better
determine when we should be verifying that the GTT space we just
used is valid.
v2: Remove the superfluous struct drm_device function param as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Also adjust the comment per irc discussion with Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Wed, 10 Sep 2014 11:18:27 +0000 (12:18 +0100)]
drm/i915: HSW always use GGTT selector for secure batches
gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell only, you are able to select the security bit
separate from the address space - and we always requested to use ppgtt.
This breaks the golden render state batch execution with full-ppgtt as
that is only present in the global GTT and more generally any secure
batch that is not colocated in the ppgtt and ggtt. So we need to
disable the use of the ppgtt selector bit for secure batches, or else we
hang immediately upon boot and thence after every GPU reset...
v2: Only HSW differentiates between secure dispatch and ggtt, so simply
ignore the differentiation and always use secure==ggtt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Rectify commit message as noted by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Deepak S [Tue, 9 Sep 2014 13:44:16 +0000 (19:14 +0530)]
drm/i915: add cherryview specfic forcewake in execlists_elsp_write
In chv, we have two power wells Render & Media. We need to use
corresponsing forcewake count. If we dont follow this we are getting
error "*ERROR*: Timed out waiting for forcewake old ack to clear" due to
multiple entry into __vlv_force_wake_get.
Signed-off-by: Deepak S <deepak.s@linux.intel.com> Requested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Michel Thierry [Tue, 9 Sep 2014 12:04:43 +0000 (13:04 +0100)]
drm/i915: fix another use-after-free in i915_gem_evict_everything
Also here, i915_gem_evict_vm causes an unbind, which can end up dropping
the last ref to the ppgtt.
Triggered by igt gem_evict_everything test.
Testcase: igt/gem_evict_everything Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Chris Wilson <chris@cris-wilsonc.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since display interrups in general survive a gpu reset on those
platforms there's also no need to reinit the hotplug settings.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sun, 7 Sep 2014 15:51:12 +0000 (16:51 +0100)]
drm/i915: Wrap -EIO send-vblank event for failed pageflip in spinlock
drm_send_vblank_event() demands that we hold the event spinlock whilst
calling it, so do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fix the double lock as requested by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 9 Sep 2014 06:02:43 +0000 (07:02 +0100)]
drm/i915: Drop any active reference before unbinding
Before we process the final unbind on an object and move it to the
unbound list, it is semantically cleaner if there are no more active
references to the object. (An active reference would imply that it was
still being accessed by the GPU after it became inaccessible.) The
caveat is that all callsites must be prepared for the object to
disappeared during the unbind - i.e. they must hold their own reference.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Tue, 9 Sep 2014 10:16:08 +0000 (11:16 +0100)]
drm/i915: Objects on the unbound list may still have an active reference
Due to the lazy retirement semantics, even though we have unbound an
object, it may still hold onto an active reference. So in the debug code,
play safe.
v2: Export i915_gem_shrink() rather than opencoding it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: use lane count and link rate from VBT as minimums for eDP
should have started using the optimal link parameters for eDP
panels. Turns out a certain other OS uses DPCD instead of VBT, which
means trusting VBT on this may not be so reliable after all. Follow
suit.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81647 Tested-by: Adam Jirasek <libm3l@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79386 Tested-by: Narthana Epa <narthana.epa+freedesktop@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 4 Sep 2014 20:43:45 +0000 (21:43 +0100)]
drm/i915/hdmi, dp: Do not dereference the encoder in the connector destroy
Oops, apparently intel_hdmi/intel_dp is the encoder - an object with a
distinct lifetime to the connector, and so we cannot simply reuse the
common function to unset and free the edid.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 5 Sep 2014 18:54:13 +0000 (21:54 +0300)]
drm/i915: Limit the watermark to at least 8 entries on gen2/3
830 is very unhappy of the watermark value is too low (indicating a very
high watermark in fact, ie. memory fetch will occur with an almost full
FIFO). Limit the watermark value to at least 8 cache lines.
That also matches the burst size we use on most platforms. BSpec seems
to indicate we should limit the watermark to 'burst size + 1'. But on
gen4 we already use a hardcoded 8 as the watermark value (as the spec
says we should), so just use 8 as the limit on gen2/3 as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Fri, 5 Sep 2014 18:52:42 +0000 (21:52 +0300)]
drm/i915: Fix DVO 2x clock enable on 830M
The spec says:
"For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register (06014h-06017h) and DPLL B Control
Register (06018h-0601Bh)."
The pipe A and B force quirks take care of DPLL_VCO_ENABLE, so we
just need a bit of special care to handle DPLL_DVO_2X_MODE.
v2: Recompute num_dvo_pipes on the spot, use PIPE_A/PIPE_B instead
of pipe/!pipe for the register offsets in disable (Daniel)
Add a comment about the ordering in enable and another one
about filtering out the DVO 2x bit in state readout
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Wed, 17 Sep 2014 09:55:19 +0000 (19:55 +1000)]
Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next
Commit "drm/rcar-du: Use struct videomode in platform data" touches board code
in arch/arm/mach-shmobile. There is, to the best of my knowledge, no risk of
conflict for v3.18. Simon, are you fine with getting those changes merged
through Dave's tree (and could you confirm that no conflict should occur) ?
Simon acked the merge: Acked-by: Simon Horman <horms+renesas@verge.net.au>
* 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev:
drm/rcar-du: Add OF support
drm/rcar-du: Use struct videomode in platform data
video: Add DT bindings for the R-Car Display Unit
video: Add THC63LVDM83D DT bindings documentation
video: Add ADV7123 DT bindings documentation
video: Add DT binding documentation for VGA connector
devicetree: Add vendor prefix "thine" to vendor-prefixes.txt
devicetree: Add vendor prefix "mitsubishi" to vendor-prefixes.txt
drm/shmob: Update copyright notice
drm/rcar-du: Update copyright notice
While zone->name is currently hard coded, the call to kobject_init_and_add()
should follow the more defensive argument list usage (as already done in
other places in ttm_memory.c) where "%s" is used instead of directly passing
in a variable as a format string.
Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
In order to support the "enable GPIO" available in many panel devices,
this commit adds a proper devicetree binding.
By providing an enable GPIO in the devicetree, the driver can now turn
off and on the panel device, and/or the backlight device. Both the
backlight and the GPIO are optional properties.
Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com>
Instead of setting an initial value for the return code, set it explicitly
on each error path. This is just a cosmetic cleanup, as preparation for the
enable GPIO support.
Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/tilcdc: panel: Fix backlight devicetree support
The current backlight support is broken; the driver expects a backlight-class
in the panel devicetree node. Fix this by implementing it properly, getting
an optional backlight from a phandle.
This shouldn't cause any backward-compatibility DT issue because the current
implementation doesn't work and is not even documented.
Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit adds the missing calls to of_node_put to release the node
that's currently held by the of_get_child_by_name() call in the panel
info parsing code.
Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com>
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().
To fix it, this commit adds proper labels to bail out at the different
stages in the load function, and release only the resources actually allocated.
Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Tue, 16 Sep 2014 06:02:09 +0000 (16:02 +1000)]
Merge tag 'drm-intel-next-2014-09-05' of git://anongit.freedesktop.org/drm-intel into drm-next
- final bits (again) for the rotation support (Sonika Jindal)
- support bl_power in the intel backlight (Jani)
- vdd handling improvements from Ville
- i830M fixes from Ville
- piles of prep work all over to make skl enabling just plug in (Damien, Sonika)
- rename DP training defines to reflect latest edp standards, this touches all
drm drivers supporting DP (Sonika Jindal)
- cache edids during single detect cycle to avoid re-reading it for e.g. audio,
from Chris
- move w/a for registers which are stored in the hw context to the context init
code (Arun&Damien)
- edp panel power sequencer fixes, helps chv a lot (Ville)
- piles of other chv fixes all over
- much more paranoid pageflip handling with stall detection and better recovery
from Chris
- small things all over, as usual
* tag 'drm-intel-next-2014-09-05' of git://anongit.freedesktop.org/drm-intel: (114 commits)
drm/i915: Update DRIVER_DATE to 20140905
drm/i915: Decouple the stuck pageflip on modeset
drm/i915: Check for a stalled page flip after each vblank
drm/i915: Introduce a for_each_plane() macro
drm/i915: Rewrite ABS_DIFF() in a safer manner
drm/i915: Add comments explaining the vdd on/off functions
drm/i915: Move DP port disable to post_disable for pch platforms
drm/i915: Enable DP port earlier
drm/i915: Turn on panel power before doing aux transfers
drm/i915: Be more careful when picking the initial power sequencer pipe
drm/i915: Reset power sequencer pipe tracking when disp2d is off
drm/i915: Track which port is using which pipe's power sequencer
drm/i915: Fix edp vdd locking
drm/i915: Reset the HEAD pointer for the ring after writing START
drm/i915: Fix unsafe vma iteration in i915_drop_caches
drm/i915: init sprites with univeral plane init function
drm/i915: Check of !HAS_PCH_SPLIT() in PCH transcoder funcs
drm/i915: Use HAS_GMCH_DISPLAY un underrun reporting code
drm/i915: Use IS_BROADWELL() instead of IS_GEN8() in forcewake code
drm/i915: Don't call gen8_fbc_sw_flush() on chv
...
Dave Airlie [Tue, 16 Sep 2014 04:59:16 +0000 (14:59 +1000)]
Merge branch 'drm-next-ast-fixes' of ssh://people.freedesktop.org/~/linux into drm-next
Pull in first set of changes from Ben for ast on ppc.
I've done a quick boot test on x86 and it still seems to boot.
* 'drm-next-ast-fixes' of ssh://people.freedesktop.org/~/linux:
drm/ast: Cleanup analog init code path
drm/ast: Don't assume DVO enabled means SIL164 on uninitialized chips
drm/ast: Properly initialize P2A base before using it in ast_init_3rdtx()
drm/ast: POST chip at probe time if VGA not enabled
drm/ast: Try to use MMIO registers when PIO isn't supported
Dave Airlie [Mon, 15 Sep 2014 20:20:53 +0000 (06:20 +1000)]
Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
This is the main merge request for Nouveau 3.18, overview:
- various bits of roy's gt21x clock work
- various bits of kepler memory clock work (don't get too excited, there's at least one more major bit left that's busting higher freqs)
- misc fan control improvements
- kepler hdmi infoframe fixes
- dp audio
- l2 cache + cbc improvements
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (68 commits)
drm/gt214-/disp: enable dp audio
drm/gt214-/kms: fix hda eld regression
drm/g94-/disp: calculate some dp audio constants
drm/gt214-/kms: perform hda codec setup on displayport too
drm/gk104-/disp: infoframe registers moved yet again on kepler
drm/nouveau/bios: parse older ramcfg/timing data like we do newer ones
drm/nva3/fb/ram: Per-partition regs
drm/nouveau/fb/ram: Support strided regs
drm/nv50/fb/ram: Store the number of partitions in the designated fields
drm/nv50/kms: Set VBLANK time in modeset script
drm/nouveau/bios: Add rammap support for version 1.0
drm/gf100-/pwr/memx: block host and fifo around reclock
drm/nouveau/pwr/memx: fix command ordering around block/unblock
drm/nouveau/pwr/memx: rename fb off/on to block/unblock
drm/nva3/clk: Pause the GPU before reclocking
drm/nouveau/gpio: rename g92 class to g94
drm/gk104-/fb/ram: move fb enable/disable to same place as nvidia
drm/gk104/fb/ram: twiddle some more bits when reclocking
drm/nouveau/bios: parse another large chunk of random memory config data
drm/gk104-/fb/ram: perform certain steps only when bios data differs
...
Ben Skeggs [Thu, 11 Sep 2014 12:59:13 +0000 (22:59 +1000)]
drm/nouveau/pwr/memx: rename fb off/on to block/unblock
More accurate as to the function of the opcodes. Not only is FB disabled,
but the host is prevented from touching the GPU. An upcoming patch for
Kepler will also halt PFIFO (as NVIDIA does).
Emil Velikov [Mon, 8 Sep 2014 19:27:57 +0000 (20:27 +0100)]
drm/nouveau/gpio: rename g92 class to g94
nv92 hardware has only 16 interrupt lines, while nv94 and later
has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect
PDISP setup. This is a regression introduced with
Ben Skeggs [Mon, 8 Sep 2014 03:38:02 +0000 (13:38 +1000)]
drm/gk104-/fb/ram: use parsed timing data in mr routines
All the other chipsets should be moved over to this too. It's not needed
yet for the upcoming commits, so left this step as it'll conflict badly
with Roy's GT21x reclocking work.
projects / karo-tx-linux.git / log