BMC/Intel-BMC/linux.git/include/drm/drm_drv.h, branch master

drm: introduce sync objects (v4)

2017-06-14T02:10:22+00:00

Sync objects are new toplevel drm object, that contain a pointer to a fence. This fence can be updated via command submission ioctls via drivers. There is also a generic wait obj API modelled on the vulkan wait API (with code modelled on some amdgpu code). These objects can be converted to an opaque fd that can be passes between processes. v2: rename reference/unreference to put/get (Chris) fix leaked reference (David Zhou) drop mutex in favour of cmpxchg (Chris) v3: cleanups from danvet, rebase on drm_fops rename check fd_flags is 0 in ioctls. v4: export find/free, change replace fence to take a syncobj. In order to support lookup first, replace later semantics which seem in the end to be cleaner. Reviewed-by: Sean Paul Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie

drm/doc: Polish irq helper documentation

2017-06-01T06:02:14+00:00

Pull a (much shorter) overview into drm_irq.c, and instead put the callback documentation into in-line comments in drm_drv.h. v2: Move the include stanzas back to the split-up patch (Stefan). Cc: Stefan Agner Reviewed-by: Stefan Agner Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170531092253.12833-1-daniel.vetter@ffwll.ch

drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

2017-05-10T08:21:31+00:00

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner Cc: Eric Anholt Cc: Rob Clark Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Reviewed-by: Neil Armstrong Acked-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch

drm/vblank: Add FIXME comments about moving the vblank ts hooks

2017-05-10T08:21:22+00:00

This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Acked-by: Ville Syrjälä Reviewed-by: Neil Armstrong Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-3-daniel.vetter@ffwll.ch

drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

2017-05-10T08:21:17+00:00

It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3: kbuild says v1 was better ... Cc: Mario Kleiner Cc: Eric Anholt Cc: Rob Clark Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Reviewed-by: Ville Syrjälä Reviewed-by: Neil Armstrong Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch

drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

2017-05-10T08:21:08+00:00

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula Cc: Mario Kleiner Cc: Eric Anholt Cc: Rob Clark Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher Cc: Christian König Cc: Ben Skeggs Reviewed-by: Neil Armstrong Acked-by: Ville Syrjälä Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch

drm: Nerf the preclose callback for modern drivers

2017-05-09T11:22:11+00:00

With all drivers converted there's only legacy dri1 drivers using it. Not going to touch those, instead just hide it like we've done with other dri1 driver hooks like firstopen. In all this I didn't find any real reason why we'd needed 2 hooks, and having symmetry between open and close just appeases my OCD better. Yeah, someone else could do an s/postclose/close/, but that's for someone who understands cocci. And maybe after this series is reviewed and landed, to avoid patch-regen churn. v2: s/last/post/close in the kernel-doc (Sean). Reviewed-by: Sean Paul Reviewed-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170508082633.4214-4-daniel.vetter@ffwll.ch

drm: drop extern from function decls

2017-03-24T08:36:06+00:00

It's the default storage class for functions, entirely redundant. And a lot of these headers are a bit inconsistent due to organically grown. Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170322083617.13361-2-daniel.vetter@ffwll.ch

drm/doc: Document drm_file.[hc]

2017-03-14T13:38:33+00:00

Well, mostly drm_file.h, and clean up all related things: - I didnt' figure out the difference between preclose and postclose. The existing explanation in drm-internals.rst didn't convince me, since it's also really outdated - we clean up pending DRM events in the core nowadays. I put a FIXME in for the future. - Another FIXME is to have a macro for default fops. - Lots of links all around, main areas are to tie the overview in drm_file.c more into the callbacks in struct drm_device, and the other is to link render/primary node code to the right sections in drm-uapi.rst. - Also moved the open/close stuff to drm_drv.h from drm-internals.rst, seems like the better place for that information. Since that section was rather outdated this amounted to full-on rewrite. A big missing piece here is some overview graph, but I think better to wait with that one until drm_device and drm_driver are also fully documented. v2: Nits from Sean. Reviewed-by: Sean Paul Reviewed-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170308141257.12119-12-daniel.vetter@ffwll.ch

drm/debugfs: Remove the drm_driver.debugfs_cleanup callback

2017-03-08T10:29:08+00:00

Remove the .debugfs_cleanup() callback now that all the users are gone. Signed-off-by: Noralf Trønnes Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170307204924.1002-3-noralf@tronnes.org