- 16 Mar, 2020 1 commit
-
-
Benjamin Gaignard authored
Fix kernel doc comments to avoid warnings when compiling with W=1. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200306102937.4932-4-benjamin.gaignard@st.com
-
- 14 Mar, 2020 2 commits
-
-
Fabrizio Castro authored
Add binding for the idk-1110wr LVDS panel from Advantech. Some panel-specific documentation can be found here: https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htmSigned-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.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/1583957020-16359-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com
-
Kamlesh Gurudasani authored
This fixes the following sparse warning: drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: sparse: incorrect type in assignment (different base types) drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: expected unsigned short [usertype] drivers/gpu/drm/tiny/ili9486.c:61:16: sparse: got restricted __be16 [usertype] drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: sparse: incorrect type in assignment (different base types) drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: expected unsigned short [usertype] drivers/gpu/drm/tiny/ili9486.c:71:32: sparse: got restricted __be16 [usertype] Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com> Signed-off-by:
-
- 13 Mar, 2020 2 commits
-
-
Sam Ravnborg authored
Fix following type af warnings in the panel bindings: Warning (unit_address_vs_reg): /example-0/dsi/panel: node has a reg or ranges property, but no unit name Warning (unit_address_vs_reg): /example-0/dsi@ff450000: node has a unit name, but no reg property Removing the "@xxx" from the node name fixed first warning. Adding a missing reg property fixed the second warning v2: - renamed mdss_dsi to dsi in panel-simple-dsi.yaml (Rob) Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Lyude Paul authored
Small nitpick that I noticed a second ago - we can save some space in the struct by making this a bitfield and sticking it with the rest of the bitfields. Also, some small cleanup to the kdocs for this member. There should be no functional changes in this patch. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by:
Wayne Lin <Wayne.Lin@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200122194846.16025-1-lyude@redhat.com
-
- 11 Mar, 2020 16 commits
-
-
Pankaj Bharadiya authored
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector((drm_connector_unregister()/drm_connector_put())) except for amdgpu_dm driver where some amdgpu_dm specific code in there. This connector cleaning up is now being handled in the drm core so driver destroy_connector callbacks are not needed (except for amdgpu_dm) hence remove them. Removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .destroy_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by:Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by:
Emil Velikov <emil.velikov@collabora.com> Suggested-by:
-
Pankaj Bharadiya authored
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector (drm_connector_unregister()/drm_connector_put()) except for amdgpu_dm driver where some amdgpu_dm specific code in there which I an not sure if it should stay or not. Create and use a helper which calls driver's destroy_connector hook if available otherwise does cleanup internally. This is the step towards removing identical hooks from every driver. Signed-off-by:
-
Pankaj Bharadiya authored
Now drm_dp_mst_topology_cbs.register_connector callback is not getting used anymore hence remove it. Signed-off-by:
-
Pankaj Bharadiya authored
drm_dp_mst_port_add_connector() directly calls the drm_connector_register() now and drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting called anymore. Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector callbacks. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. The removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .register_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by: -
Pankaj Bharadiya authored
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally identical amongst every driver and don't do anything other than calling drm_connector_register(). Hence call drm_connector_register() directly instead of a callback. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. Signed-off-by:
-
Manasi Navare authored
Adaptive Sync is a VESA feature so add a DRM core helper to parse the EDID's detailed descritors to obtain the adaptive sync monitor range. Store this info as part fo drm_display_info so it can be used across all drivers. This part of the code is stripped out of amdgpu's function amdgpu_dm_update_freesync_caps() to make it generic and be used across all DRM drivers v6: * Call it monitor_range (Ville) v5: * Use the renamed flags v4: * Use is_display_descriptor() (Ville) * Name the monitor range flags (Ville) v3: * Remove the edid parsing restriction for just DP (Nicholas) * Use drm_for_each_detailed_block (Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com
-
Manasi Navare authored
This patch adds defines for the detailed monitor range flags as per the EDID specification. v2: * Rename the flags with DRM_EDID_ (Jani N) Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
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:
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:
-
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:
-
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:
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:
-
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 2 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:
-
