linux/drivers/gpu/drm/Makefile, branch v5.9

Merge tag 'drm-xilinx-dpsub-20200718' of git://linuxtv.org/pinchartl/media into drm-next

2020-07-23T05:31:38Z

Xilinx ZynqMP DisplayPort Subsystem driver Signed-off-by: Dave Airlie From: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20200718001755.GA5962@pendragon.ideasonboard.com

drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem

2020-07-17T23:59:16Z

The Xilinx ZynqMP SoC has a hardened display pipeline named DisplayPort Subsystem. It includes a buffer manager, a video pipeline renderer (blender), an audio mixer and a DisplayPort source controller (transmitter). The DMA engine the provide data to the buffer manager, as well as the DisplayPort PHYs that drive the lanes, are external to the subsystem and interfaced using the DMA engine and PHY APIs respectively. This driver supports the DisplayPort Subsystem and implements - Two planes, for graphics and video - One CRTC that supports alpha blending - One encoder for the DisplayPort transmitter - One connector for an external monitor It currently doesn't support - Color keying - Test pattern generation - Audio - Live input from the Programmable Logic (FPGA) - Output to the Programmable Logic (FPGA) Signed-off-by: Hyun Kwon Signed-off-by: Laurent Pinchart

drm/vblank: Add vblank works

2020-07-16T22:16:31Z

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled - whichever comes first. Whatever hardware programming we do in the work must be fast (must at least complete during the vblank or scanout period, sometimes during the first few scanlines of the vblank). As such we use a high-priority per-CRTC thread to accomplish this. Changes since v7: * Stuff drm_vblank_internal.h and drm_vblank_work_internal.h contents into drm_internal.h * Get rid of unnecessary spinlock in drm_crtc_vblank_on() * Remove !vblank->worker check * Grab vbl_lock in drm_vblank_work_schedule() * Mention self-rearming work items in drm_vblank_work_schedule() kdocs * Return 1 from drm_vblank_work_schedule() if the work was scheduled successfully, 0 or error code otherwise * Use drm_dbg_core() instead of DRM_DEV_ERROR() in drm_vblank_work_schedule() * Remove vblank->worker checks in drm_vblank_destroy_worker() and drm_vblank_flush_worker() Changes since v6: * Get rid of ->pending and seqcounts, and implement flushing through simpler means - danvet * Get rid of work_lock, just use drm_device->event_lock * Move drm_vblank_work item cleanup into drm_crtc_vblank_off() so that we ensure that all vblank work has finished before disabling vblanks * Add checks into drm_crtc_vblank_reset() so we yell if it gets called while there's vblank workers active * Grab event_lock in both drm_crtc_vblank_on()/drm_crtc_vblank_off(), the main reason for this is so that other threads calling drm_vblank_work_schedule() are blocked from attempting to schedule while we're in the middle of enabling/disabling vblanks. * Move drm_handle_vblank_works() call below drm_handle_vblank_events() * Simplify drm_vblank_work_cancel_sync() * Fix drm_vblank_work_cancel_sync() documentation * Move wake_up_all() calls out of spinlock where we can. The only one I left was the call to wake_up_all() in drm_vblank_handle_works() as this seemed like it made more sense just living in that function (which is all technically under lock) * Move drm_vblank_work related functions into their own source files * Add drm_vblank_internal.h so we can export some functions we don't want drivers using, but that we do need to use in drm_vblank_work.c * Add a bunch of documentation Changes since v4: * Get rid of kthread interfaces we tried adding and move all of the locking into drm_vblank.c. For implementing drm_vblank_work_flush(), we now use a wait_queue and sequence counters in order to differentiate between multiple work item executions. * Get rid of drm_vblank_work_cancel() - this would have been pretty difficult to actually reimplement and it occurred to me that neither nouveau or i915 are even planning to use this function. Since there's also no async cancel function for most of the work interfaces in the kernel, it seems a bit unnecessary anyway. * Get rid of to_drm_vblank_work() since we now are also able to just pass the struct drm_vblank_work to work item callbacks anyway Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Tejun Heo Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Reviewed-by: Daniel Vetter Co-developed-by: Ville Syrjälä Signed-off-by: Lyude Paul Acked-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-4-lyude@redhat.com

drm/cirrus: Move to drm/tiny

2020-04-28T14:05:15Z

Because it is. Huge congrats to everyone who made this kind of refactoring happen! Acked-by: Gerd Hoffmann Reviewed-by: Thomas Zimmermann Acked-by: Sam Ravnborg Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Link: https://patchwork.freedesktop.org/patch/msgid/20200415074034.175360-38-daniel.vetter@ffwll.ch

drm/vram-helpers: Merge code into a single file

2020-04-09T07:56:33Z

Most of the documentation was in an otherwise empty file, which was probably just left from a previous clean-up effort. So move code and documentation into a single file. Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200331081238.24749-1-tzimmermann@suse.de

drm: add managed resources tied to drm_device

2020-03-26T13:49:13Z

We have lots of these. And the cleanup code tends to be of dubious quality. The biggest wrong pattern is that developers use devm_, which ties the release action to the underlying struct device, whereas all the userspace visible stuff attached to a drm_device can long outlive that one (e.g. after a hotunplug while userspace has open files and mmap'ed buffers). Give people what they want, but with more correctness. Mostly copied from devres.c, with types adjusted to fit drm_device and a few simplifications - I didn't (yet) copy over everything. Since the types don't match code sharing looked like a hopeless endeavour. For now it's only super simplified, no groups, you can't remove actions (but kfree exists, we'll need that soon). Plus all specific to drm_device ofc, including the logging. Which I didn't bother to make compile-time optional, since none of the other drm logging is compile time optional either. One tricky bit here is the chicken&egg between allocating your drm_device structure and initiliazing it with drm_dev_init. For perfect onion unwinding we'd need to have the action to kfree the allocation registered before drm_dev_init registers any of its own release handlers. But drm_dev_init doesn't know where exactly the drm_device is emebedded into the overall structure, and by the time it returns it'll all be too late. And forcing drivers to be able clean up everything except the one kzalloc is silly. Work around this by having a very special final_kfree pointer. This also avoids troubles with the list head possibly disappearing from underneath us when we release all resources attached to the drm_device. v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless shuffling while getting everything into shape. v3: Add static to add/del_dr (Neil) Move typo fix to the right patch (Neil) v4: Enforce contract for drmm_add_final_kfree: Use ksize() to check that the drm_device is indeed contained somewhere in the final kfree(). Because we need that or the entire managed release logic blows up in a pile of use-after-frees. Motivated by a discussion with Laurent. v5: Review from Laurent: - %zu instead of casting size_t - header guards - sorting of includes - guarding of data assignment if we didn't allocate it for a NULL pointer - delete spurious newline - cast void* data parameter correctly in ->release call, no idea how this even worked before v6: Review from Sam - Add the kerneldoc for the managed sub-struct back in, even if it doesn't show up in the generated html somehow. - Explain why __always_inline. - Fix bisectability around the final kfree() in drm_dev_relase(). This is just interim code which will disappear again. - Some whitespace polish. - Add debug output when drmm_add_action or drmm_kmalloc fail. v7: My bisectability fix wasn't up to par as noticed by smatch. v8: Remove unecessary {} around if else v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr() helper (Thomas). v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow we need to wrap that in kstrdup_const() too!! Also renumber revision log, I somehow reset it midway thruh. Reviewed-by: Sam Ravnborg Cc: Thomas Zimmermann Cc: Dan Carpenter Cc: Sam Ravnborg Cc: Laurent Pinchart Cc: Neil Armstrong Cc: "Rafael J. Wysocki" Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch

drm: Add helper to create a connector for a chain of bridges

2020-02-26T11:31:41Z

Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector needs to be moved to the display controller driver. To avoid code duplication in display controller drivers, add a new helper to create and manage a DRM connector backed by a chain of bridges. All connector operations are delegating to the appropriate bridge in the chain. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon Acked-by: Sam Ravnborg Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-21-laurent.pinchart@ideasonboard.com

drm/tidss: New driver for TI Keystone platform Display SubSystem

2020-01-27T17:27:30Z

This patch adds a new DRM driver for Texas Instruments DSS IPs used on Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is a major change to the older DSS IP versions, which are supported by the omapdrm driver. While on higher level the Keystone DSS resembles the older DSS versions, the registers are completely different and the internal pipelines differ a lot. DSS IP found on K2G is an "ultra-light" version, and has only a single plane and a single output. The K3 DSS IPs are found on AM65x and J721E SoCs. AM65x DSS has two video ports, one full video plane, and another "lite" plane without scaling support. J721E has 4 video ports, 2 video planes and 2 lite planes. AM65x DSS has also an integrated OLDI (LVDS) output. Version history: v2: - rebased on top of drm-next-2019-11-27 - sort all include lines in all files - remove all include - remove select "select VIDEOMODE_HELPERS" - call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no to call it in new modeset case as it is also called in vp_enable()) - change probe sequence and drm_device allocation (follow example in drm_drv.c) - use __maybe_unused instead of #ifdef for pm functions - remove "struct drm_fbdev_cma *fbdev;" from driver data - check panel connector type before connecting it v3: no change v4: no change v5: - remove fifo underflow irq handling, it is not an error and it should be used for debug purposes only - memory tuning, prefetch plane fifo up to high-threshold value to minimize possibility of underflows. v6: - Check CTM and gamma support from dispc_features when creating crtc - Implement CTM support for k2g and fix k3 CTM implementation - Remove gamma property persistence and always write color properties in a new modeset v7: - Fix checkpatch.pl --strict issues - Rebase on top of drm-misc-next-2020-01-10 v8: - Remove idle debug prints from dispc_init() - Add Reviewed-by: Benoit Parrot v9: - Rename dispc_write_irqenable() to dispc_set_irqenable() to avoid conflict exported omapfb function with same name - Add Signed-off-by: Tomi Valkeinen Co-developed-by: Tomi Valkeinen Signed-off-by: Jyri Sarha Acked-by: Sam Ravnborg Reviewed-by: Benoit Parrot Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/925fbfad58ff828e8e07fdff7073a0ee65750c3d.1580129724.git.jsarha@ti.com

drm/pci: Only build drm_pci.c if CONFIG_PCI is set

2019-12-05T07:43:14Z

Non-PCI systems should not build PCI helpers. Set up source code, header file and Makefile accordingly. Signed-off-by: Thomas Zimmermann Reviewed-by: Emil Velikov Reviewed-by: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20191203100406.9674-2-tzimmermann@suse.de

drm/r128: make ATI PCI GART part of its only user, r128

2019-11-20T09:09:05Z

The ATI Rage 128 driver has been the only user of ATI PCI GART code since Radeon dropped UMS support in commit 8333f607a631 ("drm/radeon: remove UMS support"). Clean up the drm top level directory, Kconfig and Makefile by making ati_pcigart.[ch] part of r128. Drop the CONFIG_DRM_ATI_PCIGART config option made redundant by the change. This reduces drm.ko module size slightly when legacy drivers are enabled, and moves the baggage to r128.ko instead. Cc: Alex Deucher Cc: Daniel Vetter Cc: Dave Airlie Reviewed-by: Daniel Vetter Reviewed-by: Alex Deucher Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20191119100536.12024-1-jani.nikula@intel.com