commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many
vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core
more fragile to drivers which don't update hw vblank counters and
vblank timestamps in sync with firing of the vblank irq and
essentially at leading edge of vblank.
This exposed a problem with radeon-kms/amdgpu-kms which do not
satisfy above requirements:
The vblank irq fires a few scanlines before start of vblank, but
programmed pageflips complete at start of vblank and
vblank timestamps update at start of vblank, whereas the
hw vblank counter increments only later, at start of vsync.
This leads to problems like off by one errors for vblank counter
updates, vblank counters apparently going backwards or vblank
timestamps apparently having time going backwards. The net result
is stuttering of graphics in games, or little hangs, as well as
total failure of timing sensitive applications.
See bug #93147 for an example of the regression on Linux 4.4-rc:
https://bugs.freedesktop.org/show_bug.cgi?id=93147
This patch tries to align all above events better from the
viewpoint of the drm core / of external callers to fix the problem:
1. The apparent start of vblank is shifted a few scanlines earlier,
so the vblank irq now always happens after start of this extended
vblank interval and thereby drm_update_vblank_count() always samples
the updated vblank count and timestamp of the new vblank interval.
To achieve this, the reporting of scanout positions by
radeon_get_crtc_scanoutpos() now operates as if the vblank starts
radeon_crtc->lb_vblank_lead_lines before the real start of the hw
vblank interval. This means that the vblank timestamps which are based
on these scanout positions will now update at this earlier start of
vblank.
2. The driver->get_vblank_counter() function will bump the returned
vblank count as read from the hw by +1 if the query happens after
the shifted earlier start of the vblank, but before the real hw increment
at start of vsync, so the counter appears to increment at start of vblank
in sync with the timestamp update.
3. Calls from vblank irq-context and regular non-irq calls are now
treated identical, always simulating the shifted vblank start, to
avoid inconsistent results for queries happening from vblank irq vs.
happening from drm_vblank_enable() or vblank_disable_fn().
4. The radeon_flip_work_func will delay mmio programming a pageflip until
the start of the real vblank iff it happens to execute inside the shifted
earlier start of the vblank, so pageflips now also appear to execute at
start of the shifted vblank, in sync with vblank counter and timestamp
updates. This to avoid some races between updates of vblank count and
timestamps that are used for swap scheduling and pageflip execution which
could cause pageflips to execute before the scheduled target vblank.
The lb_vblank_lead_lines "fudge" value is calculated as the size of
the display controllers line buffer in scanlines for the given video
mode: Vblank irq's are triggered by the line buffer logic when the line
buffer refill for a video frame ends, ie. when the line buffer source read
position enters the hw vblank. This means that a vblank irq could fire at
most as many scanlines before the current reported scanout position of the
crtc timing generator as the number of scanlines the line buffer can
maximally hold for a given video mode.
This patch has been successfully tested on a RV730 card with DCE-3 display
engine and on a evergreen card with DCE-4 display engine, in single-display
and dual-display configuration, with different video modes.
A similar patch is needed for amdgpu-kms to fix the same problem.
Limitations:
- Line buffer sizes in pixels are hard-coded on < DCE-4 to a value
i just guessed to be high enough to work ok, lacking info on the true
sizes atm.
Fixes: fdo#93147
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
(v1) Tested-by: Dave Witbrodt <dawitbro@sbcglobal.net>
(v2) Refine radeon_flip_work_func() for better efficiency:
In radeon_flip_work_func, replace the busy waiting udelay(5)
with event lock held by a more performance and energy efficient
usleep_range() until at least predicted true start of hw vblank,
with some slack for scheduler happiness. Release the event lock
during waits to not delay other outputs in doing their stuff, as
the waiting can last up to 200 usecs in some cases.
Retested on DCE-3 and DCE-4 to verify it still works nicely.
(v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DP audio is derived from the dfs clock.
Signed-off-by: Slava Grigorev <slava.grigorev@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This avoids allocating it on the fly.
v2: fix grammar in comment
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
This way we avoid the extra allocation for the page directory entry.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
They share the reservation object with the page directory anyway.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
In some cases the amount of vram may be less than the BAR size,
if so, limit visible vram to the amount of actual vram, not the
BAR size.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Change the default scheduler queue size from 16 to 32.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
umd somtimes will create a context for every ring,
that means some entities wouldn't be used at all.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Otherwise FW cannot see the RLC ACK for the memory clean request
It's for Stoney.
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
there is a protection fault about freed list when OCL test.
add a spin lock to protect it.
v2: drop changes in vm_fini
Signed-off-by: JimQu <jim.qu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
As soon as we leave the spinlock after the job has been added to the job
queue, we can no longer rely on the job's data to be available.
I have seen a null-pointer dereference due to sched == NULL in
amd_sched_wakeup via amd_sched_entity_push_job and
amd_sched_ib_submit_kernel_helper. Since the latter initializes
sched_job->sched with the address of the ring scheduler, which is
guaranteed to be non-NULL, this race appears to be a likely culprit.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=93079
Reviewed-by: Christian König <christian.koenig@amd.com>
Missing error check if the operation failed.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Simplified the function by folding the two paths into one.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Simplification of the function gfx_v8_0_create_bitmask().
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Simplification and LOC reduction of function gfx_v8_0_tiling_mode_table_init()
v2: remove spurious break
bug: https://bugs.freedesktop.org/show_bug.cgi?id=93236
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Allows us to set priorities in the scheduler.
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
This adds EDC support for CZ.
EDC = Error Correction and Detection
This code properly initializes the EDC hardware and
resets the error counts. This is done in late_init
since it requires the IB pool which is not initialized
during hw_init.
v2: fix the IB size as noted by Felix, fix shader pgm
register programming
v3: use the IB for the shaders as suggested by Christian
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
EDC is a RAS feature for on chip memory.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with
commit ef4c6270bf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 15 09:36:25 2015 +0200
drm/gem: Check locking in drm_gem_object_unreference
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict with
commit ef4c6270bf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 15 09:36:25 2015 +0200
drm/gem: Check locking in drm_gem_object_unreference
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Read the vbios directly from the rom. In some cases,
e.g., virtualization, the rom is not available via
the BAR or other means. Access it directly.
This is an updated version of Monks original patch which
uses family specific callbacks and unifies some of the
validation checking.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Monk Liu <Monk.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Read the vbios image directly from the rom.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu <monk.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Read the vbios image directly from the rom.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu <monk.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is necessary when the vbios image is not directly accessible via
the rom BAR or legacy vga location.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Monk Liu <monk.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The radeon_asic_ring structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This can solve the path problem when compile amdgpu with DKMS.
v2: agd: rebase on current drm-next
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
It's been deprecated behind a kconfig option for almost
two years and hasn't really been supported for years before
that. DDX support was dropped more than three years ago.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
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
...
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
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
"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
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>
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>
No locking is required for the traversal of this list, as it only
happens during suspend/resume where nothing else can be executing.
Fixes some of the issues noticed during parallel piglit runs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.
v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's an internal of the probe
helpers), or calling ->detect (which is again a layering violation
since it's used only by probe helpers) just call the official
->fill_modes function, like a GET_CONNECTOR ioctl call.
v3: Restore the accidentally removed forced-probe for echo "detect" >
force.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447951610-12622-22-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the correct function name for drm_atomic_clean_old_fb docs.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We chase pointers/lists without taking the locks protecting them,
which isn't that good.
Fix it.
v2: Actually unlock properly, spotted by Julia.
v3: Put the label _before_ the mutex_unlock (Emil)
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Link: http://patchwork.freedesktop.org/patch/msgid/1443783662-23066-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To aid in debugging failures, print the src,dst,clip rectangles
when drm_plane_helper_check_update() fails.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtouint.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I noticed that intel_fbdev->our_mode is unused. Introduced by
79e539453b ("DRM: i915: add mode setting support").
Then I noticed that intel_fbdev->fbdev_list is unused as well.
Introduced by 386516744b ("drm/fb: fix fbdev object model +
cleanup properly.") in i915, nouveau and radeon.
Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl,
virtio and mgag200.
Already removed from the latter with cc59487a05 ("drm/mgag200:
'fbdev_list' in 'struct mga_fbdev' is not used").
Remove it from the others.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm_property_unreference_blob() function tests whether its argument
is NULL and then returns immediately.
Thus the tests around the calls are not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: http://patchwork.freedesktop.org/patch/msgid/563C8B3E.405@users.sourceforge.net
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-4-git-send-email-architt@codeaurora.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev
emulation for the imx kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option where applicable. Using this config lets us also prevent
wrapping around drm_fb_helper_* calls with #ifdefs in certain places.
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1445933459-5249-2-git-send-email-architt@codeaurora.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A bunch of things have been removed meanwhile and docs not fully
brought up to speed. And a few gaps closed where I noticed missing
kerneldoc while reading through the overview sections.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445533889-7661-3-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This way the driver isn't limited in the dependency handling callback.
v2: remove extra check in amd_sched_entity_pop_job()
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
We only need to wait for jobs to be scheduled when
the dependency is from the same scheduler.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWUmHZAAoJEHm+PkMAQRiGHtcH/RVRsn8re0WdRWYaTr9+Hknm
CGlRJN4LKecttgYQ/2bS1QsDbt8usDPBiiYVopqGXQxPBmjyDAqPjsa+8VzCaVc6
WA+9LDB+PcW28lD6BO+qSZCOAm7hHSZq7dtw9x658IqO+mI2mVeCybsAyunw2iWi
Kf5q90wq6tIBXuT8YH9MXGrSCQw00NclbYeYwB9CmCt9hT/koEFBdl7uFUFitB+Q
GSPTz5fXhgc5Lms85n7flZlrVKoQKmtDQe4/DvKZm+SjsATHU9ru89OxDBdS5gSG
YcEIM4zc9tMjhs3GC9t6WXf6iFOdctum8HOhUoIN/+LVfeOMRRwAhRVqtGJ//Xw=
=DCUg
-----END PGP SIGNATURE-----
Merge tag 'v4.4-rc2' into drm-intel-next-queued
Linux 4.4-rc2
Backmerge to get at
commit 1b0e3a049e
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Nov 5 23:04:11 2015 +0200
drm/i915/skl: disable display side power well support for now
so that we can proplery re-eanble skl power wells in -next.
Conflicts are just adjacent lines changed, except for intel_fbdev.c
where we need to interleave the changs. Nothing nefarious.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
There are platforms that don't need the full GMBUS power domain (BXT)
while others do (PCH, VLV/CHV). For optimizing this we would need to add
a new power domain, but it's not clear how much we would benefit given
the short time we hold the reference. So for now let's keep things
simple.
v2:
- fix commit message, PCH won't take any redundant power resource after
this change (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[fix commit message in v2 (Imre)]
Link: http://patchwork.freedesktop.org/patch/msgid/1447959301-1263-2-git-send-email-imre.deak@intel.com
i915 fixes for 4.4, including the revert for the backlight regression
Olof reported. Otherwise fixes all around.
* tag 'drm-intel-fixes-2015-11-19' of git://anongit.freedesktop.org/drm-intel:
Revert "drm/i915: skip modeset if compatible for everyone."
drm/i915: Consider SPLL as another shared pll, v2.
drm/i915: Fix gpu frequency change tracing
drm/i915: Don't clobber the addfb2 ioctl params
drm/i915: Clear intel_crtc->atomic before updating it.
drm/i915: get runtime PM reference around GEM set_caching IOCTL
drm/i915: Fix GT frequency rounding
drm/i915: quirk backlight present on Macbook 4, 1
drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()
Here are some drm core fixes for v4.4 that I've picked up. Atomic fixes
from Maarten, and atomic helper fixes from Ville and Daniel.
Admittedly the topmost commit didn't sit in our tree for very long, but
does come with reviews and testing from trustworthy people.
* tag 'topic/drm-fixes-2015-11-19' of git://anongit.freedesktop.org/drm-intel:
drm/atomic-helper: Check encoder/crtc constraints
drm: Fix primary plane size for stereo doubled modes for legacy setcrtc
drm/core: Fix old_fb handling in pan_display_atomic.
drm/core: Fix old_fb handling in restore_fbdev_mode_atomic.
drm/atomic: add a drm_atomic_clean_old_fb helper.
drm/core: Fix old_fb handling in drm_mode_atomic_ioctl.
drm/core: Set legacy_cursor_update in drm_atomic_helper_disable_plane.
Currently if intelfb_create() errors out, it unrefs the bo even though
the fb now owns that reference. (Spotted by Ville Syrjälä.) We should
unref the fb instead of the bo.
However the fb was not necessarily allocated by intelfb_create(),
it could be inherited from BIOS (the fb struct was then allocated by
dev_priv->display.get_initial_plane_config()) and be in active use by
a crtc. In this case we should call drm_framebuffer_remove() instead
of _unreference() to also disable the crtc.
Daniel Vetter suggested that "fbdev teardown code will take care of it.
The correct approach is probably to not unref anything at all".
But if fbdev initialization fails, the fbdev isn't torn down and
occupies memory even though it's unusable. Therefore clobber it in
intel_fbdev_initial_config(). (Currently we ignore a negative return
value there.) The idea is that if fbdev initialization fails, the driver
behaves as if CONFIG_DRM_FBDEV_EMULATION wasn't set. Should X11 manage
to start up without errors, it will at least be able to use the memory
that would otherwise be hogged by the unusable fbdev.
Also, log errors in intelfb_create().
Don't call async_synchronize_full() in intel_fbdev_fini() when called
from intel_fbdev_initial_config() to avoid deadlock.
v2: Instead of calling drm_framebuffer_unreference() (if fb was not
inherited from BIOS), call intel_fbdev_fini().
v3: Rebase on e00bf69644 (drm/i915: Move the fbdev async_schedule()
into intel_fbdev.c), call async_synchronize_full() conditionally
instead of moving it into i915_driver_unload().
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/49ce5f0daead24b7598ec78591731046c333c18d.1447938059.git.lukas@wunner.de
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 2e5356da37.
It is now redundant as it is already covered in below commit which introduced
the changes to reuse initialization of resources in resume/reset path.
commit e84fe80337
Author: Nick Hoath <nicholas.hoath@intel.com>
Date: Fri Sep 11 12:53:46 2015 +0100
drm/i915: Split alloc from init for lrc
lrc_setup_hardware_status_page() in the same function gen8_init_common_ring()
takes care of this.
Cc: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447951664-9347-1-git-send-email-arun.siluvery@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intelfb_create() is called once on driver initialization. If it fails,
ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be NULL.
Further up in the call stack, intel_fbdev_initial_config() calls
intel_fbdev_fini() to tear down the ifbdev on failure. This calls
intel_fbdev_destroy() which dereferences ifbdev->fb. Fix the ensuing
oops.
Also check in these functions if ifbdev is not NULL to avoid oops:
i915_gem_framebuffer_info() is called on access to debugfs file
"i915_gem_framebuffer" and dereferences ifbdev, ifbdev->helper.fb
and ifbdev->helper.fb->obj.
intel_connector_add_to_fbdev() / intel_connector_remove_from_fbdev()
are called when registering / unregistering an mst connector and
dereference ifbdev.
v3: Drop additional null pointer checks in intel_fbdev_set_suspend(),
intel_fbdev_output_poll_changed() and intel_fbdev_restore_mode()
since they already check if ifbdev is not NULL, which is sufficient
now that intel_fbdev_fini() is called on initialization failure.
(Requested by Daniel Vetter <daniel.vetter@ffwll.ch>)
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/d05f0edf121264a9d0adb8ca713fd8cc4ae068bf.1447938059.git.lukas@wunner.de
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The rotated view depends upon the rotation paramters, but thus far we
didn't bother checking for those. This seems to have been an issue
ever since this was introduce in
commit fe14d5f4e5
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Wed Dec 10 17:27:58 2014 +0000
drm/i915: Infrastructure for supporting different GGTT views per object
But userspace is allowed to reuse framebuffer backing storage with
different framebuffers with different pixel formats/stride/whatever.
And e.g. SNA indeed does this. Hence we must check for all the
paramters to match, not just that it's rotated.
v2: intel_plane_obj_offset also needs to construct the full view, to
avoid fallout since they don't fully match.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444834266-12689-3-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't need 2 separate unions.
Note that this was done intentinoally
Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Date: Wed May 6 14:35:38 2015 +0300
drm/i915: Add a partial GGTT view type
on Tvrtko's request, but without a clear justification. Rotated views
are also not checking for matching paramters in i915_ggtt_view_equal,
which seems like a bug. But this patch here doesn't change that.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444834266-12689-2-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It can't fail and there's even a WARN_ON suggesting that if it would,
it would be a disaster.
Correct this to make things less confusing.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444834266-12689-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was totally lost when I originally created the atomic helpers.
We probably should also check possible_clones in the helpers, but
since the legacy ones didn't do that this is for a separate patch.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447868808-10266-1-git-send-email-daniel.vetter@ffwll.ch
This reverts
commit 6764e9f872
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Thu Aug 27 15:44:06 2015 +0200
drm/i915: skip modeset if compatible for everyone.
Bring back the i915.fastboot module parameter, disabled by default, due
to backlight regression on Chromebook Pixel 2015.
Apparently the firmware of the Chromebook in question enables the panel
but disables backlight to avoid a brief garbage scanout upon loading the
kernel/module. With fastboot, we leave the backlight untouched, in this
case disabled. The user would have to do a modeset (i.e. not just crank
up the brightness) to enable the backlight.
There is no clean fix readily available, so get back to the drawing
board by reverting.
[N.B. The reference below is for when the thread was included on public
lists, and some of the context had already been dropped by then.]
Reported-and-tested-by: Olof Johansson <olof@lixom.net>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: http://marc.info/?i=CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6T+fGK9J3X7cQ@mail.gmail.com
Fixes: 6764e9f872 ("drm/i915: skip modeset if compatible for everyone.")
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447921590-3785-1-git-send-email-jani.nikula@intel.com
Here are a few little VC4 fixes for 4.4 that I didn't get in to you
before the -next pull request. I dropped the feature-ish one I'd
mentioned, and also droppped the one I saw you included in the last
-fixes pull request.
* 'drm-vc4-fixes' of git://github.com/anholt/linux:
drm/vc4: Make sure that planes aren't scaled.
drm/vc4: Fix some failure to track __iomem decorations on pointers.
drm/vc4: checking for NULL instead of IS_ERR
drm/vc4: fix itnull.cocci warnings
drm/vc4: fix platform_no_drv_owner.cocci warnings
drm/vc4: vc4_plane_duplicate_state() can be static
Radeon and amdgpu fixes for 4.4. A bit more the usual since I missed
last week. Misc fixes all over the place. The big changes are the
tiling configuration fixes for Fiji.
* 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux: (35 commits)
drm/amdgpu: reserve/unreserve objects out of map/unmap operations
drm/amdgpu: move bo_reserve out of amdgpu_vm_clear_bo
drm/amdgpu: add lock for interval tree in vm
drm/amdgpu: keep the owner for VMIDs
drm/amdgpu: move VM manager clean into the VM code again
drm/amdgpu: cleanup VM coding style
drm/amdgpu: remove unused VM manager field
drm/amdgpu: cleanup scheduler command submission
drm/amdgpu: fix typo in firmware name
drm/amdgpu: remove the unnecessary parameter adev for amdgpu_sa_bo_new()
drm/amdgpu: wait interruptible when semaphores are disabled v2
drm/amdgpu: update pd while updating vm as well
drm/amdgpu: fix handling order in scheduler CS
drm/amdgpu: fix incorrect mutex usage v3
drm/amdgpu: cleanup scheduler fence get/put dance
drm/amdgpu: add command submission workflow tracepoint
drm/amdgpu: update Fiji's tiling mode table
drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.
drm/amdgpu: fix seq_printf format string
drm/radeon: fix quirk for MSI R7 370 Armor 2X
...
MISSING_CASE() would have been useful to track down a recent problem in
intel_display_port_aux_power_domain(), so add it there and a few related
helpers. This was also suggested by Ville in his review of the latest
DMC/DC changes, we forgot to address that.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447855045-7109-2-git-send-email-imre.deak@intel.com
Due to the current sharing of the DDI encoder between DP and HDMI
connectors we can run the DP detection after the HDMI detection has
already set the shared encoder's type. For now solve this keeping the
current behavior and running the detection in this case too. For a proper
solution Ville suggested to split the encoder into an HDMI and DP one, that
can be done as a follow-up.
This issue triggers the WARN in intel_display_port_aux_power_domain() and
was introduced in:
commit 25f78f58e5
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Nov 16 15:01:04 2015 +0100
drm/i915: Clean up AUX power domain handling
CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447855045-7109-1-git-send-email-imre.deak@intel.com
Change-Id: Id6514f2fb6e002437fdbe99353d5d35f4ac736c7
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Change-Id: Ifbb0c06680494bfa04d0be5e5941d31ae2e5ef28
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Change-Id: I62b892a22af37b32e6b4aefca80a25cf45426ed2
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
We don't need the last VM use any more, keep the owner directly.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <davdi1.zhou@amd.com>
It's not a good idea to duplicate that code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <davdi1.zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Fix the indentation and move the VM functions to the structures.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <davdi1.zhou@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Unify the two code path again, cause they do pretty much the same thing.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <davdi1.zhou@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
That call was moved to intel_dp_detect() in
commit d410b56d74
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Sep 2 20:03:59 2014 +0100
drm/i915/dp: Refactor common eDP lid detection
but it seem to have been resurrected in the following commit, probably
due to a wrong merge conflict resolution.
commit 2a592bec50
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Sep 1 16:58:12 2014 +1000
drm/i915: handle G45/GM45 pulse detection connected state.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447859970-9546-1-git-send-email-ander.conselvan.de.oliveira@intel.com
On the commit 3301d40921 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic")'
we already had identified that DP_PSR_NO_TRAIN_ON_EXIT
doesn't mean we shouldn't send TPS patterns, however we start sending the
minimal TP1 as possible and no TP2.
For most of the panels this is ok, but we found a reported case where
this is not true and panel keeps frozen without updating the screen for a while.
We could just get this case after patch "PSR: Don't Skip aux handshake on
DP_PSR_NO_TRAIN_ON_EXIT." is applied since that one fix the
hard freeze on this kind of panels.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436#c19
Cc: Ivan Mitev <ivan.mitev@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the beginning there is a confusion on the meaning of this bit.
A previous patch had identified this already and fixed it partially:
'commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic")
DP_PSR_NO_TRAIN_ON_EXIT means the source doesn't need to do the
training, but it doesn't tell to avoid TP patterns or to skip
aux handshake.
This patch fixes the hard freeze reported.
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91437
Cc: Ivan Mitev <ivan.mitev@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With 'commit 30886c5a ("drm/i915: VLV/CHV PSR: Increase wait delay
time before active PSR.")' we fixed a blank screen when first
activation was happening immediately after PSR being enabled.
There we gave more time for idleness by increasing the delay
between re-activating sequences.
However, commit "drm/i915: Delay first PSR activation."
delay the first activation in a better way keeping a good PSR
residency. So, we can now reduce the delay on re-enable.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When debuging the frozen screen caused by HW tracking with low
power state I noticed that if we keep moving the mouse non stop
you will miss the screen updates for a while. At least
until we stop moving the mouse for a small time and move again.
The actual enabling should happen immediately after
Display Port enabling sequence finished with links trained and
everything enabled. However we face many issues when enabling PSR
right after a modeset.
On VLV/CHV we face blank screens on this scenario and on HSW+
we face a recoverable frozen screen, at least until next
exit-activate sequence.
Another workaround for the same issue here would be to increase
re-enable idle time from 100 to 500 as we did for VLV/CHV.
However this patch workaround this issue in a better
way since it doesn't reduce PSR residency and also
allow us to reduce the delay time between re-enables at least
on VLV/CHV.
This is also important to make the sysfs toggle working properly.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
When diagnosing a unrelated bug for someone on irc, it would seem the hardware can
be brought up by the BIOS with the embedded displayport using the SPLL for spread spectrum.
Right now this is not handled well in i915, and it calculates the crtc needs to
be reprogrammed on the first modeset without SSC, but the SPLL itself was kept
active. Fix this by exposing SPLL as a shared pll that will not be returned
by intel_get_shared_dpll; you have to know it exists to use it.
Changes since v1:
- Create a separate dpll_hw_state.spll for spll, and use
separate pll functions for spll.
Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Gabriel Feceoru <gabriel.feceoru@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447681332-6318-1-git-send-email-maarten.lankhorst@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add 'u32 offset' to the uncore register access functions. For now
it's the same as 'reg', but once type safety gets added 'reg' will be
the type safe register variable and 'offset' the raw offset.
v2: s/uint32_t/u32/ (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446839236-20035-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
I need to add a new variable into GEN6_{READ,WRITE}_HEADER, but the vgpu
won't need it, so let's avoid an unused variable warning by splitting
the vgpu stuff to use its own macros.
Cc: Eddie Dong <eddie.dong@intel.com>
Cc: Jike Song <jike.song@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-26-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
We'll want to avoid performing arithmetic with register offsets, so
instead calculating the vgpu PDP as pdp0_lo+offset, make the PDPs
into an array. This way we can simply loop through them.
Cc: Eddie Dong <eddie.dong@intel.com>
Cc: Jike Song <jike.song@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Yu Zhang <yu.c.zhang@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-25-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Zhiyuan Lv <zhiyuan.lv@intel.com>
We set up a load of LRIs in the logical ring context. Wrap that stuff
in a macro to avoid typos with position of each reg/value pair in the
context. This also makes it easier to make the register defines type
safe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-24-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When register type safety happens, we can't just try to emit the
register itself to the ring. Instead we'll need to extract the
offset from it first. Add some convenience functions that will do
that.
v2: Convert MOCS setup too
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-20-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Store the upper dword of the register offset in the whitelist as well.
This would allow it to read register where the two halves aren't sitting
right next to each other, and it'll make it easier to make register
access type safe.
While at it change the register offsets to u32 from u64. Our register
space isn't quite that big, yet :)
v2: Use ldw/udw as the suffixes, and add a note about
64bit wide split regs (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446839021-18599-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Most of our register defines follow the convention that if there's a
need for the raw register offset, that one has an underscore sa a
prefix. The define (possibly parametrized) without the underscore is
the one people should normally use, since it will take into account
all the parameters and other potential offsets that are needed.
Fix up the few stragglers that don't follow this convention.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-14-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
If we ignore the BXT situation, we can observe that the only variables
affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT
situation we can fit into the same pattern if we change gmbus_pins_bxt[]
to house the GMCH GPIO register offsets (like we do for all other
platfotms). So let's do that.
We could even simplify the VLV situation more by including the
display_mmio_offset in the GPIO register defines, but let's leave it be
for now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-13-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store the DVO SRCDIM register offset alongside the DVO control register
offset in intel_dvo_device. This gets rid of the switch statement whose
case values are the DVO control register offsets. Such a construct would
cause problems for register type safety.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-12-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Replace the is_sdvob bool and some sdvo_reg checks with enum port. This
makes the SDVO code look more modern, and gets rid of explicit register
offset checks in the code which will hamper register type checking.
v2: Add assert_sdvo_port_valid() (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1446838199-3666-1-git-send-email-ville.syrjala@linux.intel.com
It was created at 'commit aabc95dcf2 (drm/i915: Dont -ETIMEDOUT
on identical new and previous (count, crc).")' becase the counter
wasn't reliable.
Now that we properly wait for the counter to be reset we can rely
a bit more in the counter.
Also that patch stopped to return -ETIMEDOUT so the test case is
unable to skip when it is unreliable and end up in many fails
that should be skip instead.
So, with the counter more reliable we can remove
this hack that just makes things more confusing when test cases
are really expecting the same CRC and let test case skip if that's
not the case.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to VESA DP spec TEST_CRC_COUNT (Bits 3:0) at
TEST_SINK_MISC (00246h) is "Reset to 0 when TEST_SINK bit 0 = 0;
So let's give few vblanks so we are really sure that this counter
is really zeroed on the next sink_crc read.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to VESA DP Spec, setting TEST_SINK_START (bit 0)
of TEST_SINK (00270h) "Stop/Start calculating CRC on the next frame"
So let's wait at least 1 vblank to really say the calculation
stopped or started.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With gen < 9 we have had always 50Mhz units as our hw
ratio. With gen >= 9 the hw ratio changed to 16.667Mhz (50/3).
The result was that our gpu frequency tracing started to output
values 3 times larger than expected due to hardcoded scaling
value. Fix this by using Use intel_gpu_freq() when generating Mhz
value from ratio for 'intel_gpu_freq_change' trace event.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92591
Cc: stable@vger.kernel.org # v4.3+
Reported-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447776866-29384-1-git-send-email-mika.kuoppala@intel.com
We would scan out the memory around them if an upscale was attempted,
and would just scan out incorrectly for downscaling.
Signed-off-by: Eric Anholt <eric@anholt.net>
vc4_plane_init() returns an ERR_PTR on error, it doesn't return NULL.
This was obviously intended because the next lines call
PTR_ERR(primary_plane) already.
Fixes: c8b75bca92 ('Eric Anholt <eric@anholt.net>')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Connector cannot be null because it is a list entry, ie accessed at an
offset from the positions of the list structure pointers themselves.
Generated by: scripts/coccinelle/iterators/itnull.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
drivers/gpu/drm/vc4/vc4_drv.c:248:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
Handle DC off as a power well where enabling the power well will prevent
the DMC to enter selected DC states (required around modesets and Aux
A). Disabling the power well will allow DC states again. For now the
highest DC state is DC6 for Skylake and DC5 for Broxton but will be
configurable for Skylake in a later patch.
v2: Check both DC5 and DC6 bits in power well enabled function (Ville)
v3:
- Remove unneeded DC_OFF case in skl_set_power_well() (Imre)
- Add PW2 dependency to DC_OFF (Imre)
v4: Put DC_OFF before PW2 in BXT power well array
Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[fixed line over 80 and parenthesis alignment checkpatch warns (imre)]
Link: http://patchwork.freedesktop.org/patch/msgid/1447687201-24759-1-git-send-email-patrik.jakobsson@linux.intel.com
PG2 enabled is not a requirement for disabling DC5. It's just one
of the reasons why the DMC wouldn't enter DC5. During modeset we don't
care about PG2 from a DC perspective, only the fact that DC5/DC6 is not
allowed.
Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-9-git-send-email-patrik.jakobsson@linux.intel.com
All the DDI power domains are already excluded from
SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS on account of
excluding SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS and
SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS, no need to spell them out again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-6-git-send-email-patrik.jakobsson@linux.intel.com
Currently the gmbus code uses intel_aux_display_runtime_get/put in an
effort to make sure the hardware is powered up sufficiently for gmbus.
That function only takes the runtime PM reference which on VLV/CHV/BXT
is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well
2 on BXT. So add a new power domnain for gmbus and kill off the now
unused intel_aux_display_runtime_get/put. And change
intel_hdmi_set_edid() to use the gmbus power domain too since that's all
we need there.
Also toss in a BUILD_BUG_ON() to catch problems if we run out of
bits for power domains. We're already really close to the limit...
[Patrik: Add gmbus string to debugfs output]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
Introduce intel_display_port_aux_power_domain() which simply returns
the appropriate AUX power domain for a specific port, and then replace
the intel_display_port_power_domain() with calls to the new function
in the DP code. As long as we're not actually enabling the port we don't
need the lane power domains, and those are handled now purely from
modeset_update_crtc_power_domains().
My initial motivation for this was to see if I could keep the DPIO power
wells powered down while doing AUX on CHV, but turns out I can't so this
doesn't change anything for CHV at least. But I think it's still a
worthwile change.
v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447682467-6237-1-git-send-email-patrik.jakobsson@linux.intel.com
Mario Kleiner