- 25 Jun, 2019 8 commits
-
-
Daniel Vetter authored
Greg is busy already, but maybe he won't do everything ... Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-59-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Thanks to Noralf some good progress already. Reviewed-by:
-
Daniel Vetter authored
Basic helpers have been extracted, now there's a pile more todo still across the entire tree. Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Daniel Vetter authored
I've done that. Reviewed-by:
-
Daniel Vetter authored
This is done in drm_prime.c now. Reviewed-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
This is now done in drm_prime.c Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Daniel Vetter authored
If we use the gem fb helper as the prepare_fb hook, plus the drm_prime.c import helpers now automatically setting obj->resv, we can use the shared helpers to wait for fences instead of rolling our own. Note that this relies on mtk setting drm_fb->obj, which is already done in mtk_drm_framebuffer_init(). Aside: Probably can use the default commit_tail with this again, but I didn't check for that. Reviewed-by:
CK Hu <ck.hu@mediatek.com> Reviewed-by:
-
Daniel Vetter authored
It was only used for prime import, which is now handled by drm_prime.c. Reviewed-by:
-
- 24 Jun, 2019 8 commits
-
-
Rob Herring authored
Convert the tpo,tpg110 panel binding to DT schema. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
We need to handle the case when of_drm_find_bridge() returns NULL. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Ville Syrjälä authored
Just use a pointer to the display_info rather than make a copy on stack. Cc: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326173810.11979-1-ville.syrjala@linux.intel.comAcked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
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:
-
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 20 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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
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:
-
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:
-
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:
-
