summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_irq.c
AgeCommit message (Collapse)AuthorFilesLines
2016-04-06Merge tag 'topic/drm-misc-2016-04-01' of ↵Dave Airlie1-4/+1
git://anongit.freedesktop.org/drm-intel into drm-next * tag 'topic/drm-misc-2016-04-01' of git://anongit.freedesktop.org/drm-intel: drm: Add new DCS commands in the enum list drm: Make uapi headers C89 pendantic compliant drm/atomic: export drm_atomic_helper_wait_for_fences() drm: Untangle __KERNEL__ guards drm: Move DRM_MODE_OBJECT_* to uapi headers drm: align #include directives with libdrm in uapi headers drm: Make drm.h uapi header safe for C++ vgacon: dummy implementation for vgacon_text_force drm/sysfs: Nuke TV/DVI property files drm/ttm: Remove TTM_HAS_AGP drm: bridge/dw-hdmi: Remove pre_enable/post_disable dummy funcs Revert "drm: Don't pass negative delta to ktime_sub_ns()" drm/atmel: Fixup drm_connector_/unplug/unregister/_all drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all() drm: bridge: Make (pre/post) enable/disable callbacks optional
2016-03-30Revert "drm: Don't pass negative delta to ktime_sub_ns()"Daniel Vetter1-4/+1
This reverts commit e91abf80a0998f326107874c88d549f94839f13c. Since commit 24e4a8c3e8868874835b0f1ad6dd417341e99822 Author: John Stultz <john.stultz@linaro.org> Date: Wed Jul 16 21:03:53 2014 +0000 ktime: Kill non-scalar ktime_t implementation for 2038 there is no longer a 32bit version that's unsigned, and we don't have to jump through ridiculous hoops to make the calculations correct. I didn't look whether there's more of this pattern in the kernel. Cc: John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459249942-21589-1-git-send-email-daniel.vetter@ffwll.ch
2016-03-14Merge drm-fixes into drm-next.Dave Airlie1-3/+70
Nouveau wanted this to avoid some worse conflicts when I merge that.
2016-02-17drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)Mario Kleiner1-2/+1
drm_vblank_offdelay can have three different types of values: < 0 is to be always treated the same as dev->vblank_disable_immediate = 0 is to be treated as "never disable vblanks" > 0 is to be treated as disable immediate if kms driver wants it that way via dev->vblank_disable_immediate. Otherwise it is a disable timeout in msecs. This got broken in Linux 3.18+ for the implementation of drm_vblank_on. If the user specified a value of zero which should always reenable vblank irqs in this function, a kms driver could override the users choice by setting vblank_disable_immediate to true. This patch fixes the regression and keeps the user in control. v2: Only reenable vblank if there are clients left or the user requested to "never disable vblanks" via offdelay 0. Enabling vblanks even in the "delayed disable" case (offdelay > 0) was specifically added by Ville in commit cd19e52aee922 ("drm: Kick start vblank interrupts at drm_vblank_on()"), but after discussion it turns out that this was done by accident. Citing Ville: "I think it just ended up as a mess due to changing some of the semantics of offdelay<0 vs. offdelay==0 vs. disable_immediate during the review of the series. So yeah, given how drm_vblank_put() works now, I'd just make this check for offdelay==0." Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 3.18+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4Mario Kleiner1-0/+16
Changes to drm_update_vblank_count() in Linux 4.4 broke the behaviour of the pre/post modeset functions as the new update code doesn't deal with hw vblank counter resets inbetween calls to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it should. This causes mistreatment of such hw counter resets as counter wraparound, and thereby large forward jumps of the software vblank counter which in turn cause vblank event dispatching and vblank waits to fail/hang --> userspace clients hang. This symptom was reported on radeon-kms to cause a infinite hang of KDE Plasma 5 shell's login procedure, preventing users from logging in. Fix this by detecting when drm_update_vblank_count() is called inside a pre->post modeset interval. If so, clamp valid vblank increments to the safe values 0 and 1, pretty much restoring the update behavior of the old update code of Linux 4.3 and earlier. Also reset the last recorded hw vblank count at call to drm_vblank_post_modeset() to be safe against hw that after modesetting, dpms on etc. only fires its first vblank irq after drm_vblank_post_modeset() was already called. Reported-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2)Mario Kleiner1-0/+43
This fixes a regression introduced by the new drm_update_vblank_count() implementation in Linux 4.4: Restrict the bump of the software vblank counter in drm_update_vblank_count() to a safe maximum value of +1 whenever there is the possibility that concurrent readers of vblank timestamps could be active at the moment, as the current implementation of the timestamp caching and updating is not safe against concurrent readers for calls to store_vblank() with a bump of anything but +1. A bump != 1 would very likely return corrupted timestamps to userspace, because the same slot in the cache could be concurrently written by store_vblank() and read by one of those readers in a non-atomic fashion and without the read-retry logic detecting this collision. Concurrent readers can exist while drm_update_vblank_count() is called from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank- irq callers. However, all those calls are happening with the vbl_lock locked thereby preventing a drm_vblank_get(), so the vblank refcount can't increase while drm_update_vblank_count() is executing. Therefore a zero vblank refcount during execution of that function signals that is safe for arbitrary counter bumps if called from outside vblank irq, whereas a non-zero count is not safe. Whenever the function is called from vblank irq, we have to assume concurrent readers could show up any time during its execution, even if the refcount is currently zero, as vblank irqs are usually only enabled due to the presence of readers, and because when it is called from vblank irq it can't hold the vbl_lock to protect it from sudden bumps in vblank refcount. Therefore also restrict bumps to +1 when the function is called from vblank irq. Such bumps of more than +1 can happen at other times than reenabling vblank irqs, e.g., when regular vblank interrupts get delayed by more than 1 frame due to long held locks, long irq off periods, realtime preemption on RT kernels, or system management interrupts. A better solution would be to rewrite the timestamp caching to use full seqlocks to allow concurrent writes and reads for arbitrary vblank counter increments. v2: Add code comment that this is essentially a hack and should be replaced by a full seqlock implementation for caching of timestamps. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-17drm: No-Op redundant calls to drm_vblank_off() (v2)Mario Kleiner1-1/+10
Otherwise if a kms driver calls into drm_vblank_off() more than once before calling drm_vblank_on() again, the redundant calls to vblank_disable_and_save() will call drm_update_vblank_count() while hw vblank counters and vblank timestamping are in a undefined state during modesets, dpms off etc. At least with the legacy drm helpers it is not unusual to get multiple calls to drm_vblank_off and drm_vblank_on, e.g., half a dozen calls to drm_vblank_off and two calls to drm_vblank_on were observed on radeon-kms during dpms-off -> dpms-on transition. We don't no-op calls from atomic modesetting drivers, as they should do a proper job of tracking hw state. Fixes large jumps of the software maintained vblank counter due to the hardware vblank counter resetting to zero during dpms off or modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on instead of drm_vblank_pre/post_modeset(). This fixes a regression caused by the changes made to drm_update_vblank_count() in Linux 4.4. v2: Don't no-op on atomic modesetting drivers, per suggestion of Daniel Vetter. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # 4.4+ Cc: michel@daenzer.net Cc: vbabka@suse.cz Cc: ville.syrjala@linux.intel.com Cc: alexander.deucher@amd.com Cc: christian.koenig@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-02-08drm/vblank: Use drm_event_reserve_initDaniel Vetter1-7/+4
Well we can't use that directly since that code must hold dev->event_lock already. Extract an _unlocked version. Embarrassingly I've totally forgotten about this patch and any kind of event-based vblank wait totally blew up, killing the kernel. v2: Pick the right base struct, someone didn't noticed that gcc was unhappy. No bug since the addresses at least matched (Daniel Stone) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453978864-1513-1-git-send-email-daniel.vetter@ffwll.ch
2016-01-25drm: Create drm_send_event helpersDaniel Vetter1-5/+2
Use them in the core vblank code and exynos/vmwgfx drivers. Note that the difference between wake_up_all and _interruptible in vmwgfx doesn't matter since the only waiter is the core code in drm_fops.c. And that is interruptible. v2: Adjust existing kerneldoc too. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Acked-by: Daniel Stone <daniels@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Inki Dae <inki.dae@samsung.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452548477-15905-6-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [danvet: Squash in compile fixup, spotted by 0-day.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-01-08drm: move MODULE_PARM_DESC to other fileDan Carpenter1-0/+3
We moved the module options from drm_drv.c to drm_irq.c in 18882995713d ('drm: Move vblank related module options into drm_irq.c'). Let's move the MODULE_PARM_DESC()s as well so they're together. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160108110045.GF32195@mwanda Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-04drm/nouveau: Fix pre-nv50 pageflip events (v4)Daniel Vetter1-1/+53
Apparently pre-nv50 pageflip events happen before the actual vblank period. Therefore that functionality got semi-disabled in commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 Author: Mario Kleiner <mario.kleiner.de@gmail.com> Date: Tue May 13 00:42:08 2014 +0200 drm/nouveau/kms/nv04-nv40: fix pageflip events via special case. Unfortunately that hack got uprooted in commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb Author: Thierry Reding <treding@nvidia.com> Date: Wed Aug 12 17:00:31 2015 +0200 drm/irq: Make pipe unsigned and name consistent Triggering a warning when trying to sample the vblank timestamp for a non-existing pipe. There's a few ways to fix this: - Open-code the old behaviour, which just enshrines this slight breakage of the userspace ABI. - Revert Mario's commit and again inflict broken timestamps, again not pretty. - Fix this for real by delaying the pageflip TS until the next vblank interrupt, thereby making it accurate. This patch implements the third option. Since having a page flip interrupt that happens when the pageflip gets armed and not when it completes in the next vblank seems to be fairly common (older i915 hw works very similarly) create a new helper to arm vblank events for such drivers. v2 (Mario Kleiner): - Fix function prototypes in drmP.h - Add missing vblank_put() for pageflip completion without pageflip event. - Initialize sequence number for queued pageflip event to avoid trouble in drm_handle_vblank_events(). - Remove dead code and spelling fix. v3 (Mario Kleiner): - Add a signed-off-by and cc stable tag per Ilja's advice. v4 (Thierry Reding): - Fix kerneldoc typo, discovered by Michel Dänzer - Rearrange tags and changelog Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431 Cc: Thierry Reding <treding@nvidia.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org # v4.3 Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-13drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() ↵Ville Syrjälä1-1/+9
wasn't called Seems the crtc helpers call drm_calc_timestamping_constants() unconditionally even if the driver didn't initialize vblank support by calling drm_vblank_init(). That used to be OK since the constants were stored under drm_crtc. However I broke this with commit eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc") when I moved the constants to live inside the drm_vblank_crtc struct instead. If drm_vblank_init() isn't called, we don't allocate these structures, and so drm_calc_timestamping_constants() will oops. Fix it by adding a check into drm_calc_timestamping_constants() to see if vblank support was initialized at all. And to keep in line with other such checks, also toss in a check and warn for the case where vblank support was initialized, but the wrong number of crtcs was specified. Fixes the following sort of oops: BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0 IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] PGD 0 Oops: 0002 [#1] SMP Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1 Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015 Workqueue: events work_for_cpu_fn task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000 RIP: 0010:[<ffffffffa014b266>] [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] RSP: 0018:ffff88007830f4e8 EFLAGS: 00010246 RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540 RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000 RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712 R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00 R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8 FS: 0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0 Stack: ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000 ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7 ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000 Call Trace: [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper] [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper] [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm] [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper] [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170 [<ffffffff8138cf70>] bit_update_start+0x20/0x50 [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590 [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240 [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310 [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0 [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0 [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750 [<ffffffff810a5599>] notifier_call_chain+0x49/0x70 [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70 [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff81394881>] register_framebuffer+0x1f1/0x330 [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper] [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200] [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200] [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200] [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm] [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm] [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200] [<ffffffff813662d5>] local_pci_probe+0x45/0xa0 [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20 [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0 [<ffffffff8109eaa4>] worker_thread+0x244/0x470 [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760 [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310 [<ffffffff810a4438>] kthread+0xd8/0xf0 [<ffffffff810a4360>] ? kthread_park+0x60/0x60 [<ffffffff8169030f>] ret_from_fork+0x3f/0x70 [<ffffffff810a4360>] ? kthread_park+0x60/0x60 Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b RIP [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm] RSP <ffff88007830f4e8> CR2: 00000000000000b0 Cc: Jeff Moyer <jmoyer@redhat.com> Reported-by: Jeff Moyer <jmoyer@redhat.com> References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html Fixes: eba1f35dfe14 ("drm: Move timestamping constants into drm_vblank_crtc") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-10-16drm: Add DRM_DEBUG_VBL()Ville Syrjälä1-11/+11
Add a new debug class for _verbose_ debug message from the vblank code. That is message we spew out potentially for every vblank interrupt. Thierry already got annoyed at the spew, and now I managed to lock up my box with these debug prints (seems serial console + a few debug prints every vblank aren't a good combination). Or should I maybe call it DRM_DEBUG_IRQ? Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-16drm: Don't use '\' for string literal concatenationVille Syrjälä1-2/+2
String literals get concatenated just fine on their own, no need to use '\'. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-07drm: Stop using drm_vblank_count() as the hw frame counterVille Syrjälä1-0/+17
drm_vblank_count() returns the software counter. We should not pretend it's the hw counter since we use the hw counter to figuere out what the software counter value should be. So instead provide a new function drm_vblank_no_hw_counter() for drivers that don't have a real hw counter. The new function simply returns 0, which is about the only thing it can do. Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Vincent Abriou <vincent.abriou@st.com> [danvet: s/int pipe/unsigned int pipe/ to follow Thierry's interface change.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-06drm/irq: Use unsigned int pipe in public APIThierry Reding1-1/+1
This continues the pattern started in commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent"). This is applied to the public APIs and driver callbacks, so pretty much all drivers need to be updated to match the new prototypes. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Inki Dae <inki.dae@samsung.com> Cc: Jianwei Wang <jianwei.wang.chn@gmail.com> Cc: Alison Wang <alison.wang@freescale.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-01drm: Don't zero vblank timestamps from the irq handlerVille Syrjälä1-3/+4
If we couldn't get a high precisions vblank timestamp, we currently store a zeroed timestamp instead and assume the next vblank irq to get us something better. This makes sense when trying to update the timestamp from eg. vblank enable. But if we do this from the vblank irq we will never get a vblank timestamp unless we high precision timestamps are available and succeeded. This break weston for instance on drivers lacking high precision timestamps. To fix this, zero the timestamp only when not called from vbl irq. When called from the irq, we still want the timestamp, even if not perfect. This fixes a regression from 4dfd64862ff852df drm: Use vblank timestamps to guesstimate how many vblanks were missed Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reported-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm/irq: Add drm_crtc_vblank_count_and_time()Thierry Reding1-0/+23
This function is the KMS native variant of drm_vblank_count_and_time(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm/irq: Rename drm_crtc -> crtcThierry Reding1-4/+4
Since the original crtc parameter was renamed to pipe, there is no longer a need to artificially prefix the CRTC parameter. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Use vblank timestamps to guesstimate how many vblanks were missedVille Syrjälä1-115/+91
When lacking am accurate hardware frame counter, we can fall back to using the vblank timestamps to guesstimagte how many vblanks have elapsed since the last time the vblank counter was updated. Take the oppostunity to unify the vblank_disable_and_save() and drm_handle_vblank_events() to call the same function (drm_update_vblank_count()) to perform the vblank updates. If the hardware/driver has an accurate frame counter use it instead of the timestamp based guesstimate. If the hardware/driver has neither a frame counter nor acurate vblank timestamps, we fall back to assuming that each drm_handle_vblank_events() should increment the vblank count by one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: store_vblank() is never called with NULL timestampVille Syrjälä1-7/+5
Remove the NULL 't_vblank' checks from store_vblank() since that will never happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Clean up drm_calc_vbltimestamp_from_scanoutpos() vbl_statusVille Syrjälä1-11/+8
Avoid confusion and don't use 'vbl_status' as both the .get_scanout_position() return value and the return value from drm_calc_vbltimestamp_from_scanoutpos(). While at it make 'vbl_status' unsigned and print it as hex in the debug prints since it's a bitmask. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Limit the number of .get_vblank_counter() retriesVille Syrjälä1-2/+4
Pontential infinite loops in the vblank code are a bad idea. Add some limits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Pass flags to drm_update_vblank_count()Ville Syrjälä1-4/+5
We'll soon have use for the 'flags' in drm_update_vblank_count() so pass it in. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Kill pixeldur_nsVille Syrjälä1-8/+5
pixeldur_ns is now unsued, so kill it from drm_vblank_crtc. framedur_ns is also currently unused but we will have use for it in the near future so leave it be. linedur_ns is still used by nouveau for some internal delays. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Stop using linedur_ns and pixeldur_ns for vblank timestampsVille Syrjälä1-11/+8
linedur_ns, and especially pixeldur_ns are becoming rather inaccurate to be used for the vblank timestamp correction. With 4k@60 the pixel duration is already below 2ns, so the amount of error due to the truncation to nanoseconds is introducing quite a bit of error. We can avoid such problems if we instead calculate the timestamp delta_ns directly from the dislay timings, avoiding the use of these intermediate truncated values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in fixup from Thierry Reding for amdgpu.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: Move timestamping constants into drm_vblank_crtcVille Syrjälä1-8/+8
Collect the timestamping constants alongside the rest of the relevant stuff under drm_vblank_crtc. We can now get rid of the 'refcrtc' parameter to drm_calc_vbltimestamp_from_scanoutpos(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-24drm: s/int crtc/unsigned int pipe/ stragglesVille Syrjälä1-8/+8
Finish the recent replacement of 'int pipe' with 'unsigned int pipe' Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-17Merge tag 'v4.2-rc7' into drm-nextDave Airlie1-1/+1
Linux 4.2-rc7 Backmerge master for i915 fixes
2015-08-12drm/irq: Document return values more consistentlyThierry Reding1-2/+5
Some of the functions are documented inconsistently. Add Returns: sections where missing and use consistent style to describe the return value. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Make pipe unsigned and name consistentThierry Reding1-157/+159
Name all references to the pipe number (CRTC index) consistently to make it easier to distinguish which is a pipe number and which is a pointer to struct drm_crtc. While at it also make all references to the pipe number unsigned because there is no longer any reason why it should ever be negative. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Check for valid VBLANK before dereferenceThierry Reding1-2/+9
When accessing the array of per-CRTC VBLANK structures we must always check that the index into the array is valid before dereferencing to avoid crashing. Signed-off-by: Thierry Reding <treding@nvidia.com> [danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12drm/irq: Remove negative CRTC index special-caseThierry Reding1-1/+1
The drm_send_vblank_event() function treats negative CRTC indices as meaning that a driver doesn't have proper VBLANK handling. This is the only place where DRM needs negative CRTC indices, so in order to enable subsequent cleanup, remove this special case and replace it by the more obvious check for whether or not VBLANK support was initialized. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-07drm/vblank: Use u32 consistently for vblank countersDaniel Vetter1-1/+1
In commit 99264a61dfcda41d86d0960cf2d4c0fc2758a773 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 15 19:34:43 2015 +0200 drm/vblank: Fixup and document timestamp update/read barriers I've switched vblank->count from atomic_t to unsigned long and accidentally created an integer comparison bug in drm_vblank_count_and_time since vblanke->count might overflow the u32 local copy and hence the retry loop never succeed. Fix this by consistently using u32. Cc: Michel Dänzer <michel@daenzer.net> Reported-by: Michel Dänzer <michel@daenzer.net> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-15drm: Fix warning with make xmldocs caused by drm_irq.cMasanari Iida1-1/+1
This patch fix following warnings. Warning(.//drivers/gpu/drm/drm_irq.c:1279): No description found for parameter drm_crtc' Warning(.//drivers/gpu/drm/drm_irq.c:1279): Excess function parameter 'crtc' description in 'drm_crtc_vblank_reset' Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-04Merge branch 'virtio-gpu-drm-next' of git://git.kraxel.org/linux into drm-nextDave Airlie1-0/+3
Yay, thanks to Gerd for pull this together. * 'virtio-gpu-drm-next' of git://git.kraxel.org/linux: Add MAINTAINERS entry for virtio-gpu. Add virtio gpu driver. drm_vblank_get: don't WARN_ON in case vblanks are not initialized break kconfig dependency loop
2015-06-02drm_vblank_get: don't WARN_ON in case vblanks are not initializedGerd Hoffmann1-0/+3
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-05-27drm: Fix off-by-one in vblank hardware counter wraparound handlingMichel Dänzer1-2/+2
dev->max_vblank_count contains the largest value that can be represented by the hardware counter. When the hardware counter wraps around, we have to add that value + 1 to get the same value as if the hardware counter didn't wrap around. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04drm: Zero out invalid vblank timestamp in drm_update_vblank_count. (v2)Mario Kleiner1-3/+6
Since commit 844b03f27739135fe1fed2fef06da0ffc4c7a081 we make sure that after vblank irq off, we return the last valid (vblank count, vblank timestamp) pair to clients, e.g., during modesets, which is good. An overlooked side effect of that commit for kms drivers without support for precise vblank timestamping is that at vblank irq enable, when we update the vblank counter from the hw counter, we can't update the corresponding vblank timestamp, so now we have a totally mismatched timestamp for the new count to confuse clients. Restore old client visible behaviour from before Linux 3.18, but zero out the timestamp at vblank counter update (instead of disable as in original implementation) if we can't generate a meaningful timestamp immediately for the new vblank counter. This will fix this regression, so callers know they need to retry again later if they need a valid timestamp, but at the same time preserves the improvements made in the commit mentioned above. v2: Rebased on top of Daniel Vetter's fixup and documentation patch for timestamp updates. Drop request for stable kernel backport as this would be more difficult, unless the original patch would get applied to stable kernels. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04drm: Prevent invalid use of vblank_disable_immediate. (v2)Mario Kleiner1-0/+7
For a kms driver to support immediate disable of vblank irq's reliably without introducing off by one errors or other mayhem for clients, it must not only support a hardware vblank counter query, but also high precision vblank timestamping, so vblank count and timestamp can be instantaneously reinitialzed to valid values. Additionally the exposed hardware counter must behave as if it is incrementing at leading edge of vblank to avoid off by one errors during reinitialization of the counter while the display happens to be inside or close to vblank. Check during drm_vblank_init that a driver which claims to be capable of vblank_disable_immediate at least supports high precision timestamping and prevent use of instant disable if that isn't present as a minimum requirement. v2: Changed from DRM_ERROR to DRM_INFO and made message more clear, as suggested by Michel Dänzer. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04drm/vblank: Fixup and document timestamp update/read barriersDaniel Vetter1-44/+51
This was a bit too much cargo-culted, so lets make it solid: - vblank->count doesn't need to be an atomic, writes are always done under the protection of dev->vblank_time_lock. Switch to an unsigned long instead and update comments. Note that atomic_read is just a normal read of a volatile variable, so no need to audit all the read-side access specifically. - The barriers for the vblank counter seqlock weren't complete: The read-side was missing the first barrier between the counter read and the timestamp read, it only had a barrier between the ts and the counter read. We need both. - Barriers weren't properly documented. Since barriers only work if you have them on boths sides of the transaction it's prudent to reference where the other side is. To avoid duplicating the write-side comment 3 times extract a little store_vblank() helper. In that helper also assert that we do indeed hold dev->vblank_time_lock, since in some cases the lock is acquired a few functions up in the callchain. Spotted while reviewing a patch from Chris Wilson to add a fastpath to the vblank_wait ioctl. v2: Add comment to better explain how store_vblank works, suggested by Chris. v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the implicit barrier in the spin_unlock. But that can only be proven by auditing all callers and my point in extracting this little helper was to localize all the locking into just one place. Hence I think that additional optimization is too risky. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Peter Hurley <peter@hurleysoftware.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-03-09Merge tag 'drm-intel-next-2015-02-27' of ↵Dave Airlie1-10/+46
git://anongit.freedesktop.org/drm-intel into drm-next - Y tiling support for scanout from Tvrtko&Damien - Remove more UMS support - some small prep patches for OLR removal from John Harrison - first few patches for dynamic pagetable allocation from Ben Widawsky, rebased by tons of other people - DRRS support patches (Sonika&Vandana) - fbc patches from Paulo - make sure our vblank callbacks aren't called when the pipes are off - various patches all over * tag 'drm-intel-next-2015-02-27' of git://anongit.freedesktop.org/drm-intel: (61 commits) drm/i915: Update DRIVER_DATE to 20150227 drm/i915: Clarify obj->map_and_fenceable drm/i915/skl: Allow Y (and Yf) frame buffer creation drm/i915/skl: Update watermarks for Y tiling drm/i915/skl: Updated watermark programming drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling drm/i915/skl: Allow scanning out Y and Yf fbs drm/i915/skl: Add new displayable tiling formats drm/i915: Remove DRIVER_MODESET checks from modeset code drm/i915: Remove regfile code&data for UMS suspend/resume drm/i915: Remove DRIVER_MODESET checks from gem code drm/i915: Remove DRIVER_MODESET checks in the gpu reset code drm/i915: Remove DRIVER_MODESET checks from suspend/resume code drm/i915: Remove DRIVER_MODESET checks in load/unload/close code drm/i915: fix a printk format drm/i915: Add media rc6 residency file to sysfs drm/i915: Add missing description to parameter in alloc_pt_range drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions ...
2015-02-23drm: Fix drm_crtc_vblank_get() documentationDamien Lespiau1-1/+1
drm_crtc_vblank_get() is the new drm_vblank_get(), not the new drm_vblank_off(). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-23drm: WARN if drm_handle_vblank is called errornouslyDaniel Vetter1-1/+1
KMS drivers are in full control of their irq and vblank handling, if they get a vblank interrupt before drm_vblank_init or after drm_vblank_cleanup that's just a driver bug. For ums driver there's only r128 and radeon which support vblank, and they call drm_vblank_init in their driver load functions. Which again means that userspace can do whatever it wants with interrupt, vblank structures will always be there. So this should never happen, let's catch driver issues with a WARN_ON. Motivated by some discussions with Imre. v2: Use WARN_ON_ONCE as suggested by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-02-23drm/irq: Don't call ->get_vblank_counter directly from irq_uninstall/cleanupDaniel Vetter1-9/+13
The pipe might already have been shut down, and then it's not a good idea to call hw accessor functions. Instead use the same logic as drm_vblank_off which has all the necessary checks to avoid troubles or inconsistency. Noticed by Imre while reviewing my patches to remove some sanity checks from ->get_vblank_counter. v2: Try harder. disable_and_save can still access the vblank stuff when vblank->enabled isn't set. It has to, since vlbank irq could be disable but the pipe is still on when being called from drm_vblank_off. But we still want to use that code for more code sharing. So add a check for vblank->enabled on top - if that's not set we shouldn't have anyone waiting for the vblank. If we have that's a pretty serious bug. The other issue that Imre spotted is drm_vblank_cleanup. That code again calls disable_and_save and so suffers from the same issues. But really drm_irq_uninstall should have cleaned that all up, so replace the code with WARN_ON. Note that we can't delete the timer cleanup since drivers aren't required to use drm_irq_install/uninstall, but can do their own irq handling. v3: Make it clear that all that gunk in drm_irq_uninstall is really just bandaids for UMS races between the irq/vblank code. In UMS userspace is in control of enabling/disabling interrupts in general and vblanks specifically. v4: Imre observed that KMS drivers all call drm_vblank_cleanup before drm_irq_uninstall (as they should), so again the code in there is dead for KMS (due to dev->num_crtcs == 0 after drm_vblank_cleanup). Or should be, so only WARN for KMS - with UMS userspace could try to do evil things. v5: After more discussion on irc we've gone back to v3: the del_timer_sync is required in all cases in drm_vblank_cleanup, but let's restrict the WARN_ON to kms drivers only. Imre was also concerned that bad things could happen without the disable_and_save call. But we immediately free vblank structures afterwards which makes the save useless. And drm_handle_vblank has a check for dev->num_crtcs to avoid surprises with ums. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-02-23drm/irq: Add drm_crtc_vblank_resetDaniel Vetter1-0/+32
At driver load we need to tell the vblank code about the state of the pipes, so that the logic around reject vblank_get when the pipe is off works correctly. Thus far i915 used drm_vblank_off, but one of the side-effects of it is that it also saves the vblank counter. And for that it calls down into the ->get_vblank_counter hook. Which isn't really a good idea when the pipe is off for a few reasons: - With runtime pm the register might not respond. - If the pipe is off some datastructures might not be around or unitialized. The later is what blew up on gen3: We look at intel_crtc->config to compute the vblank counter, and for a disabled pipe at boot-up that's just not there. Thus far this was papered over by a check for intel_crtc->active, but I want to get rid of that (since it's fairly race, vblank hooks are called from all kinds of places). So prep for that by adding a _reset functions which only does what we really need to be done at driver load: Mark the vblank pipe as off, but don't do any vblank counter saving or event flushing - neither of that is required. v2: Clarify the code flow slightly as suggested by Ville. v3: Fix kerneldoc spelling, spotted by Laurent. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v2) Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-29drm/irq: Don't disable vblank interrupts when already disabledLaurent Pinchart1-2/+9
The .enable_vblank() operation is only called when vblank interrupts are disabled, but no similar check exists when disabling vblank interrupts. This leads to .disable_vblank() being called with vblank interrupts already disabled and the device possibly runtime suspended. As the operation is called with a spinlock held drivers can't runtime resume the device there and thus must avoid touching device registers in that case, requiring vblank refcounting. As the DRM core tracks whether vblank interrupts are enabled just skip the .disable_vblank() call when the interrupts are already disabled. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-09Merge tag 'topic/core-stuff-2014-12-19' of ↵Dave Airlie1-5/+6
git://anongit.freedesktop.org/drm-intel into drm-next Misc drm patches with mostly polish patches from Thierry, with a bit of generic mode validation from Ville and a few other oddball things. * tag 'topic/core-stuff-2014-12-19' of git://anongit.freedesktop.org/drm-intel: (25 commits) drm: Include drm_crtc_helper.h in DocBook drm: Make drm_crtc_helper.h standalone includible drm: Move IRQ related fields to proper section drm: Remove stale comment drm: Do basic sanity checks for user modes drm: Perform basic sanity checks on probed modes drm: Reorganize probed mode validation drm/doc: Remove duplicate "by" drm/info: Remove unused code drm/cache: Use wbinvd helpers drm/plane-helper: Test for plane disable earlier drm/doc: Document drm_add_modes_noedid() usage drm: bit of spell-check / editorializing. drm: Prefer sizeof(type) over sizeof type drm: Remove useless else block drm: Remove unneeded braces for single statement blocks drm: Do not assign in if condition drm: Prefer kmalloc_array() over kmalloc() with multiply drm: Prefer kcalloc() over kzalloc() with multiply drm: Miscellaneous checkpatch whitespace cleanups ...
2014-12-17drm/irq: Add drm_crtc_vblank_count()Thierry Reding1-0/+21
This function is the KMS native variant of drm_vblank_count(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/irq: Add drm_crtc_handle_vblank()Thierry Reding1-0/+20
This function is the KMS native variant of drm_handle_vblank(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 09:49:28 +0000