27 Apr, 2016
1 commit
-
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
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
14 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
