22 Apr, 2016
13 commits
-
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
2 commits
-
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 -
Commit 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to
drm_connector_unregister_all()") replaced a manual connectors list walk
in drm_connector_unregister_all() with drm_for_each_connector(). The
list was walked without the mode config mutex locked as that ends up in
a clash with sysfs, but drm_connector_unregister_all() warns when the
mutex isn't locked.The problem is known and doesn't require a large warning every time
drm_connector_unregister_all() is called. Fix it by reverting to manual
list walk.Fixes: 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()")
Signed-off-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461190874-32674-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com
20 Apr, 2016
17 commits
-
Push the ifdef to the drm_edid.h and create a stub, for the
DRM_LOAD_EDID_FIRMWARE=n case. This removes some clutter in
the code, making it more readable.Signed-off-by: Ezequiel Garcia
Reviewed-by: Jani Nikula
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461087638-16959-1-git-send-email-ezequiel@vanguardiasur.com.ar -
Now that a generic drm_connector_register_all() helper exists we may safely
substitute it for the driver-specific implementation of connectors plugging
in sysfs.Signed-off-by: Alexey Brodkin
Cc: Daniel Vetter
Cc: David Airlie
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461068693-11260-4-git-send-email-abrodkin@synopsys.com -
This driver used to have its own implementation of connector_register_all()
which actually was taken as a prototype of drm_connector_register_all().Now when drm_connector_register_all() exists reusing it here.
Signed-off-by: Alexey Brodkin
Cc: Daniel Vetter
Cc: David Airlie
Cc: Boris Brezillon
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461068693-11260-3-git-send-email-abrodkin@synopsys.com -
As a pair to already existing drm_connector_unregister_all() we're adding
generic implementation of what is already done in some drivers.Once this helper is implemented we'll be ready to switch existing
driver-specific implementations with the generic one.Signed-off-by: Alexey Brodkin
Cc: Daniel Vetter
Cc: David Airlie
Cc: Boris Brezillon
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1461068693-11260-2-git-send-email-abrodkin@synopsys.com -
It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.Cc: David Herrmann
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-14-git-send-email-daniel.vetter@ffwll.ch -
With the previous two changes it doesn't protect anything any more.
v2: Use _unlocked unreference variant.
v3: Appease gcc noise.
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-13-git-send-email-daniel.vetter@ffwll.ch -
vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.Instead grab pages when we allocate the object right away.
v2: Fix compiling.
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-12-git-send-email-daniel.vetter@ffwll.ch -
The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.v2: Fix title (Emil).
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-11-git-send-email-daniel.vetter@ffwll.ch -
Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.With this patch exynos is completely struct_mutex free!
Cc: Inki Dae
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-10-git-send-email-daniel.vetter@ffwll.ch -
The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably should be removed.v2: Use _unlocked unreference (Daniel Stone).
Cc: Daniel Stone
Cc: Inki Dae
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-9-git-send-email-daniel.vetter@ffwll.ch -
The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.So drop the locking since it doesn't protect anything.
Cc: Inki Dae
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-8-git-send-email-daniel.vetter@ffwll.ch -
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.v2: Use _unlocked unreference (Daniel Stone).
Cc: Daniel Stone
Cc: Inki Dae
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-7-git-send-email-daniel.vetter@ffwll.ch -
Doesn't protect anything at all.
With this patch nouveau is completely dev->struct_mutex free!
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-6-git-send-email-daniel.vetter@ffwll.ch -
For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict withcommit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter
Date: Thu Oct 15 09:36:25 2015 +0200drm/gem: Check locking in drm_gem_object_unreference
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-4-git-send-email-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-5-git-send-email-daniel.vetter@ffwll.ch -
For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict withcommit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter
Date: Thu Oct 15 09:36:25 2015 +0200drm/gem: Check locking in drm_gem_object_unreference
Cc: Tomi Valkeinen
Cc: Laurent Pinchart
Acked-by: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-3-git-send-email-daniel.vetter@ffwll.ch -
For drm_gem_object_unreference callers are required to hold
dev->struct_mutex, which these paths don't. Enforcing this requirement
has become a bit more strict withcommit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
Author: Daniel Vetter
Date: Thu Oct 15 09:36:25 2015 +0200drm/gem: Check locking in drm_gem_object_unreference
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1459330852-27668-2-git-send-email-daniel.vetter@ffwll.ch -
When extracting the value at full precision (16 bits), no need to
round the value.This was spotted by Jani when running sparse. Unfortunately this fix
doesn't get rid of the warning.Signed-off-by: Lionel Landwerlin
Reported-by: Jani Nikula
Cc: Daniel Stone
Cc: Daniel Vetter
Cc: Matt Roper
Cc: dri-devel@lists.freedesktop.org
Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties")
Reviewed-by: Emil Velikov
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1458655833-19547-1-git-send-email-lionel.g.landwerlin@intel.com
18 Apr, 2016
1 commit
-
Vblank waits timing out is no a normal thing to happen, so let's inform
people when it happens.Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460978973-24945-2-git-send-email-ville.syrjala@linux.intel.com
15 Apr, 2016
5 commits
-
Some hubs are forgetful, and end up forgetting whatever GUID we set
previously after we do a suspend/resume cycle. This can lead to
hotplugging breaking (along with probably other things) since the hub
will start sending connection notifications with the wrong GUID. As
such, we need to check on resume whether or not the GUID the hub is
giving us is valid.Signed-off-by: Lyude
Signed-off-by: Dave Airlie
Reviewed-by: Harry Wentland
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com -
When userspace closes a handle, we remove it from the file->object_idr
and then tell the driver to drop its references to that file/handle.
However, as the file/handle is already available again for reuse, it may
be reallocated back to userspace and active on a new object before the
driver has had a chance to drop the old file/handle references.Whilst calling back into the driver, we have to drop the
file->table_lock spinlock and so to prevent reusing the closed handle we
mark that handle as stale in the idr, perform the callback and then
remove the handle. We set the stale handle to point to the NULL object,
then any idr_find() whilst the driver is removing the handle will return
NULL, just as if the handle is already removed from idr.Note: This will be used to have a direct handle -> vma lookup table,
instead of first a handle -> obj lookup, and then an (obj, vm) -> vma
lookup.v2: Use NULL rather than an ERR_PTR to avoid having to adjust callers.
idr_alloc() tracks existing handles using an internal bitmap, so we are
free to use the NULL object as our stale identifier.
v3: Needed to update the return value check after changing from using
the stale error pointer to NULL.Signed-off-by: Chris Wilson
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Ville Syrjälä
Cc: Thierry Reding
[danvet: Add note about the use-case.]
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460721308-32405-1-git-send-email-chris@chris-wilson.co.uk -
Modify the debugfs output for i915_dp_mst_info to list the source port for
the DP MST topology in question.v2: rebase
v3: rebase
v4: rebasecc: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Jim Bride
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-3-git-send-email-jim.bride@linux.intel.com -
Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.v2: Rebase + change drm_edid_get_monitor_name() call to reflect new
signature.v3: Minor changes suggested by Jani + rebase.
v4: Rebase
cc: dri-devel@lists.freedesktop.org
cc: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Jim Bride
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-2-git-send-email-jim.bride@linux.intel.com -
In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file where the rest of the EDID helper
functions are implemented.v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld()
use a common helper function to extract the monitor name from the
edid. [Jani] + rebase.v3: Minor changes suggested by Jani + rebase.
v4: Few more minor changes suggested by Jani + rebase.
cc: dri-devel@lists.freedesktop.org
cc: Jani Nikula
Reviewed-by: Jani Nikula
Signed-off-by: Jim Bride
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com
14 Apr, 2016
2 commits
-
The debug category comment mentions 4 categories, but
more than 4 categories are listed. Let's change the
wording to something a bit more generic.Signed-off-by: Robert Foss
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1460644456-9752-1-git-send-email-robert.foss@collabora.com -
In relation with the actuall bandwidth consumed on a DMA Source interface,
choose the less used one for a created plane.Signed-off-by: Boris Brezillon
Tested-by: Nicolas Ferre
