- 16 Jun, 2022 4 commits
-
-
Samuel Holland authored
Now that the HDMI PHY is using a platform driver, it can use device- managed resources. Use these, as well as the dev_err_probe helper, to simplify the probe function and get rid of the remove function. Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220615045543.62813-4-samuel@sholland.org
-
Samuel Holland authored
The struct resource is not used for anything else, so we can simplify the code a bit by using the helper function. Signed-off-by:
-
Samuel Holland authored
Now that the HDMI PHY is using a platform driver, we can use the usual helper function for getting the variant structure. Signed-off-by:
-
Alex Deucher authored
amdgpu_dm_crtc_late_register() is only used when CONFIG_DEBUG_FS is enabled so make it dependent on that. Fixes: 4cd79f61 ("drm/amd/display: Move connector debugfs to drm") Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reported-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://lists.freedesktop.org/archives/dri-devel/2022-June/359496.htmlSigned-off-by:
-
- 15 Jun, 2022 2 commits
-
-
Zheng Bin authored
The driver uses crypto hash functions so it needs to select CRYPTO_HASH. This fixes build errors: drivers/gpu/drm/bridge/ite-it6505.o: in function `it6505_hdcp_wait_ksv_list': ite-it6505.c:(.text+0x4c26): undefined reference to `crypto_alloc_shash' ite-it6505.c:(.text+0x4c6d): undefined reference to `crypto_shash_digest' ite-it6505.c:(.text+0x4c7d): undefined reference to `crypto_destroy_tfm' ite-it6505.c:(.text+0x4d69): undefined reference to `crypto_destroy_tfm' Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Nícolas F. R. A. Prado authored
While parsing the DT, the anx7625 driver checks for the presence of a panel bridge on endpoint 1. If it is missing, pdata->panel_bridge stores the error pointer and the function returns successfully without first cleaning that variable. This is an issue since other functions later check for the presence of a panel bridge by testing the trueness of that variable. In order to ensure proper behavior, zero out pdata->panel_bridge before returning when no panel bridge is found. Fixes: 9e82ea0f ("drm/bridge: anx7625: switch to devm_drm_of_get_bridge") Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
- 13 Jun, 2022 9 commits
-
-
Javier Martinez Canillas authored
This reverts commit fa0e2564. The kernel test robot reported that attempting to build the vesafb driver fails on some architectures, because these don't define a `struct screen_info`. This leads to linking errors, for example on parisc with allyesconfig: hppa-linux-ld: drivers/video/fbdev/vesafb.o: in function `vesafb_probe': >> (.text+0x738): undefined reference to `screen_info' >> hppa-linux-ld: (.text+0x73c): undefined reference to `screen_info' hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': >> (.init.text+0x28): undefined reference to `screen_info' >> hppa-linux-ld: (.init.text+0x30): undefined reference to `screen_info' hppa-linux-ld: (.init.text+0x78): undefined reference to `screen_info' The goal of commit fa0e2564 ("fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled") was to have more build coverage for the driver but it wrongly assumed that all architectures would define a screen_info. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220610085450.1341880-1-javierm@redhat.com
-
Marek Vasut authored
Add missing header file into dsi_host.c and encode data-lanes string directly into the warning message in the driver to avoid build issues detected by lkp. Fixes: 185443ef ("drm/msm: Convert to drm_of_get_data_lanes_count") Reported-by:
Marek Vasut <marex@denx.de> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Rob Clark <robdclark@gmail.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sean Paul <sean@poorly.run> To: dri-devel@lists.freedesktop.org Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220612143349.105766-1-marex@denx.de
-
Jani Nikula authored
Abstract the .get_modes() connector helper call, including the override/firmware EDID fallback, for clarity. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a4de51efc246e4f5bcbf7b84d66bb49aaf7fd974.1654674560.git.jani.nikula@intel.com
-
Jani Nikula authored
Add new functions drm_edid_read(), drm_edid_read_ddc(), and drm_edid_read_custom() to replace drm_get_edid() and drm_do_get_edid() for reading the EDID. The transition is expected to happen over a fairly long time. Note that the new drm_edid_read*() functions do not do any of the connector updates anymore. The reading and parsing will be completely separated from each other. Add new functions drm_edid_alloc(), drm_edid_dup(), and drm_edid_free() for allocating and freeing drm_edid containers. Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
We'll want to return the allocated buffer size in the future. Keep track of it. Signed-off-by:
-
Jani Nikula authored
Add drm_edid based block count and data access helper functions that take the EDID allocated size into account. At the moment, the allocated size should always match the EDID size indicated by the extension count, but this will change in the future. Signed-off-by:
-
Jani Nikula authored
Add a function to get the cea data block collection size. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The CTA Data Block Collection is valid only for CTA extension version 3. In versions 1 and 2, it is a reserved block, which we ignore. The DTD start offset (byte 2, or d in CTA-861 spec), which determines the CTA Data Block Collection size, is specified slightly differently for different versions: Version 1: d = offset for the byte following the reserved data block. If no data is provided in the reserved data block, then d=4. If no DTDs are provided, then d=0 Version 2: d = offset for the byte following the reserved data block. If no data is provided in the reserved data block, then d=4. If d=0, then no detailed timing descriptors are provided, and no data is provided in the reserved data block. Version 3: d = offset for the byte following the data block collection. If no data is provided in the data block collection, then d=4. If d=0, then no detailed timing descriptors are provided, and no data is provided in the data block collection. Ever since commit 9e50b9d5 ("drm: edid: Add some bounds checking"), we've interpreted 0 to mean there are no DTDs but it's all Data Blocks. Per the spec, Data Blocks are only valid for version 3, where we should interpret 0 to mean there are no data blocks. Follow the spec (and hope the EDIDs follow it too). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Yang Yingliang authored
If dma_fence_unwrap_merge() fails, it should return error code in drm_syncobj_transfer_to_timeline() Fixes: ec8d985f ("drm: use dma_fence_unwrap_merge() in drm_syncobj") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 12 Jun, 2022 20 commits
-
-
Igor Torrente authored
Currently, the memory to the composition frame is being allocated using the kzmalloc. This comes with the limitation of maximum size of one page size(which in the x86_64 is 4Kb and 4MB for default and hugepage respectively). Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when testing some pixel formats like ARGB16161616 and the following error were showing up when running kms_plane@plane-panning-bottom-right*: [drm:vkms_composer_worker [vkms]] *ERROR* Cannot allocate memory for output frame. This problem is addessed by allocating the memory using kvzalloc that circunvents this limitation. V5: Improve the commit message and drop the debugging issues in VKMS TO-DO(Melissa Wen). Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Igor Torrente <igormtorrente@gmail.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220404204515.42144-2-igormtorrente@gmail.com
-
Tales Lelo da Aparecida authored
Fix a copypasta error. The caller of compose_plane() already checks primary_composer->map. In contrast, plane_composer->map is never verified here before handling. Fixes: 7938f421 ("dma-buf-map: Rename to iosys-map") Reviewed-by:
André Almeida <andrealmeid@riseup.net> Signed-off-by:
Tales Lelo da Aparecida <tales.aparecida@gmail.com> Signed-off-by:
-
Peter Robinson authored
Add compatible string and Kconfig options and help for bcm2711. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
-
Peter Robinson authored
Runtime PM doesn't seem to work correctly on this driver. On top of that, commit 8b6864e3 ("drm/v3d/v3d_drv: Remove unused static variable 'v3d_v3d_pm_ops'") hints that it most likely never did as the driver's PM ops were not hooked-up. So, in order to support regular operation with V3D on BCM2711 (Raspberry Pi 4), get rid of the PM code. PM will be reinstated once we figure out the underlying issues. Signed-off-by:
-
Peter Robinson authored
BCM2711, Raspberry Pi 4's SoC, contains a V3D core. So add its specific compatible to the bindings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marek Vasut authored
The rcar_mipi_dsi_parse_dt() now contains two uninitialized variables due to conversion to common drm_of_get_data_lanes_count_ep() helper. Drop them. Fixes: d643daaf ("drm/bridge: rcar: Convert to drm_of_get_data_lanes_count_ep") Reported-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220612132152.91052-3-marex@denx.de
-
Marek Vasut authored
Initialize dsi_lanes to -1, so that in case the endpoint is missing, probe would fail as it did before the conversion, instead of depending on uninitialized variable and thus undefined behavior. Fixes: 56426faa ("drm/bridge: tc358775: Convert to drm_of_get_data_lanes_count_ep") Reported-by:
-
Marek Vasut authored
Mark empty implementations of drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep as static inline, just like the rest of empty implementations of various functions in drm_of.h . Add missing comma to drm_of_get_data_lanes_count_ep() . Fixes: fc801750 ("drm: of: Add drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep") Reported-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
The DSI lane count can be accessed via the dsi device pointer, make use of that. The DSI host pointer is only used in sn65dsi83_host_attach(), move the code around so that the host does not have to be cached in the driver private data. This simplifies the code further. No functional change. This has the added bonus that lt9211, tc358767, sn65dsi83 now use very similar *_mipi_dsi_host_attach() which is ripe for deduplication. Signed-off-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220524010522.528569-10-marex@denx.de
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Convert driver to use this new helper to standardize OF "data-lanes" parsing. Reviewed-by:
-
Marek Vasut authored
Add helper function to count and sanitize DT "data-lanes" property and return either error or the data-lanes count. This is useful for both DSI and (e)DP "data-lanes" property. The later version of the function is an extra wrapper which handles the endpoint look up by regs, that's what majority of the drivers duplicate too, but not all of them. Reviewed-by:
-
- 11 Jun, 2022 1 commit
-
-
Douglas Anderson authored
Two blank lines are needed to make the rst valid. Fixes: 69ef4a19 ("drm: Document the power requirements for DP AUX transfers") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
- 10 Jun, 2022 1 commit
-
-
Antonio Borneo authored
Commit 680532c5 ("drm: adv7511: Add support for i2c_new_secondary_device") allows a device tree node to override the default addresses of the secondary i2c devices. This is useful for solving address conflicts on the i2c bus. In adv7511_init_cec_regmap() the new i2c address of cec device is read from device tree and immediately accessed, well before it is written in the proper register to override the default address. This can cause an i2c error during probe and a consequent probe failure. Once the new i2c address is read from the device tree, override the default address before any attempt to access the cec. Tested with adv7533 and stm32mp157f. Signed-off-by:
Antonio Borneo <antonio.borneo@foss.st.com> Fixes: 680532c5 ("drm: adv7511: Add support for i2c_new_secondary_device") Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
- 09 Jun, 2022 3 commits
-
-
Paul Kocialkowski authored
Introduces a driver for the LogiCVC display controller, a programmable logic controller optimized for use in Xilinx Zynq-7000 SoCs and other Xilinx FPGAs. The controller is mostly configured at logic synthesis time so only a subset of configuration is left for the driver to handle. The following features are implemented and tested: - LVDS 4-bit interface; - RGB565 pixel formats; - Multiple layers and hardware composition; - Layer-wide alpha mode; The following features are implemented but untested: - Other RGB pixel formats; - Layer framebuffer configuration for version 4; - Lowest-layer used as background color; - Per-pixel alpha mode. The following features are not implemented: - YUV pixel formats; - DVI, LVDS 3-bit, ITU656 and camera link interfaces; - External parallel input for layer; - Color-keying; - LUT-based alpha modes. Additional implementation-specific notes: - Panels are only enabled after the first page flip to avoid flashing a white screen. - Depth used in context of the LogiCVC driver only counts color components to match the definition of the synthesis parameters. Support is implemented for both version 3 and 4 of the controller. With version 3, framebuffers are stored in a dedicated contiguous memory area, with a base address hardcoded for each layer. This requires using a dedicated CMA pool registered at the base address and tweaking a few offset-related registers to try to use any buffer allocated from the pool. This is done on a best-effort basis to have the hardware cope with the DRM framebuffer allocation model and there is no guarantee that each buffer allocated by GEM CMA can be used for any layer. In particular, buffers allocated below the base address for a layer are guaranteed not to be configurable for that layer. See the implementation of logicvc_layer_buffer_find_setup for specifics. Version 4 allows configuring each buffer address directly, which guarantees that any buffer can be configured. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220520141555.1429041-2-paul.kocialkowski@bootlin.com
-
Daniel Vetter authored
This reverts commit fb561bf9. With commit 27599aac Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Tue Jan 25 10:12:18 2022 +0100 fbdev: Hot-unplug firmware fb devices on forced removal this should be fixed properly and we can remove this somewhat hackish check here (e.g. this won't catch drm drivers if fbdev emulation isn't enabled). Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zackr@vmware.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Zack Rusin <zackr@vmware.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilya Trukhanov <lahvuun@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Javier Martinez Canillas authored
The platform devices registered by sysfb match with firmware-based DRM or fbdev drivers, that are used to have early graphics using a framebuffer provided by the system firmware. DRM or fbdev drivers later are probed and remove conflicting framebuffers, leading to these platform devices for generic drivers to be unregistered. But the current solution has a race, since the sysfb_init() function could be called after a DRM or fbdev driver is probed and request to unregister the devices for drivers with conflicting framebuffes. To prevent this, disable any future sysfb platform device registration by calling sysfb_disable(), if a driver requests to remove the conflicting framebuffers. Suggested-by:
-
