License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2015-10-29 08:36:23 +00:00
|
|
|
|
2008-05-29 00:09:59 +00:00
|
|
|
# Makefile for the drm device driver. This driver provides support for the
|
|
|
|
|
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
|
|
|
|
|
|
2019-04-18 07:10:40 +00:00
|
|
|
drm-y := drm_auth.o drm_cache.o \
|
2017-03-08 14:12:40 +00:00
|
|
|
drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
|
2019-12-03 10:03:55 +00:00
|
|
|
drm_memory.o drm_drv.o \
|
2016-12-13 19:24:34 +00:00
|
|
|
drm_sysfs.o drm_hashtab.o drm_mm.o \
|
2016-06-09 09:54:08 +00:00
|
|
|
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
|
2018-11-21 21:35:10 +00:00
|
|
|
drm_encoder_slave.o \
|
2018-10-19 08:54:23 +00:00
|
|
|
drm_trace_points.o drm_prime.o \
|
2013-11-19 17:10:12 +00:00
|
|
|
drm_rect.o drm_vma_manager.o drm_flip_work.o \
|
2016-08-15 14:07:02 +00:00
|
|
|
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
|
2016-08-29 08:27:49 +00:00
|
|
|
drm_framebuffer.o drm_connector.o drm_blend.o \
|
2016-09-21 08:59:24 +00:00
|
|
|
drm_encoder.o drm_mode_object.o drm_property.o \
|
2016-11-14 11:58:16 +00:00
|
|
|
drm_plane.o drm_color_mgmt.o drm_print.o \
|
2017-04-04 03:26:24 +00:00
|
|
|
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
|
2018-09-05 13:57:11 +00:00
|
|
|
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
|
drm: add managed resources tied to drm_device
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 <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Neil Armstrong <narmstrong@baylibre.com
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200324124540.3227396-1-daniel.vetter@ffwll.ch
2020-03-24 12:45:40 +00:00
|
|
|
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o \
|
drm/vblank: Add vblank works
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 <tj@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200627194657.156514-4-lyude@redhat.com
2020-04-17 19:33:13 +00:00
|
|
|
drm_managed.o drm_vblank_work.o
|
2008-05-29 00:09:59 +00:00
|
|
|
|
2019-04-18 07:10:40 +00:00
|
|
|
drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o
|
2016-12-22 08:36:08 +00:00
|
|
|
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
|
2017-01-04 09:12:56 +00:00
|
|
|
drm-$(CONFIG_DRM_VM) += drm_vm.o
|
2008-05-29 00:09:59 +00:00
|
|
|
drm-$(CONFIG_COMPAT) += drm_ioc32.o
|
2012-06-27 13:30:18 +00:00
|
|
|
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
|
2019-03-13 00:43:44 +00:00
|
|
|
drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
|
2013-08-30 11:36:43 +00:00
|
|
|
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
|
2014-06-15 10:07:12 +00:00
|
|
|
drm-$(CONFIG_OF) += drm_of.o
|
2015-09-09 14:45:52 +00:00
|
|
|
drm-$(CONFIG_AGP) += drm_agpsupport.o
|
2019-12-03 10:03:55 +00:00
|
|
|
drm-$(CONFIG_PCI) += drm_pci.o
|
2016-10-06 15:21:06 +00:00
|
|
|
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
|
drm: handle override and firmware EDID at drm_do_get_edid() level
Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data, such as audio parameters.
This change also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe. This is useful if the reason for
preferring override EDID are problems with reading the data, or
corruption of the data.
Move firmware EDID loading from helper to core, as the functionality
moves to lower level as well. This will result in a change of module
parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
arguably makes more sense anyway.
Some future work remains related to override and firmware EDID
validation. Like before, no validation is done for override EDID. The
firmware EDID is validated separately in the loader. Some unification
and deduplication would be in order, to validate all of them at the
drm_do_get_edid() level, like "real" EDIDs.
v2: move firmware loading to core
v3: rebase, commit message refresh
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e8a710bcac46e5136c1a7b430074893c81f364a.1505203831.git.jani.nikula@intel.com
2017-09-12 08:19:26 +00:00
|
|
|
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
|
2008-05-29 00:09:59 +00:00
|
|
|
|
2020-03-31 08:12:38 +00:00
|
|
|
drm_vram_helper-y := drm_gem_vram_helper.o
|
2019-05-08 08:26:11 +00:00
|
|
|
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
|
|
|
|
|
|
2019-09-04 05:47:35 +00:00
|
|
|
drm_ttm_helper-y := drm_gem_ttm_helper.o
|
|
|
|
|
obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
|
|
|
|
|
|
2020-02-26 11:24:40 +00:00
|
|
|
drm_kms_helper-y := drm_bridge_connector.o drm_crtc_helper.o drm_dp_helper.o \
|
|
|
|
|
drm_dsc.o drm_probe_helper.o \
|
2016-01-21 23:10:18 +00:00
|
|
|
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
|
2016-06-10 14:55:59 +00:00
|
|
|
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
|
2017-03-13 11:23:59 +00:00
|
|
|
drm_simple_kms_helper.o drm_modeset_helper.o \
|
2018-10-04 20:24:28 +00:00
|
|
|
drm_scdc_helper.o drm_gem_framebuffer_helper.o \
|
2019-04-05 09:52:15 +00:00
|
|
|
drm_atomic_state_helper.o drm_damage_helper.o \
|
2019-06-12 14:50:19 +00:00
|
|
|
drm_format_helper.o drm_self_refresh_helper.o
|
2016-01-21 23:10:18 +00:00
|
|
|
|
2017-06-06 14:31:50 +00:00
|
|
|
drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
|
2015-08-05 06:58:57 +00:00
|
|
|
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
|
2012-07-02 14:37:47 +00:00
|
|
|
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
|
2016-01-21 23:10:19 +00:00
|
|
|
drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
|
2018-07-11 13:29:07 +00:00
|
|
|
drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
|
2009-09-07 05:45:33 +00:00
|
|
|
|
2009-09-08 01:08:32 +00:00
|
|
|
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
|
2018-05-03 11:22:16 +00:00
|
|
|
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
|
2009-09-07 05:45:33 +00:00
|
|
|
|
2008-05-29 00:09:59 +00:00
|
|
|
obj-$(CONFIG_DRM) += drm.o
|
2019-07-22 10:43:11 +00:00
|
|
|
obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
|
2013-12-04 15:35:12 +00:00
|
|
|
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
|
2017-11-25 19:35:48 +00:00
|
|
|
obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
|
2018-12-05 03:41:35 +00:00
|
|
|
obj-y += arm/
|
2009-06-22 16:16:13 +00:00
|
|
|
obj-$(CONFIG_DRM_TTM) += ttm/
|
2018-01-24 10:44:49 +00:00
|
|
|
obj-$(CONFIG_DRM_SCHED) += scheduler/
|
2008-05-29 00:09:59 +00:00
|
|
|
obj-$(CONFIG_DRM_TDFX) += tdfx/
|
|
|
|
|
obj-$(CONFIG_DRM_R128) += r128/
|
|
|
|
|
obj-$(CONFIG_DRM_RADEON)+= radeon/
|
2015-04-20 20:55:21 +00:00
|
|
|
obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
|
2008-05-29 00:09:59 +00:00
|
|
|
obj-$(CONFIG_DRM_MGA) += mga/
|
|
|
|
|
obj-$(CONFIG_DRM_I810) += i810/
|
2016-08-19 15:54:28 +00:00
|
|
|
obj-$(CONFIG_DRM_I915) += i915/
|
2012-04-17 14:01:25 +00:00
|
|
|
obj-$(CONFIG_DRM_MGAG200) += mgag200/
|
2018-04-30 18:10:58 +00:00
|
|
|
obj-$(CONFIG_DRM_V3D) += v3d/
|
2015-03-02 21:01:12 +00:00
|
|
|
obj-$(CONFIG_DRM_VC4) += vc4/
|
2008-05-29 00:09:59 +00:00
|
|
|
obj-$(CONFIG_DRM_SIS) += sis/
|
|
|
|
|
obj-$(CONFIG_DRM_SAVAGE)+= savage/
|
2009-12-10 00:19:58 +00:00
|
|
|
obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
|
2008-05-29 00:09:59 +00:00
|
|
|
obj-$(CONFIG_DRM_VIA) +=via/
|
2015-03-05 00:33:41 +00:00
|
|
|
obj-$(CONFIG_DRM_VGEM) += vgem/
|
2018-05-14 14:33:46 +00:00
|
|
|
obj-$(CONFIG_DRM_VKMS) += vkms/
|
2009-12-11 09:24:15 +00:00
|
|
|
obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
|
2011-10-04 10:19:01 +00:00
|
|
|
obj-$(CONFIG_DRM_EXYNOS) +=exynos/
|
2014-08-22 10:36:26 +00:00
|
|
|
obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
|
2011-11-03 18:22:48 +00:00
|
|
|
obj-$(CONFIG_DRM_GMA500) += gma500/
|
2010-12-14 21:14:24 +00:00
|
|
|
obj-$(CONFIG_DRM_UDL) += udl/
|
drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)
This is the initial driver for the Aspeed Technologies chips found in
servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
doesn't support the AST11xx due to lack of hw to test it on, and them requiring
different codepaths.
This driver is intended to be used with xf86-video-modesetting in userspace.
This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does dirty
updates to a copy in video RAM. When userspace sets a new scanout buffer,
it forcefully evicts the video RAM console, and X can create a framebuffer
that can use all of of video RAM.
This driver uses TTM but in a very simple fashion to control the eviction
to system RAM of the console, and multiple servers.
v2: add s/r support, fix Kconfig.
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-02-29 13:40:04 +00:00
|
|
|
obj-$(CONFIG_DRM_AST) += ast/
|
2012-08-15 12:59:49 +00:00
|
|
|
obj-$(CONFIG_DRM_ARMADA) += armada/
|
2015-01-06 10:13:28 +00:00
|
|
|
obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/
|
2019-01-16 23:11:37 +00:00
|
|
|
obj-y += rcar-du/
|
2012-04-26 11:53:59 +00:00
|
|
|
obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
|
2015-12-09 18:26:00 +00:00
|
|
|
obj-y += omapdrm/
|
2015-10-29 08:36:23 +00:00
|
|
|
obj-$(CONFIG_DRM_SUN4I) += sun4i/
|
2015-02-18 10:26:50 +00:00
|
|
|
obj-y += tilcdc/
|
drm: add new QXL driver. (v1.4)
QXL is a paravirtual graphics device used by the Spice virtual desktop
interface.
The drivers uses GEM and TTM to manage memory, the qxl hw fencing however
is quite different than normal TTM expects, we have to keep track of a number
of non-linear fence ids per bo that we need to have released by the hardware.
The releases are freed from a workqueue that wakes up and processes the
release ring.
releases are suballocated from a BO, there are 3 release categories, drawables,
surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling.
The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface
ids.
This requires a newer version of the QXL userspace driver, so shouldn't be
enabled until that has been placed into your distro of choice.
Authors: Dave Airlie, Alon Levy
v1.1: fixup some issues in the ioctl interface with padding
v1.2: add module device table
v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq,
don't try flush release ring (broken hw), fix -modesetting.
v1.4: fbcon cpu usage reduction + suitable accel flags.
Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-25 04:47:55 +00:00
|
|
|
obj-$(CONFIG_DRM_QXL) += qxl/
|
2013-12-17 17:04:46 +00:00
|
|
|
obj-$(CONFIG_DRM_BOCHS) += bochs/
|
2013-09-09 00:02:56 +00:00
|
|
|
obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
|
drm/msm: basic KMS driver for snapdragon
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version. (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.) And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.
To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.
The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently. But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge. This
would remove the 'msm_connector' base class. But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..
This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-06-26 16:44:06 +00:00
|
|
|
obj-$(CONFIG_DRM_MSM) += msm/
|
2013-10-09 08:32:49 +00:00
|
|
|
obj-$(CONFIG_DRM_TEGRA) += tegra/
|
2017-04-14 10:13:34 +00:00
|
|
|
obj-$(CONFIG_DRM_STM) += stm/
|
2014-07-30 16:20:56 +00:00
|
|
|
obj-$(CONFIG_DRM_STI) += sti/
|
2020-07-31 08:18:29 +00:00
|
|
|
obj-y += imx/
|
2019-06-03 15:23:31 +00:00
|
|
|
obj-$(CONFIG_DRM_INGENIC) += ingenic/
|
2016-01-04 17:36:34 +00:00
|
|
|
obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
|
2016-11-10 14:29:37 +00:00
|
|
|
obj-$(CONFIG_DRM_MESON) += meson/
|
2009-12-11 09:24:15 +00:00
|
|
|
obj-y += i2c/
|
2013-08-30 13:10:14 +00:00
|
|
|
obj-y += panel/
|
2014-02-24 10:31:24 +00:00
|
|
|
obj-y += bridge/
|
2015-08-20 02:19:49 +00:00
|
|
|
obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
|
2015-12-03 17:21:29 +00:00
|
|
|
obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
|
2016-02-19 12:30:26 +00:00
|
|
|
obj-$(CONFIG_DRM_ARCPGU)+= arc/
|
2015-10-09 10:00:56 +00:00
|
|
|
obj-y += hisilicon/
|
2016-09-22 11:52:39 +00:00
|
|
|
obj-$(CONFIG_DRM_ZTE) += zte/
|
2016-08-18 18:23:01 +00:00
|
|
|
obj-$(CONFIG_DRM_MXSFB) += mxsfb/
|
2019-07-25 10:51:31 +00:00
|
|
|
obj-y += tiny/
|
drm/pl111: Initial drm/kms driver for pl111
This is a modesetting driver for the pl111 CLCD display controller
found on various ARM platforms such as the Versatile Express. The
driver has only been tested on the bcm911360_entphn platform so far,
with PRIME-based buffer sharing between vc4 and clcd.
It reuses the existing devicetree binding, while not using quite as
many of its properties as the fbdev driver does (those are left for
future work).
v2: Nearly complete rewrite by anholt, cutting 2/3 of the code thanks
to DRM core's excellent new helpers.
v3: Don't match pl110 any more, don't attach if we don't have a DRM
panel, use DRM_GEM_CMA_FOPS, update MAINTAINERS, use the simple
display helper, use drm_gem_cma_dumb_create (same as our wrapper).
v4: Change the driver's .name to not clash with fbdev in sysfs, drop
platform alias, drop redundant "drm" in DRM driver name, hook up
.prepare_fb to the CMA helper so that DMA fences should work.
v5: Move register definitions inside the driver directory, fix build
in COMPILE_TEST and !AMBA mode.
v6: Drop TIM2_CLKSEL for now to be consistent with existing DT
bindings, switch back to external register definitions.
Signed-off-by: Tom Cooksey <tom.cooksey@arm.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> (v5)
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413031746.12921-2-eric@anholt.net
2017-04-13 03:17:46 +00:00
|
|
|
obj-$(CONFIG_DRM_PL111) += pl111/
|
2017-08-20 10:05:55 +00:00
|
|
|
obj-$(CONFIG_DRM_TVE200) += tve200/
|
drm/xen-front: Add support for Xen PV display frontend
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].
Driver limitations:
1. Only primary plane without additional properties is supported.
2. Only one video mode supported which resolution is configured
via XenStore.
3. All CRTCs operate at fixed frequency of 60Hz.
1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.
2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
- read connector(s) configuration
- read buffer allocation mode (backend/frontend)
3. Handle Xen event channels:
- create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with respect to Xen bus state
4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
- handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
page directory
- allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
- grant references to the required set of pages for the
shared buffer itself
- implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)
5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:
- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- create and destroy frame buffers and propagate those
to the backend
- propagate set/reset mode configuration to the backend on display
enable/disable callbacks
- send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback
- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
configuration
6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
- display buffers can be allocated by either
frontend driver or backend
- display buffers can be allocated to be contiguous
in memory or not
Note! Frontend driver itself has no dependency on contiguous memory for
its operation.
6.1. Buffers allocated by the frontend driver.
The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.
6.1.1. Front driver configured to use GEM CMA helpers
This use-case is useful when used with accompanying DRM/vGPU driver
in guest domain which was designed to only work with contiguous
buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
only import contiguous PRIME buffers, thus requiring frontend driver
to provide such. In order to implement this mode of operation
para-virtualized frontend driver can be configured to use
GEM CMA helpers.
6.1.2. Front driver doesn't use GEM CMA
If accompanying drivers can cope with non-contiguous memory then, to
lower pressure on CMA subsystem of the kernel, driver can allocate
buffers from system memory.
Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.
6.2. Buffers allocated by the backend
This mode of operation is run-time configured via guest domain
configuration through XenStore entries.
For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.
Note, while using this scenario the following should be considered:
a) If guest domain dies then pages/grants received from the backend
cannot be claimed back
b) Misbehaving guest may send too many requests to the
backend exhausting its grant references and memory
(consider this from security POV).
Note! Configuration options 1.1 (contiguous display buffers) and 2
(backend allocated buffers) are not supported at the same time.
7. Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3000 ms
- manage display buffers shared with the backend
[1] https://github.com/xen-troops/displ_be
[2] https://github.com/xen-troops/libxenbe
[3] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com
2018-04-03 11:23:17 +00:00
|
|
|
obj-$(CONFIG_DRM_XEN) += xen/
|
2019-03-04 16:47:24 +00:00
|
|
|
obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
|
2019-03-09 12:20:12 +00:00
|
|
|
obj-$(CONFIG_DRM_LIMA) += lima/
|
2018-09-10 19:27:58 +00:00
|
|
|
obj-$(CONFIG_DRM_PANFROST) += panfrost/
|
2019-04-03 00:19:08 +00:00
|
|
|
obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
|
2019-05-24 09:20:19 +00:00
|
|
|
obj-$(CONFIG_DRM_MCDE) += mcde/
|
drm/tidss: New driver for TI Keystone platform Display SubSystem
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 <drm/drmP.h>
- 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 <bparrot@ti.com>
v9: - Rename dispc_write_irqenable() to dispc_set_irqenable() to avoid
conflict exported omapfb function with same name
- Add Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Co-developed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/925fbfad58ff828e8e07fdff7073a0ee65750c3d.1580129724.git.jsarha@ti.com
2019-11-08 07:45:28 +00:00
|
|
|
obj-$(CONFIG_DRM_TIDSS) += tidss/
|
2018-07-08 02:05:34 +00:00
|
|
|
obj-y += xlnx/
|
