- 09 Jan, 2018 2 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 4.16: Cross-subsystem Changes: - some dt-binding changes for Ilitek and sun4i devices Core Changes: - panel_orientation_quirks: fix tainted kernel Driver Changes: - panel changes - A83T and LVDS support to sun4i * tag 'drm-misc-next-2018-01-08' of git://anongit.freedesktop.org/drm/drm-misc: drm/panel: lvds: Add support for the power-supply property dt-bindings: panel: lvds: Document power-supply property drm/sun4i: Add A83T support drm/sun4i: Add LVDS support drm/sun4i: Create minimal multipliers and dividers drm/sun4i: Force the mixer rate at 150MHz dt-bindings: display: sun4i-drm: Add A83T pipeline dt-bindings: display: sun4i-drm: Add LVDS properties drm/tinydrm: add driver for ST7735R panels dt-bindings: Add binding for Sitronix ST7735R display panels dt-bindings: add jianda vendor prefix drm/tinydrm: Update ILI9225 compatible string dt-bindings: update compatible string for ILI9225 dt-bindings: Add "vot" vendor prefix drm: fix tainted kernel caused by drm_panel_orientation_quirks.c drm/panel: Add Ilitek ILI9322 driver drm/panel: Add DT bindings for Ilitek ILI9322
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Last few updates for 4.16: - Misc fixes for amdgpu - Enable swapout for reserved BOs during allocation for ttm - Misc cleanups for ttm * 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux: (24 commits) drm/amdgpu: Correct the IB size of bo update mapping. drm/ttm: enable swapout for reserved BOs during allocation drm/ttm: add new function to check if bo is allowable to evict or swapout drm/ttm: use an operation ctx for ttm_tt_bind drm/ttm: use an operation ctx for ttm_tt_populate in ttm_bo_driver (v2) drm/ttm: use an operation ctx for ttm_mem_global_alloc_page drm/ttm: use an operation ctx for ttm_mem_global_alloc drm/ttm: call ttm_bo_swapout directly when ttm shrink drm/vmwgfx: remove the default io_mem_pfn set drm/virtio: remove the default io_mem_pfn set drm/radeon: remove the default io_mem_pfn set drm/qxl: remove the default io_mem_pfn set drm/nouveau: remove the default io_mem_pfn set drm/mgag200: remove the default io_mem_pfn set drm/cirrus: remove the default io_mem_pfn set drm/bochs: remove the default io_mem_pfn set drm/ast: remove the default io_mem_pfn set drm/ttm: add ttm_bo_io_mem_pfn to check io_mem_pfn drm/amdgpu: fix VM faults with per VM BOs drm/ttm: drop the spin in delayed delete if the trylock doesn't work ...
-
- 05 Jan, 2018 3 commits
-
-
Maxime Ripard authored
A significant number of panels need to power up a regulator in order to operate properly. Add support for the power-supply property to enable and disable such a regulator whenever needed. Reviewed-by:
Chen-Yu Tsai <wens@csie.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/0c0819bdf88fa948188df95e57a10820a8a4548d.1513854122.git-series.maxime.ripard@free-electrons.com
-
Maxime Ripard authored
The power-supply property is used by a vast majority of panels, including panel-simple. Let's document it as a common property Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
drm/imx: format modifier support - Add tiled prefetch support to PRE - Add format modifier support to PRG and imx-drm-core - Use runtime PM to control PRG clock - Allow building ipu-v3 under COMPILE_TEST * tag 'imx-drm-next-2018-01-02' of git://git.pengutronix.de/git/pza/linux: gpu: ipu-v3: allow to build with COMPILE_TEST drm/imx: advertise supported plane format modifiers drm/imx: add FB modifier support gpu: ipu-v3: prg: add modifier support gpu: ipu-v3: pre: add tiled prefetch support gpu: ipu-v3: prg: switch to runtime PM
-
- 04 Jan, 2018 10 commits
-
-
git://git.armlinux.org.uk/~rmk/linux-armDave Airlie authored
This series builds upon the set of fixes previously submitted to move Armada DRM closer to atomic modeset. We're nowhere near yet, but this series helps to get us closer by unifying some of the differences between the primary and overlay planes. New features added allows userspace to disable the primary plane if overlay is full screen and there's nothing obscuring the colorkey - this saves having to fetch an entire buffer containing nothing but colorkey when displaying full screen video. [airlied: fixup for atomic plane helper rename: a01cb8ba Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 1 22:16:19 2017 +0200 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c ] * 'drm-armada-devel-4.15' of git://git.armlinux.org.uk/~rmk/linux-arm: (29 commits) drm/armada: expand overlay trace entry drm/armada: implement primary plane update drm/armada: extract register generation from armada_drm_primary_set() drm/armada: wait for previous work when moving overlay window drm/armada: move overlay plane register update generation drm/armada: re-organise overlay register update generation drm/armada: disable planes at next blanking period drm/armada: avoid work allocation drm/armada: allow armada_drm_plane_work_queue() to silently fail drm/armada: use drm_plane_helper_check_state() drm/armada: only enable HSMOOTH if scaling horizontally drm/armada: move writes of LCD_SPU_SRAM_PARA1 under lock drm/armada: move regs into armada_plane_work drm/armada: move event sending into armada_plane_work drm/armada: move fb retirement into armada_plane_work drm/armada: move overlay plane work out from under spinlock drm/armada: clear plane enable bit when disabling drm/armada: clean up armada_drm_crtc_plane_disable() drm/armada: allow the primary plane to be disabled drm/armada: wait and cancel any pending frame work at disable ...
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
Highlights this time: 1. Fix for a nasty Kconfig dependency chain issue from Philipp. 2. Occlusion query buffer address added to the cmdstream validator by Christian. 3. Fixes and cleanups to the job handling from me. This allows us to turn on the GPU performance profiling added in the last cycle. It is also prep work for hooking in the DRM GPU scheduler, which I hope to land for the next cycle. * 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux: (32 commits) drm/etnaviv: use memset32 to init pagetable drm/etnaviv: move submit free out of critical section drm/etnaviv: re-enable perfmon support drm/etnaviv: couple runtime PM management to submit object lifetime drm/etnaviv: move GPU active handling to bo pin/unpin drm/etnaviv: move cmdbuf into submit object drm/etnaviv: use submit exec_state for perfmon sampling drm/etnaviv: move exec_state to submit object drm/etnaviv: move PMRs to submit object drm/etnaviv: refcount the submit object drm/etnaviv: move ww_acquire_ctx out of submit object drm/etnaviv: move object unpinning to submit cleanup drm/etnaviv: attach in fence to submit and move fence wait to fence_sync drm/etnaviv: rename submit fence to out_fence drm/etnaviv: move object fence attachment to gem_submit path drm/etnaviv: simplify submit_create drm/etnaviv: add lockdep annotations to buffer manipulation functions drm/etnaviv: hold GPU lock while inserting END command drm/etnaviv: move workqueue to be per GPU drm/etnaviv: remove switch_context member from etnaviv_gpu ...
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Remove lagacy IPP driver - This driver isn't used anymore so remove it. Marek is preparing new one which includes completely rewritten API so this driver will be replaced with the new version[1] later. And cleanups. [1] https://patches.linaro.org/cover/118386/ * tag 'exynos-drm-next-for-v4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: ipp: Remove Exynos DRM IPP subsystem drm/exynos/decon: Add include guard to the Exynos7 header drm/exynos/decon: Move headers from global to local place drm/exynos: decon5433: Remove unnecessary platform_get_resource() error check
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
- Add CWSR (compute wave save restore) support for GFX8 (Carrizo) - Fix SDMA user-mode queues support for GFX7 (Kaveri) - Add SDMA user-mode queues support for GFX8 (Carrizo) - Allow HWS (hardware scheduling) to schedule multiple processes concurrently - Add debugfs support - Simplify process locking and lock dependencies - Refactoring topology code to prepare for dGPU support + fixes to that code - Add option to generate dummy/virtual CRAT table when its missing or deformed - Recognize CPUs other then APUs as compute entities - Various clean ups and bug fixes I have not yet sent the dGPU topology code because it depends on a patch for the PCI subsystem that adds PCIe atomics support. Once that patch is upstreamed we can continue with the rest of the dGPU code. * tag 'drm-amdkfd-next-2017-12-24' of git://people.freedesktop.org/~gabbayo/linux: (53 commits) drm/amdgpu: Add support for reporting VRAM usage drm/amdkfd: Ignore ACPI CRAT for non-APU systems drm/amdkfd: Module option to disable CRAT table drm/amdkfd: Add AQL Queue Memory flag on topology drm/amdkfd: Fixup incorrect info in the CZ CRAT table drm/amdkfd: Add perf counters to topology drm/amdkfd: Add topology support for dGPUs drm/amdkfd: Add topology support for CPUs drm/amdkfd: Fix sibling_map[] size drm/amdkfd: Simplify counting of memory banks drm/amdkfd: Turn verbose topology messages into pr_debug drm/amdkfd: sync IOLINK defines to thunk spec drm/amdkfd: Support enumerating non-GPU devices drm/amdkfd: Decouple CRAT parsing from device list update drm/amdkfd: Reorganize CRAT fetching from ACPI drm/amdkfd: Group up CRAT related functions drm/amdkfd: Fix memory leaks in kfd topology drm/amdkfd: Topology: Fix location_id drm/amdkfd: Update number of compute unit from KGD drm/amd: Remove get_vmem_size from KGD-KFD interface ...
-
Maxime Ripard authored
Add support for the A83T display pipeline. Reviewed-by:
-
Maxime Ripard authored
The TCON supports the LVDS interface to output to a panel or a bridge. Let's add support for it. Reviewed-by:
-
Maxime Ripard authored
The various outputs the TCON can provide have different constraints on the dotclock divider. Let's make them configurable by the various mode_set functions. Reviewed-by:
-
Maxime Ripard authored
It seems like the mixer can only run properly when clocked at 150MHz. In order to have something more robust than simply a fire-and-forget assigned-clocks-rate, let's put that in the code. Reviewed-by:
-
Maxime Ripard authored
The A83T has two video pipelines in parallel that looks quite similar to the other SoCs. The video planes are handled through a controller called the mixer, and the video signal is then passed to the timing controller (TCON). And while there is two instances of the mixers and TCONs, they have a significant number of differences. The TCONs are quite easy to deal with, one is supposed to generate TV (in the broader term, so including things like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs call them TCON-TV and TCON-LCD, which seems more appropriate. However, the mixers differ mostly by their capabilities, with some features being available only in the first one, or the number of planes they expose, but also through their register layout. And while the capabilities could be represented as properties, the register layout differences would need to express all the registers offsets as properties, which is usually quite bad. Especially since documentation on that hardware block is close to non-existent and we don't even have the list of all those registers in the first place. So let's call them mixer 0 and 1 in our compatibles, even though the name is pretty bad... At the moment, we only have tested the code on a board that has a single display output, so we're leaving the tcon-tv and mixer1 out. Reviewed-by:
-
Maxime Ripard authored
Some clocks and resets supposed to drive the LVDS logic in the display engine have been overlooked when the driver was first introduced. Add those additional resources to the binding, and we'll deal with the ABI stability in the code. Reviewed-by:
-
- 03 Jan, 2018 6 commits
-
-
David Lechner authored
This adds a new driver for Sitronix ST7735R display panels. This has been tested using an Adafruit 1.8" TFT. Signed-off-by:
David Lechner <david@lechnology.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
David Lechner authored
This adds a new device tree binding for Sitronix ST7735R display panels, such as the Adafruit 1.8" TFT. Signed-off-by:
-
David Lechner authored
This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd. Signed-off-by:
-
David Lechner authored
This updates the compatible string for a no-name LCD panel to "vot,v220hf01a-t", "ilitek,ili9225". The original bindings were the generic "ilitek,ili9225-2.2in-176x220" because I could not find a datasheet. However, after some more research, I finally found one, so the actual vendor and model name are now known. This previous bindings have not made it to the mainline kernel yet, so this is not breaking backwards compatibility. Signed-off-by:
-
David Lechner authored
This updates the compatible string for a no-name LCD panel to "vot,v220hf01a-t", "ilitek,ili9225". The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220" because I could not find a datasheet. However, after some more research, I finally found one, so the actual vendor and model name are now known. This previous bindings have not made it to the mainline kernel yet, so this is not breaking backwards compatibility. This is also following the precedence of the ILI9322 bindings [2] by using the pattern "vendor,specific-system-config", "vendor,ip-part"; [1]: https://patchwork.ozlabs.org/patch/839352/ [2]: https://patchwork.ozlabs.org/patch/843576/Signed-off-by:
-
David Lechner authored
This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd. They make LCD displays. Signed-off-by:
-
- 02 Jan, 2018 19 commits
-
-
Lucas Stach authored
Now that memset32 is available, the open-coded pagetable initialization loop can be replaced. Signed-off-by:Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
There is no need to hold the GPU lock while freeing the submit object. Only move the retired submits from the GPU active list to a temporary retire list under the GPU lock. Signed-off-by: -
Lucas Stach authored
Now that the PMR lifetime issues are solved we can safely re-enable performance counter profiling support. Signed-off-by: -
Lucas Stach authored
As long as there is an active submit, we want the GPU to stay awake. This is slightly complicated by the fact that we really want to wake the GPU at the last possible moment to achieve maximum power savings. Signed-off-by: -
Lucas Stach authored
The active count is used to check if the BO is idle, where idle is defined as not active on the GPU and all VM mappings and reference counts dropped to the initial state. As the idling of the mappings and references now only happens in the submit cleanup, the active state handling must be moved to the same location in order to keep the userspace semantics. Signed-off-by: -
Lucas Stach authored
Less dynamic allocations and slims down the cmdbuf object to only the required information, as everything else is already available in the submit object. This also simplifies buffer and mappings lifetime management, as they are now exlusively attached to the submit object and not additionally to the cmdbuf. Signed-off-by: -
Lucas Stach authored
The GPU exec state may have changed at the time when the perfmon sampling is done, as it reflects the state of the last submission, not the current GPU execution state. So for proper sampling we must use the submit exec_state. Signed-off-by: -
Lucas Stach authored
We'll need this in some places where only the submit is available. Also this is a first step at slimming down the cmdbuf object. Signed-off-by: -
Lucas Stach authored
To make them available to the event worker even after the actual command stream execution has finished. Signed-off-by: -
Lucas Stach authored
The submit object lifetime will get extended to the actual GPU execution. As multiple users will depend on this, add a kref to properly control destruction of the object. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
The acquire_ctx is special in that it needs to be released from the same thread as has been used to initialize it. This collides with the intention to extend the submit lifetime beyond the gem_submit function with potentially other threads doing the final cleanup. Move the ww_acquire_ctx to the function local stack as suggested in the documentation. Signed-off-by:
-
Lucas Stach authored
This is safe to call in all paths, as the BO_PINNED flag tells us if the BO needs unpinning. Signed-off-by:
-
Lucas Stach authored
Simplifies the cleanup path and moves fence waiting to a central location. Signed-off-by:
-
Lucas Stach authored
This is the fence passed out on a sucessful GPU submit. Make the name more clear. Signed-off-by: -
Lucas Stach authored
The object fencing has nothing to do with the actual GPU buffer submit, so move it to the gem submit path to have a cleaner split. Signed-off-by:
-
Lucas Stach authored
Use kzalloc so other code doesn't need to worry about uninitialized members. Drop the non-standard GFP flags, as we really don't want to fail the submit when under slight memory pressure. Remove one level of indentation by using an early return if the allocation failed. Also remove the unused drm device member. Signed-off-by:
-
Lucas Stach authored
When manipulating the kernel command buffer the GPU mutex must be held, as otherwise different callers might try to replace the same part of the buffer, wreacking havok in the GPU execution. Signed-off-by:
-
Lucas Stach authored
Inserting the END command when suspending the GPU is changing the command buffer state, which requires the GPU to be held. Signed-off-by:
Christian Gmeiner <christian.gmeiner@gmail.com>
-
Lucas Stach authored
While the etnaviv workqueue needs to be ordered, as we rely on work items being executed in queuing order, this is only true for a single GPU. Having a shared workqueue for all GPUs in the system limits concurrency artificially. Getting each GPU its own ordered workqueue still meets our ordering expectations and enables retire workers to run concurrently. Signed-off-by:
-
