Age | Commit message (Collapse) | Author | Files | Lines |
|
http://github.com/zourongrong/linux into drm-next
hibmc drm driver for hisilicon.
* tag 'drm-hisilicon-next-2016-11-17' of http://github.com/zourongrong/linux:
MAINTAINERS: Update HISILICON DRM entries
drm/hisilicon/hibmc: Add support for vblank interrupt
drm/hisilicon/hibmc: Add support for VDAC
drm/hisilicon/hibmc: Add support for display engine
drm/hisilicon/hibmc: Add support for frame buffer
drm/hisilicon/hibmc: Add video memory management
drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver
|
|
If the LLC is coherent with the object, we do not need to worry about
whether main memory and cache mismatch when we hand the object back to
the system.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.
v2: Only send the fb flush message if flushing the dirt on flip
v3: Make flush-for-flip and dirtyfb look more alike since they serve
similar roles as end-of-frame marker.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]> #v2
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On the DMA mapping error path, sg may be NULL (it has already been
marked as the last scatterlist entry), and we should avoid dereferencing
it again.
Reported-by: Dan Carpenter <[email protected]>
Fixes: e227330223a7 ("drm/i915: avoid leaking DMA mappings")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Imre Deak <[email protected]>
Cc: [email protected]
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matthew Auld <[email protected]>
|
|
Trying to chase an impossible bug (ivb):
[ 207.765411] [drm:i915_reset_and_wakeup [i915]] resetting chip
[ 207.765734] [drm:i915_gem_reset [i915]] resetting render ring to restart from tail of request 0x4ee834
[ 207.765791] [drm:intel_print_rc6_info [i915]] Enabling RC6 states: RC6 on RC6p on RC6pp off
[ 207.767213] [drm:intel_guc_setup [i915]] GuC fw status: path (null), fetch NONE, load NONE
[ 207.767515] kernel BUG at drivers/gpu/drm/i915/i915_gem_request.c:203!
[ 207.767551] invalid opcode: 0000 [#1] PREEMPT SMP
[ 207.767576] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me mei snd_pcm sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
[ 207.767808] CPU: 3 PID: 8855 Comm: gem_ringfill Tainted: G U 4.9.0-rc5-CI-Patchwork_3052+ #1
[ 207.767854] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012
[ 207.767894] task: ffff88012c82a740 task.stack: ffffc9000383c000
[ 207.767927] RIP: 0010:[<ffffffffa00a0a3a>] [<ffffffffa00a0a3a>] i915_gem_request_retire+0x2a/0x4b0 [i915]
[ 207.767999] RSP: 0018:ffffc9000383fb20 EFLAGS: 00010293
[ 207.768027] RAX: 00000000004ee83c RBX: ffff880135dcb480 RCX: 00000000004ee83a
[ 207.768062] RDX: ffff88012fea42a8 RSI: 0000000000000001 RDI: ffff88012c82af68
[ 207.768095] RBP: ffffc9000383fb48 R08: 0000000000000000 R09: 0000000000000000
[ 207.768129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880135dcb480
[ 207.768163] R13: ffff88012fea42a8 R14: 0000000000000000 R15: 00000000000001d8
[ 207.768200] FS: 00007f955f658740(0000) GS:ffff88013e2c0000(0000) knlGS:0000000000000000
[ 207.768239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 207.768258] CR2: 0000555899725930 CR3: 00000001316f6000 CR4: 00000000001406e0
[ 207.768286] Stack:
[ 207.768299] ffff880135dcb480 ffff880135dcbe00 ffff88012fea42a8 0000000000000000
[ 207.768350] 00000000000001d8 ffffc9000383fb70 ffffffffa00a1339 0000000000000000
[ 207.768402] ffff88012f296c88 00000000000003f0 ffffc9000383fbb0 ffffffffa00b582d
[ 207.768453] Call Trace:
[ 207.768493] [<ffffffffa00a1339>] i915_gem_request_retire_upto+0x49/0x90 [i915]
[ 207.768553] [<ffffffffa00b582d>] intel_ring_begin+0x15d/0x2d0 [i915]
[ 207.768608] [<ffffffffa00b59cb>] intel_ring_alloc_request_extras+0x2b/0x40 [i915]
[ 207.768667] [<ffffffffa00a2fd9>] i915_gem_request_alloc+0x359/0x440 [i915]
[ 207.768723] [<ffffffffa008bd03>] i915_gem_do_execbuffer.isra.15+0x783/0x1a10 [i915]
[ 207.768766] [<ffffffff811a6a2e>] ? __might_fault+0x3e/0x90
[ 207.768816] [<ffffffffa008d380>] i915_gem_execbuffer2+0xc0/0x250 [i915]
[ 207.768854] [<ffffffff815532a6>] drm_ioctl+0x1f6/0x480
[ 207.768900] [<ffffffffa008d2c0>] ? i915_gem_execbuffer+0x330/0x330 [i915]
[ 207.768939] [<ffffffff81202f6e>] do_vfs_ioctl+0x8e/0x690
[ 207.768972] [<ffffffff818193ac>] ? retint_kernel+0x2d/0x2d
[ 207.769004] [<ffffffff810d6ef2>] ? trace_hardirqs_on_caller+0x122/0x1b0
[ 207.769039] [<ffffffff812035ac>] SyS_ioctl+0x3c/0x70
[ 207.769068] [<ffffffff818189ae>] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 207.769103] Code: 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 8b 35 fa 7b e1 e1 85 f6 0f 85 55 03 00 00 41 8b 84 24 80 02 00 00 85 c0 75 02 <0f> 0b 49 8b 94 24 a8 00 00 00 48 8b 8a e0 01 00 00 8b 89 c0 00
[ 207.769400] RIP [<ffffffffa00a0a3a>] i915_gem_request_retire+0x2a/0x4b0 [i915]
[ 207.769463] RSP <ffffc9000383fb20>
Let's add a couple more BUG_ONs before this to ascertain that the request
did make it to hardware. The impossible part of this stacktrace is that
request must have been considered completed by the i915_request_wait()
before we tried to retire it.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matthew Auld <[email protected]>
|
|
When gathering the pages from our backing storage we expect get_pages()
to either give us our sg_table or an err ptr. However when gathering our
fake pages for stolen memory we may return NULL in the event of a
failure. To prevent any funny business we should therefore return the
proper err ptr value.
Fixes: 03ac84f1830e ("drm/i915: Pass around sg_table to get_pages/put_pages backend")
Cc: Chris Wilson <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
|
|
To avoid userspace-triggerable dmesg spam, downgrade messages in the sysfs
write parsing code to debug level.
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161118141158.32415.71438.stgit@bhelgaas-glaptop.roam.corp.google.com
|
|
Signed-off-by: Maarten Lankhorst <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-12-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <[email protected]> #irc
|
|
Since we can retire requests from multiple paths, we cannot assume that
i915_gem_retire_requests() is the sole path on which we can transition
to gt.active_requests == 0. A consequence of this is that we would skip
the function if we had already retired all the requests and not
scheduled the idle worker.
This is fallout from changing the routine from considering active_engines
(for which it was the only consumer) to active_requests.
v2: Move kicking the idle working to i915_gem_request_retire() otherwise
we could postpone the idle callback everytime we called retire_requests
even though we did no work.
v3: We only need to move the idle work kicking!
v4: Drop the BUG_ON(!awake) as we may be called from the shrinker in the
middle of constructing a request before we have marked the device awake.
v5: Add a BUG_ON() for active_requests underflow upon retirement (Joonas)
Fixes: 28176ef4cfa5 ("drm/i915: Reserve space in the global seqno during request allocation")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
I tried to avoid having to track the write for every VMA by only
tracking writes to the ggtt. However, for the purposes of frontbuffer
tracking this is insufficient as we need to invalidate around writes not
just to the the ggtt but all aliased ppgtt views of the framebuffer. By
moving the critical section to the object and only doing so for
framebuffer writes we can reduce the tracking even further by only
watching framebuffers and not vma.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Paulo Zanoni <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
|
|
Otherwise it is just an useless empty line.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Suggested-by: Maarten Lankhorst <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use dev_printk() when possible. This makes messages more consistent with
other device-related messages and, in some cases, adds useful information.
This changes messages like this:
vgaarb: failed to allocate pci device
vgaarb: setting as boot device: PCI:0000:01:00.0
vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: bridge control possible 0000:01:00.0
to this:
pci 0000:01:00.0: vgaarb: failed to allocate VGA arbiter data
pci 0000:01:00.0: vgaarb: setting as boot VGA device
pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
pci 0000:01:00.0: vgaarb: bridge control possible
No functional change intended.
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/20161117174758.16810.67625.stgit@bhelgaas-glaptop.roam.corp.google.com
|
|
There's a really big pile of additional connector properties, a lot of
them standardized. But they're all for specific outputs (panels, TV,
scaling, ...) so I left them out for now since this is enough for a
start.
I typed this to give Manasi a place to add her new link status
property documentation.
v2: forgot to git add all the bits (Manasi).
v3: Be more epxlicit about integrated tiled panels (Archit)
Cc: Manasi Navare <[email protected]>
Cc: Archit Taneja <[email protected]>
Reviewed-by: Archit Taneja <[email protected]>
Reviewed-by: Manasi Navare <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
ssh://git.freedesktop.org/git/drm-intel into drm-fixes
i915 misc fixes.
* tag 'drm-intel-fixes-2016-11-17' of ssh://git.freedesktop.org/git/drm-intel:
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
drm/i915: Refresh that status of MST capable connectors in ->detect()
drm/i915: Grab the rotation from the passed plane state for VLV sprites
drm/i915: Mark CPU cache as dirty when used for rendering
|
|
This reverts commit f752fff611b99f5679224f3990a1f531ea64b1ec.
Signed-off-by: Dave Airlie <[email protected]>
|
|
This reverts commit 83ba62bc700bab710b22be3a1bf6cf973f754273.
Signed-off-by: Dave Airlie <[email protected]>
|
|
Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
cec_read() is non-atomic in the presence of other I2C bus transactions
to the same device. This presents a problem when we add support for
the TDA9950 CEC engine part - both drivers can be trying to access the
device.
Avoid the inherent problems by switching to i2c_transfer() instead,
which allows us to perform more than one bus transaction atomically.
As this means we will be using I2C transactions rather than SMBUS, we
have to check that the host supports I2C functionality.
Tested-by: Brian Starkey <[email protected]>
Reviewed-by: Brian Starkey <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Some TDA998x contain several different I2C devices - there is the HDMI
encoder, and there is a TDA9950 CEC engine. These two share the same
interrupt signal.
In order to allow a driver for the CEC engine to work, we need to be
able to share the interrupt with the CEC driver, so convert the handler
and registration to allow this to happen.
Tested-by: Brian Starkey <[email protected]>
Reviewed-by: Brian Starkey <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Disabling the pre-filter block of the TDA998x saves 40mW and the colour
conversion block saves 15mW. As we always disable these two blocks, we
can power these sections of the chip down to save 55mW of unnecessary
power consumption.
Tested-by: Brian Starkey <[email protected]>
Reviewed-by: Brian Starkey <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Rather than storing the DPMS mode (which will always be on or off) use a
boolean to store this instead.
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
tda998x_audio_get_eld() is needlessly complex - the connector associated
with the encoder is always our own priv->connector. Remove this
complexity, but ensure that there are no races when copying out the ELD.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Group the TDA998x audio functions together rather than split between
two different locations in the file, keeping like code together.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Separate out the connector initialisation from the rest of the drivers
initialisation.
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Group the TDA998x connector functions and funcs structures together
before the encoder support, rather than scattered amongst the rest of
the file. This keeps like code together.
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
The naming of tda998x_encoder_set_config() is a left-over from when
TDA998x was a slave encoder. Since this is part of the initialisation,
drop the _encoder from the name, and move it near tda998x_bind().
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Correct two references to tda998x_connector_get_modes() which were
incorrectly referring to tda998x_encoder_get_modes().
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Check for audio support by the attached sink by consulting the EDID
prior to enabling audio over the TMDS link. We must consult the EDID
after calling drm_helper_probe_single_connector_modes(), as this can
use an override EDID, or load a replacement EDID.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
The CEA 861B specification indicates the situations when we are able to
send each infoframe based on the version of the EDID's CEA extension.
Update the tda998x driver to follow the CEA specification wrt sending
of infoframes.
Since we only support the generation of AVI version 2, this limits us
to CEA extension version 3, so we treat CEA extension version 2 as
CEA 861 (no infoframes, no audio.)
Tested-by: Robin Murphy <[email protected]>
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Avoid a race between programming audio and an in-progress mode set.
A mode set is complex, and disables the ability to send infoframes
to the sink, and is disruptive to audio - we have to mute the audio
FIFO while doing a mode set.
If an attempt is made to start up the audio side, we will undo the
audio FIFO mute before the mode set has completed.
Move the lock so that we prevent audio interfering with an in-progress
mode set.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
Avoid a racy access to the mode clock by storing the current mode clock
during a mode set under the audio mutex. This allows us to access it
from the audio path in a safe way.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
As priv->audio_params can now be changed at run time, we need to be more
careful about how we deal with a mode set. We must take the audio lock
while checking if there's a valid audio configuration.
However, it's slightly worse than that - during mode set, we mute the
audio, and it must not be unmuted until we have finished the mode set.
It is possible that the audio side may start while a mode set is in
progress, so take the audio_mutex lock around the whole mode setting
procedure.
Tested-by: Jon Medhurst <[email protected]>
Acked-by: Jon Medhurst <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Russell King <[email protected]>
|
|
We will need the audio mutex initialised in all cases, so lets move this
to be early, rather than only being initialised for the DT case.
Signed-off-by: Russell King <[email protected]>
|
|
We need to clean up the global_timeline in i915_gem_load_cleanup.
v2: don't forget about the struct_mutex, and also WARN_ON if we have any
remaining timelines before purging the global_timeline.
v3: it might be a good idea to first remove the global_timeline...duh!
Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct")
Cc: Chris Wilson <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We already have an i915_address_space_init, so for symmetry we should
also have a _fini, plus we already open code it twice. This then also
fixes a bug where we leak the timeline for the ggtt vm.
v2: don't forget about the struct_mutex for the ggtt path.
Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Cc: Chris Wilson <[email protected]>
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We should never be called via obj->ops->release() on anything other than
a fully formed stolen object, so raise that to an assert. In the process
tidy up a comment and variable no longer used outside of a conditional
BUG.
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Matthew Auld <[email protected]>
|
|
We have to make sure there are no holes in the table in Gen9.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Suggested-by: Chris Wilson <[email protected]>
Cc: Chris Wilson <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Similar to existing yesno and onoff and use it throughout the code.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
Kernel pointer does not sound like an useful thing to log and
pipe name is already contained in the crtc name.
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
And also only dump DP config for crtcs with DP encoders.
Signed-off-by: Tvrtko Ursulin <[email protected]>
|
|
We don't spam the debug when we create a normal object, nor when we
allocate their pages. Yet we do for stolen objects, and since these are
quite frequently used (at least once per context), the resulting spam
floods the dmesg in CI.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
|
|
We use DRM_DEBUG() when reporting on user actions, to try and keep
intentional errors out of the CI dmesg. Demote the debug from
i915_gem_open() similarly so that it is only apparent with drm.debug & 1
like its brethren.
Signed-off-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
|
|
It looks to me skl_update_scaler will already log interesting
debug messages when the state transitions or there is an error.
In this case it feels we can remove the two unconditional
debug messages which happen immediately before calling
skl_update_scaler. This way we get rid of the sole debug
message when switching virtual terminals for example.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
And at the same time introduce a static inline helper for
more type safety.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Suggested-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Macro takes dev_priv and not dev.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|
|
v2: Rebase.
Signed-off-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
|