| Age | Commit message (Collapse) | Author |
|---|
|
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-6-git-send-email-ankit.k.nautiyal@intel.com
|
|
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com
|
|
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.
Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com
|
|
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-3-git-send-email-ankit.k.nautiyal@intel.com
|
|
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-2-git-send-email-ankit.k.nautiyal@intel.com
|
|
The new helper returns index of the matching string in an array.
We are going to use it here.
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503184119.22355-1-andriy.shevchenko@linux.intel.com
|
|
Exynos Scaler is a hardware module, which processes graphic data fetched
from memory and transfers the resultant dato another memory buffer.
Graphics data can be up/down-scaled, rotated, flipped and converted color
space. Scaler hardware modules are a part of Exynos5420 and newer Exynos
SoCs.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Merge conflict so merged manually.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core. During the conversion
driver has been adapted to support more specific compatible strings
to distinguish between Exynos5250 and Exynos5420 (different hardware
limits). Support for Exynos5433 variant has been added too
(different limits table, removed dependency on ARCH_EXYNOS5).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch adds Exynos IPP v2 subsystem and userspace API.
New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging operation modes of obsolete IPP v1 API (framebuffer
writeback and local-path output with image processing) can be implemented
using standard DRM features: writeback connectors and additional DRM planes
with scaling features.
V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.
The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
provided structures (source and destination buffers, operation rectangle,
transformation, etc).
The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.
Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.
Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Merge conflict so merged manually.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This fixes setting the clock divider on the TI OMAP-L138 LCDK board.
The clock drivers for OMAP-L138 are being covernted to the common clock
framework. When this happens, clk_set_rate() will no longer return an
error. However, on this SoC, the clock rate cannot actually be changed
because the clock has to maintain a fixed ratio to the ARM clock. So
after attempting to set the clock rate, we need to check to see if the
new rate is actually close enough. If not, then follow the previous
error path to adjust the divider in LCDC IP block to compensate for not
being able to change the parent clock rate.
Tested working on a TI OMAP-L138 LCDK board.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
Driver features data block has a boolean flag for PSR, use this to decide
whether PSR should be enabled on a platform. The module parameter can
still be used to override this.
Note: The feature currently remains disabled by default for all platforms
irrespective of what VBT says.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509003524.3199-1-dhinakaran.pandiyan@intel.com
|
|
Prepare to allow the GuC submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508210318.10274-2-chris@chris-wilson.co.uk
|
|
Prepare to allow the execlists submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508210318.10274-1-chris@chris-wilson.co.uk
|
|
In igt_flush_test() we try to switch back to the kernel context, but we
are only able to do so when we are called with struct_mutex held.
More of my CI fallout from lockdep being temporarily suppressed :(
Fixes: 4cdf65ce8cc2 ("drm/i915/selftests: Return to kernel context after each test")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509065926.19207-1-chris@chris-wilson.co.uk
|
|
Calling mock_engine() calls i915_timeline_init() and that requires
struct_mutex to be held as it adds itself to the global list of
timelines. This error was introduced by commit a89d1f921c15 ("drm/i915:
Split i915_gem_timeline into individual timelines") but the issue was
masked in CI by the earlier lockdep spam.
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508211056.17151-1-chris@chris-wilson.co.uk
|
|
This patch brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.
Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS")
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.
Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Use new return type vm_fault_t for fault handler
in struct vm_operations_struct.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next
Fixup pagefault issue of mixer driver
- it makes sure to check shadow register for interlace scan.
- it corrects chroma_addr[1], height and vertical position values.
And trivial cleanup
- it just removes duplicated drm_bridge_attach.
|
|
drm_bridge_attach takes care of these assignments, so there is no need
to open-code them a second time.
Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
CI noticed
<4>[ 23.430701] ============================================
<4>[ 23.430706] WARNING: possible recursive locking detected
<4>[ 23.430713] 4.17.0-rc4-CI-CI_DRM_4156+ #1 Not tainted
<4>[ 23.430720] --------------------------------------------
<4>[ 23.430725] systemd-udevd/169 is trying to acquire lock:
<4>[ 23.430732] (ptrval) (&(&timeline->lock)->rlock){....}, at: move_to_timeline+0x48/0x12c [i915]
<4>[ 23.430888]
but task is already holding lock:
<4>[ 23.430894] (ptrval) (&(&timeline->lock)->rlock){....}, at: i915_request_submit+0x1a/0x40 [i915]
<4>[ 23.430995]
other info that might help us debug this:
<4>[ 23.431002] Possible unsafe locking scenario:
<4>[ 23.431007] CPU0
<4>[ 23.431010] ----
<4>[ 23.431013] lock(&(&timeline->lock)->rlock);
<4>[ 23.431021] lock(&(&timeline->lock)->rlock);
<4>[ 23.431028]
*** DEADLOCK ***
<4>[ 23.431036] May be due to missing lock nesting notation
<4>[ 23.431044] 5 locks held by systemd-udevd/169:
<4>[ 23.431049] #0: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x42/0xe0
<4>[ 23.431065] #1: (ptrval) (&dev->mutex){....}, at: __driver_attach+0x50/0xe0
<4>[ 23.431078] #2: (ptrval) (&dev->struct_mutex){+.+.}, at: i915_gem_init+0xca/0x630 [i915]
<4>[ 23.431174] #3: (ptrval) (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915]
<4>[ 23.431271] #4: (ptrval) (&(&timeline->lock)->rlock){....}, at: i915_request_submit+0x1a/0x40 [i915]
<4>[ 23.431369]
stack backtrace:
<4>[ 23.431377] CPU: 0 PID: 169 Comm: systemd-udevd Not tainted 4.17.0-rc4-CI-CI_DRM_4156+ #1
<4>[ 23.431385] Hardware name: Dell Inc. OptiPlex GX280 /0G8310, BIOS A04 02/09/2005
<4>[ 23.431394] Call Trace:
<4>[ 23.431403] dump_stack+0x67/0x9b
<4>[ 23.431411] __lock_acquire+0xc67/0x1b50
<4>[ 23.431421] ? ring_buffer_lock_reserve+0x154/0x3f0
<4>[ 23.431429] ? lock_acquire+0xa6/0x210
<4>[ 23.431435] lock_acquire+0xa6/0x210
<4>[ 23.431530] ? move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431540] _raw_spin_lock+0x2a/0x40
<4>[ 23.431634] ? move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431730] move_to_timeline+0x48/0x12c [i915]
<4>[ 23.431826] __i915_request_submit+0xfa/0x280 [i915]
<4>[ 23.431923] i915_request_submit+0x25/0x40 [i915]
<4>[ 23.432024] i9xx_submit_request+0x11/0x140 [i915]
<4>[ 23.432120] submit_notify+0x8d/0x124 [i915]
<4>[ 23.432202] __i915_sw_fence_complete+0x81/0x250 [i915]
<4>[ 23.432300] __i915_request_add+0x31c/0x7c0 [i915]
<4>[ 23.432395] i915_gem_init+0x621/0x630 [i915]
<4>[ 23.432476] i915_driver_load+0xbee/0x10b0 [i915]
<4>[ 23.432485] ? trace_hardirqs_on_caller+0xe0/0x1b0
<4>[ 23.432566] i915_pci_probe+0x29/0x90 [i915]
<4>[ 23.432574] pci_device_probe+0xa1/0x130
<4>[ 23.432582] driver_probe_device+0x306/0x480
<4>[ 23.432589] __driver_attach+0xb7/0xe0
<4>[ 23.432596] ? driver_probe_device+0x480/0x480
<4>[ 23.432602] ? driver_probe_device+0x480/0x480
<4>[ 23.432609] bus_for_each_dev+0x74/0xc0
<4>[ 23.432616] bus_add_driver+0x15f/0x250
<4>[ 23.432623] ? 0xffffffffa02d7000
<4>[ 23.432629] driver_register+0x52/0xc0
<4>[ 23.432635] ? 0xffffffffa02d7000
<4>[ 23.432642] do_one_initcall+0x58/0x370
<4>[ 23.432653] ? do_init_module+0x1d/0x1ea
<4>[ 23.432660] ? rcu_read_lock_sched_held+0x6f/0x80
<4>[ 23.432667] ? kmem_cache_alloc_trace+0x282/0x2e0
<4>[ 23.432675] do_init_module+0x56/0x1ea
<4>[ 23.432682] load_module+0x2435/0x2b20
<4>[ 23.432694] ? __se_sys_finit_module+0xd3/0xf0
<4>[ 23.432701] __se_sys_finit_module+0xd3/0xf0
<4>[ 23.432710] do_syscall_64+0x55/0x190
<4>[ 23.432717] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 23.432724] RIP: 0033:0x7fa780782839
<4>[ 23.432729] RSP: 002b:00007ffcea73e668 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
<4>[ 23.432738] RAX: ffffffffffffffda RBX: 0000561a472a4b30 RCX: 00007fa780782839
<4>[ 23.432745] RDX: 0000000000000000 RSI: 00007fa7804610e5 RDI: 000000000000000e
<4>[ 23.432752] RBP: 00007fa7804610e5 R08: 0000000000000000 R09: 00007ffcea73e780
<4>[ 23.432758] R10: 000000000000000e R11: 0000000000000246 R12: 0000000000000000
<4>[ 23.432765] R13: 0000561a47296450 R14: 0000000000020000 R15: 0000561a472a4b30
but did not report it as an issue as it only occurred during the first
module on boot. This is due to the removal of the distinct global
timeline, and its separate lock class. So instead mark up the expected
nesting. An alternative would be to define a separate lock class for the
engine, but since we only expect to have a single point of nesting, we
can avoid having multiple lock classes for the struct.
Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Tested-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508153514.20251-1-chris@chris-wilson.co.uk
|
|
The i915_flip* tracepoints are no longer in use since the removal of CS
flip in commit 8b5d27b911d7 ("drm/i915: Remove intel_flip_work
infrastructure")
References: 8b5d27b911d7 ("drm/i915: Remove intel_flip_work infrastructure")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508151552.31024-1-chris@chris-wilson.co.uk
|
|
DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address 0000eh.
With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
To avoid breaking panels that are not spec compiant we now warn on
invalid values.
V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo
V8: Style
V9: Strip out DPCD_REV_XX into seperate patch
v10: DPCD_REV_XX to DP_DPCD_REV_XX
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504221800.17830-2-matthew.s.atwood@intel.com
|
|
As more differentation occurs between DP spec. Its useful to have these
as macros in a drm_dp_helper.
v2: DPCD_REV_XX to DP_DPCD_REV_XX
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504221800.17830-1-matthew.s.atwood@intel.com
|
|
During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.
v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.
v2: Keep rcu_read_lock() around for PREEMPT_RCU
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
As we flush each test and wait for idle before the next, also switch
back to the kernel context. This helps limit the amount of collateral
damage a test may cause by resetting to the default state each time (and
also helps clean up temporaries used by the test).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508115312.12628-1-chris@chris-wilson.co.uk
|
|
Add some onion to populate_lr_context.
v2: prefer err_unpin_ctx
drop the fixes tag, worst case we just spew a warn before everything
is cleaned up and balance is restored
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180301114639.510-1-matthew.auld@intel.com
|
|
igt_ctx_exec() expects that we retire all active requests/objects before
completing, so that when we clean up the files afterwards they are ready
to be freed. Before we do so, it is then prudent to ensure that we have
indeed retired the GPU activity, raising an error if it fails. If we do
not, we run the risk of triggering an assertion when freeing the object:
__i915_gem_free_objects:4793 GEM_BUG_ON(i915_gem_object_is_active(obj))
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-2-chris@chris-wilson.co.uk
|
|
Pull igt_flush_test() out into its own library before copying and
pasting the code for a third time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180505091014.26126-1-chris@chris-wilson.co.uk
|
|
Operating on a zero sized GEM userptr object will lead to explosions.
Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Testcase: igt/gem_userptr_blits/input-checking
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502195021.30900-1-matthew.auld@intel.com
|
|
If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092829.GC661@mwanda
|
|
The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092739.GB661@mwanda
|
|
drm_dev_alloc() returns error pointers, it never returns NULL.
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508092650.GA661@mwanda
|
|
When rescheduling a change of dependencies, they all need to be added to
the same priolist (at least the ones on the same engine!). Since we
likely want to move a batch of requests, keep the priolist around.
v2: Throw in an assert to catch trivial errors quickly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-2-chris@chris-wilson.co.uk
|
|
lookup_priolist() no longer attaches the request into the priolist, it
just returns the priolist for the given priority instead. Drop the
unused parameter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-1-chris@chris-wilson.co.uk
|
|
Unsafe module parameters are just that, unsafe. If the user is foolish
enough to try them and the kernel breaks, they get to keep both pieces.
Don't ask them to file a bug report if they broke it themselves.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106423
Fixes: d15d7538c6d2 ("drm/i915: Tune down init error message due to failure injection")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506183147.2690-1-chris@chris-wilson.co.uk
|
|
This implements the "MG PLL Programming" sequence from our spec. The
biggest problem was that the spec assumes real numbers, so we had to
adjust some numbers and calculations due to the fact that the Kernel
prefers to deal with integers.
I recommend grabbing some coffee, a pen and paper before reviewing
this patch.
v2:
- Correctly identify DP encoders after upstream change.
- Small checkpatch issues.
- Rebase.
v3:
- Try to impove the comment on the tdc_targetcnt calculation based on
Manasi's feedback (Manasi).
- Rebase.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-7-paulo.r.zanoni@intel.com
|
|
Just use the hardcoded tables provided by our spec.
v2: Rebase.
v3: Clarify that 38.4 uses the 19.2 table (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-6-paulo.r.zanoni@intel.com
|
|
HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
the CNL code.
v2:
- Properly detect HDMI crtcs.
- Rebase after changes to the cnl function (clock * 1000).
v3:
- Add a comment to clarify why we treat 38.4 as 19.2 (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-5-paulo.r.zanoni@intel.com
|
|
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.
Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.
v2:
- Rebase around dpll_lock changes.
v3:
- The spec now says what the timeouts should be.
- Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
the machine.
- Checkpatch found a white space problem.
- Small adjustments before upstreaming.
v4:
- Move the ICL checks out of the *map_plls_to_ports() functions
(James)
- Add extra encoder check (James)
- Call icl_unmap_plls_to_ports() later (James)
v5:
- Rebase after the pll struct changes.
v6:
- Properly make the unmap function based on encoders_post_disable()
with regarding to checks and iterators.
- Address checkpatch comment on "min = max = x()".
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
|
|
Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com
|
|
The sync_debug.h header is internal, and only used by
sw_sync.c. Therefore, SW_SYNC is always defined and there
is no need for the stubs. Remove them and make the code
simpler.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504180037.10661-1-ezequiel@collabora.com
|
|
We have to check dma-buf reservation objects of our framebuffers before
we use them. Otherwise, another driver might be writing on the same
buffer which we are using. This would cause visible tearing effects
on display.
We can use existing atomic helper functions to solve this problem.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The R8A77965 (M3-N) SoC provides RGB, HDMI and LVDS output.
This platform is unusual in that the RGB is connected to DU3 leaving DU2
unpopulated. This is reflected by the channels_mask accordingly.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The group objects assume linear indexing, and more so always assume that
channel 0 of any active group is used.
Now that the CRTC objects support non-linear indexing, adapt the groups
to remove assumptions that channel 0 is utilised in each group by using
the channel mask provided in the device structures.
Finally ensure that the RGB routing is determined from the index of the
CRTC object (which represents the hardware DU channel index).
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The DU CRTC driver does not support distinguishing between a hardware
index, and a software (CRTC) index in the event that a DU channel might
not be populated by the hardware.
Support this by adapting the rcar_du_device_info structure to store a
bitmask of available channels rather than a count of CRTCs. The count
can then be obtained by determining the hamming weight of the bitmask.
This allows the rcar_du_crtc_create() function to distinguish between
both index types, and non-populated DU channels will be skipped without
leaving a gap in the software CRTC indexes.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The M3-N HDMI TX controller is compatible with the M3-W and H3. No
extension to the DT bindings are needed.
Add an SoC-specific compatible string in case differences between the IP
versions are found later and require model-specific handling.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
