- 21 Aug, 2019 8 commits
-
-
Xu YiPing authored
As part of refactoring the kirin driver to better support different hardware revisions, this patch renames the struct ade_crtc to kirin_crtc. The struct kirin_crtc will later used by both kirin620 and future kirin960 driver, and will be moved to a common kirin_drm_drv.h in a future patch Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
Xinliang Liu <z.liuxinliang@hisilicon.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Xu YiPing <xuyiping@hisilicon.com> [jstultz: reworded commit message] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Xu YiPing authored
As part of refactoring the kirin driver to better support different hardware revisions, this patch renames the struct ade_plane to kirin_plane. The struct kirin_plane will later used by both kirin620 and future kirin960 driver, and will be moved to a common kirin_drm_drv.h in a future patch Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Xu YiPing authored
As part of refactoring the kirin driver to better support different hardware revisions, this patch removes the out_format field in the struct ade_crtc, which was only ever set to LDI_OUT_RGB_888. Thus this patch removes the field and instead directly uses LDI_OUT_RGB_888. Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Xu YiPing authored
In a few functions, we pass in a struct ade_crtc, which we only use to get to the underlying struct ade_hw_ctx. Thus this patch refactors the functions to just take the struct ade_hw_ctx directly. Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
John Stultz authored
The 'return 0' in kirin_drm_platform_probe() is unreachable code, so remove it. Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
John Stultz authored
The CONFIG_HISI_KIRIN_DW_DSI option is only used w/ kirin driver, so cut out the middleman and condense the config logic down. Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Da Lv authored
The original HiKey (620) board has had a long running issue where when using a 1080p montior, the display would occasionally blink and come come back with a horizontal offset (usually also shifting the colors, depending on the value of the offset%4). After lots of analysis by HiSi developers, they found the issue was due to when running at 1080p, it was possible to hit the device memory bandwidth limits, which could cause the DSI signal to get out of sync. Unfortunately the DSI logic doesn't have the ability to automatically recover from this situation, but we can get a an LDI underflow interrupt when it happens. To then correct the issue, when we get an LDI underflow irq, we we can simply suspend and resume the display, which resets the hardware. Thus, this patch enables the ldi underflow interrupt, and initializes a workqueue that is used to suspend/resume the display to recover. Then when the irq occurs we clear it and schedule the workqueue to reset display engine. Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel <dri-devel@lists.freedesktop.org> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by:
Da Lv <lvda3@hisilicon.com> Signed-off-by:
Yidong Lin <linyidong@huawei.com> [jstultz: Reworded the commit message, checkpatch cleanups] Signed-off-by:
-
Thierry Reding authored
TTM assumes that drivers initialize the embedded GEM object before calling the ttm_bo_init() function. This is not currently the case in the Nouveau driver. Fix this by splitting up nouveau_bo_new() into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can be initialized before TTM BO initialization when necessary. Fixes: b96f3e7c ("drm/ttm: use gem vma_node") Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo
-
- 20 Aug, 2019 6 commits
-
-
Nickey Yang authored
This patch update describe panel/port links, including unit addresses in documentation of device tree bindings for the rockchip DSI controller based on the Synopsys DesignWare MIPI DSI host controller. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Rob Herring <robh@kernel.org> [this seems to have gotten lost when the original dsi-series was applied] Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123845.11818-5-heiko@sntech.de
-
Chris Wilson authored
The dma-fence selftest uses an on-stack timer that requires explicit annotation for debugobjects. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111442Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190820122118.13698-1-chris@chris-wilson.co.uk
-
Mihail Atanassov authored
The 'memory-region' property of the komeda display driver DT binding allows the use of a 'reserved-memory' node for buffer allocations. Add the requisite of_reserved_mem_device_{init,release} calls to actually make use of the memory if present. Changes since v1: - Move handling inside komeda_parse_dt Signed-off-by:Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Link:- https://patchwork.kernel.org/patch/11076413/
-
Chris Wilson authored
Use the %zu format specifier for a size_t returned by sizeof. Reported-by: kbuild-all@01.org Signed-off-by:
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_cec_adap_(un)register() functions to (un)register the notifier for the CEC adapter. Also adds CEC_CAP_CONNECTOR_INFO capability to the adapter. Changes since v3: - add CEC_CAP_CONNECTOR_INFO to cec_allocate_adapter, - replace CEC_CAP_LOG_ADDRS | CEC_CAP_TRANSMIT | CEC_CAP_RC | CEC_CAP_PASSTHROUGH with CEC_CAP_DEFAULTS. Signed-off-by:
Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Changes since v6: - move cec_notifier_conn_unregister to a bridge detach function, - add a mutex protecting a CEC notifier. Changes since v4: - typo fix Changes since v2: - removed unnecessary NULL check before a call to cec_notifier_conn_unregister, - use cec_notifier_phys_addr_invalidate to invalidate physical address. Changes since v1: Add memory barrier to make sure that the notifier becomes visible to the irq thread once it is fully constructed. Signed-off-by:
-
- 19 Aug, 2019 18 commits
-
-
Chris Wilson authored
Include the DMABUF_SELFTESTS as part of the standard build for IGT, so that they can be run by igt/dmabuf Testcase: igt/dmabuf Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819171900.4501-1-chris@chris-wilson.co.uk
-
Jonathan Neuschäfer authored
This improves Sphinx output in two ways: - It avoids an unmatched single-quote ('), about which Sphinx complained: Documentation/gpu/drm-internals.rst:298: WARNING: Could not lex literal_block as "c". Highlighting skipped. An alternative approach would be to replace "can't" with a word that doesn't have a single-quote. - It lets Sphinx format the comments in italics and grey, making the code slightly easier to read. Signed-off-by:Jonathan Neuschäfer <j.neuschaefer@gmx.net> Acked-by: Daniel Vetter <daniel@ffwll.ch> [via irc] Signed-off-by:
-
Chris Wilson authored
Exercise the dma-fence API exported to drivers. Signed-off-by:
-
Chris Wilson authored
In light of recent review slip ups, the absence of a suite of tests for dma-buf became apparent. Given the current plethora of testing frameworks, opt for one already in use by Intel's CI and so allow easy hook up into igt. We introduce a new module that when loaded will execute the list of selftests and their subtest. The names of the selftests are put into the modinfo as parameters so that igt can identify each, and run them independently, principally for ease of error reporting. Signed-off-by:
-
Steven Price authored
The devfreq opp table needs to be removed when unloading the driver to free the memory associated with it. Signed-off-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Steven Price authored
If there is no regulator defined for the GPU then still control the frequency using the supplied clock. Some boards have clock control but no (direct) control of the regulator. For example the HiKey960 uses a mailbox protocol to a MCU to control frequencies and doesn't directly control the voltage. This patch allows frequency control of the GPU on this system. Signed-off-by:
-
Rob Herring authored
Up until now, a single shared GPU address space was used. This is not ideal as there's no protection between processes and doesn't work for supporting the same GPU/CPU VA feature. Most importantly, this will hopefully mitigate Alyssa's fear of WebGL, whatever that is. Most of the changes here are moving struct drm_mm and struct panfrost_mmu objects from the per device struct to the per FD struct. The critical function is panfrost_mmu_as_get() which handles allocating and switching the h/w address spaces. There's 3 states an AS can be in: free, allocated, and in use. When a job runs, it requests an address space and then marks it not in use when job is complete(but stays assigned). The first time thru, we find a free AS in the alloc_mask and assign the AS to the FD. Then the next time thru, we most likely already have our AS and we just mark it in use with a ref count. We need a ref count because we have multiple job slots. If the job/FD doesn't have an AS assigned and there are no free ones, then we pick an allocated one not in use from our LRU list and switch the AS from the old FD to the new one. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Wei Yongjun authored
Add the missing unlock before return from function panfrost_mmu_map_fault_addr() in the error handling case. Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
-
Nishka Dasgupta authored
Static structure dlfb_ops, of type fb_ops, is not used except to be copied into another variable. Hence make dlfb_ops constant to protect it from unintended modification. Issue found with Coccinelle. Signed-off-by:
Nishka Dasgupta <nishkadg.linux@gmail.com> Cc: Bernie Thompson <bernie@plugable.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819075236.1051-1-nishkadg.linux@gmail.com
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct mmp_path { ... struct mmp_overlay overlays[0]; }; size = sizeof(struct mmp_path) + count * sizeof(struct mmp_overlay); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, overlays, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Souptick Joarder authored
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by:
Souptick Joarder <jrdr.linux@gmail.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> [b.zolnierkie: fix patch summary] Signed-off-by:
-
Souptick Joarder authored
This is dead code since 3.15. If there is no plan to use it further, this can be removed forever. Signed-off-by:
-
Anders Roxell authored
Now that -Wimplicit-fallthrough is passed to GCC by default, the following warnings shows up: ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_channel_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:2087:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_lcdc_overlay_fb_init’: ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=] info->fix.ypanstep = 2; ~~~~~~~~~~~~~~~~~~~^~~ ../drivers/video/fbdev/sh_mobile_lcdcfb.c:1597:2: note: here case V4L2_PIX_FMT_NV16: ^~~~ Rework to address a warnings due to the enablement of -Wimplicit-fallthrough. Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> [b.zolnierkie: fix patch summary] Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [b.zolnierkie: fix patch summary and intendation] Signed-off-by:
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by:
-
Gustavo A. R. Silva authored
There is no need to compare *var->xoffset* or *var->yoffset* with < 0 because such variables are of type unsigned, making it impossible to hold a negative value. Fix this by removing such comparisons. Addresses-Coverity-ID: 1451964 ("Unsigned compared against 0") Signed-off-by: -
Hans de Goede authored
For various reasons, at least with x86 EFI firmwares, the xoffset and yoffset in the BGRT info are not always reliable. Extensive testing has shown that when the info is correct, the BGRT image is always exactly centered horizontally (the yoffset variable is more variable and not always predictable). This commit simplifies / improves the bgrt_sanity_check to simply check that the BGRT image is exactly centered horizontally and skips (re)drawing it when it is not. This fixes the BGRT image sometimes being drawn in the wrong place. Cc: stable@vger.kernel.org Fixes: 88fe4ceb ("efifb: BGRT: Do not copy the boot graphics for non native resolutions") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Cc: Peter Jones <pjones@redhat.com>, Signed-off-by:
-
Nishka Dasgupta authored
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only when it is passed to drm_gem_fb_create_with_funcs() as its last argument. drm_gem_fb_create_with_funcs does not modify its lst argument (fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs constant to protect it from further modification. Issue found with Coccinelle. Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by:
-
- 18 Aug, 2019 1 commit
-
-
Nishka Dasgupta authored
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs, is used only when it is passed as the third argument to drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it constant to protect it from unintended modifications. Issue found with Coccinelle. Signed-off-by:
-
- 17 Aug, 2019 5 commits
-
-
Chris Wilson authored
The timestamp and the cb_list are mutually exclusive, the cb_list can only be added to prior to being signaled (and once signaled we drain), while the timestamp is only valid upon being signaled. Both the timestamp and the cb_list are only valid while the fence is alive, and as soon as no references are held can be replaced by the rcu_head. By reusing the union for the timestamp, we squeeze the base dma_fence struct to 64 bytes on x86-64. v2: Sort the union chronologically Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chris Wilson authored
Currently dma_fence_signal() tries to avoid the spinlock and only takes it if absolutely required to walk the callback list. However, to allow for some users to surreptitiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence, we always need to notify the callbacks on signaling. As such, we will always need to take the spinlock and dma_fence_signal() effectively becomes a clone of dma_fence_signal_locked(). v2: Update the test_and_set_bit() before entering the spinlock. v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller error so expected to be very unlikely. Signed-off-by:
-
Chris Wilson authored
Before we notify the fence signal callback, we remove the cb from the list. However, since we are processing the entire list from underneath the spinlock, we do not need to individual delete each element, but can simply reset the link and the entire list. Signed-off-by:
-
Chris Wilson authored
Rearrange the couple of 32-bit atomics hidden amongst the field of pointers that unnecessarily caused the compiler to insert some padding, shrinks the size of the base struct dma_fence from 80 to 72 bytes on x86-64. Signed-off-by:
-
Colin Ian King authored
Variable val is initialized to a value in a for-loop that is never read and hence it is redundant. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 16 Aug, 2019 2 commits
-
-
Laurent Pinchart authored
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Laurent Pinchart authored
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: dc2e1e5b ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel") Fixes: 415b8dd0 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel") Fixes: 1c8fc3f0 ("drm/panel: Add driver for the Sony ACX565AKM panel") Fixes: c9cf4c2a ("drm/panel: Add driver for the Sharp LS037V7DW01 panel") Fixes: df439abe ("drm/panel: Add driver for the NEC NL8048HL11 panel") Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags] Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com
-
