- 29 Apr, 2024 1 commit
-
-
Luca Ceresoli authored
This reverts commit 8a91b29f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com
-
- 27 Apr, 2024 2 commits
-
-
Anatoliy Klymenko authored
Fix W=1 clang 19 compilation error in zynqmp_disp_layer_drm_formats(). Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404260946.4oZXvHD2-lkp@intel.com/Signed-off-by:
Anatoliy Klymenko <anatoliy.klymenko@amd.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240426-dp-live-fmt-fix-v3-2-e904b5ae51d7@amd.com
-
Anatoliy Klymenko authored
Fix arguments description for zynqmp_disp_layer_find_live_format() and zynqmp_disp_layer_set_live_format(). Reported-by:
-
- 26 Apr, 2024 11 commits
-
-
Sean Anderson authored
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- Fixes: eb2d64bf ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Signed-off-by:
Sean Anderson <sean.anderson@linux.dev> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Sean Anderson authored
The feedback we get from the DPRX is per-lane. Make changes using this information, instead of picking the maximum values from all lanes. This results in more-consistent training on marginal links. Signed-off-by:
-
Sean Anderson authored
Enable this message for verbose debugging only as it is otherwise printed after every AUX message, quickly filling the log buffer. Signed-off-by:
-
Sean Anderson authored
Fix a few errors in the kerneldoc. Mostly this addresses missing/renamed members. Signed-off-by:
-
Sean Anderson authored
The blend, avbuf, and audio members of zynqmp_disp are anonymous structs with only one member each. This is rather pointless, so move the members up a level. Signed-off-by:
-
Timur Tabi authored
Add the NVreg_RegistryDwords command line parameter, which allows specifying additional registry keys to be sent to GSP-RM. This allows additional configuration, debugging, and experimentation with GSP-RM, which uses these keys to alter its behavior. Note that these keys are passed as-is to GSP-RM, and Nouveau does not parse them. This is in contrast to the Nvidia driver, which may parse some of the keys to configure some functionality in concert with GSP-RM. Therefore, any keys which also require action by the driver may not function correctly when passed by Nouveau. Caveat emptor. The name and format of NVreg_RegistryDwords is the same as used by the Nvidia driver, to maintain compatibility. Signed-off-by:
Timur Tabi <ttabi@nvidia.com> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417215317.3490856-1-ttabi@nvidia.com
-
Krzysztof Kozlowski authored
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
David Lechner <david@lechnology.com> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240327174842.519758-4-krzysztof.kozlowski@linaro.org
-
Krzysztof Kozlowski authored
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in spi_register_driver() already sets the .owner, so driver does not need to. Signed-off-by:
-
Jani Nikula authored
The drm-misc git repo has moved to Gitlab. Fix the URL. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240425110352.1374729-1-jani.nikula@intel.comSigned-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- 25 Apr, 2024 4 commits
-
-
Andy Yan authored
The port mux of VP2 should be RK3568_OVL_PORT_SET__PORT2_MUX. Fixes: 604be855 ("drm/rockchip: Add VOP2 driver") Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Jani Nikula authored
Never include where a forward declaration will suffice. Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-2-jani.nikula@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20240422121011.4133236-2-jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Surprisingly many places depend on debugfs.h to be included via drm_print.h. Fix them. v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe v2: Also fix ivpu and vmwgfx Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Robert Foss <rfoss@kernel.org> #drm/bridge Reviewed-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422121011.4133236-1-jani.nikula@intel.comSigned-off-by:
-
Adam Ford authored
When enabling i.MX8MP DWC HDMI driver, it automatically selects PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy. This may cause some Kconfig warnings during various build tests. Fix this by implying the phy instead of selecting the phy. To prevent this from happening with the DRM_IMX8MP_HDMI_PVI, also imply it instead of selecting it. Fixes: 1f36d634 ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI") Reported-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
-
- 24 Apr, 2024 14 commits
-
-
Anatoliy Klymenko authored
Program live video input format according to selected media bus format. In the bridge mode of operation, DPSUB is connected to FPGA CRTC which almost certainly supports a single media bus format as its output. Expect this to be delivered via the new bridge atomic state. Program DPSUB registers accordingly. Signed-off-by:
-
Anatoliy Klymenko authored
Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer context. This flag signals whether the driver runs in DRM CRTC or DRM bridge mode, assuming that all display layers share the same live or non-live mode of operation. Using per-layer mode instead of global flag will simplify future support of the hybrid scenario. Remove redundant checks in DMA request/release contexts as zynqmp_disp_layer.info is well-defined for all layer types, including the correct number of DMA channels required for each particular layer. Signed-off-by:
Tomi Valkeinen <tomi.valkainen@ideasonboard.com> Reviewed-by:
-
Anatoliy Klymenko authored
DPSUB in bridge mode supports multiple input media bus formats. Announce the list of supported input media bus formats via drm_bridge.atomic_get_input_bus_fmts callback. Introduce a set of live input formats supported by DPSUB. Add safeguards to format list functions to prevent their misuse in the different layer modes contexts. Reviewed-by:
-
Anatoliy Klymenko authored
Add a helper function capturing the first connected live display layer discovery logic. Signed-off-by:
-
Anatoliy Klymenko authored
Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register layout. These defines were never referenced before, so no other changes required. Reviewed-by:
-
Anatoliy Klymenko authored
Set layer mode of operation (live or dma-based) during layer creation. Each DPSUB layer mode of operation is defined by corresponding DT node port connection, so it is possible to assign it during layer object creation. Previously it was set in layer enable functions, although it is too late as setting layer format depends on layer mode, and should be done before given layer enabled. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by:
-
Krzysztof Kozlowski authored
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by:
-
Barnabás Czémán authored
The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. Signed-off-by:
Barnabás Czémán <trabarni@gmail.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240423-jdi-fix-v1-1-808970662b40@gmail.comSigned-off-by:
-
Dmitry Baryshkov authored
DT bindings for adv7511 and adv7533 bridges specify HDMI output to be present at the port@1. This allows board DT to add e.g. HDMI connector nodes or any other next chained bridge. Make adv7511 driver discover that bridge and attach it to the chain. Signed-off-by:
-
Dmitry Baryshkov authored
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by:
-
Dmitry Baryshkov authored
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by:
-
Dmitry Baryshkov authored
Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240404-drop-panel-unregister-v1-4-9f56953c5fb9@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
It is pointless to set register load before disabling the register. This vote is going to be dropped as soon as the register is disabled. Drop these register_set_load calls. Signed-off-by:
-
- 23 Apr, 2024 8 commits
-
-
Maíra Canal authored
In V3D, the conclusion of a job is indicated by a IRQ. When a job finishes, then we update the local and the global GPU stats of that queue. But, while the GPU stats are being updated, a user might be reading the stats from sysfs or fdinfo. For example, on `gpu_stats_show()`, we could think about a scenario where `v3d->queue[queue].start_ns != 0`, then an interrupt happens, we update the value of `v3d->queue[queue].start_ns` to 0, we come back to `gpu_stats_show()` to calculate `active_runtime` and now, `active_runtime = timestamp`. In this simple example, the user would see a spike in the queue usage, that didn't match reality. In order to address this issue properly, use a seqcount to protect read and write sections of the code. Fixes: 09a93cc4 ("drm/v3d: Implement show_fdinfo() callback for GPU usage stats") Reported-by:
Tvrtko Ursulin <tursulin@igalia.com> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240420213632.339941-7-mcanal@igalia.com
-
Maíra Canal authored
Create a function to decouple the stats calculation from the printing. This will be useful in the next step when we add a seqcount to protect the stats. Signed-off-by:
-
Maíra Canal authored
Given a set of GPU stats, that is, a `struct v3d_stats` related to a queue in a given context, create a function that can update this set of GPU stats. Signed-off-by:
Jose Maria Casanova Crespo <jmcasanova@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240420213632.339941-5-mcanal@igalia.com
-
Maíra Canal authored
This will make it easier to instantiate the GPU stats variables and it will create a structure where we can store all the variables that refer to GPU stats. Note that, when we created the struct `v3d_stats`, we renamed `jobs_sent` to `jobs_completed`. This better express the semantics of the variable, as we are only accounting jobs that have been completed. Signed-off-by:
-
Maíra Canal authored
Currently, we manually perform all operations to update the GPU stats variables. Apart from the code repetition, this is very prone to errors, as we can see on commit 35f4f8c9 ("drm/v3d: Don't increment `enabled_ns` twice"). Therefore, create two functions to manage updating all GPU stats variables. Now, the jobs only need to call for `v3d_job_update_stats()` when the job is done and `v3d_job_start_stats()` when starting the job. Co-developed-by:
-
Xuxin Xiong authored
Add support for the following panel: CSOT MNB601LS1-1 Signed-off-by:
Xuxin Xiong <xuxinxiong@huaqin.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Tony Lindgren authored
The hs_rate and lp_rate may be used by the dsi host for timing calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane, tc358765 has maximurate of 800 Mbps per lane. Reviewed-by:
Michael Walle <mwalle@kernel.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Tony Lindgren authored
The tc358775 bridge is pin compatible with earlier tc358765 according to the tc358774xbg_datasheet_en_20190118.pdf documentation. Compared to the tc358765, the tc358775 supports a STBY GPIO and higher data rates. The tc358765 has a register bit for video event mode vs video pulse mode. We must set it to video event mode for the LCD output to work, and on the tc358775, this bit no longer exists. Looks like the registers seem to match otherwise based on a quick glance comparing the defines to the earlier Android kernel tc358765 driver. Reviewed-by:
-
