- 22 Dec, 2022 7 commits
-
-
Maíra Canal authored
The structs drm_debugfs_info and drm_debugfs_entry introduced a new debugfs structure to DRM, centered on drm_device instead of drm_minor. Therefore, remove the tasks related to create a new device-centered debugfs structure and add a new task to replace the use of drm_debugfs_create_files() for the use of drm_debugfs_add_file() and drm_debugfs_add_files(). Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20221219120621.15086-8-mcanal@igalia.com
-
Maíra Canal authored
Replace the use of drm_debugfs_create_files() with the new drm_debugfs_add_files() function, which centers the debugfs files management on the drm_device instead of drm_minor. Moreover, remove the debugfs_init hook and add the debugfs files directly on vkms_create(), before drm_dev_register(). Signed-off-by:
-
Maíra Canal authored
Replace the use of drm_debugfs_create_files() with the new drm_debugfs_add_files() function, which centers the debugfs files management on the drm_device instead of drm_minor. Signed-off-by:
-
Maíra Canal authored
Currently, vc4 has its own debugfs infrastructure that adds the debugfs files on drm_dev_register(). With the introduction of the new debugfs, functions, replace the vc4 debugfs structure with the DRM debugfs device-centered function, drm_debugfs_add_file(). Moreover, remove the explicit error handling of debugfs related functions, considering that the only failure mode is -ENOMEM and also that error handling is not recommended for debugfs functions, as pointed out in [1]. [1] https://lore.kernel.org/all/YWAmZdRwnAt6wh9B@kroah.com/Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
-
Maíra Canal authored
Although the device-centered debugfs functions can track requests for the addition of DRM debugfs files at any time and have them added all at once during drm_dev_register(), they are not able to create debugfs files for modeset components, as they are registered after the primary and the render drm_minor are registered. So, create a drm_debugfs_late_register() function, which is responsible for dealing with the creation of all the debugfs files for modeset components at once. Therefore, the functions drm_debugfs_add_file() and drm_debugfs_add_files() can be used in late_register hooks. Signed-off-by:
-
Maíra Canal authored
Replace the use of drm_debugfs_create_files() with the new drm_debugfs_add_files() function in all DRM core files, centering the debugfs files management on the drm_device instead of drm_minor. Signed-off-by:
-
Maíra Canal authored
Introduce the ability to track requests for the addition of DRM debugfs files at any time and have them added all at once during drm_dev_register(). Drivers can add DRM debugfs files to a device-managed list and, during drm_dev_register(), all added files will be created at once. Now, the drivers can use the functions drm_debugfs_add_file() and drm_debugfs_add_files() to create DRM debugfs files instead of using the drm_debugfs_create_files() function. Co-developed-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
- 20 Dec, 2022 3 commits
-
-
Thomas Zimmermann authored
Ast hardware scans out the primary plane from video memory, which is in I/O-memory space. Hence init the damage handler's iosys_map pointer as I/O memory. Not all platforms support accessing I/O memory as system memory, although it's usually not a problem in ast's x86-based systems. The error report is at [1]. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Fixes: f2fa5a99 ("drm/ast: Convert ast to SHMEM") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/lkml/202212170111.eInM0unS-lkp@intel.com/T/#u # 1 Link: https://patchwork.freedesktop.org/patch/msgid/20221216193005.30280-1-tzimmermann@suse.de
-
Deepak R Varma authored
A call to platform_get_irq() already prints an error on failure within its own implementation. So printing another error based on its return value in the caller is redundant and should be removed. The clean up also makes if condition block braces unnecessary. Remove that as well. Issue identified using platform_get_irq.cocci coccicheck script. Signed-off-by:
Deepak R Varma <drv@mailo.com> Reviewed-by:
-
Uwe Kleine-König authored
There is a local variable that contains dev->driver. Make use of it instead of "open coding" it. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
- 19 Dec, 2022 3 commits
-
-
Christian König authored
TTM is just wrapping core DMA functionality here, remove the mid-layer. No functional change. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-6-christian.koenig@amd.com
-
Melissa Wen authored
As v3d_lookup_bos() performs the same steps as drm_gem_objects_lookup(), replace the explicit code in v3d to simply use the DRM function. Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221205135538.3545051-3-mwen@igalia.com
-
Melissa Wen authored
When v3d_lookup_bos fails to `allocate validated BO pointers`, job->bo_count was already set to args->bo_count, but job->bo points to NULL. In this scenario, we must verify that job->bo is not NULL before iterating on it to proper clean up a job. Also, drm_gem_object_put already checks that the object passed is not NULL, doing the job->bo[i] checker redundant. Signed-off-by:
-
- 16 Dec, 2022 20 commits
-
-
Lucas Stach authored
The IPUv3 and DCSS driver are two totally separate DRM drivers. Having one of them live in the drivers/gpu/drm/imx toplevel directory and the other one in the dcss/ subdirectory is confusing. Move the IPUv3 driver into its own subdirectory to make the separation more clear. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20221125112519.3849636-1-l.stach@pengutronix.deSigned-off-by:
-
Philipp Zabel authored
ipu_src_rect_width() was introduced to support odd screen resolutions such as 1366x768 by internally rounding up primary plane width to a multiple of 8 and compensating with reduced horizontal blanking. This also caused overlay plane width to be rounded up, which was not intended. Fix overlay plane width by limiting the rounding up to the primary plane. drm_rect_width(&new_state->src) >> 16 is the same value as drm_rect_width(dst) because there is no plane scaling support. Fixes: 94dfec48 ("drm/imx: Add 8 pixel alignment fix") Reviewed-by:
-
Liang He authored
In ipu_add_client_devices(), we need to call of_node_put() for reference returned by of_graph_get_port_by_id() in fail path. Fixes: 17e05217 ("gpu: ipu-v3: Do not bail out on missing optional port nodes") Signed-off-by:
Liang He <windhl@126.com> Reviewed-by:
-
Tomi Valkeinen authored
dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large struct in its frame, which can result in: drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=] As the performance of the function is of no concern, let's allocate the struct with kmalloc instead. Compile-tested only. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reported-by:
Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220916082206.167427-1-tomi.valkeinen@ideasonboard.com
-
Yuan Can authored
After commit 64ff1891, struct csc_coef_rgb2yuv is not used any more and can be removed as well. Fixes: 64ff1891 ("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Randolph Sapp authored
There was a long-standing bug from a typo that created 2 ARGB1555 and ABGR1555 pixel format entries. Weston 10 has a sanity check that alerted me to this issue. According to the Supported Pixel Data formats table we have the later entries should have been for Alpha-X instead. Signed-off-by:
Randolph Sapp <rs@ti.com> Fixes: 32a1795f ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Reviewed-by:
Aradhya Bhatia <a-bhatia1@ti.com> Acked-by:
Andrew Davis <afd@ti.com> Signed-off-by:
-
Andrew Davis authored
We have no segment size limitations. Set to unlimited. Signed-off-by:
-
Imre Deak authored
If an MST stream is enabled on a disconnected sink, the payload for the stream is not created and the MST manager's payload count/next start VC slot is not updated. Since the payload's start VC slot may still contain a valid value (!= -1) the subsequent disabling of such a stream could cause an incorrect decrease of the payload count/next start VC slot in drm_dp_remove_payload() and hence later payload additions will fail. Fix the above by marking the payload as invalid in the above case, so that it's skipped during payload removal. While at it add a debug print for this case. Cc: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v6.1+ Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221214184258.2869417-3-imre.deak@intel.com
-
Imre Deak authored
After an error during receiving a packet for a multi-packet DP MST sideband message, the state tracking which packets have been received already is not reset. This prevents the reception of subsequent down messages (due to the pending message not yet completed with an end-of-message-transfer packet). Fix the above by resetting the reception state after a packet error. Cc: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
-
Imre Deak authored
If the sink gets disconnected during receiving a multi-packet DP MST AUX down-reply/up-request sideband message, the state keeping track of which packets have been received already is not reset. This results in a failed sanity check for the subsequent message packet received after a sink is reconnected (due to the pending message not yet completed with an end-of-message-transfer packet), indicated by the "sideband msg set header failed" error. Fix the above by resetting the up/down message reception state after a disconnect event. Cc: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
-
Paul Cercueil authored
Add support for the IT6610 HDMI encoder. The hardware is very similar, and therefore the driver did not require too many changes. Some bits are only available on the IT66121, and vice-versa. Also, the IT6610 requires specific polarities on the DE and pixel lines. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221214130131.12962-1-paul@crapouillou.net
-
Paul Cercueil authored
This will make it easier later to introduce support for new chips in this driver. Signed-off-by:
-
Paul Cercueil authored
The DDC preamble and target address only need to be set once before reading the EDID, even if multiple segments have to be read. Signed-off-by:
-
Paul Cercueil authored
The DDC FIFO was cleared before the loop in it66121_get_edid_block(), and at the beginning of each iteration; which means that it did not have to be cleared before the loop. Signed-off-by:
-
Paul Cercueil authored
The DDC error IRQs will fire on the IT6610 every time the FIFO is empty, which is not very helpful. To resolve this, we can simply disable them, and handle DDC errors in it66121_wait_ddc_ready(). Signed-off-by:
-
Paul Cercueil authored
The function it66121_wait_ddc_ready() would previously read the status register until "true", which means it never actually polled anything and would just read the register once. Now, it will properly wait until the DDC hardware is ready or until it reported an error. The 'busy' variable was also renamed to 'error' since these bits are set on error and not when the DDC hardware is busy. Since the DDC ready function is now working properly, the msleep(20) can be removed. Signed-off-by:
-
Paul Cercueil authored
Since all AVI infoframe registers are contiguous in the address space, the AVI infoframe can be written in one go with regmap_bulk_write(). Signed-off-by:
-
Paul Cercueil authored
Use regmap_noinc_read() instead of reading the data from the DDC FIFO one byte at a time. Signed-off-by:
-
Paul Cercueil authored
Simplify the code of the driver by using devm_regulator_bulk_get_enable(), which will handle powering up the regulators, and disabling them on probe error or module removal. Signed-off-by:
-
Paul Cercueil authored
Add a new ite,it6610 compatible string to the IT66121 binding documentation, since the two chips are very similar. Signed-off-by:
-
- 15 Dec, 2022 7 commits
-
-
allen chen authored
Add driver to read data-lanes and link-frequencies from dt property to restrict output bandwidth. Signed-off-by:
allen chen <allen.chen@ite.com.tw> Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Signed-off-by:
-
allen chen authored
Currently there are no "upstream" users. So, no existing users to break. Add properties to restrict dp output data-lanes and clock. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Pin-yen Lin authored
Add caching when EDID is read, and invalidate the cache until the bridge detects HPD low or sink count changes on HPD_IRQ. It takes 1.2s for IT6505 bridge to read a 3-block EDID, and skipping one EDID read would be a notable difference on user experience. Signed-off-by:
-
Robert Foss authored
This fixes PLL being unable to lock, and is derived from an equivalent downstream commit. Available LT9611 documentation does not list this register, neither does LT9611UXC (which is a different chip). This commit has been confirmed to fix HDMI output on DragonBoard 845c. Suggested-by:
Amit Pundir <amit.pundir@linaro.org> Reviewed-by:
-
Dave Stevenson authored
Post_disable was sending the D-PHY sequence to put any device into ULPS suspend mode, and then cutting power to the DSI block. The power-on reset state of the DSI block is for DSI to be in an operational state, not ULPS, so it then never sent the sequence for exiting ULPS. Any attached device that didn't have an external reset therefore remained in ULPS / standby, and didn't function. Use of ULPS isn't well specified in DRM, therefore remove entering it to avoid the above situation. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-6-8f68ee0b0adb@cerno.techSigned-off-by:
-
Dave Stevenson authored
Remove the encoder functions, and create a bridge attached to this dumb encoder which implements the same functionality. As a bridge has state which an encoder doesn't, we need to add the state management functions as well. As there is no bridge atomic_mode_set, move the initialisation code that was in mode_set into _pre_enable. The code to actually enable and disable sending video are split from the general control into _enable and _disable. Signed-off-by:
-
Dave Stevenson authored
The atomic calls are preferred as the non-atomic ones are deprecated. In preparation for conversion to a bridge, switch to the atomic calls. Signed-off-by:
-
