- 21 Jun, 2019 1 commit
-
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190620150306.124839-1-yuehaibing@huawei.com
-
- 20 Jun, 2019 3 commits
-
-
Daniel Vetter authored
I rushed merging this a bit too much, and Noralf pointed out that we're a lot better already and have made great progress. Let's try again. v2: Fix typo spotted by Eric Engestrom. Fixes: 8db420ac ("drm/todo: Improve drm_gem_object funcs todo") Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Eric Anholt <eric@anholt.net> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618140241.19856-1-daniel.vetter@ffwll.ch
-
Yannick Fertré authored
Without this fix, the system can not go in "suspend" mode due to an error in drv_suspend function. Fixes: 35ab6cfb ("drm/stm: support runtime power management") Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
Sean Paul authored
If state allocation fails, we still try to give back the reference on it. Also initialize ret in case the crtc is not enabled and we hit the eject button. Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190619181951.192305-1-sean@poorly.run
-
- 19 Jun, 2019 21 commits
-
-
Dan Carpenter authored
This test is flipped around so it either leads to a memory leak or a NULL dereference. Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Signed-off-by:
-
Paul Cercueil authored
Add a KMS driver for the Ingenic JZ47xx family of SoCs. This driver is meant to replace the aging jz4740-fb driver. This driver does not make use of the simple pipe helper, for the reason that it will soon be updated to support more advanced features like multiple planes, IPU integration for colorspace conversion and up/down scaling, support for DSI displays, and TV-out and HDMI outputs. Notes: v2: - Remove custom handling of panel. The panel is now discovered using the standard API. - Lots of small tweaks suggested by upstream v3: - Use devm_drm_dev_init() - Update compatible strings to -lcd instead of -drm - Add destroy() callbacks to plane and crtc - The ingenic,lcd-mode is now read from the bridge's DT node v4: Remove ingenic,lcd-mode property completely. The various modes are now deduced from the connector type, the pixel format or the bus flags. v5: - Fix framebuffer size incorrectly calculated for 24bpp framebuffers - Use 32bpp framebuffer instead of 16bpp, as it'll work with both 16-bit and 24-bit panel - Get rid of drm_format_plane_cpp() which has been dropped upstream - Avoid using drm_format_info->depth, which is deprecated. Signed-off-by:Paul Cercueil <paul@crapouillou.net> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Paul Cercueil authored
Add documentation for the devicetree bindings of the LCD controller present in the JZ47xx family of SoCs from Ingenic. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maarten Lankhorst authored
topic/remove-fbcon-notifiers: - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking - assorted locking checks in vt/console code - assorted notifier and cleanups in fbdev and backlight code This is the pull request that was sent out, plus the compile fix for sh4 reported by kbuild. Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Maarten Lankhorst authored
remove-fbcon-notifiers topic branch is based on rc4, so we need a fresh backmerge of drm-next to pull it in. Signed-off-by: -
Maxime Ripard authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Acked-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/44e24172e300be6a41578517021ef6a6e90ed682.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
The command line parser is pretty tough to get right and very error prone, so let's add a selftest to try to catch any regression. Reviewed-by:
-
Maxime Ripard authored
During the connector reset, if that connector has a TV property, it needs to be reset to the value provided on the command line. Provide a helper to do that. Reviewed-by:
-
Maxime Ripard authored
Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by:
-
Maxime Ripard authored
The TV margins has been defined as a structure inside the drm_connector_state structure so far. However, we will need it in other structures as well, so let's move that structure definition so that it can be reused. Reviewed-by:
-
Maxime Ripard authored
Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by:
-
Maxime Ripard authored
The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by:
-
Maxime Ripard authored
Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by:
-
Maxime Ripard authored
The drm_client_panel_rotation function has been used so far to set the default rotation based on the panel orientation. However, we can have more sources of information to make that decision, starting with the command line that we will introduce later in this series. Change the name to remove the panel mention. Reviewed-by:
-
Maxime Ripard authored
The drm_client_rotation has a check on the rotation value, but the reflections are also stored in the same variable, and the check doesn't take this into account. Therefore, even though we might have a valid rotation, if we're also using a reflection parameter, the test will fail for no particular reason. Reviewed-by:
-
Maxime Ripard authored
The drm_client_modeset_commit_atomic function uses two times the plane_state variable in inner blocks of code, but the variable has a scope global to this function. This will lead to inadvertent devs to reuse the variable in the second block with the value left by the first, without any warning from the compiler since value would have been initialized. Fix this by moving the variable declaration to the proper scope. Reviewed-by:
-
Maxime Ripard authored
The struct drm_cmdline_mode holds the result of the command line parsers. However, it wasn't documented so far, so let's do that. Reviewed-by:
-
Daniel Vetter authored
Maarten needs -rc4 backmerged so he can pull in the fbcon notifier removal topic branch into drm-misc-next. Signed-off-by: -
Daniel Vetter authored
I failed to spot this while compile-testing. Oops. Reported-by:
kbuild test robot <lkp@intel.com> Fixes: 9e146700 ("fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Jingoo Han <jingoohan1@gmail.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Yisheng Xie <ysxie@foxmail.com> Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl> Cc: Peter Rosin <peda@axentia.se> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: linux-fbdev@vger.kernel.org Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lukas Wunner <lukas@wunner.de> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Oleg Vasilev authored
Other drivers are able to list crc sources when accessing /sys/kernel/debug/dri/.../crtc-0/crc/control Even though VKMS now supports only 'auto' mode, it is more consistent to have the list available to the userspace. Signed-off-by:
Oleg Vasilev <oleg.vasilev@intel.com> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by:
-
Daniel Vetter authored
No need to have them multiple times. Signed-off-by:
-
- 18 Jun, 2019 6 commits
-
-
Serge Semin authored
Since commit 4b050ba7 ("MIPS: pgtable.h: Implement the pgprot_writecombine function for MIPS") and commit c4687b15 ("MIPS: Fix definition of pgprot_writecombine()") write-combine vma mapping is available to be used by kernel subsystems for MIPS. In particular the uncached accelerated attribute is requested to be set by ioremap_wc() method and by generic PCI memory pages/ranges mapping methods. The same is done by the drm_io_prot()/ttm_io_prot() functions in case if write-combine flag is set for vma's passed for mapping. But for some reason the pgprot_writecombine() method calling is ifdefed to be a platform-specific with MIPS system being marked as lacking of one. At the very least it doesn't reflect the current MIPS platform implementation. So in order to improve the DRM subsystem performance on MIPS with UCA mapping enabled, we need to have pgprot_writecombine() called for buffers, which need store operations being combined. In case if particular MIPS chip doesn't support the UCA attribute, the mapping will fall back to noncached. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: James Hogan <jhogan@kernel.org> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Paul Burton <paul.burton@mips.com> Signed-off-by:
Vadim V. Vlasov <vadim.vlasov@t-platforms.ru> Signed-off-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
-
Sean Paul authored
drm_atomic_get_crtc_state() returns an error pointer when it fails, so the null check is doing nothing here. Credit to 0-day/Dan Carpenter for reporting this. Fixes: 6f3b6278 ("drm: Convert connector_helper_funcs->atomic_check to accept drm_atomic_state") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [for rcar lvds] Cc: Sean Paul <seanpaul@chromium.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Boris Brezillon authored
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
-
Boris Brezillon authored
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change with new gens). Suggested-by:
-
Boris Brezillon authored
We plan to expose performance counters through 2 driver specific ioctls until there's a solution to expose them in a generic way. In order to be able to deprecate those ioctls when this new infrastructure is in place we add an unsafe module parameter that will keep those ioctls hidden unless it's set to true (which also has the effect of tainting the kernel). All unstable ioctl handlers should use panfrost_unstable_ioctl_check() to check whether they're supposed to handle the request or reject it with ENOSYS. Suggested-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Boris Brezillon authored
So they can be used from other files. Signed-off-by:
-
- 17 Jun, 2019 3 commits
-
-
Daniel Vetter authored
They're purely for internal use, not for drivers. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
-
Daniel Vetter authored
We're kinda going in the wrong direction. Spotted while typing better gem/prime docs. Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
Pick up rc3 and rc4 and the merges from the other branches, we're a bit out of date. Signed-off-by:
-
- 16 Jun, 2019 6 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "The accumulated fixes from this and last week: - Fix vmalloc TLB flush and map range calculations which lead to stale TLBs, spurious faults and other hard to diagnose issues. - Use fault_in_pages_writable() for prefaulting the user stack in the FPU code as it's less fragile than the current solution - Use the PF_KTHREAD flag when checking for a kernel thread instead of current->mm as the latter can give the wrong answer due to use_mm() - Compute the vmemmap size correctly for KASLR and 5-Level paging. Otherwise this can end up with a way too small vmemmap area. - Make KASAN and 5-level paging work again by making sure that all invalid bits are masked out when computing the P4D offset. This worked before but got broken recently when the LDT remap area was moved. - Prevent a NULL pointer dereference in the resource control code which can be triggered with certain mount options when the requested resource is not available. - Enforce ordering of microcode loading vs. perf initialization on secondary CPUs. Otherwise perf tries to access a non-existing MSR as the boot CPU marked it as available. - Don't stop the resource control group walk early otherwise the control bitmaps are not updated correctly and become inconsistent. - Unbreak kgdb by returning 0 on success from kgdb_arch_set_breakpoint() instead of an error code. - Add more Icelake CPU model defines so depending changes can be queued in other trees" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback x86/kasan: Fix boot with 5-level paging and KASAN x86/fpu: Don't use current->mm to check for a kthread x86/kgdb: Return 0 from kgdb_arch_set_breakpoint() x86/resctrl: Prevent NULL pointer dereference when local MBM is disabled x86/resctrl: Don't stop walking closids when a locksetup group is found x86/fpu: Update kernel's FPU state before using for the fsave header x86/mm/KASLR: Compute the size of the vmemmap section properly x86/fpu: Use fault_in_pages_writeable() for pre-faulting x86/CPU: Add more Icelake model numbers mm/vmalloc: Avoid rare case of flushing TLB with weird arguments mm/vmalloc: Fix calculation of direct map addr range -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "A set of small fixes: - Repair the ktime_get_coarse() functions so they actually deliver what they are supposed to: tick granular time stamps. The current code missed to add the accumulated nanoseconds part of the timekeeper so the resulting granularity was 1 second. - Prevent the tracer from infinitely recursing into time getter functions in the arm architectured timer by marking these functions notrace - Fix a trivial compiler warning caused by wrong qualifier ordering" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Repair ktime_get_coarse*() granularity clocksource/drivers/arm_arch_timer: Don't trace count reader functions clocksource/drivers/timer-ti-dm: Change to new style declaration -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull RAS fixes from Thomas Gleixner: "Two small fixes for RAS: - Use a proper search algorithm to find the correct element in the CEC array. The replacement was a better choice than fixing the crash causes by the original search function with horrible duct tape. - Move the timer based decay function into thread context so it can actually acquire the mutex which protects the CEC array to prevent corruption" * 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: RAS/CEC: Convert the timer callback to a workqueue RAS/CEC: Fix binary search function -
Douglas Anderson authored
In vop_crtc_mode_fixup() we fixup the mode to show what we actually will be able to achieve. However we should base our adjustments on any previous adjustments that were made. As an example, the dw_hdmi driver may wish to make some small adjustments to clock rates in its atomic_check() function. If it does, it will update the adjusted_mode. We shouldn't throw away those adjustments. NOTE: the version of the dw_hdmi driver upstream doesn't _actually_ make such adjustments, but downstream in Chrome OS it does. It is plausible that one day we'll figure out how to cleanly make that happen in an upstream-friendly way, so we should prepare by using the right mode. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-2-dianders@chromium.org
-
Douglas Anderson authored
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de3 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
-
