- 11 Mar, 2020 9 commits
-
-
Ville Syrjälä authored
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Adam Ford <aford173@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-22-ville.syrjala@linux.intel.comReviewed-by:
Adam Ford <aford173@gmail.com>
-
Ville Syrjälä authored
The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Ville Syrjälä authored
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Heiko Schocher <hs@denx.de> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by:
Heiko Schocher <hs@denx.de>
-
Ville Syrjälä authored
The listed dotclocks are two orders of mangnitude out. Fix them. v2: Just divide everything by 100 (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Ville Syrjälä authored
The dotclock is three orders of magnitude out. Fix it. v2: Just set it to 20MHz (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Takashi Iwai authored
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/357174/Signed-off-by:
-
Christian König authored
The assert sometimes incorrectly triggers when pinned BOs are destroyed. Signed-off-by:
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Link: https://patchwork.freedesktop.org/patch/356737/
-
Heiko Stuebner authored
rockchip_drm_endpoint_is_subdriver() may also return error codes. For example if the target-node is in the disabled state, so no platform-device is getting created for it. In that case current code would count that as external rgb device, which in turn would make probing the rockchip-drm device fail. So only count the target as rgb device if the function actually returns 0. Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121224828.4070067-1-heiko@sntech.de
-
- 10 Mar, 2020 17 commits
-
-
Fabrizio Castro authored
Add binding for the idk-2121wr LVDS panel from Advantech. Some panel-specific documentation can be found here: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htmSigned-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1583869169-1006-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
-
Lyude Paul authored
We actually expect this to return a 0 on success, or negative error code on failure. In order to do that, we check whether or not we managed to write the whole GUID and then return 0 if so, otherwise return a negative error code. Also, let's add an error message here so it's a little more obvious when this fails in the middle of a link address probe. This should fix issues with certain MST hubs seemingly stopping for no reason in the middle of the link address probe process. Fixes: cb897542 ("drm/dp_mst: Fix W=1 warnings") Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Sean Paul <sean@poorly.run> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306234923.547873-3-lyude@redhat.comReviewed-by:
Alex Deucher <alexander.deucher@amd.com>
-
Lyude Paul authored
Noticed this while having some problems with hubs sometimes not being detected on the first plug. Every single dpcd read or write function returns the number of bytes transferred on success or a negative error code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on success. There's not really any good reason for this difference that I can tell, and having the two functions give differing behavior means that drm_dp_dpcd_write() will end up returning 0 on success for MST devices, but the number of bytes transferred for everything else. So, fix that and update the kernel doc. Signed-off-by:
-
H. Nikolaus Schaller authored
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. There are two variants of the COM37H3M panel. The older one's COM37H3M05DTC data sheet specifies: MIN TYP MAX CLK frequency fCLK -- 22.4 26.3 MHz (in VGA mode) VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv -- 650 -- H HSYNC frequency fHSYNC -- 39.3 -- kHz HSYNC cycle time th -- 570 -- CLK The newer one's COM37H3M99DTC data sheet says: MIN TYP MAX CLK frequency fCLK 18 19.8 27 MHz VSYNC Frequency fVSYNC 54 60 66 Hz VSYNC cycle time tv 646 650 700 H HSYNC frequency fHSYNC -- 39.0 50.0 kHz HSYNC cycle time th 504 508 630 CLK So we choose a parameter set that lies within the specs of both variants. We start at .vrefresh = 60, choose .htotal = 570 and .vtotal = 650 and end up in a clock of 22.230 MHz. Reported-by:H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
-
Laurent Pinchart authored
The OrtusTech COM43H4M85ULC is a DPI panel, set the connector type accordingly. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Akeem G Abodunrin authored
In Pete Goodliffe words, "You can improve a system by adding new code. You can also improve a system by removing code" - In this case, commit "202b52b7" added new code to initialize end of the node. So, there is no need for duplicated initialization, and this patch simply removes it. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Neil Armstrong authored
This patch adds support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch enables the bridge bus format negociation, and handles the YUV420 case if selected by the negociation. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Jernej Škrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304104052.17196-12-narmstrong@baylibre.com
-
Neil Armstrong authored
This patch adds clocking support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. This mode needs a different clock generation scheme since the TMDS PHY clock must match the 10x ratio with the YUV420 pixel clock, but the video encoder must run at 2x the pixel clock. This patch adds the TMDS PHY clock value in all the video clock setup in order to better support these specific uses cases and switch to the Common Clock framework for clocks handling in the future. Signed-off-by:
-
Neil Armstrong authored
This patch adds encoding support for the YUV420 output from the Amlogic Meson SoCs Video Processing Unit to the HDMI Controller. The YUV420 is obtained by generating a YUV444 pixel stream like the classic HDMI display modes, but then the Video Encoder output can be configured to down-sample the YUV444 pixel stream to a YUV420 stream. In addition if pixel stream down-sampling, the Y Cb Cr components must also be mapped differently to align with the HDMI2.0 specifications. Signed-off-by:
-
Neil Armstrong authored
To allow using formats from negotiation, stop enforcing input_bus_format in the private dw-plat-data struct. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
-
Neil Armstrong authored
Switch the dw-hdmi driver to drm_bridge_funcs by implementing a new local bridge, connecting it to the dw-hdmi bridge, then implement the atomic_get_input_bus_fmts/atomic_get_output_bus_fmts. Signed-off-by:
-
Neil Armstrong authored
Before switching to bridge funcs, make sure drm_display_mode is passed as const to the venc functions. Signed-off-by:
-
Neil Armstrong authored
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support for these modes in the connector if the platform supports them. We limit these modes to DW-HDMI IP version >= 0x200a which are designed to support HDMI2.0 display modes. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
-
Neil Armstrong authored
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by:
-
Neil Armstrong authored
Add atomic_duplicate_state/atomic_destroy_state/atomic_reset bridge funcs to allow setup of atomic bridge state. Signed-off-by:
-
Jonas Karlman authored
Add the max_bpc property to the dw-hdmi connector to prepare support for 10, 12 & 16bit output support. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
Jonas Karlman authored
Configure the correct mtmdsclock for deep colors to prepare support for 10, 12 & 16bit output. Signed-off-by:
-
- 09 Mar, 2020 3 commits
-
-
Gurchetan Singh authored
This function can be reused for hostmem objects. v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object() v3: use-after free fix Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20200305013212.130640-2-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
A resource will be a shmem based resource or a (planned) vram based resource, so it makes sense to factor out common fields (resource handle, dumb). v2: move mapped field to shmem object Signed-off-by:
-
Chris Wilson authored
Pull the drm_pci_agp_init() underneath the legacy ifdeffry alongside its only caller. The diff chooses it to so it by moving drm_pci_agp_destroy earlier, but the important bit is moving the #ifdef earlier before drm_pci_agp_init. Signed-off-by:
-
- 07 Mar, 2020 2 commits
-
-
Peter Rosin authored
This reverts commit 0f9cdd74. The interface of the panel is LVDS, not parallel. The color depth is RGB888, not RGB565. The panel has additional features, making it not so simple. The only user (upstream) of this panel is appropriately using panel-lvds. Suggested-by:
Thierry Reding <thierry.reding@gmail.com> Suggested-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 06 Mar, 2020 9 commits
-
-
Dafna Hirschfeld authored
convert the binding file rockchip-drm.txt to yaml format. This was tested and verified on ARM and ARM64 with: make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml Changes since v2: - add a missing ">" sign in maintainers list - change the licens to GPL-2.0-only - add "additionalProperties: false" - change the commit message to conform that it was tested on both ARM and ARM64 Changes since v1: - fixed worng sign-off - fixed the path of the $id property to be the path of the yaml file Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200121154314.3444-1-dafna.hirschfeld@collabora.com
-
Daniel Vetter authored
Only user left is the shadow attach for legacy drivers. v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include drm_get_pci_dev() (Thomas) Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225165835.2394442-1-daniel.vetter@ffwll.ch
-
Pankaj Bharadiya authored
drm_fb_helper tasks are completed now hence remove them from todo list. Changes since v1: * remove entire drm_fb_helper tasks from todo list. Daniel's "64914da2 drm/fbdev-helper: don't force restores" already fixes first one (Daniel) Signed-off-by:
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200305120434.111091-8-pankaj.laxminarayan.bharadiya@intel.com
-
Pankaj Bharadiya authored
drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector() don't keep an array of connectors anymore and are just dummy. Now we have no callers to these functions hence remove them. Signed-off-by:
-
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() and drm_fb_helper_single_add_all_connectors() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h This removal is done using below sementic patch and unused variable compilation warnings are fixed manually. @@ @@ - drm_fb_helper_single_add_all_connectors(...); @@ expression e1; statement S; @@ - e1 = drm_fb_helper_single_add_all_connectors(...); - S @@ @@ - drm_fb_helper_add_one_connector(...); @@ @@ - drm_fb_helper_remove_one_connector(...); Changes since v1: * Squashed warning fixes into the patch that introduced the warnings (into 5/7) (Laurent, Emil, Lyude) Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
drm_fb_helper_{add,remove}_one_connector() are dummy functions now and serve no purpose. Hence remove their calls. This is the preparatory step for removing the drm_fb_helper_{add,remove}_one_connector() functions from drm_fb_helper.h Signed-off-by: -
Pankaj Bharadiya authored
The max connector argument for drm_fb_helper_init() isn't used anymore hence remove it. All the drm_fb_helper_init() calls are modified with below sementic patch. @@ expression E1, E2, E3; @@ - drm_fb_helper_init(E1,E2, E3) + drm_fb_helper_init(E1,E2) Signed-off-by:
-
