These are the patches from Daniel Vetter, getting rid of struct_mutex
from the Armada DRM driver.
* 'drm-armada-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/armada: use a private mutex to protect priv->linear
drm/armada: drop struct_mutex from cursor paths
drm/armada: don't grab dev->struct_mutex for in mmap offset ioctl
drm/armada: plug leak in dumb_map_offset
drm/armada: use unlocked gem unreferencing
There was a silent conflict between
commit 0a87871626
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 15 14:23:01 2015 +0200
drm/i915: restore ggtt double-bind avoidance
and
commit 5bab6f60cb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Oct 23 18:43:32 2015 +0100
drm/i915: Serialise updates to GGTT with access through GGTT on Braswell
thankfully caught by the extra WARN safegaurd in 0a878716. Since we now
override the GGTT insert_pages callback when installing the aliasing
ppgtt, we assert that the callback is the original ggtt routine.
However, on Braswell we now use a different insertion routine to
serialise access through the GGTT with updating the PTE and hence the
conflict. To avoid the conflict, move the custom insertion routine for
Braswell down a level.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447859979-20107-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit c140330b5e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms delay.
v2:
- straight up to loop execution for more clear in code readability
- mdelay will replace with msleep by Daniel's new patch
drm/i915: mdelay(10) considered harmful
- suggest to re-evaluate try times for being compatible to old HDMI monitor
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Tested-by: Gary Wang <gary.c.wang@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Gavin Hindman <gavin.hindman@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Gary Wang <gary.c.wang@intel.com>
[danvet: fixup conflict with s/mdelay/msleep/ patch.]
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 61fb3980dd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I missed this myself when reviewing
commit 237ed86c69
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
Long sleeps like this really shouldn't waste cpu cycles spinning.
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: "Wang, Gary C" <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 71a199bacb)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other uses thanks to universal plane support.
Chris pointed out that cursor updates are currently too slow
via universal planes that micro optimizations like these wouldn't
even help.
v2: Add a note about futility of micro optimizations (Chris)
Cc: drm-intel-fixes@lists.freedesktop.org
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 1264859d64)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Turns out CHV pipe C was glued on somewhat poorly, and there's something
wrong with the cursor. If the cursor straddles the left screen edge,
and is then moved away from the edge or disabled, the pipe will often
underrun. If enough underruns are triggered quickly enough the pipe
will fall over and die (it just scans out a solid color and reports
a constant underrun). We need to turn the disp2d power well off and
on again to recover the pipe.
None of that is very nice for the user, so let's just refuse to place
the cursor in the compromised position. The ddx appears to fall back
to swcursor when the ioctl returns an error, so theoretically there's
no loss of functionality for the user (discounting swcursor bugs).
I suppose most cursors images actually have the hotspot not exactly
at 0,0 so under typical conditions the fallback will in fact kick in
as soon as the cursor touches the left edge of the screen.
Any atomic compositor should anyway be prepared to fall back to
GPU composition when things don't work out, so there should be no
problem with those.
Other things that I tried to solve this include flipping all
display related clock gating knobs I could find, increasing the
minimum gtt alignment all the way up to 512k. I also tried to see
if there are more specific screen coordinates that hit the bug, but
the findings were somewhat inconclusive. Sometimes the failures
happen almost across the whole left edge, sometimes more at the very
top and around the bottom half. I wasn't able to find any real pattern
to these variations, so it seems our only choice is to just refuse
to straddle the left screen edge at all.
Cc: stable@vger.kernel.org
Cc: Jason Plum <max@warheads.net>
Testcase: igt/kms_chv_cursor_fail
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit b29ec92c4f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.
v2: Check for logical inversion when rebasing - we were incorrectly
checking for this request being active, and instead busywaiting for
when the GPU was not yet processing the request of interest.
v3: Try another colour for the seqno names.
v4: Another colour for the function names.
v5: Remove the forced coherency when checking for the active request. On
reflection and plenty of recent experimentation, the issue is not a
cache coherency problem - but an irq/seqno ordering problem (timing issue).
Here, we do not need the w/a to force ordering of the read with an
interrupt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk
(cherry picked from commit 821485dc2a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as possible. However, if it is a slow
request, we want to sleep as quickly as possible. The tradeoff between
waiting and sleeping is roughly the time it takes to sleep on a request,
on the order of a microsecond. Based on measurements of synchronous
workloads from across big core and little atom, I have set the limit for
busywaiting as 10 microseconds. In most of the synchronous cases, we can
reduce the limit down to as little as 2 miscroseconds, but that leaves
quite a few test cases regressing by factors of 3 and more.
The code currently uses the jiffie clock, but that is far too coarse (on
the order of 10 milliseconds) and results in poor interactivity as the
CPU ends up being hogged by slow requests. To get microsecond resolution
we need to use a high resolution timer. The cheapest of which is polling
local_clock(), but that is only valid on the same CPU. If we switch CPUs
because the task was preempted, we can also use that as an indicator that
the system is too busy to waste cycles on spinning and we should sleep
instead.
__i915_spin_request was introduced in
commit 2def4ad99b [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
so we can use native register sizes on smaller architectures. Mention
the approximate microseconds units for elapsed time and add some extra
comments describing the reason for busywaiting.
v3: Raise the limit to 10us
v4: Now 5us.
Reported-by: Jens Axboe <axboe@kernel.dk>
Link: https://lkml.org/lkml/2015/11/12/621
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk
(cherry picked from commit ca5b721e23)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.
In the worst case this could cause a delay in signal processing of 20ms,
which would be a noticeable jitter in cursor tracking. If a higher
resolution signal was being used, for example to provide fairness of a
server timeslices between clients, we could expect to detect some
unfairness between clients (i.e. some windows not updating as fast as
others). This issue was noticed when inspecting a report of poor
interactivity resulting from excessively high __i915_spin_request usage.
Fixes regression from
commit 2def4ad99b [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
v2: Try to assess the impact of the bug
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk
(cherry picked from commit 91b0c352ac)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best solution is to just disable the primary plane and
pretend the BIOS never had it enabled.
v2: Add intel_pre_disable_primary() call (Maarten)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com
(cherry picked from commit 200757f5d7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that later
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1448029000-10616-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit d0710abbcd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The cursor code tries to treat base==0 to mean disabled. That fails
when the cursor bo gets bound at ggtt offset 0, and the user is left
looking at an invisible cursor.
We lose the disabled->disabled optimization, but that seems like
something better handled at a slightly higher level.
Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450091808-32607-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 663f3122d0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I've decided to just send this fixes-for-next pull request now, even if
we don't have a patch for the CONFIG_PM_SLEEP build failure reviewed.
If you like my patch for that, I'd be happy to see it applied directly.
This pull request brings in little fixes from Dan Carpenter for the 3D
support added in this -next cycle.
* tag 'drm-vc4-next-2015-12-21' of http://github.com/anholt/linux:
drm/vc4: fix an error code
drm/vc4: allocate enough memory in vc4_save_hang_state()
drm/vc4: copy_to_user() returns the number of bytes remaining
Some systems have a single fan controlled by ACPI or some other
method.
Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Show GPU load in in the debugfs output.
v2: integrate Tom's optimization
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
In I+A platform(skylake), it is controlled by intel.
v2: integrate Tom's fix
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
To avoid users accessing them before the module has finished
initializing them and make sure they are only created if
dpm has properly initialized.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
in dpm module, sysfs init func move to late_init from sw_init.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Change-Id: Ice4a73212d8e3106d05f04a27043820ffd32929e
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppatomctrl.c:475:10-11: WARNING: return of 0/1 in function 'atomctrl_lookup_gpio_pin' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: yanyang1 <young.yang@amd.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
v2: fix grbm locking
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
v2: fix bug in register mask setting.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
This conflicts with fiji_smumgr.h from powerplay
in DKMS environment
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jordan Lazare <Jordan.Lazare@amd.com>
This conflicts with the tonga_smumgr.h from powerplay
in DKMS environement
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jordan Lazare <Jordan.Lazare@amd.com>
- The macro is silent by default.
- Use the macro to print Display Configuration - related changes.
Signed-off-by: David Rokhvarg <David.Rokhvarg@amd.com>
Removed fiji_mgcg_cgcg_init that is affected and redundant for new implementation.
v2: re-add mgcg_cgcg init
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_hwmgr.c:2653:9-10: WARNING: return of 0/1 in function 'is_pcie_gen2_supported' with return type bool
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_hwmgr.c:2645:9-10: WARNING: return of 0/1 in function 'is_pcie_gen3_supported' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci
CC: yanyang1 <young.yang@amd.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rather than hardcode it.
v2: integrate spc fix from Rex
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rather than hardcode it.
v2: integrate spc fix from Rex
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add a helper to get the max link width of the port.
Similar to the helper to get the max link speed.
v2: fix typo in commit message
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
These will be used by multiple powerplay drivers and
other IP modules.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Better handle power state changes.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Implement the new callbacks for tonga.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Interface between hwmgr and eventmgr.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
The amdgu_powerplay variable is global for multiple GPU instances.
v2: fold in Flora's module option change, protect adev reference in
macros
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Same interface exposed in pre-powerplay dpm code.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Hook up the amdgpu thermal control callbacks for powerplay.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This adds the interface needed to expose powerplay fan control to sysfs
via hwmon.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Implement thermal and fan control for tonga.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add thermal handling to the event manager.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Redefine interrupt callback function in accordance with cgs.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add the interface for fan and thermal control.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Implement clock and power gating support for tonga. On Tonga
this is handles by the SMU rather than direct register settings
in the driver.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add callbacks interface for clock and powergating.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Interface for clock and power gating handling.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Implement displaygap programming for tonga. This is
required for properly mclk switching.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add support for display configuration changes to the event manager.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This allows the eventmgr to properly update the displaygap on
certain power events.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Displaygap support is required for proper mclk switching.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Switch over to handling in the powerplay module.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
This option can be used to enable the new powerplay implementation,
and it is disabled by default.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This enabled DPM support for Fiji. DPM is dynamic
clock and voltage scaling.
v2: rename fiji_hwmgr_early_init to fiji_hwmgr_init
v3: (agd) fold in endian fix, additional function addition
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Add support for the SMU manager for Fiji. This handles the
firmware loading for other IP blocks (GFX, SDMA, etc.).
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Add some new functions to support Fiji. Split out
from the previous patch.
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
This implements DPM for tonga. DPM handles dynamic
clock and voltage scaling.
v2: merge all the patches related with tonga dpm
v3: merge dpm force level fix, cgs display fix, spelling fix
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: yanyang1 <young.yang@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
The SMU manager handles firmware loading for other IP
blocks (GFX, SDMA, etc.). This implements it for Tonga.
v3: delete peci sub-module
v2: use cgs interface directly
Signed-off-by: Young Yang <Young.Yang@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
These headers provide the SMU interface used by the driver.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: yanyang1 <young.yang@amd.com>
Move smu7.h, smu7_discrete.h and smu7_fusion.h from amdgpu to powerplay.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: yanyang1 <young.yang@amd.com>
Add ixSWRST_COMMAND_1 in bif_5_0_d.h. Required by
new powerplay code for tonga and fiji.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: yanyang1 <young.yang@amd.com>
This is the common interface for interacting with the powerplay
module.
v2: squash in fixes
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The event manager handles power related driver events.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This adds clock and powergating support for CZ.
v2: squash in fixes
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This patch enables basic DPM support for Carrizo.
DPM handles dynamic clock and voltage scaling.
v3: delete peci sub-module
v2: use cgs interface directly
correct define SMU_EnabledFeatureScoreboard_SclkDpmOn
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This implements the SMU firmware manager interface for CZ.
Some header files are moved from amdgpu folder to powerplay as well.
v3: delete peci sub-module.
v2: use cgs interface directly
add load_mec_firmware function
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The hwmgr handles all hardware related calls, including clock/power
gating control, DPM, read and parse PPTable, etc.
v5: squash in fixes
v4: implement acpi's atcs function use cgs interface
v3: fix code style error and add big-endian mode support.
v2: use cgs interface directly in hwmgr sub-module
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The SMUMGR is one sub-component of powerplay for SMU firmware support.
The SMU handles firmware loading for other IP blocks (GFX, SDMA, etc.)
on VI parts. The adds the core powerplay infrastructure to handle that.
v3: direct use printk in powerplay module.
v2: direct use cgs_read/write_register functions in smu-modules
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Update amdgpu to deal with the new powerplay module properly.
v2: squash in fixes
v3: squash in Rex's power state reporting fix
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Powerplay will use a different interface once it's integrated. These
legacy pathes will be removed once powerplay is enabled by default.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_pp_ip_funcs is introduced to handle the two code paths,
the legacy one and the new powerplay implementation.
CONFIG_DRM_AMD_POWERPLAY kernel configuration option is
introduced for the powerplay component.
v4: squash in fixes
v3: register debugfs file when powerplay module enable
v2: add amdgpu_ucode_init_bo in hw init when amdgpu_powerplay enable.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add new CGS interfaces to query display info across modules.
This is nedded by the powerplay module for synchronizing with
the display module.
v2: (agd): fold in refresh rate fix, rebase
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Add a new driver internal interface for accessing ACPI
methods. These will be used by various new components
including powerplay.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This will be shared with the new powerplay module.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
These will be shared with the new powerplay module.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
eaddr is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
eoffset is sometimes treated as the last address inside the address
range, and sometimes as the first address outside the range. This
was resulting in errors when a test filled up the entire address
space. Make it consistent to always be the last address within the
range. Also fixed related errors when checking the VA limit and in
radeon_vm_fence_pts.
Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.
v2: simplify logic, add array bounds check
Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to properly handle the max link rate in the dpcd.
This prevents some cases where 5.4 Ghz is selected when
it shouldn't be.
v2: simplify logic, add array bounds check
Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the
legacy FB fields (plane->fb and plane->old_fb). However it was building
the plane mask to pass to this function incorrectly (the bitwise OR was
using plane indices rather than plane masks). The end result was that
sometimes the legacy pointers would become out of sync with the atomic
pointers. If another operation tried to re-set the same FB onto the
plane, we might end up with the pointers back in sync, but improper
reference counts, which would eventually lead to system crashes when we
accessed a pointer to a prematurely-destroyed FB.
The cause here was a very subtle bug introduced in commit:
commit 07d3bad6c1
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Wed Nov 11 11:29:11 2015 +0100
drm/core: Fix old_fb handling in pan_display_atomic.
I found the crashes were most easily reproduced (on i915 at least) by
starting X and then VT switching to a VT that wasn't running a console
instance...the sequence of vt/fbcon entries that happen in that case
trigger a reference count mismatch and crash the system.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since atomic check is called also for disabled crtcs it should skip
mode checking as it can be uninitialized. The patch fixes it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
here is the pull request for the etnaviv DRM driver. It includes the DT bindings
and the driver itself, platform devicetree changes will be merged through the
respective SoC trees. Otherwise it's just a squashed version of the V2 patches
that have been on the list for a while.
* 'drm-etnaviv-next' of git://git.pengutronix.de/git/lst/linux:
MAINTAINERS: add maintainer and reviewers for the etnaviv DRM driver
drm/etnaviv: add initial etnaviv DRM driver
drm/etnaviv: add devicetree bindings
devicetree: add vendor prefix for Vivante Corporation
Seems I lied in my last drm-misc pull request and suddenly there's a big
pile of random stuff. Boris dug out Thierry's drm-trivial branch and
resubmitted everything since that branch didn't really work out.
On top of that Nicolas' changes to drm_dev_set_unique - this might
conflict with new driver pulls (I double checked and current drm-next
should be fine), so please beware. The -next/-fixes conflict in vmwgfx
will change slightly with this here too.
* tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (36 commits)
drm: use dev_name as default unique name in drm_dev_alloc()
drm: make drm_dev_set_unique() not use a format string
drm/vmwgfx: Constify function pointer structs
drm/udl: Constify function pointer structs
drm/tegra: Constify function pointer structs
drm/rockchip: Constify function pointer structs
drm/nouveau: Constify function pointer structs
drm/mgag200: Constify function pointer structs
drm/imx: Constify function pointer structs
drm/i2c/sil164: Constify function pointer structs
drm/i2c/adv7511: Constify function pointer structs
drm/exynos: Constify function pointer structs
drm/cirrus: Constify function pointer structs
drm/i2c/ch7006: Constify function pointer structs
drm/bridge/nxp-ptn3460: Constify function pointer structs
drm/bridge/dw_hdmi: Constify function pointer structs
drm/bochs: Constify function pointer structs
drm/atmel-hlcdc: Constify function pointer structs
drm/armada: Constify function pointer structs
drm: Constify drm_encoder_slave_funcs
...
In the rare situation where the kmalloc fails we're probably screwed anyway,
but let's try to be more robust about it.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Nicolai Hähnle <Nicolai.Haehnle@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Commit 88e72717c2 ("drm/irq: Use unsigned int pipe in public API")
updated the prototype of this function but not the implementation. This
wasn't noticed even through compile tests because the prototype is part
of the source file that uses it and hence the compiler won't know the
prototype when it compiles the implementation.
The right thing would've been to move the prototype to a header that's
included in radeon_kms.c so that the implementation signature could be
checked against it, but the closest thing would've been radeon_drv.h
and including that results in a lot of build errors, so we'll leave it
as is for now.
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
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>
The workarounds for disabling hdc invalidation and also forcing
context to be non coherent, are advised to be used up until rev D0.
However as it was found that rev F0, without the
WaForceEnableNonCoherent might system hang if the mesa
tried to use coherent mode.
As these two workarounds are about non coherent access, are
grouped in scope and they point the same HSD, increase the
scope of both to set default behaviour to non coherent access.
References: HSD: gen9lp/2131413
References: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101515.html
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450448093-22906-1-git-send-email-mika.kuoppala@intel.com
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
spin timeout and so we will just be wasting CPU cycles.
v2: Check for logical inversion when rebasing - we were incorrectly
checking for this request being active, and instead busywaiting for
when the GPU was not yet processing the request of interest.
v3: Try another colour for the seqno names.
v4: Another colour for the function names.
v5: Remove the forced coherency when checking for the active request. On
reflection and plenty of recent experimentation, the issue is not a
cache coherency problem - but an irq/seqno ordering problem (timing issue).
Here, we do not need the w/a to force ordering of the read with an
interrupt.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk
When waiting for high frequency requests, the finite amount of time
required to set up the irq and wait upon it limits the response rate. By
busywaiting on the request completion for a short while we can service
the high frequency waits as quick as possible. However, if it is a slow
request, we want to sleep as quickly as possible. The tradeoff between
waiting and sleeping is roughly the time it takes to sleep on a request,
on the order of a microsecond. Based on measurements of synchronous
workloads from across big core and little atom, I have set the limit for
busywaiting as 10 microseconds. In most of the synchronous cases, we can
reduce the limit down to as little as 2 miscroseconds, but that leaves
quite a few test cases regressing by factors of 3 and more.
The code currently uses the jiffie clock, but that is far too coarse (on
the order of 10 milliseconds) and results in poor interactivity as the
CPU ends up being hogged by slow requests. To get microsecond resolution
we need to use a high resolution timer. The cheapest of which is polling
local_clock(), but that is only valid on the same CPU. If we switch CPUs
because the task was preempted, we can also use that as an indicator that
the system is too busy to waste cycles on spinning and we should sleep
instead.
__i915_spin_request was introduced in
commit 2def4ad99b [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe,
so we can use native register sizes on smaller architectures. Mention
the approximate microseconds units for elapsed time and add some extra
comments describing the reason for busywaiting.
v3: Raise the limit to 10us
v4: Now 5us.
Reported-by: Jens Axboe <axboe@kernel.dk>
Link: https://lkml.org/lkml/2015/11/12/621
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-3-git-send-email-chris@chris-wilson.co.uk
The busywait in __i915_spin_request() does not respect pending signals
and so may consume the entire timeslice for the task instead of
returning to userspace to handle the signal.
In the worst case this could cause a delay in signal processing of 20ms,
which would be a noticeable jitter in cursor tracking. If a higher
resolution signal was being used, for example to provide fairness of a
server timeslices between clients, we could expect to detect some
unfairness between clients (i.e. some windows not updating as fast as
others). This issue was noticed when inspecting a report of poor
interactivity resulting from excessively high __i915_spin_request usage.
Fixes regression from
commit 2def4ad99b [v4.2]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 7 16:20:41 2015 +0100
drm/i915: Optimistically spin for the request completion
v2: Try to assess the impact of the bug
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc; "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-2-git-send-email-chris@chris-wilson.co.uk
pm_runtime_{use,dont_use}_autosuspend() controls whether the device's
sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on
access to user space. Since
commit 25b181b46e
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Dec 17 13:44:56 2015 +0200
drm/i915: get a permanent RPM reference on platforms w/o RPM support
this sysfs file is writeable also on platforms without RPM support, but
userspace (at least IGT) depends on this file being unchangable to
determine whether the device supports runtime PM at all. So restore the
old behavior.
This gets rid of igt/pm_rpm failures on old platforms without RPM
support, where the test should be skipped.
Testcase: igt/pm_rpm/basic-rte
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: David Weinehall <david.weinehall@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com
This is an oversight that made use of the trip-point-based fan managenent on
cards that never expose those. This led the fan to stay at fan_min.
Fortunately, the emergency code would kick when the temperature would reach
90°C.
Reported-by: Tom Englund <tomenglund26@gmail.com>
Tested-by: Tom Englund <tomenglund26@gmail.com>
Signed-off-by: Martin Peres <martin.peres@free.fr>
Tested-by: Daemon32 <lnf.purple@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92126
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
"exec->exec_bo" is NULL at this point so this code returns success. We
want to return -ENOMEM.
Fixes: d5b1a78a77 ('drm/vc4: Add support for drawing 3D frames.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
"state" is smaller than "kernel_state" so we end up corrupting memory.
Fixes: 214613656b ('drm/vc4: Add an interface for capturing the GPU state after a hang.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The copy_to/from_user() functions return the number of bytes remaining
to be copied. We want to return error codes here.
Also it's a bad idea to print an error message if a copy from user fails
because users can use that to spam /var/log/messages which is annoying
so I removed those.
Fixes: 214613656b ('drm/vc4: Add an interface for capturing the GPU state after a hang.')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
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>
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best solution is to just disable the primary plane and
pretend the BIOS never had it enabled.
v2: Add intel_pre_disable_primary() call (Maarten)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-2-git-send-email-matthew.d.roper@intel.com
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb is only pinned whilst it is active and we no
longer have an explicit pin for the info->system_base mmapping used by
the fbdev. The result is that after some aperture pressure the fbdev may
be evicted, but we continue to write the fbcon into the same GGTT
address - overwriting anything else that may be put into that offset.
The effect is most pronounced across suspend/resume as
intel_fbdev_set_suspend() does a full clear over the whole scanout.
v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from
the BIOS, we do not own the pinned vma (except for the reference we add
in this patch for our access via info->screen_base).
v3: Finish balancing the vma pinning for the normal !preallocated case.
v4: Try to simplify the pinning even further.
v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1449245126-26158-1-git-send-email-chris@chris-wilson.co.uk
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that later
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1448029000-10616-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I missed this myself when reviewing
commit 237ed86c69
Author: Sonika Jindal <sonika.jindal@intel.com>
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
Long sleeps like this really shouldn't waste cpu cycles spinning.
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: "Wang, Gary C" <gary.c.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The device should be on for the whole duration of the update, so check
for this.
v2:
- use the existing dev_priv directly everywhere (Ville)
v3:
- check also that we are in an RPM atomic section (Chris)
- add the assert to i915_ggtt_insert_entries/clear_range too (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-11-git-send-email-imre.deak@intel.com
In some cases we want to check whether we hold an RPM wakelock reference
for the whole duration of a sequence. To achieve this add a new RPM
atomic sequence counter that we increment any time the wakelock refcount
drops to zero. Check whether the sequence number stays the same during
the atomic section and that we hold the wakelock at the beginning of the
section.
Motivated by Chris.
v2-v3:
- unchanged
v4:
- swap the order of atomic_read() and assert_rpm_wakelock_held() in
assert_rpm_atomic_begin() to avoid race
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
With this change we have the corresponding wake lock checks in both the
rpm get and put functions.
v2-v3:
- unchanged
v4:
- keep the corresponding check in the get helper (Chris)
v5:
- add a note to the commit message that with this change we have the
checks both in the rpm get and put functions (Joonas)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-9-git-send-email-imre.deak@intel.com
Atm, we assert that the device is not suspended until the point when the
device is truly put to a suspended state. This is fine, but we can catch
more problems if we check that RPM refcount is non-zero. After that one
drops to zero we shouldn't access the device any more, even if the actual
device suspend may be delayed. Change assert_rpm_wakelock_held()
accordingly to check for a non-zero RPM refcount in addition to the
current device-not-suspended check.
For the new asserts to work we need to annotate every place explicitly in
the code where we expect that the device is powered. The places where we
only assume this, but may not hold an RPM reference:
- driver load
We assume the device to be powered until we enable RPM. Make this
explicit by taking an RPM reference around the load function.
- system and runtime sudpend/resume handlers
These handlers are called when the RPM reference becomes 0 and know the
exact point after which the device can get powered off. Disable the
RPM-reference-held check for their duration.
- the IRQ, hangcheck and RPS work handlers
These handlers are flushed in the system/runtime suspend handler
before the device is powered off, so it's guaranteed that they won't
run while the device is powered off even though they don't hold any
RPM reference. Disable the RPM-reference-held check for their duration.
In all these cases we still check that the device is not suspended.
These explicit annotations also have the positive side effect of
documenting our assumptions better.
This caught additional WARNs from the atomic modeset path, those should
be fixed separately.
v2:
- remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville)
v3:
- use a new dedicated RPM wakelock refcount to also catch cases where
our own RPM get/put functions were not called (Chris)
- assert also that the new RPM wakelock refcount is 0 in the RPM
suspend handler (Chris)
- change the assert error message to be more meaningful (Chris)
- prevent false assert errors and check that the RPM wakelock is 0 in
the RPM resume handler too
- prevent false assert errors in the hangcheck work too
- add a device not suspended assert check to the hangcheck work
v4:
- rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts
and wakelock_count to wakeref_count
- disable the wakeref asserts in the IRQ handlers and RPS work too
- update/clarify commit message
v5:
- mark places we plan to change to use proper RPM refcounting with
separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com
As a preparation for follow-up patches add a new helper that checks
whether we hold an RPM reference, since this is what we want most of
the cases. Atm this helper will only check for the HW suspended state, a
follow-up patch will do the actual change to check the refcount instead.
One exception is the forcewake release timer function, where it's
guaranteed that the HW is on even though the RPM refcount drops to zero.
This guarantee is provided by flushing the timer in the runtime suspend
handler. So leave the assert_device_not_suspended check in place there.
Also rename assert_device_suspended for consistency and export these
helpers as a preparation for the follow-up patches.
No functional change.
v3:
- change the assert warning message to be more meaningful (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-6-git-send-email-imre.deak@intel.com
We don't really need to check this flag in the get/put/assert helpers,
as on platforms without RPM support we won't ever enable RPM. That means
pm.suspend will be always false and the assert will be always true.
Do this to simplify the code and to let us extend the RPM asserts to all
platforms for a better coverage.
Motivated by Ville.
v2-v3:
- unchanged
v4:
- remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too
made possible by the previous two patches
v5:
- rebased on the previous new patch in the series that keeps
HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent
reference taken there
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450352931-16498-1-git-send-email-imre.deak@intel.com
Currently we disable RPM functionality on platforms that doesn't support
this by not putting/getting the RPM reference we receive from the RPM
core during driver loading/unloading respectively. This is somewhat
obscure, so make it more explicit by keeping a reference dedicated for
this particular purpose whenever the driver is loaded. This makes it
possible to remove the HAS_RUNTIME_PM() special casing from every other
places in the next patch.
v2:
- fix intel_runtime_pm_get vs. intel_runtime_pm_put in
intel_power_domains_fini()
v3:
- take only a low level RPM reference so the ref tracking asserts
continue to work (Ville)
- update the commit message
- move the patch earlier for bisectability
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450352696-16135-1-git-send-email-imre.deak@intel.com
We can make the RPM dependency on RC6 explcit in the code by taking an
actual RPM reference, instead of avoiding to drop the initial one. This
will also enable us to remove the HAS_RUNTIME_PM special casing from
more places in the next patch.
v2:
- fixed typo in commit message (Joonas)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-4-git-send-email-imre.deak@intel.com
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
mailbox may specify an alternate location for VBT instead of mailbox #4.
Use the alternate location if available and valid, falling back to
mailbox #4 otherwise.
v2: Update debug logging (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com
This fixes a random corruption under memory pressure. We need to fence
the BO for the user fence as well, otherwise it might be swapped out
and the GPU could write the fence value to an undesired location.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
This adds support for the version of host1x found on Tegra210 SoCs. It
also makes use of the new atomic suspend/resume functionality to bring
this feature to Tegra.
Other than that it's mostly small fixes and cleanups, with some prep-
work for things that will hopefully get merged for the next release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWcZ2kAAoJEN0jrNd/PrOhkIMP+gIN8HuXN4p7LfpQ/SvOCios
FvSz8qCAa00/PDVSUjykQtTeGwFyW/KXkQgsOXea8YignrZXHQkt/ldAS6D63+d6
NcHmu7S8Hd2D9K8yogaVccP3sILgrkatVl4WreqEVCvlD9v1pvhlw8Y9NHftSMop
ghStN6QcKI/uT13MSqNI3LrfR/KfBb4g6QAZ5M+ElSN6+lOGkMGADv4a2wyIPfL0
nw3Vy0Zgq0qFwqLAKOPm89WFtKeZ0PSVPUT3bdKw82XPKJW7f20WoM8GWM3CQKVS
gVcOGl1QJV/TEMnRsij3HvgU2KNAdyRCybdvGKJF+i0uFgXSDT0LKLxGOf6cDs7b
TvnmBS0so8j/6bWo5Sj7gKC9LKFSuA282xTLBEE+PnZCAxHDoCH11tKplIvMH9Uy
SaAnR8cwZnURu1ARflMK7AZFNiZXZTJYmP9qyiPT52HtU2xMIjWylnwsZVlmWNcz
9WxWt5Z6V2KtxXUuiqFbBjJl0I1ZUfKA1nyZsCGomBpqpj7RXU2ObrdcRZ1u2fMV
8ArRffd8lxFeLn0gDjopL3gUqWXV73Y/NerDAiHyoS6tLybvQg6AQaRuhonrFvcW
kJabO6RDAxWMOwXmLca0IgX92DJXI373DHBSDeFW4ETs6yNT3Hc9fN5ZqyMr005G
t0ym/jN1rVMUxHV67eTA
=aaka
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.5-rc1
This adds support for the version of host1x found on Tegra210 SoCs. It
also makes use of the new atomic suspend/resume functionality to bring
this feature to Tegra.
Other than that it's mostly small fixes and cleanups, with some prep-
work for things that will hopefully get merged for the next release.
* tag 'drm/tegra/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Advertise DRIVER_ATOMIC
drm/tegra: Use DRIVER level for IOMMU aperture message
drm/tegra: checking for IS_ERR() instead of NULL
drm/tegra: dc: Add missing of_node_put()
drm/tegra: Implement subsystem-level suspend/resume
drm/tegra: sor: Remove unnecessary conditional
drm/tegra: sor: Operate on struct drm_dp_aux *
drm/tegra: Use drm_gem_object_unreference_unlocked()
drm/tegra: Don't take dev->struct_mutex in mmap offset ioctl
drm/tegra: Use unlocked gem unreferencing
drm/tegra: Use new multi-driver module helpers
gpu: host1x: Add Tegra210 support
gpu: host1x: Remove core driver on unregister
gpu: host1x: Use platform_register/unregister_drivers()
This set of changes brings in a few more helpers for DSI support as well
as a couple of new drivers and support for some more simple panels.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWcZxDAAoJEN0jrNd/PrOhuWkP/0VX9HrqF0R3eGB4Vk7I2O1Q
ftM7LNnLkN9fhs2D+uL3mkNyMEdYwCVuwkPM3dfWLDZ17Y1MQgqmdRCUwavzjxTx
ZHATjCPry2sB/0A8a4HiRd7tmexJGSuxU4TKZgBMykdcdtK3Pxu4X3RyLeiirPsm
/8XU/WmEnWnmNuyXWtgGDokiu/QW6kcjZrcHVVMklvdl6kNgSB60HoaH56z7+g51
y4ixFHvdj4ijBNf5wB6Gd8CVQY/2yLNq5GVuh4H0KYL7LapzB2VNFJDp5jxM3KCA
63hPBa9y2Yews0jdRK+BQCVerVzWG92cwm/3sKdUfABHULLdZ+qBwfKON/Obm3pQ
a1QNFr+2KVTRT1BfVv5qoLNzC0xUa55tFeduFOssZI1DhQClrsWkkzPxs3TDrAYf
6fo3pSYSlvb3P1vAcVcA15NlwoCGAV0QDIIFPL+uZPwObcCVuWWGGvfYT2hrrD+u
Gh1L3Mw2+tvMm1xx3U38ABs5ZiFwnogZKOY0g3AWR0n0HP0Hs/znWtUE8wyfpMf4
fVKrU+4vxYAYsY40jTrmOzT3Pt6b5lfIBvdpeqb8lFuWpsMzslc9p2mkXpIBkn3K
VbY8Z0e6F0LySThG0iLykxaeMklEIfe9eybkCQGV5sWrIIQ2+falKAZvu5Ho9zzh
ioGnJn/05KVIfKd6w2E8
=vV7Q
-----END PGP SIGNATURE-----
Merge tag 'drm/panel/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.5-rc1
This set of changes brings in a few more helpers for DSI support as well
as a couple of new drivers and support for some more simple panels.
* tag 'drm/panel/for-4.5-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Add QiaoDian qd43003c0-40
of: Add vendor prefix for QiaoDian Xianshi
drm/panel: add kernel doc for size attributes in panel_desc
drm/panel: simple: Add support for Kyocera TCG121XGLP panel
devicetree: add vendor prefix for Kyocera Corporation
drm/bridge: Remove gratuitous blank line
drm/bridge: dw-hdmi: Use dashes in filenames
drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel
dt-bindings: Add Sharp LS043T1LE01 panel binding
drm/dsi: Add Turn On/Shutdown Peripheral command helpers
drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel
dt-bindings: Add Panasonic VVX10F034N00 panel binding
drm/panel: simple: Add support for Innolux G121X1-L03
drm/panel: simple: Add support for BOE TV080WUM-NL0
dt-bindings: Add BOE TV080WUM-NL0 panel binding
of: Add vendor prefix for BOE Technology Group
drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type
safety changes. We were supposed to check that the infoframe data
register is valid before writing the infoframe data, but the check
ended up inverted, and so in practice we never wrote or enabled
these infoframes.
We were still sending out the GCP infoframe when the sink was
deep-color capable. That and the fact that we use a single
bool to track our infoframe state meant that the state checker
only caught this when a HDMI sink that doesn't do deep-color was
used.
We really need to fix our infoframe state checking to be much
more anal. But in the meantime let's just fix the regression.
In fact let's just throw out the register validity check and
convert some of the "unknown info frame type" debug messages
into MISSING_CASE(). So far we support the same set of infoframe
types on all platforms, so the silent debug messages make no
sense.
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: f0f59a00a1 ("drm/i915: Type safe register read/write")
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450282200-4203-1-git-send-email-ville.syrjala@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93119
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Document that 'width' and 'height' are measured in millimeters.
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Kyocera TCG121XGLP panel is an XGA LCD TFT panel connected through
LVDS, which can be supported by the simple panel driver.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.
v2: Drop the locking as unneeded (Chris)
v3: Rebase
Cc: Chris Wilson <chris@chris-wilson.co.uk>
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/1450178232-27780-1-git-send-email-jani.nikula@intel.com
Make the validation function a boolean operating on a buffer of given
size, removing the extra pointer dances.
Move the OpRegion based VBT validation to intel_opregion_setup(), only
initializing opregion->vbt if it's valid.
v2: move logging about valid VBT to opregion setup too (Ville)
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/1450178175-27420-1-git-send-email-jani.nikula@intel.com
The decision about which source will be used for VBT is done in
intel_parse_bios(), not in the VBT validation function. Make the VBT
validation function strictly about validation, and move the debug
logging to where it logically belongs.
Also split the logging about where the valid VBT was found and what the
signature is. This will make even more sense in the future when the
validation for ACPI OpRegion based VBT takes place at OpRegion setup
time.
v2: Split logging about VBT signature and BDB version.
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/1450178092-27148-1-git-send-email-jani.nikula@intel.com
Mailbox 5 is BIOS to Driver Notification mailbox is intended
to support BIOS to Driver event notification or data storage
for BIOS to Driver data synchronization purpose. Mailbox 5 is
the extension of mailbox 3.
v4 by Jani:
- don't add asle_ext to dev_priv as it's unused
- use u8 for bddc and rsvd fields in asle ext struct
- add BUILD_BUG_ON the asle ext struct size
- debug logging for asle ext present
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Deepak M <m.deepak@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/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com
This adds the etnaviv DRM driver and hooks it up in Makefiles
and Kconfig.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The following code pattern exists in some DRM drivers:
ddev = drm_dev_alloc(&driver, parent_dev);
drm_dev_set_unique(ddev, dev_name(parent_dev));
(Sometimes dev_name(ddev->dev) is used, which is the same.)
As suggested in
http://lists.freedesktop.org/archives/dri-devel/2015-December/096441.html,
the unique name of a new DRM device can be set as dev_name(parent_dev)
when parent_dev is not NULL (vgem is a special case).
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_dev_set_unique() uses a format string to define the unique name of a
device. This feature is not used as currently all the calls to this
function either use "%s" as a format string or directly use
dev_name().
Even though this second kind of call does not introduce security
problems, because there cannot be "%" characters in dev_name() results,
gcc issues a warning when building with -Wformat-security flag
("warning: format string is not a string literal (potentially
insecure)"). This warning is useful to find real bugs like the one
fixed by commit 3958b79266 ("configfs: fix kernel infoleak through
user-controlled format string"). False positives which do not bring
an extra value make the work of finding real bugs harder.
Therefore remove the format-string feature from drm_dev_set_unique().
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1449829228-4425-1-git-send-email-nicolas.iooss_linux@m4x.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/tegra/tegra-drm.ko:
-.rodata 13672
+.rodata 13684
-.data 1108
+.data 1096
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-26-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/nouveau/nouveau.ko:
-.rodata 105688
+.rodata 105792
-.data 125724
+.data 125620
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-24-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/i2c/adv7511.ko:
-.rodata 1368
+.rodata 1416
-.data 164
+.data 116
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-20-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/bridge/nxp-ptn3460.ko:
-.rodata 440
+.rodata 536
-.data 208
+.data 112
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-16-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/bridge/dw_hdmi.ko:
-.rodata 120
+.rodata 216
-.data 96
+.data 0
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-15-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moves a bunch of junk to .rodata from .data.
drivers/gpu/drm/armada/armada.ko:
-.rodata 1040
+.rodata 1100
-.data 1156
+.data 1096
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-12-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-29-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As the hardware description for this chip is the same as the sama5d4, we use
this SoC structures for layers and DC descriptions. Thus only 2 lines are added
to the atmel_hlcdc_of_match table.
The compatible string is already documented in the parent MFD driver's binding.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-10-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
srf->sizes has been allocated and checked a few lines above; fix up
the copy-pasto so that we check srf->offsets.
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-8-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the drm_crtc_index() helper to determine the pipe number of the CRTC
instead.
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-5-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no reason whatsoever why this should ever be negative. The same
goes for the number of pipes added to the DRM device.
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-4-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Previously a negative pipe caused a special case to be triggered for
drivers that didn't have proper VBLANK support. The trigger for this
special case is now independent of the pipe, so the correct CRTC index
can now be stored in events.
v2: convert to use drm_crtc_send_vblank_event()
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-3-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the DSI output isn't connected, then mdfld_dsi_encoder_get_pipe()
will return -1. The mdfld_dsi_dp_mode_set() function doesn't properly
check for this condition and causes the following compiler warnings:
CC drivers/gpu/drm/gma500/mdfld_dsi_dpi.o
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c: In function ‘mdfld_dsi_dpi_mode_set’:
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:828:35: warning: array subscript is below array bounds [-Warray-bounds]
u32 pipeconf = dev_priv->pipeconf[pipe];
^
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:829:33: warning: array subscript is below array bounds [-Warray-bounds]
u32 dspcntr = dev_priv->dspcntr[pipe];
^
Fix this by checking for a valid pipe before indexing the pipeconf and
dspcntr arrays.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-2-git-send-email-boris.brezillon@free-electrons.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VC4 wraps the CMA objects in its own structures, so it needs to do its
own teardown (waiting for GPU to finish, updating bo_stats tracking).
The other CMA drivers are using drm_gem_cma_free_object as their
gem_free_object, so this should be a no-op for them.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we reply with NACK to UP requests which might
confuse receivers. We haven't seen any actual issues with
this but should still respond to UP requests correctly.
Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449514552-10236-2-git-send-email-harry.wentland@amd.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a remnant from an old iteration of this patch that I've forgotten
to remove: We only need the encoder to figure out whether it has been
reassigned in this update already or not to figure out whether there's
a conflict or not.
Reported-by: Thierry Reding <thierry.reding@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449564561-3896-2-git-send-email-daniel.vetter@ffwll.ch
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.
* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore
* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
to look pretty bad on html. Fixed by using proper code markup.
* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
a proper markup list.
* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
it doesn't support table cell spanning. But we can use fixed-width
for those special cases.
* include/drm/drm_vma_manager.h: Another code example that should be
proper indented with four spaces.
v2 (Daniel): Adjust name to gpu.xml due to rename.
v3 (Daniel):
Split out the actual enabling in the Makefile - this way we can merge
the conversion, while just keeping the enabling in a drm-private tree.
Signed-off-by: Danilo Cesar Lemes de Paula <danilo.cesar@collabora.co.uk> (v1)
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Stephan Mueller <smueller@chronox.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448471279-19748-2-git-send-email-daniel.vetter@ffwll.ch
This is the "fix igt basic test set issues" edition.
- more PSR fixes from Rodrigo, getting closer
- tons of fifo underrun fixes from Ville
- runtime pm fixes from Imre, Daniel Stone
- fix SDE interrupt handling properly (Jani Nikula)
- hsw/bdw fdi modeset sequence fixes (Ville)
- "don't register bad VGA connectors and fall over" fixes (Ville)
- more fbc fixes from Paulo
- and a grand total of exactly one feature item: Implement dma-buf/fence based
cross-driver sync in the i915 pageflip path (Alex Goins)
* tag 'drm-intel-next-2015-12-04-1' of git://anongit.freedesktop.org/drm-intel: (70 commits)
drm/i915: Update DRIVER_DATE to 20151204
drm/i915/skl: Add SKL GT4 PCI IDs
Revert "drm/i915: Extend LRC pinning to cover GPU context writeback"
drm/i915: Correct the Ref clock value for BXT
drm/i915: Restore skl_gt3 device info
drm/i915: Fix RPS pointer passed from wait_ioctl to i915_wait_request
Revert "drm/i915: Remove superfluous NULL check"
drm/i915: Clean up device info structure definitions
drm/i915: Remove superfluous NULL check
drm/i915: Handle cdclk limits on broadwell.
i915: wait for fence in prepare_plane_fb
i915: wait for fence in mmio_flip_work_func
drm/i915: Extend LRC pinning to cover GPU context writeback
drm/i915/guc: Clean up locks in GuC
drm/i915: only recompress FBC after flushing a drawing operation
drm/i915: get rid of FBC {,de}activation messages
drm/i915: kill fbc.uncompressed_size
drm/i915: use a single intel_fbc_work struct
drm/i915: check for FBC planes in the same place as the pipes
drm/i915: alloc/free the FBC CFB during enable/disable
...
The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
status OK)
3. Modes are moved from the probed_modes list to the actual
mode list. If a mode already on the mode list is deemed
to match one of the probed modes, the duplicate is dropped
and the mode status updated to OK. After this the
probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
with an appropriate debug message.
What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).
I broke that in
commit 05acaec334 ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.
Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.
Cc: stable@vger.kernel.org
Cc: Adam Jackson <ajax@redhat.com>
Fixes: 05acaec334 ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.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>
This pull request brings in 3D acceleration support for the VC4 GPU.
While there is still performance work to be done (particularly
surrounding RCL generation), the CL submit ABI should be settled and
done now.
* tag 'drm-vc4-next-2015-12-11' of http://github.com/anholt/linux:
drm/vc4: Add an interface for capturing the GPU state after a hang.
drm/vc4: Add support for async pageflips.
drm/vc4: Add support for drawing 3D frames.
drm/vc4: Bind and initialize the V3D engine.
drm/vc4: Fix a typo in a V3D debug register.
drm/vc4: Add an API for creating GPU shaders in GEM BOs.
drm/vc4: Add create and map BO ioctls.
drm/vc4: Add a BO cache.
drm: Create a driver hook for allocating GEM object structs.
- Support runtime pm
. In case of most ARM SoC, each IP has each power domain which should be
controlled by each IP driver using runtime pm interface. So this patch
series makes each IP driver to control its own power domain when
drm dpms is requested.
- Support of_graph based dt binding for DP panel.
. This patch series adds of_graph based dt binding for DP panel.
And also it keeps backward compatibility. This includes dt binding
patch so I got Acked-by from Krzysztof Kozlowski who is a Exynos
SoC maintainer and from Rob Herring who is a device tree maintainer.
- Cleanup for Exynos DRM IPP enhancement.
. This patch series is a first step for enhancing existing IPP framework
which will integrate existing IPP functions with DRM KMS part so that
these can be transparent to userspace. For other portion of the patch
series, we will have more times for the review.]
* 'exynos-drm-next' of git://git.kernel.org:/pub/scm/linux/kernel/git/daeinki/drm-exynos: (29 commits)
drm/exynos: gem: remove old unused prototypes
drm/exynos: fimd: fix dma burst size setting for small plane size
drm/exynos: fix clipping when scaling is enabled
drm/exynos: mixer: use ratio precalculated in exynos_state
drm/exynos: add generic check for plane state
drm/exynos: introduce exynos_drm_plane_config structure
drm/exynos: mixer: enable video overlay plane only when VP is available
drm/exynos: mixer: use crtc->state->adjusted_mode instead of crtc->mode
drm/exynos: introduce exynos_drm_plane_state structure
drm/exynos: move dma_addr attribute from exynos plane to exynos fb
drm/exynos: exynos7-decon: remove excessive check
drm/exynos: rotator: convert to common clock framework
drm/exynos: gsc: add device tree support and remove usage of static mappings
drm/exynos: gsc: fix wrong pm_runtime state
drm/exynos: gsc: prepare and unprepare gsc clock
ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
dt-bindings: exynos-dp: update ports node binding for panel
drm/exynos: dp: add of_graph dt binding support for panel
drm/exynos: decon: remove unused variables
drm/exynos: dsi: modify a error type when getting a node failed
...
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>
Last (very likely at least) drm-misc pull for 4.5. 3 big things:
- piles of docs for kms vtables.
- drm.debug dmesg output prettification from Ville (i915 parts are for 4.6
I think)
- connector mode probing/validating/merging cleanup from Ville.
[airlied : fix drm_encoder_init conflict.]
* tag 'topic/drm-misc-2015-12-14' of git://anongit.freedesktop.org/drm-intel: (43 commits)
drm: modes: Revert cc344980c7 "replace simple_strtoul by kstrtouint"
drm: Expand the drm_helper_probe_single_connector_modes() docs
drm: Allow override_edid to override the firmware EDID
drm/sti: Drop bogus drm_mode_sort() call
drm: Drop drm_helper_probe_single_connector_modes_nomerge()
drm: Only merge mode type bits between new probed modes
drm: Flatten drm_mode_connector_list_update() a bit
drm: Rename MODE_UNVERIFIED to MODE_STALE
drm: Don't overwrite UNVERFIED mode status to OK
drm: Add plane->name and use it in debug prints
drm: Add crtc->name and use it in debug messages
drm: Use driver specified encoder name
drm: Pass 'name' to drm_encoder_init()
drm: Pass 'name' to drm_universal_plane_init()
drm: Pass 'name' to drm_crtc_init_with_planes()
drm: Documentation style guide
drm: Document drm_encoder/crtc_helper_funcs
drm: Move drm_display_mode an related docs into kerneldoc
drm/atomic-helper: Mention the new system/resume helpers the docs
drm: Document drm_connector_helper_funcs
...
Here are some i915 fixes for v4.4, sorry for being late this week.
* tag 'drm-intel-fixes-2015-12-11' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Do a better job at disabling primary plane in the noatomic case.
drm/i915/skl: Double RC6 WRL always on
drm/i915/skl: Disable coarse power gating up until F0
drm/i915: Remove incorrect warning in context cleanup
The cursor code tries to treat base==0 to mean disabled. That fails
when the cursor bo gets bound at ggtt offset 0, and the user is left
looking at an invisible cursor.
We lose the disabled->disabled optimization, but that seems like
something better handled at a slightly higher level.
Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450091808-32607-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other uses thanks to universal plane support.
Chris pointed out that cursor updates are currently too slow
via universal planes that micro optimizations like these wouldn't
even help.
v2: Add a note about futility of micro optimizations (Chris)
Cc: drm-intel-fixes@lists.freedesktop.org
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
WARN_ON() takes a condition rather than a format string. This patch
converted WARN_ON() to WARN() instead.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
in case of failed to get iova, function was returning without releasing
the mutex. Added it.
Signed-off-by: Saurabh Sengar <saurabh.truth@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.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: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For DSIv2 to work, we need to enable MMSS_AHB_ARB_MASTER_PORT in
MMSS_SFPB. We enable the required bitfield by retrieving MMSS_SFPB
regmap pointer via syscon.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We currently use iommu allocated DMA buffers for sending DSI commands.
DSIv2 doesn't have a port connected to the MDP iommu. Therefore, it
can't use iommu allocated buffers to fetch DSI commands.
Use a regular contiguous DMA buffer if we are DSIv2.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a dsi_cfg entry for APQ8064. Since this is the first DSIv2 chip to
be supported, add a list of bus clocks that are required by the DSIv2
block.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSIv2 (DSI on older A family chips) has slightly different link clock
requirements.
First, we have an extra clock called src_clk (with a dedicated RCG).
This is required by the DSI controller to process the pixel data
coming from MDP. It needs to be set at the rate "pclk * bytes_per_pixel".
We also need to explicitly configure esc_clk. On DSI6G chips, we don't
need to set a rate to esc_clk because its RCG is always sourced from
crystal clock (19.2 Mhz in all cases), which is within the escape clock
frequency range in the mipi DSI spec. For chips with DSIv2, the crystal
clock rate may not be within the required range (27Mhz on APQ8064).
Therefore, we derive it from the DSI byte clock. We calculate an esc_clck
rate that is within the mipi spec and also divisible by the byte clock
rate.
When setting rate and enabling the link clocks, we make sure that byte_clk
is configured before esc_clk, and src_clk before pixel_clk. We create two
different link_enable funcs for DSI6G and DSIv2 since the sequences are
different.
We also obtain two extra source clocks (dsi_src_clk and esc_src_clk) and
set their parent to the clocks provided by DSI PLL.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSI bus clocks seem to vary between different DSI host versions, and the
SOC to which they belong. Even the enable/disable sequence varies.
Provide a list of bus clock names in dsi_cfg. The driver will use this to
retrieve the clocks, and enable/disable them.
Add bus clock lists for DSI6G, and DSI for MSM8916(this is DSI6G too, but
there is no MMSS_CC specific clock since there is no MMSS clock controller
on 8916).
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Initialize clocks only after we get the DSI host version. This will allow
us to get clocks using a pre-defined list based on the DSI major/minor
version of the host. This is required since clock requirements of
different major DSI revisions(v2 vs 6g) aren't the same.
Modify dsi_get_version to get the interface clock, and then put it after
it is used.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The current version checking mechanism works fine for DSI6G blocks. It
doesn't work so well for older generation DSIv2 blocks.
The initial read of REG_DSI_6G_HW_VERSION(offset 0x0) would result in a
read of REG_DSI_CTRL for DSIv2. This register won't necessarily be 0 on
DSIv2. It can be non zero if DSI was previously initialized by the
bootloader.
Instead of reading offset 0x0, we now read offset 0x1f0. For DSIv2, this
register is DSI_VERSION, and is bound to be non-zero. On DSI6G, this
register(offset 0x1f0) is SCRATCH_REGISTER_0, which no one ever seems to
touch, and from all register dumps I'vc seen, holds 0 all the time.
Modify dsi_get_version to read REG_DSI_VERSION to determine whether we
are DSI6G or DSIv2.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add DSI PLL common clock framework clocks for 8960 PHY.
The PLL here is different from the ones found in B family msm chips. As
before, the DSI provides two clocks to the outside world. dsixpll and
dsixpllbyte (x = 1, 2). dsixpll is a regular clock divider, but
dsixpllbyte is modelled as a custom clock divider.
dsixpllbyte is the starting point of the PLL configuration. It is the
one that sets up the VCO clock rate. We need the VCO clock rate in the
form: F * byteclk, where F is a multiplication factor that varies on
the byte clock the DSI driver is trying to set. We use the custom
clk_ops for dsixpllbyte to ensure that the parent (VCO) is set at this
rate.
An additional divider (POSTDIV1) generates the bitclk. Since bit clock
can be derived from byteclock, we calculate it internally, and don't
expose it as a clock.
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
DSI PHY on MSM8960 and APQ8064 is a 28nm PHY that's different from the
supported 28nm LP PHY found in newer chips.
Add support for the new PHY.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We retrieve the byte and pixel source clocks (RCG clocks) in the dsi
driver via DT. These are needed so that we can re-parent these source
clocks if we want to drive it using a different DSI PLL.
We shouldn't get these via DT because they aren't clocks that directly
serve as inputs to the dsi host.
Fortunately, there is a static parent-child link between the
byte_clk_src/pixel_clk_src and byte_clk/pixel_clk clocks. So, we can
retrieve the source clocks via clk_get_parent.
Do this instead of retrieving via DT.
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Create DSI encoders during modeset_init. The 2 encoders should ideally be
one command mode and one video mode DSI encoder respectively, but we don't
support command mode yet. We just create 2 of the same because the dsi
driver expects it, we end up using only the first one.
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
