02 May, 2016
4 commits
-
Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
When the framebuffer memory is allocated using dma_alloc_writecombine()
instead of vmalloc(), I get cache syncing problems on ARM.
This solves it:static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
struct vm_area_struct *vma)
{
fb_deferred_io_mmap(info, vma);
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);return 0;
}Could this have been done in the core?
Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
fb_pgprotect() at the end of the default fb_mmap implementation
(drivers/video/fbdev/core/fbmem.c). This is an architecture specific
function that on many platforms uses pgprot_writecombine(), but not on
all. And looking at some of the fb_mmap implementations, some of them
sets vm_page_prot to nocache for instance, so I think the safest bet is
to do this in the driver and not in the fbdev core. And we can't call
fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
access to the file pointer that powerpc needs.Signed-off-by: Noralf Trønnes
Acked-by: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-5-git-send-email-noralf@tronnes.org -
This adds deferred io support to drm_fb_helper.
The fbdev framebuffer changes are flushed using the callback
(struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
ensuring that it always runs in process context.For those wondering why we need to be able to handle atomic calling
contexts: Both panic paths and cursor code and fbcon blanking can run
from atomic. Seecommit bcb39af4486be07e896fc374a2336bad3104ae0a
Author: Dave Airlie
Date: Thu Feb 7 11:19:15 2013 +1000drm/udl: make usage as a console safer
for where this was originally discovered.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
[danvet: Augment commit message with why we need to handle atomic
contexts.]
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-4-git-send-email-noralf@tronnes.org -
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-3-git-send-email-noralf@tronnes.org -
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-2-git-send-email-noralf@tronnes.org
28 Apr, 2016
4 commits
-
Some of the functions implemented are flagged as not having a prototype
defined when building with W=1. Include the header to avoid these build
warnings.Signed-off-by: Thierry Reding
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461849596-12819-1-git-send-email-thierry.reding@gmail.com -
Let's be nice and interrupt the dpcd aux-dev reads/writes when there's
a signal pending. Much nicer if the user can hit ^C instead of having to
sit around waiting for the read/write to finish.time dd if=/dev/drm_dp_aux0 bs=$((1024*1024))
^Cbefore:
real 0m34.681s
user 0m0.003s
sys 0m6.880safter:
real 0m0.222s
user 0m0.006s
sys 0m0.057sCc: Rafael Antognolli
Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461786225-7790-1-git-send-email-ville.syrjala@linux.intel.com -
The debug logging here can be very verbose in the kernel logs
and provides no information which userspace doesn't have the
access to already. Turn it off so kernel logs become more
manageable.Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461755507-30453-1-git-send-email-tvrtko.ursulin@linux.intel.com -
Debug logging in this function does not provide any information
apart that the userspace is calling an ioctl on the connector.There is not any info on the connector provided at all and
since there are other ioctls userspace typically calls which
do log useful things about the same connectors, remove this
one to make things a little bit more readable when KMS debugging
is turned on.Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461751622-26927-10-git-send-email-tvrtko.ursulin@linux.intel.com
27 Apr, 2016
8 commits
-
amdgpu gained dev->struct_mutex usage, and that's because it's walking
the dev->filelist list. Protect that list with it's own lock to take
one more step towards getting rid of struct_mutex usage in drivers
once and for all.While doing the conversion I noticed that 2 debugfs files in i915
completely lacked appropriate locking. Fix that up too.v2: don't forget to switch to drm_gem_object_unreference_unlocked.
Cc: Alex Deucher
Reviewed-by: Alex Deucher
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-9-git-send-email-daniel.vetter@ffwll.ch -
It's only used for legacy mmaping support now.
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-8-git-send-email-daniel.vetter@ffwll.ch -
And again make sure it's a no-op for modern drivers. Another case of
dev->struct_mutex gone for modern drivers!Note that the entirety of the legacy addmap interface is now protected
by DRIVER_MODESET. Note that just auditing kernel code is not enough,
since userspace loves to set up legacy maps on it's own for various
things - with ums userspace and kernel space share control over
resources.v2: Also add a DRIVER_* check like for all other maps functions to
really short-circuit the code. And give drm_legacy_rmmap used by the
dev unregister code the same treatment.v3:
- remove redundant return; (Alex, Chris)
- don't special case nouveau with DRIVER_KMS_LEGACY_CONTEXT.v4: Again special case nouveau. The problem is not directly in the
ddx, but that it calls dri1 functions from the X server. And those do
call drmAddMap. Fixed only incommit b1a630b48210d6a3c44994fce1b73273000ace5c
Author: Dave Airlie
Date: Wed Nov 7 14:45:14 2012 +1000nouveau: drop DRI1 device open interface.
Acked-by: Alex Deucher
Reviewed-by: Chris Wilson
Cc: Alex Deucher
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461741618-12679-1-git-send-email-daniel.vetter@ffwll.ch -
Like in
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine
Date: Tue Jun 23 08:18:49 2015 +0100drm: Turn off Legacy Context Functions
we need to again make an exception for nouveau, but everyone else
really doesn't need this.Dave Airlie dug out again why we need this: The problem is the legacy
dri1 open function the nouveau ddx called, and the problematic code is
actually in the X server itself. It was only fixed incommit b1a630b48210d6a3c44994fce1b73273000ace5c
Author: Dave Airlie
Date: Wed Nov 7 14:45:14 2012 +1000nouveau: drop DRI1 device open interface.
Cc: Peter Antoine
Cc: Ben Skeggs
Acked-by: Alex Deucher
Acked-by: Dave Airlie
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-5-git-send-email-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-6-git-send-email-daniel.vetter@ffwll.ch -
Only two drivers implement this hook. vmwgfx (which doesn't need it
really) and legacy radeon (which since v1 has been nuked, yay).v1: Rebase over radeon ums removal.
Cc: Thomas Hellstrom
Cc: Alex Deucher
Reviewed-by: Chris Wilson
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-6-git-send-email-daniel.vetter@ffwll.ch -
It belongs right next to the addmap and rmmap functions really. And
for OCD consistency name it drm_legacy_getmap_ioctl.Reviewed-by: Chris Wilson
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-4-git-send-email-daniel.vetter@ffwll.ch -
Except for the ->lasclose driver callback evrything in drm_lastclose()
is all legacy cruft and can be hidden. Which means another
dev->struct_mutex site disappears entirely for modern drivers!Also while at it change the return value of drm_lastclose to void
since it will always succeed. No one checks the return value of
close() anyway, ever.v2: Move misplaced hunk, spotted by 0day.
Cc: Thierry Reding
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-3-git-send-email-daniel.vetter@ffwll.ch -
It has a DRIVER_MODESET check to sure make it's not creating havoc
for drm drivers. Make that clear in the name too.v2: Move misplaced hunk, spotted by 0day and Thierry.
Cc: Thierry Reding
Reviewed-by: Chris Wilson
Acked-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-2-git-send-email-daniel.vetter@ffwll.ch
26 Apr, 2016
1 commit
-
For documentation and paranoia.
Acked-by: Chris Wilson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459331120-27864-4-git-send-email-daniel.vetter@ffwll.ch
25 Apr, 2016
1 commit
-
Cc: Patrik Jakobsson
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Emil Velikov
Acked-by: Patrik Jakobsson
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461279842-28695-5-git-send-email-emil.l.velikov@gmail.com
23 Apr, 2016
5 commits
-
Commit d63c25e4245a ("drm: rcar-du: Use generic
drm_connector_register_all() helper") left an unused local variable
behind. Remove it.Fixes: d63c25e4245a ("drm: rcar-du: Use generic drm_connector_register_all() helper")
Signed-off-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461336879-2469-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com -
Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
timeout, there's no use for having this function anymore. Good riddens.Signed-off-by: Lyude
Tested-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-5-git-send-email-cpaul@redhat.com -
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an additional
read before the actual read to workaround this.Changes since v5
- If the throwaway read in drm_dp_dpcd_read() fails, return the error
from that instead of continuing. This follows the same logic we do in
drm_dp_dpcd_access() (e.g. the error from the first transaction may
differ from the errors that proceeding attempts might return).Signed-off-by: Lyude
Tested-by: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460730335-5012-1-git-send-email-cpaul@redhat.com -
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.We cannot rely on sinks NACKing or deferring when they can't receive
transactions, nor can we rely on any other sort of consistent error to
know when we should stop retrying. As such, we need to just retry
unconditionally on errors. We also make sure here to return the error we
encountered during the first transaction, since it's possible that
retrying the transaction might return a different error then we had
originally.This, along with the previous patch, work around a weird bug with the
ThinkPad T560's and it's dock. When resuming the laptop, it appears that
there's a short period of time where we're unable to complete any aux
transactions, as they all immediately timeout. The only machine I'm able
to reproduce this on is the T560 as other production Skylake models seem
to be fine. The period during which AUX transactions fail appears to be
around 22ms long. AFAIK, the dock for the T560 never actually turns off,
the only difference is that it's in SST mode at the start of the resume
process, so it's unclear as to why it would need so much time to come
back up.There's been a discussion on this issue going on for a while on the
intel-gfx mailing list about this that has, in addition to including
developers from Intel, also had the correspondence of one of the
hardware engineers for Intel:http://www.spinics.net/lists/intel-gfx/msg88831.html
http://www.spinics.net/lists/intel-gfx/msg88410.htmlWe've already looked into a couple of possible explanations for the
problem:- Calling intel_dp_mst_resume() before right fix.
intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
and while it worked it definitely wasn't the right fix. This worked
because DP aux transactions don't actually require interrupts to work:static uint32_t
intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
uint32_t status;
bool done;#define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
msecs_to_jiffies_timeout(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done)
DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
has_aux_irq);
#undef Creturn status;
}When there's no interrupts enabled, we end up timing out on the
wait_event_timeout() call, which causes us to check the DP status
register once to see if the transaction was successful or not. Since
this adds a 10ms delay to each aux transaction, it ends up adding a
long enough delay to the resume process for aux transactions to become
functional again. This gave us the illusion that enabling interrupts
had something to do with making things work again, and put me on the
wrong track for a while.- Interrupts occurring when we try to perform the aux transactions
required to put the dock back into MST mode. This isn't the problem,
as the only interrupts I've observed that come during this timeout
period are from the snd_hda_intel driver, and disabling that driver
doesn't appear to change the behavior at all.- Skylake's PSR block causing issues by performing aux transactions
while we try to bring the dock out of MST mode. Disabling PSR through
i915's command line options doesn't seem to change the behavior
either, nor does preventing the DMC firmware from being loaded.Since this investigation went on for about 2 weeks, we decided it would
be better for the time being to just workaround this issue by making
sure AUX transactions wait a short period of time before retrying.Signed-off-by: Lyude
Tested-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-3-git-send-email-cpaul@redhat.com -
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to
drm's DP helper.Some sinks need some time during the process of resuming the system from
sleep before they're ready to handle transactions. While it would be
nice if they responded with NACKs in these scenarios, this isn't always
the case as a few sinks will just timeout on all of the transactions
they receive until they're ready.Signed-off-by: Lyude
Tested-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460559513-32280-2-git-send-email-cpaul@redhat.com
22 Apr, 2016
16 commits
-
Since ref counting is in the object now we can just call the
normal interfaces.Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
This reduces the fb_lock to just protecting the num_fb/fb_list.
"Previously fb refcounting, and especially the weak reference
(kref_get_unless_zero) used in fb lookups have been protected by fb_lock.
But with the refactoring to share refcounting in the drm_mode_object base
class that switched to being protected by idr_mutex, which means fb_lock
critical sections can be reduced."Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
When we lookup an ref counted object we now take a proper reference
using kref_get_unless_zero.Framebuffer lookup no longer needs do this itself.
Convert rmfb to using framebuffer lookup and deal with the fact
it now gets an extra reference that we have to cleanup. This should
mean we can avoid holding fb_lock across rmfb. (if I'm wrong let me
know).We also now only hold the fbs_lock around the list manipulation.
"Previously fb refcounting, and especially the weak reference
(kref_get_unless_zero) used in fb lookups have been protected by fb_lock.
But with the refactoring to share refcounting in the drm_mode_object base
class that switched to being protected by idr_mutex, which means fb_lock
critical sections can be reduced."Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
No need to hold the lock while assigning the variable.
Daniel wrote:
"Not sure why exactly I put that under the lock, but the only thing that
can race here is rmfb while addfb2 is still doing it's thing, with a
correctly guess (easy to do since they're fully deterministic) fb_id."Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
We don't need to hold the fb lock around the initialisation,
only around the list manipulaton.So do the lock hold only around the register for now.
From Daniel:
Previously fb refcounting, and especially the weak reference
(kref_get_unless_zero) used in fb lookups have been protected by fb_lock.
But with the refactoring to share refcounting in the drm_mode_object base
class that switched to being protected by idr_mutex, which means fb_lock
critical sections can be reduced.Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
No point have this code dupliated at this point, use the
_object_find code instead now.Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter -
This is the initial code to add references to some mode objects.
In the future we need to start reference counting connectors so
firstly I want to reorganise the code so the framebuffer ref counting
uses the same paths.This patch shouldn't change any functionality, just moves the kref.
[airlied: move kerneldoc as well]
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
Avoids drivers knowing where the kref is stored.
[airlied: add kerneldoc]
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
Just use the generic function.
The main side effect of this is that the fb->base.id
is now protected by the idr mutex as well.Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
A later patch will use it in framebuffer_init, and I want
to keep the diff cleaner.Acked-by: Daniel Vetter
Signed-off-by: Dave Airlie -
This changes the code to handle being called multiple times without
side effects. The new names seems more suitable for what it does.Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie -
This PR contains several improvement and cleanup patches for the
atmel-hlcdc driver to be applied on drm-next (targeting 4.7).* 'drm-atmel-hlcdc-devel' of https://github.com/bbrezillon/linux-at91:
drm: atmel-hlcdc: route DMA accesses through AHB interfaces
drm: atmel-hlcdc: check display mode validity in crtc->mode_fixup()
drm: atmel-hlcdc: rework the output code to support drm bridges
drm: atmel-hlcdc: move output mode selection in CRTC implementation
drm: atmel-hlcdc: support extended timing ranges on sama5d4 and sama5d2
drm: atmel-hlcdc: remove leftovers from atomic mode setting migration
drm: atmel-hlcdc: fix connector and encoder types
drm: atmel-hlcdc: support asynchronous atomic commit operations
drm: atmel-hlcdc: add a ->cleanup_fb() operation -
- make modeset hw state checker atomic aware (Maarten)
- close races in gpu stuck detection/seqno reading (Chris)
- tons&tons of small improvements from Chris Wilson all over the gem code
- more dsi/bxt work from Ramalingam&Jani
- macro polish from Joonas
- guc fw loading fixes (Arun&Dave)
- vmap notifier (acked by Andrew) + i915 support by Chris Wilson
- create bottom half for execlist irq processing (Chris Wilson)
- vlv/chv pll cleanup (Ville)
- rework DP detection, especially sink detection (Shubhangi Shrivastava)
- make color manager support fully atomic (Maarten)
- avoid livelock on chv in execlist irq handler (Chris)* tag 'drm-intel-next-2016-04-11' of git://anongit.freedesktop.org/drm-intel: (82 commits)
drm/i915: Update DRIVER_DATE to 20160411
drm/i915: Avoid allocating a vmap arena for a single page
drm,i915: Introduce drm_malloc_gfp()
drm/i915/shrinker: Restrict vmap purge to objects with vmaps
drm/i915: Refactor duplicate object vmap functions
drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj
drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf
drm/i915: implement WaClearTdlStateAckDirtyBits
drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
drm/i915: Rename hw state checker to hw state verifier.
drm/i915: Move modeset state verifier calls.
drm/i915: Make modeset state verifier take crtc as argument.
drm/i915: Replace manual barrier() with READ_ONCE() in HWS accessor
drm/i915: Use simplest form for flushing the single cacheline in the HWS
drm/i915: Harden detection of missed interrupts
drm/i915: Separate out the seqno-barrier from engine->get_seqno
drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+
drm/i915: Fixup the free space logic in ring_prepare
drm/i915: Simplify check for idleness in hangcheck
drm/i915: Apply a mb between emitting the request and hangcheck
... -
Backmerge 4.6-rc3 for i915.
Linux 4.6-rc3
-
misc pull req all over. Biggest thing is the
drm_connector_(un)register_all cleanup from Alexey for drivers without the
load/unload midlayer hooks. I.e. all the new ones, and a bunch of the
pending new atomic drivers depend upon this. Or at least I asked them to
rebase ;-)* tag 'topic/drm-misc-2016-04-21' of git://anongit.freedesktop.org/drm-intel:
drm: Make drm.debug parameter description more helpful
drm: Remove warning from drm_connector_unregister_all()
drm: probe_helper: Hide ugly ifdef
drm: rcar-du: Use generic drm_connector_register_all() helper
drm: atmel_hldc: Use generic drm_connector_register_all() helper
drm: Introduce drm_connector_register_all() helper
drm: fix lut value extraction function
drm/atomic-helper: Print an error if vblank wait times out
drm/dp/mst: Restore primary hub guid on resume
drm: Release driver references to handle before making it available again
drm/i915/dp/mst: Add source port info to debugfs output
drm/dp/mst: Enhance DP MST debugfs output
drm/edid: Add drm_edid_get_monitor_name()
include/drm: Reword debug categories comment.
drm/crtc_helper: Reset empty plane state in drm_helper_crtc_mode_set_base()
drm/virtio: Drop dummy gamma table support
drm/bochs: Drop fake gamma support
drm/core: Fix ordering in drm_mode_config_cleanup. -
struct_mutex cleanups and error paths fixes. Unfortunately I didn't manage
to get acks from everyone, but this stuff has been hanging out for months
now and imo simple enough to just land the remaining few patches. But
separate pull request so that you can take a look yourself.* tag 'topic/struct_mutex-2016-04-21' of git://anongit.freedesktop.org/drm-intel:
drm/vma_manage: Drop has_offset
drm/vgem: Drop dev->struct_mutex
drm/vgem: Move get_pages to gem_create
drm/vgem: Simplify dumb_map
drm/exynos: drop struct_mutex from fbdev setup
drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl
drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma
drm/exynos: Drop dev->struct_mutex from mmap offset function
drm/nouveau: Drop dev->struct_mutex from fbdev init
drm/qxl: Use unlocked gem unreferencing
drm/omapdrm: Use unlocked gem unreferencing
drm/nouveau: Use unlocked gem unreferencing
21 Apr, 2016
1 commit
-
Let's be user-friendly and print an actually helpful parameter
description.This makes modinfo output the debug parameter like this:
parm: debug:Enable debug output, where each bit enables a debug category.
Bit 0 (0x01) will enable CORE messages (drm core code)
Bit 1 (0x02) will enable DRIVER messages (drm controller code)
Bit 2 (0x04) will enable KMS messages (modesetting code)
Bit 3 (0x08) will enable PRIME messages (prime code)
Bit 4 (0x10) will enable ATOMIC messages (atomic code)
Bit 5 (0x20) will enable VBL messages (vblank code) (int)Changes from v1:
* Fixed s/PRMIE/PRIME typo.
* Add ATOMIC and VBL debug parameter documentation.
* Prefix the continuation lines with two tabs and
removed the last new line.
* Remove spurious whitespace.Signed-off-by: Ezequiel Garcia
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461170703-11216-1-git-send-email-ezequiel@vanguardiasur.com.ar
