| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.
Note that register_framebuffer will do a modeset (when fbcon is enabled)
and hence must be moved out of the critical section. A follow-up patch
will add new locking for the fb list, hence move all the related
registration code together.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:
[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at addr ffff88074cdd2608
[ 1250.873020] Write of size 40 by task kworker/u8:3/480
[ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U 4.9.0-rc6+ #285
[ 1250.873043] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 1250.873050] Workqueue: events_unbound async_run_entry_fn
[ 1250.873056] ffff88070f9d78f0 ffffffff814b72aa ffff88074e40c5c0 ffff88074cdd2608
[ 1250.873067] ffff88070f9d7918 ffffffff8124ff3c ffff88070f9d79b0 ffff88074cdd2600
[ 1250.873079] ffff88074e40c5c0 ffff88070f9d79a0 ffffffff812501e4 0000000000000005
[ 1250.873090] Call Trace:
[ 1250.873099] [<ffffffff814b72aa>] dump_stack+0x67/0x9d
[ 1250.873106] [<ffffffff8124ff3c>] kasan_object_err+0x1c/0x70
[ 1250.873113] [<ffffffff812501e4>] kasan_report_error+0x204/0x4f0
[ 1250.873120] [<ffffffff81698df0>] ? drm_dev_printk+0x140/0x140
[ 1250.873127] [<ffffffff81250ac3>] kasan_report+0x53/0x60
[ 1250.873134] [<ffffffff81688b40>] ? drm_setup_crtcs+0x320/0xf80
[ 1250.873142] [<ffffffff8124f18e>] check_memory_region+0x13e/0x1a0
[ 1250.873147] [<ffffffff8124f5f3>] memset+0x23/0x40
[ 1250.873154] [<ffffffff81688b40>] drm_setup_crtcs+0x320/0xf80
[ 1250.873161] [<ffffffff810be7c5>] ? wake_up_q+0x45/0x80
[ 1250.873169] [<ffffffff81b0c180>] ? mutex_lock_nested+0x5a0/0x5a0
[ 1250.873176] [<ffffffff8168a0e6>] drm_fb_helper_initial_config+0x206/0x7a0
[ 1250.873183] [<ffffffff81689ee0>] ? drm_fb_helper_set_par+0x90/0x90
[ 1250.873303] [<ffffffffa0b68690>] ? intel_fbdev_fini+0x140/0x140 [i915]
[ 1250.873387] [<ffffffffa0b686b2>] intel_fbdev_initial_config+0x22/0x40 [i915]
[ 1250.873391] [<ffffffff810b50ff>] async_run_entry_fn+0x7f/0x270
[ 1250.873394] [<ffffffff810a64b0>] process_one_work+0x3d0/0x960
[ 1250.873398] [<ffffffff810a641d>] ? process_one_work+0x33d/0x960
[ 1250.873401] [<ffffffff810a60e0>] ? max_active_store+0xf0/0xf0
[ 1250.873406] [<ffffffff810f6f9d>] ? do_raw_spin_lock+0x10d/0x1a0
[ 1250.873413] [<ffffffff810a767d>] worker_thread+0x8d/0x840
[ 1250.873419] [<ffffffff810a75f0>] ? create_worker+0x2e0/0x2e0
[ 1250.873426] [<ffffffff810b0454>] kthread+0x194/0x1c0
[ 1250.873432] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873438] [<ffffffff810f095d>] ? trace_hardirqs_on+0xd/0x10
[ 1250.873446] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873453] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60
[ 1250.873457] [<ffffffff81b12277>] ret_from_fork+0x27/0x40
[ 1250.873460] Object at ffff88074cdd2608, in cache kmalloc-32 size: 32
However, when holding the mode_config.lock around the fb_helper, we have
to be careful of any callbacks that may reenter the fb_helper and so try
to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid
the mutex recursion, we have to rearrange the sequence to move the
registration into the caller outside of the mode_config.lock.
v2: drop the 1; following the lockdep assertion inside the for(;;), I
anticipated an error that doesn't happen!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826
Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Sean Paul <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Fix race from forced shutdown of crtc in unload by adding internal
locking and a boolean telling if device is going to be shutdown.
Signed-off-by: Jyri Sarha <[email protected]>
|
|
Use unload to handle initialization failures instead of complex goto
label mess. To do this the initialization sequence needed slight
reordering and some unload functions needed to become conditional.
Signed-off-by: Jyri Sarha <[email protected]>
|
|
Stop using struct drm_driver load() and unload() callbacks. The
callbacks should not be used anymore. Instead of using load the
drm_device is allocated with drm_dev_alloc() and registered with
drm_dev_register() only after the driver is completely initialized.
The deinitialization is done directly either in component unbind
callback or in platform driver demove callback.
Signed-off-by: Jyri Sarha <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Remove obsolete drm_connector_register() calls from tilcdc_panel.c and
tilcdc_tfp410.c. All connectors are registered when drm_dev_register()
is called.
Signed-off-by: Jyri Sarha <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
This error message will be printed when a FIFO underflow irq has
triggered. Since this happens sometimes and the error message will be
displayed on the console, it should have a correct spelling.
Signed-off-by: Daniel Schultz <[email protected]>
Signed-off-by: Jyri Sarha <[email protected]>
|
|
The commit d8ff0c63fbcb ("drm/tilcdc: Adjust the FB_CEILING address")
added an adjustment of the FB_CEILING address. This is done by decrementing
the address by one.
On the AM335x (rev 0x4F201000) the framebuffer is rotated left over the
display border, because the ceiling address is 8f276fff instead of
8f277000. Since this adjustment isn't necessary for the LCDC v2, the
origin ceiling address should be used.
Signed-off-by: Daniel Schultz <[email protected]>
Signed-off-by: Jyri Sarha <[email protected]>
|
|
Due to some potential tweaks for the da850 LCDC (for example: the
required memory bandwith settings) we need a separate compatible
for the IP present on the da850 boards.
Suggested-by: Sekhar Nori <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Jyri Sarha <[email protected]>
|
|
Some architectures don't use the common clock framework and don't
implement all the clk interfaces for every clock. This is the case
for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
Trying to set the clock rate for the LCDC clock results in -EINVAL
being returned.
As a workaround for that: if the call to clk_set_rate() fails, fall
back to adjusting the clock divider instead. Proper divider value is
calculated by dividing the current clock rate by the required pixel
clock rate in HZ.
This code is based on a hack initially developed internally for
baylibre by Karl Beldan <[email protected]>.
Tested with a da850-lcdk with an LCD display connected over VGA.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Jyri Sarha <[email protected]>
|
|
Looks like we're only initializing dev_priv->atomic_cdclk_freq
at resume and commit times, not at init time. Let's do that as
well.
We're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in
hsw_compute_linetime_wm() on account of populating
intel_state->cdclk from dev_priv->atomic_cdclk_freq.
Previously we were mispopulating intel_state->cdclk with
dev_priv->cdclk_freq which always had a proper value at init
time and hence the WARN_ON() didn't trigger.
Cc: [email protected]
Cc: Matthew Auld <[email protected]>
Reported-by: Matthew Auld <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902
Fixes: e0ca7a6be38c ("drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Matthew Auld <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
|
|
Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed to the execlists reset handler). The issue is that after a reset,
we have to refill the GuC workqueues, which we do by resubmitting the
requests. However, if we already have submitted them, the fences within
them have already been used and triggering them again is an error.
Instead, just repopulate the guc workqueue.
[ 115.858560] [IGT] gem_busy: starting subtest hang-render
[ 135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], reason: Hang on render ring, action: reset
[ 135.839902] drm/i915: Resetting chip after gpu hang
[ 135.839957] [drm] RC6 on
[ 135.858351] ------------[ cut here ]------------
[ 135.858357] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
[ 135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci libahci i2c_hid hid
[ 135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: G W 4.9.0-rc4+ #238
[ 135.858389] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 135.858392] Workqueue: events_long i915_hangcheck_elapsed
[ 135.858394] ffffc900001bf9b8 ffffffff812bb238 0000000000000000 0000000000000000
[ 135.858396] ffffc900001bf9f8 ffffffff8104f621 0000006c00000000 ffff8808296137f8
[ 135.858398] 0000000000000a00 ffff8808457a0000 ffff880845764e60 ffff880845760000
[ 135.858399] Call Trace:
[ 135.858403] [<ffffffff812bb238>] dump_stack+0x4d/0x65
[ 135.858405] [<ffffffff8104f621>] __warn+0xc1/0xe0
[ 135.858406] [<ffffffff8104f748>] warn_slowpath_null+0x18/0x20
[ 135.858408] [<ffffffff813f8c15>] i915_sw_fence_complete+0x25/0x30
[ 135.858410] [<ffffffff813f8fad>] i915_sw_fence_commit+0xd/0x30
[ 135.858412] [<ffffffff8142e591>] __i915_gem_request_submit+0xe1/0xf0
[ 135.858413] [<ffffffff8142e5c8>] i915_gem_request_submit+0x28/0x40
[ 135.858415] [<ffffffff814433e7>] i915_guc_submit+0x47/0x210
[ 135.858417] [<ffffffff81443e98>] i915_guc_submission_enable+0x468/0x540
[ 135.858419] [<ffffffff81442495>] intel_guc_setup+0x715/0x810
[ 135.858421] [<ffffffff8142b6b4>] i915_gem_init_hw+0x114/0x2a0
[ 135.858423] [<ffffffff813eeaa8>] i915_reset+0xe8/0x120
[ 135.858424] [<ffffffff813f3937>] i915_reset_and_wakeup+0x157/0x180
[ 135.858426] [<ffffffff813f79db>] i915_handle_error+0x1ab/0x230
[ 135.858428] [<ffffffff812c760d>] ? scnprintf+0x4d/0x90
[ 135.858430] [<ffffffff81435985>] i915_hangcheck_elapsed+0x275/0x3d0
[ 135.858432] [<ffffffff810668cf>] process_one_work+0x12f/0x410
[ 135.858433] [<ffffffff81066bf3>] worker_thread+0x43/0x4d0
[ 135.858435] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410
[ 135.858436] [<ffffffff81066bb0>] ? process_one_work+0x410/0x410
[ 135.858438] [<ffffffff8106bbb4>] kthread+0xd4/0xf0
[ 135.858440] [<ffffffff8106bae0>] ? kthread_park+0x60/0x60
v2: Only resubmit submitted requests
v3: Don't forget the pending requests have reserved space.
Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to actual hw submission")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to avoid some complexity in trying to reconstruct the
workqueues across reset, remember them instead. The issue comes when we
have to handle a reset between request allocation and submission, the
request has reserved space in the wq, but is not in any list so we fail
to restore the reserved space. By keeping the execbuf client intact
across the reset, we also keep the reservations.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Set the initial value of the doorbell cookie from the client.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The client->cookie is a shadow of the doorbell->cookie value, so rename
it to indicate its association with the doorbell, like the doorbell id
and offset.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
i915_guc_info() (part of debugfs output) tries to avoid holding
struct_mutex for a long period by copying onto the stack. This causes a
warning that the stack frame is massive, so stop doing that. We can even
forgo holding the struct_mutex here as that doesn't serialise the values
being read (and the lists used exist for the device lifetime).
v2: Skip printing anything if guc->execbuf_client is disabled (avoids
potential NULL dereference).
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
|
|
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support DP MST audio will be implemented
in audio driver.
This patch is ported from
commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")
And because commit 3708d5e082c3 ("drm/i915: start adding dp mst audio")
breaks MST multi-monitor setups on some platforms, the orignal patch is
reverted by
commit be754b101f70 ("Revert "drm/i915: start adding dp mst audio"")
As the multi-monitor setups issue is fixed, let's port the patch and
enable the dp mst audio.
Signed-off-by: Libin Yang <[email protected]>
Cc: Lyude <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Dhinakaran Pandiyan <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Prepare for using the same code for judging ddi being audio enabled.
No functional changes.
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Signed-off-by: Libin Yang <[email protected]>
Reviewed-by: Lyude <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add the DP MST info dump in debugfs.
Signed-off-by: Dhinakaran Pandiyan <[email protected]>
Signed-off-by: Libin Yang <[email protected]>
Reviewed-by: Lyude <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The ATPX method does not always exist on the dGPU, it may be located at
the iGPU. The parent device of the iGPU is the root port for which
bridge_d3 is false. This accidentally enables the legacy PM method which
conflicts with port PM and prevented the dGPU from powering on.
Ported from amdgpu commit:
drm/amdgpu: fix check for port PM availability
from Peter Wu.
Fixes: d3ac31f3b4bf9fad (drm/radeon: fix power state when port pm is unavailable (v2))
Signed-off-by: Alex Deucher <[email protected]>
Cc: Peter Wu <[email protected]>
Cc: <[email protected]> # 4.8+
|
|
The ATPX method does not always exist on the dGPU, it may be located at
the iGPU. The parent device of the iGPU is the root port for which
bridge_d3 is false. This accidentally enables the legacy PM method which
conflicts with port PM and prevented the dGPU from powering on.
Fixes: 1db4496f167b ("drm/amdgpu: fix power state when port pm is unavailable")
Reported-and-tested-by: Mike Lothian <[email protected]>
Signed-off-by: Peter Wu <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: <[email protected]> # 4.8+
|
|
drivers/gpu/drm/i915/./i915_trace.h: In function ‘trace_event_raw_event_i915_gem_evict’:
drivers/gpu/drm/i915/./i915_trace.h:409:24: error: ‘struct i915_address_space’ has no member named ‘dev’
__entry->dev = vm->dev->primary->index;
A couple of macros missed in the s/vm->dev/vm->i915/ conversion.
Fixes: 49d73912cbfc ("drm/i915: Convert vm->dev backpointer to vm->i915")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Michał Winiarski <[email protected]>
|
|
Just a couple of naked 64bit divides causing link errors on 32bit
builds, with:
ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!
v2: do_div() is only u64/u32, we need a u32/u64!
v3: div_u64() == u64/u32, div64_u64() == u64/u64
Reported-by: kbuild test robot <[email protected]>
Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Robert Bragg <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Robert Bragg <[email protected]>
|
|
99% of the time we access i915_address_space->dev we want the i915
device and not the drm device, so let's store the drm_i915_private
backpointer instead. The only real complication here are the inlines
in i915_vma.h where drm_i915_private is not yet defined and so we have
to choose an alternate path for our asserts.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
Two warnings are produced by gcc (tested with gcc 6.2.1):
drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’:
drivers/gpu/drm/i915/intel_csr.c:400:5: error: ‘fw’ is used
uninitialized in this function [-Werror=uninitialized]
if (fw)
^
and
In file included from drivers/gpu/drm/i915/i915_drv.h:47:0,
from drivers/gpu/drm/i915/intel_guc_loader.c:30:
drivers/gpu/drm/i915/intel_guc_loader.c: In function ‘intel_guc_init’:
./include/drm/drmP.h:228:2: error: ‘fw’ may be used uninitialized in this
function -Werror=maybe-uninitialized]
drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
^~~~~~~~~~
drivers/gpu/drm/i915/intel_guc_loader.c:595:25: note: ‘fw’ was declared here
const struct firmware *fw;
^~
When CONFIG_DRM_I915_WERROR is set, those warnings break the build.
Initializing fw pointer to NULL in both cases removes the warnings.
Signed-off-by: Jérémy Lefaure <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
a PT page will be released if it doesn't contain any meaningful mappings
during PPGTT page table shrinking. The PT entry in the upper level will
be set to a scratch entry.
Normally this works nicely, but in virtualization world, the PPGTT page
table is tracked by hypervisor. Releasing the PT page before modifying
the upper level PT entry would cause extra efforts.
As the tracked page has been returned to OS before losing track from
hypervisor, it could be written in any pattern. Hypervisor has to recognize
if a page is still being used as a PT page by validating these writing
patterns. It's complicated. Better let the guest modify the PT entry in
upper level PT first, then release the PT page.
Reviewed-by: Chris Wilson <[email protected]>
Reviewed-by: Michał Winiarski <[email protected]>
Cc: Michał Winiarski <[email protected]>
Cc: Michel Thierry <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Zhenyu Wang <[email protected]>
Cc: Zhiyuan Lv <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/122697/msgid/[email protected]
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in display pageflips")
Cc: Chris Wilson <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Cc: <[email protected]> # v4.7+
|
|
In a couple of places currently, and with the intent to add more, we
update a pointer to a framebuffer to hold a new fb reference (evicting
the old).
Signed-off-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This reverts commit 27745e829a5c ("drm/i915/execlists: Use a local lock
for dfs_link access") as the struct_mutex was required to prevent
concurrent retiring and freeing, now restored in the previous patch.
Signed-off-by: Chris Wilson <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
|
|
David found another issue with priority bumping from mmioflips, where we
are accessing the requests concurrently to them being retired and freed.
Whilst we are skipping the dependency if has been submitted, that is not
sufficient to stop the dependency from disappearing if another thread
retires that request. To prevent we can either employ the struct_mutex (or a
request mutex in the future) to serialise retiring before it is freed.
Alternatively, we need to keep the dependencies alive using RCU whilst
they are being accessed via the DFS.
[ 1746.698111] general protection fault: 0000 [#1] PREEMPT SMP
[ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid
[ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1
[ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016
[ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]
[ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000
[ 1746.699361] RIP: 0010:[<ffffffffa006595d>] [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
[ 1746.699632] RSP: 0018:ffffc90000f6fcd8 EFLAGS: 00010206
[ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10
[ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458
[ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002
[ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400
[ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68
[ 1746.700307] FS: 0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000
[ 1746.700435] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0
[ 1746.700635] Stack:
[ 1746.700682] ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28
[ 1746.700827] ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000
[ 1746.700947] 00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0
[ 1746.701071] Call Trace:
[ 1746.701117] [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50
[ 1746.701260] [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]
[ 1746.701406] [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]
[ 1746.701599] [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]
[ 1746.701717] [<ffffffff81094c4d>] process_one_work+0x14d/0x470
[ 1746.701809] [<ffffffff81094fb3>] worker_thread+0x43/0x4e0
[ 1746.701888] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.701969] [<ffffffff81094f70>] ? process_one_work+0x470/0x470
[ 1746.702072] [<ffffffff8109a4d5>] kthread+0xc5/0xe0
[ 1746.702152] [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10
[ 1746.702234] [<ffffffff8109a410>] ? kthread_park+0x60/0x60
[ 1746.702318] [<ffffffff81772272>] ret_from_fork+0x22/0x30
[ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d
[ 1746.702921] RIP [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]
Nov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027] RSP <ffffc90000f6fcd8>
Fixes: 27745e829a5c ("drm/i915/execlists: Use a local lock for dfs_link access")
Fixes: 9a151987d709 ("drm/i915: Add execution priority boosting for mmioflips")
Signed-off-by: Chris Wilson <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
|
|
This patch enables the Audio Data and Clock pads to the adv7533 bridge.
Without this patch audio can not be played.
Cc: David Airlie <[email protected]>
Cc: Archit Taneja <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Andy Green <[email protected]>
Cc: Dave Long <[email protected]>
Cc: Guodong Xu <[email protected]>
Cc: Zhangfei Gao <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Jose Abreu <[email protected]>
Cc: Kuninori Morimoto <[email protected]>
Cc: [email protected]
Signed-off-by: Srinivas Kandagatla <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This patch adds support to Audio for both adv7511 and adv7533
bridge chips.
This patch was originally from [1] by Lars-Peter Clausen <[email protected]>
and was adapted by Archit Taneja <[email protected]> and
Srinivas Kandagatla <[email protected]>.
Then I heavily reworked it to use the hdmi-codec driver. And also
folded in some audio packet initialization done by Andy Green
<[email protected]>. So credit to them, but blame to me.
[1] https://github.com/analogdevicesinc/linux/blob/xcomm_zynq/drivers/gpu/drm/i2c/adv7511_audio.c
Cc: David Airlie <[email protected]>
Cc: Archit Taneja <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Cc: "Ville Syrjälä" <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Andy Green <[email protected]>
Cc: Dave Long <[email protected]>
Cc: Guodong Xu <[email protected]>
Cc: Zhangfei Gao <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Jose Abreu <[email protected]>
Cc: Kuninori Morimoto <[email protected]>
Cc: [email protected]
Acked-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: John Stultz <[email protected]>
Signed-off-by: Archit Taneja <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add a kernel parameter legancyfb_depth (like the i.MX drm driver)
to control the legancy fbdev depth. Default to the so far hard
coded depth of 24-bit. Currently changing the framebuffer depth
is not possible from user space when using the fbdev emulation
layer... This provides a rudimentary mechanism to change depth
without having to change kernel code.
Signed-off-by: Stefan Agner <[email protected]>
|
|
The separate file fsl_dcu_drm_fbdev.c only initialized fbdev
emulation which is a one-line operation. There is not much more
code on sight which justifies a separate file, hence call the
initialization helper directly from the drv file.
Signed-off-by: Stefan Agner <[email protected]>
|
|
In case of platform_get_irq() failure, let's propagate the real
error code, instead of a 'fake' one.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Stefan Agner <[email protected]>
|
|
devm_ioremap_resource() performs NULL check for the 'res' argument,
so remove the unneeded check.
Signed-off-by: Fabio Estevam <[email protected]>
Signed-off-by: Stefan Agner <[email protected]>
|
|
Make sure that all outputs are disabled before unloading the DRM
driver. Otherwise vblank handling is not shut down properly and
warnings such as this appear:
WARNING: CPU: 0 PID: 540 at drivers/gpu/drm/drm_irq.c:339 drm_vblank_cleanup+0x5c/0x94
Signed-off-by: Stefan Agner <[email protected]>
|
|
Use drm_put_dev to unload the driver before disabling clocks.
Otherwise the driver might read a register during unload which
leads to an external abort.
Signed-off-by: Stefan Agner <[email protected]>
|
|
This could lead to mclk dpm problems on some boards.
Signed-off-by: Rex Zhu <[email protected]>
Ack-by: Tom St Denis <[email protected]>
Reviewed-by: Huang Rui <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Most 5XX targets have GPMU (Graphics Power Management Unit) that
handles a lot of the heavy lifting for power management including
thermal and limits management and dynamic power collapse. While
the GPMU itself is optional, it is usually nessesary to hit
aggressive power targets.
The GPMU firmware needs to be loaded into the GPMU at init time via a
shared hardware block of registers. Using the GPU to write the microcode
is more efficient than using the CPU so at first load create an indirect
buffer that can be executed during subsequent initalization sequences.
After loading the GPMU gets initalized through a shared register
interface and then we mostly get out of its way and let it do
its thing.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Add support for the A5XX family of Adreno GPUs.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Disable the interrupt during the init sequence to avoid having
interrupts fired for errors and other things that we are not
ready to handle while initializing.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
The adreno code inherited a silly workaround from downstream
from the bad old days before decent clock control. grp_clk[0]
(named 'src_clk') doesn't actually exist - it was used as a proxy
for whatever the core clock actually was (usually 'core_clk').
All targets should be able to correctly request 'core_clk' and
get the right thing back so zap the anachronism and directly
use grp_clk[0] to control the clock rate.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Add helper functions for TYPE4 and TYPE7 ME opcodes that replace
TYPE0 and TYPE3 starting with the A5XX targets.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Add a new generic function to write a "64" bit value. This isn't
actually a 64 bit operation, it just writes the upper and lower
32 bit of a 64 bit value to a specified LO and HI register. If
a particular target doesn't support one of the registers it can
mark that register as SKIP and writes/reads from that register
will be quietly dropped.
This can be immediately put in place for the ringbuffer base and
the RPTR address. Both writes are converted to use
adreno_gpu_write64() with their respective high and low registers
and the high register appropriately marked as SKIP for both 32 bit
targets (a3xx and a4xx). When a5xx comes it will define valid target
registers for the 'hi' option and everything else will just work.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Add some new functions to manipulate GPU registers. gpu_read64 and
gpu_write64 can read/write a 64 bit value to two 32 bit registers.
For 4XX and older these are normally perfcounter registers, but
future targets will use 64 bit addressing so there will be many
more spots where a 64 bit read and write are needed.
gpu_rmw() does a read/modify/write on a 32 bit register given a mask
and bits to OR in.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
When the GPU hardware init function fails (like say, ME_INIT timed
out) return error instead of blindly continuing on. This gives us
a small chance of saving the system before it goes boom.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
There are very few register accesses in the common code. Cut down
the list of common registers to just those that are used. This
saves const space and saves us the effort of maintaining registers
for A3XX and A4XX that don't exist or are unused.
Signed-off-by: Jordan Crouse <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
|
|
Pull in a5xx registers.
Signed-off-by: Rob Clark <[email protected]>
|
|
Scratch registers move, annoyingly enough, in a5xx. Move to
per-generation aNxx_recover() fxn.
Signed-off-by: Rob Clark <[email protected]>
|