- 24 Jun, 2019 5 commits
-
-
Ville Syrjälä authored
WARN if the incoming drm_display_mode has an illegal aspect ratio when converting it to a user mode. This should never happen unless the driver made a mistake and put an invalid value into the aspect ratio. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-4-ville.syrjala@linux.intel.comReviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Ville Syrjälä authored
Don't let userspace feed us any old garbage in the mode aspect ratio flags. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Ville Syrjälä authored
enum hdmi_picture_aspect is not a bitmask, so don't use bitwise OR to populate it. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Maxime Ripard authored
The commit 3aeeb13d ("drm/modes: Support modes names on the command line") added name support to the DRM modes, and added that name to the debug message. However, that code tests for whether or not the name variable is NULL and only prints it if it's not. Except that that variable is an array, so it will never be NULL. The original intent was to print it only when the name has been specified. Just printing the array directly will achieve the same thing since the drm_cmdline_mode structure that holds it is itself contained in drm_connector, that is allocated with its whole content zero'd. That means that if the name is not declared, the array will be all zeros, which will not print anything. Cc: Nick Desaulniers <ndesaulniers@google.com> Reported-by:
kbuild test robot <lkp@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 3aeeb13d ("drm/modes: Support modes names on the command line") Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190624084016.12937-1-maxime.ripard@bootlin.com
-
Matt Redfearn authored
The Synopsys MIPI DSI IP contains a video test pattern generator which is helpful in debugging video timing with connected displays. Add a debugfs directory containing files which allow the VPG to be enabled and disabled, and its orientation to be changed. Signed-off-by:
Matt Redfearn <matt.redfearn@thinci.com> Tested-by:
Yannick Fertré <yannick.fertre@st.com> Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430081646.23845-1-matt.redfearn@thinci.com
-
- 23 Jun, 2019 4 commits
-
-
Krzysztof Kozlowski authored
There is no point to print deferred probe messages as errors. Adjust the printks for error paths of obtaining clocks and reset controller. This removes the error message of lima_clk_init() call in favor or specific failure messages inside. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190621162117.22533-4-krzk@kernel.org
-
Krzysztof Kozlowski authored
Store the PTR_ERR() result in local variable in clock init error path. This makes the code consistent with similar section in regulator init code. Signed-off-by:
-
Krzysztof Kozlowski authored
There is no point to print deferred probe (and its failures to get resources) as an error. For example getting a regulator causes three unneeded error messages: lima 13000000.gpu: failed to get regulator: -517 lima 13000000.gpu: regulator init fail -517 lima 13000000.gpu: Fatal error during GPU init Also do not print clock rates before the initialization finishes because they will be duplicated after deferral. Each probe step already prints error so remove the final error message "Fatal error during GPU init". In case of multiple probe tries this would pollute the dmesg. Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: -
Krzysztof Kozlowski authored
Mark long numbers with ULL to silence the Smatch warning: drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x100000000 is so big it is long long Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by:
-
- 21 Jun, 2019 31 commits
-
-
Daniel Vetter authored
It looks like this was done purely to get a consistent place to look up the reservation object pointer. With the drm_prime.c helper code now also setting gem_object->resv for imported objects we can just use that pointer directly, instead of first ensuring a dma-buf exists. v2: Note that I screwed up the patch ordering, hence why this needed a Fixes: tag - CI spotted the broken intermediate state. Fixes: 5eab9987 ("drm/vgem: Drop drm_gem_prime_export") Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-49-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's really the only reasonable thing to do, and it won't hurt drivers which don't (yet) use drm_gem_object->resv. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Acked-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. We can't do the same on the import side, due to the exynos_drm->dma_dev not necessarily matching the overall drm device. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
