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

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

Merge drm/drm-next into drm-misc-next

2019-10-03T14:38:50Z

We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard

drm/vram: Move VRAM memory manager to GEM VRAM implementation

2019-09-12T17:54:04Z

The separation between GEM VRAM objects and the memory manager is artificial, as they are only used with each other. Copying both implementations into the same file is a first step to simplifying the code. This patch only moves code without functional changes. v3: * update to use dev->vma_offset_manager v2: * update for debugfs support * typos in commit message Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Link: https://patchwork.freedesktop.org/patch/msgid/20190911110910.30698-2-tzimmermann@suse.de

drm/ttm: add drm gem ttm helpers, starting with drm_gem_ttm_print_info()

2019-09-10T06:53:08Z

Now with ttm_buffer_object being a subclass of drm_gem_object we can easily lookup ttm_buffer_object for a given drm_gem_object, which in turn allows to create common helper functions. This patch starts off with a drm_gem_ttm_print_info() helper function which adds some ttm specific lines to the debug output. Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20190904054740.20817-3-kraxel@redhat.com