| Age | Commit message (Collapse) | Author |
|---|
|
BXT power well support is not yet stable. Starting with patch
commit 9f836f9016ad5320e0c9230419d2102cf15a28aa
Author: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Date: Mon Nov 16 16:20:01 2015 +0100
drm/i915/gen9: Turn DC handling into a power well
DPMS off operations may actually cause the entire system to powerdown or
reboot. Disable power well support for now until Broxton gets fixes
similar to what we have for SKL.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
References: http://lists.freedesktop.org/archives/intel-gfx/2015-November/081037.html
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448990818-11005-1-git-send-email-matthew.d.roper@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
|
|
ironlake_crtc_compute_clock() gets called during atomic compute phase,
so we must check the future pipe type instead of the current type.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462131-13321-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The .get_config() hooks should not reference anything in crtc->config,
everything should be based on the passed in pipe_config instead. So
don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
and also avoid using the encoder->crtc link and instead look up the
pipe via pipe_config->base.crtc.
I don't think this will actually fix anything since during the initial
state readout we set up the encoder->crtc link prior to calling
.get_config(), and during the modeset state check the encoder->crtc
ought to be correct anyway since it's that state we just programmed.
But this seems the right thing to do anyway.
While at it, do some house cleaning on the local variables in the
.infoframe_enabled() hooks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448555227-31403-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When doing the initial setup both the hclk and the aclk need to be
enabled otherwise the board will simply hang. This only occurs when
building the vop driver as a module, when its built-in the initial setup
happens to run before the clock framework shuts of unused clocks
(including the aclk).
While there also switch to doing prepare and enable in one step rather
then separate steps to reduce the amount of code required.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Tested-by: Yakir Yang <ykk@rock-chips.com>
Tested-by: Romain Perier <romain.perier@gmail.com>
|
|
There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
the 2nd thread would get an error code).
Everything else (specifically psb_gtt_pin) is already protected by
some other locks. Hence just create a new driver-private mmap_mutex
just for this function.
With this gma500 is complete dev->struct_mutex free!
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-21-git-send-email-daniel.vetter@ffwll.ch
|
|
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-20-git-send-email-daniel.vetter@ffwll.ch
|
|
This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.
Again important to switch obj_unref to _unlocked variants.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-19-git-send-email-daniel.vetter@ffwll.ch
|
|
It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.
The only important bit is to switch all gem_obj_unref calls to the
_unlocked variant.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-18-git-send-email-daniel.vetter@ffwll.ch
|
|
This is called without dev->struct_mutex held, we need to use the
_unlocked variant.
Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch
|
|
We have relied upon the sole caller (wait_ioctl) validating the timeout
argument. However, when waiting for multiple requests I forgot to ensure
that the timeout was still positive on the later requests. This is more
simply done inside __i915_wait_request.
Fixes regression introduced in
commit b47161858ba13c9c7e03333132230d66e008dd55
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Apr 27 13:41:17 2015 +0100
drm/i915: Implement inter-engine read-read optimisations
The impact of the regression is 1 jiffie for each extra active ring for
a wait_ioctl with a timeout -- I don't think anyone has noticed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448544702-5594-1-git-send-email-chris@chris-wilson.co.uk
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Similar to
commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Oct 30 19:20:27 2015 +0200
drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
we can only enable fifo underrun reporting when using the fdi/lpt
after everything is set up and after a bit of waiting. The waiting
is required, enabling it right after enabling encoders will first trigger
an underrun on the pch and then, 1 frame later, an underrun on the
cpu. Two vblank waits after encoder enabling seems enough to curb it.
And similar to
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Nov 20 22:09:18 2015 +0200
drm/i915: Suppress spurious CPU FIFO underruns on ILK-IVB
we also need to make sure cpu fifo underrun reporting is disabled when
enabling the fdi rx/tx and pch transcoder&port. But somehow this is
only needed when enabling, not also when disabling.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448705139-12534-1-git-send-email-daniel.vetter@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91578
Tested-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
clock difference
Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.
drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.
Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?
Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Avoid the sticky preferred mode bit by using the no-merge version of the
function (this allows gnome-shell to resize to lower resolutions than
the default resolution)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
drm-intel-next-2015-11-20-rebased:
4 weeks because of my vacation, so a bit more:
- final bits of the typesafe register mmio functions (Ville)
- power domain fix for hdmi detection (Imre)
- tons of fixes and improvements to the psr code (Rodrigo)
- refactoring of the dp detection code (Ander)
- complete rework of the dmc loader and dc5/dc6 handling (Imre, Patrik and
others)
- dp compliance improvements from Shubhangi Shrivastava
- stop_machine hack from Chris to fix corruptions when updating GTT ptes on bsw
- lots of fifo underrun fixes from Ville
- big pile of fbc fixes and improvements from Paulo
- fix fbdev failures paths (Tvrtko and Lukas Wunner)
- dp link training refactoring (Ander)
- interruptible prepare_plane for atomic (Maarten)
- basic kabylake support (Deepak&Rodrigo)
- don't leak ringspace on resets (Chris)
drm-intel-next-2015-10-23:
- 2nd attempt at atomic watermarks from Matt, but just prep for now
- fixes all over
* tag 'drm-intel-next-2015-11-20-merged' of git://anongit.freedesktop.org/drm-intel: (209 commits)
drm/i915: Update DRIVER_DATE to 20151120
drm/i915: take a power domain reference while checking the HDMI live status
drm/i915: take a power domain ref only when needed during HDMI detect
drm/i915: Tear down fbdev if initialization fails
async: export current_is_async()
Revert "drm/i915: Initialize HWS page address after GPU reset"
drm/i915: Fix oops caused by fbdev initialization failure
drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly
drm/i915: Stuff rotation params into view union
drm/i915: Drop return value from intel_fill_fb_ggtt_view
drm/i915 : Fix to remove unnecsessary checks in postclose function.
drm/i915: add MISSING_CASE to a few port/aux power domain helpers
drm/i915/ddi: fix intel_display_port_aux_power_domain() after HDMI detect
drm/i915: Remove platform specific *_dp_detect() functions
drm/i915: Don't do edp panel detection in g4x_dp_detect()
drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT.
drm/i915: PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT.
drm/i915: Reduce PSR re-activation time for VLV/CHV.
drm/i915: Delay first PSR activation.
drm/i915: Type safe register read/write
...
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
Here's the first drm-misc pull, with really mostly misc stuff all over.
Somewhat invasive is only Ville's change to mark the arg struct for
fb_create const - that might conflict with a new driver pull. So better to
get in fast.
* tag 'topic/drm-misc-2015-11-26' of git://anongit.freedesktop.org/drm-intel:
drm/mm: use list_next_entry
drm/i915: fix potential dangling else problems in for_each_ macros
drm: fix potential dangling else problems in for_each_ macros
drm/sysfs: Send out uevent when connector->force changes
drm/atomic: Small documentation fix.
drm/mm: rewrite drm_mm_for_each_hole
drm/sysfs: Grab lock for edid/modes_show
drm: Print the src/dst/clip rectangles in error in drm_plane_helper
drm: Add "prefix" parameter to drm_rect_debug_print()
drm: Keep coordinates in the typical x, y, w, h order instead of x, y, h, w
drm: Pass the user drm_mode_fb_cmd2 as const to .fb_create()
drm: modes: replace simple_strtoul by kstrtouint
drm: Describe the Rotation property bits.
drm: Remove unused fbdev_list members
GPU-DRM: Delete unnecessary checks before drm_property_unreference_blob()
drm/dp: add eDP DPCD backlight control bit definitions
drm/tegra: Remove local fbdev emulation Kconfig option
drm/imx: Remove local fbdev emulation Kconfig option
drm/gem: Update/Polish docs
drm: Update GEM refcounting docs
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
few i915 fixes.
* tag 'drm-intel-fixes-2015-11-30' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Don't override output type for DDI HDMI
drm/i915: Don't compare has_drrs strictly in pipe config
drm/i915: Mark uneven memory banks on gen4 desktop as unknown swizzling
|
|
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Thinkpad T40p needs agpmode 1.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We use the reservation object of the page directory for the page tables as
well, because of this the page directory should be freed last. Ensure that
by keeping a reference from the page tables to the directory.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
That got messed up while porting it from Radeon.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
DSI has quite a few special cases, like DP, so add it to crtc
state. This way we can get rid of a number of intel_pipe_has_type()
checks for DSI. This isn't necessarily the prettiest way, but it's a
step towards being aligned with what's being done with other encoders.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448619706-21293-3-git-send-email-jani.nikula@intel.com
|
|
The hook was added to cater for DSI, but with the hooks rearranged on
the DSI encoder side, this is no longer needed. It was a bit silly
anyway to have two hooks called back-to-back.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448619706-21293-2-git-send-email-jani.nikula@intel.com
|
|
For DSI, the pre_pll_enable and the pre_enable hooks are called
back-to-back on all platforms that support DSI. The distinction is
artificial for DSI, for which we enable the DSI PLL in the encoder
hooks. Do everything in pre_enable, and remove DSI pre_pll_enable hook.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448619706-21293-1-git-send-email-jani.nikula@intel.com
|
|
Found by static code analysis tool.
v2: Inserted block instead of goto & renamed variables (Chris)
v3: Aligned code as per the opening brace (Chris)
Rebased on top of nightly (Daniel)
Signed-off-by: Namrta Salonie <namrta.salonie@intel.com>
Signed-off-by: Deepak S <deepak.s@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Add drm_atomic_helper_disable_planes_on_crtc() for disabling all
planes associated with the given CRTC. This can be used for instance
in the CRTC helper disable callback to disable all planes before
shutting down the display pipeline.
v2:
- Address Daniels review comments [1]
- Do atomic_begin() and atomic_flush() always if they are defined and
atomic knob is set
- update kerneldoc
- Put drm_atomic_helper_disable_planes_on_crtc() after
drm_atomic_helper_commit_planes_on_crtc() in drm_atomic_helper.c
to have functions in the same order as in drm_atomic_helper.h
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448633641-6486-1-git-send-email-jsarha@ti.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
Ben Skeggs wrote:
A couple of regression fixes, some more boards whitelisted for a hw bug
workaround, gr/ucode fixes for hangs a user is seeing.
The changes look larger than they actually are due to the ucode binaries
(*.fucN.h) being regenerated.
* 'linux-4.4' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/volt/pwm/gk104: fix an off-by-one resulting in the voltage not being set
drm/nouveau/nvif: allow userspace access to its own client object
drm/nouveau/gr/gf100-: fix oops when calling zbc methods
drm/nouveau/gr/gf117-: assume no PPC if NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK is zero
drm/nouveau/gr/gf117-: read NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK from correct GPC
drm/nouveau/gr/gf100-: split out per-gpc address calculation macro
drm/nouveau/bios: return actual size of the buffer retrieved via _ROM
drm/nouveau/instmem: protect instobj list with a spinlock
drm/nouveau/pci: enable c800 magic for some unknown Samsung laptop
drm/nouveau/pci: enable c800 magic for Clevo P157SM
|
|
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448461290-12333-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Pull the BDW+ DE pipe interrupt mask frobbing into a central place,
like we have for other platforms.
v2: Fix the kerneldoc (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448294777-13722-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
ironlake_{enable,disable}_display_irq() each just call
ilk_update_display_irq() so let's make them static inlines.
While at it s/ironlake/ilk/ to make things shorter, and a bit more
consistent with the ibx functions.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448294777-13722-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
No reason why ibx_{enable,disable}_display_interrupt() couldn't be
static inlines instead of cpp macros.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448294777-13722-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The WARN_ON() macro only takes a condition argument, it doesn't take
a message. I have converted this to WARN() instead.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
|
|
In ttm_write_lock(), the uninterruptible path should call
__ttm_write_lock() not __ttm_read_lock(). This fixes a vmwgfx hang
on F23 start up.
syeh: Extracted this from one of Thomas' internal patches.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
|
|
This reverts
commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
With the proper fix ("drm/i915: fix the SDE irq dmesg warnings
properly") reliably in place, bring back the error message.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462843-32739-2-git-send-email-jani.nikula@intel.com
|
|
We had the "The master control interrupt lied (SDE)!" check and error
message in place for a long time without any problems, until
commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Wed Jul 8 17:07:47 2015 +0530
drm/i915: Handle HPD when it has actually occurred
caused the errors to start happening. This was bisected and reported,
but the error message was silenced in
commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Oct 23 10:56:12 2015 +0200
drm/i915: shut up gen8+ SDE irq dmesg noise
shooting the messenger while the debugging for why Sonika's commit
triggered the errors was still in progress.
It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
register even though the hotplug trigger indicates there isn't a hotplug
irq to handle. The PCH doesn't seem to really ack the the interrupt to
the CPU unless we touch the hotplug register.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
[Jani: added a comment and amended the commit message while applying]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462843-32739-1-git-send-email-jani.nikula@intel.com
|
|
The previous patch reintroduced a race condition whereby a failure in
one reader may allow a second reader to see out-of-order events.
Introduce a mutex to serialise readers so that an event is completed in
its entirety before another reader may process an event. The two readers
may race against each other, but the events each retrieves are in the
correct order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-2-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In
commit cdd1cf799bd24ac0a4184549601ae302267301c5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Dec 4 21:03:25 2014 +0000
drm: Make drm_read() more robust against multithreaded races
I fixed the races by serialising the use of the event by extending the
dev->event_lock. However, as Thomas pointed out, the copy_to_user() may
fault (even the __copy_to_user_inatomic() variant used here) and calling
into the driver backend with the spinlock held is bad news. Therefore we
have to drop the spinlock before the copy, but that exposes us to the
old race whereby a second reader could see an out-of-order event (as the
first reader may claim the first request but fail to copy it back to
userspace and so on returning it to the event list it will be behind the
current event being copied by the second reader).
Reported-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448462343-2072-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx. Add the ich9 south
bridge emulated by 'qemu -M q35'.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
"Could not force DPM to low", etc. is usually harmless and
just confuses users.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Currently a DDI port may register the DP hotplug handler even though
it's used with HDMI, and the DP HPD handler overrides the encoder
type forcibly to DP. This caused the inconsistency on a machine
connected with a HDMI monitor; upon a hotplug event, the DDI port is
suddenly switched to be handled as a DP although the same monitor is
kept connected, and this leads to the erroneous blank output.
This patch papers over the bug by excluding the previous HDMI encoder
type from this override. This should be fixed more fundamentally,
e.g. by moving the encoder type reset from the HPD or by having
individual encoder objects for HDMI and DP. But since the bug has
been present for a long time (3.17), it's better to have a
quick-n-dirty fix for now, and keep working on a cleaner fix.
Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=955190
Fixes: 0e32b39ceed6 ('drm/i915: add DP 1.2 MST support (v0.7)')
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1447931396-19147-1-git-send-email-tiwai@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
pipe_config_compare, v2] relaxed the way to compare the pipe
configurations, but one new comparison sneaked in there: it added the
strict has_drrs value check. This causes a regression on many
machines, typically HP laptops with a docking port, where the kernel
spews warnings and eventually fails to set the mode properly like:
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs (expected 1, found 0)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700 intel_modeset_check_state+0x5aa/0x870 [i915]()
pipe state doesn't match!
....
This patch just removes the check again for fixing the regression.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare, v2')
Cc: <stable@vger.kernel.org> # v4.3+
Reported-and-tested-by: Max Lin <mlin@suse.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1448461607-16868-1-git-send-email-tiwai@suse.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
ipu_crtc_handle_pageflip() was calling drm_send_vblank_event() with
a pipe argument of -1. Commit cc1ef118fc09 ("drm/irq: Make pipe
unsigned and name consistent") now makes this error obvious, as we
now may get a warning from:
if (WARN_ON(pipe >= dev->num_crtcs))
in drm_vblank_count_and_time(). Prior to this change, we would end
up making out-of-bounds array accesses via:
struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
and
*vblanktime = vblanktimestamp(dev, pipe, cur_vblank);
So, this has been broken for a very long time, and is not a result
of the above commit. Since we don't care about the staging versions,
I've tagged this with the earliest mainline commit where we do care,
even though this commit did not introduce the bug.
Fixes: 6556f7f82b9c ("drm: imx: Move imx-drm driver out of staging")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Kbuild now supports <modname>-m variables.
This reverts commit 8fa884dc355ffd0caa964a284a530bf747df5c77.
Signed-off-by: Michal Marek <mmarek@suse.cz>
|
|
We have serious dangling else bugs waiting to happen in our for_each_
style macros with ifs. Consider, for example,
#define for_each_power_domain(domain, mask) \
for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
if ((1 << (domain)) & (mask))
If this is used in context:
if (condition)
for_each_power_domain(domain, mask);
else
foo();
foo() will be called for each domain *not* in mask, if condition holds,
and not at all if condition doesn't hold.
Fix this by reversing the conditions in the macros, and adding an else
branch for the "for each" block, so that other if/else blocks can't
interfere. Provide a "for_each_if" helper macro to make it easier to get
this right.
v2: move for_each_if to drmP.h in a separate patch.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448392916-2281-2-git-send-email-jani.nikula@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
being set
Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Martin Peres <martin.peres@free.fr>
|
|
Regression from "abi16: implement limited interoperability with
usif/nvif".
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Somehow missed these two when removing dodgy void casts during the
rework.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
is zero
fdo#92761
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
correct GPC
Each GPCCS unit was reading the mask from GPC0, which causes problems on
boards where some GPCs are missing PPCs.
Part of the fix for fdo#92761.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There's a few places where we need to access a GPC register from ucode,
but outside of the falcon's io address space. To do this we need to
calculate the offset based on which GPC we're executing on.
This used to be done manually, but we've since found a "base" offset
that can be added by the hardware. To use this, an extra bit needs to
be set in the register address, which is what this macro achieves.
There should be no functional change from this commit.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Fixes detection of a failed attempt at fetching the entire ROM image
in one-shot (a violation of the spec, that works a lot of the time).
Tested on a HP Zbook 15 G2.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
