- 26 Apr, 2024 7 commits
-
-
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:
Sean Anderson <sean.anderson@linux.dev> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> 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:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404190103.lLm8LtuP-lkp@intel.com/Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240422103352.8886-1-aford173@gmail.com
-
- 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 <anatoliy.klymenko@amd.com> Reviewed-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 15 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:
-
Tony Lindgren authored
Set pre_enable_prev_first to ensure the previous bridge is enabled first. Reviewed-by:
-
Tony Lindgren authored
Burst and low-power modes are supported both for tc358765 and tc358775. Reviewed-by:
-
Tony Lindgren authored
The current code assumes the data-lanes property is configured on the DSI host side instead of the bridge side, and assumes DSI host endpoint 1. Let's standardize on what the other bridge drivers are doing and parse the data-lanes property for the bridge. Only if data-lanes property is not found, let's be nice and also check the DSI host for old dtb in use and warn. And as Dmitry pointed out, the lanes for the host and the bridge may be different because the lanes may be swapped on the host side. Reviewed-by:
-
Michael Walle authored
The stby pin is optional. It is only needed for power-up and down sequencing. It is not needed, if the power rails cannot by dynamically enabled. Because the GPIO is now optional, remove the error message. Signed-off-by:
-
Michael Walle authored
The bridge always uses 24bpp internally. Therefore, for jeida-18 mapping we need to discard the lowest two bits for each channel and thus starting with LV_[RGB]2. jeida-24 has the same mapping but uses four lanes instead of three, with the forth pair transmitting the lowest two bits of each channel. Thus, the mapping between jeida-18 and jeida-24 is actually the same, except that one channel is turned off (by selecting the RGB666 format in VPCTRL). While at it, remove the bogus comment about the hardware default because the default is overwritten in any case. Tested with a jeida-18 display (Evervision VGG644804). Fixes: b2697559 ("display/drm/bridge: TC358775 DSI/LVDS driver") Signed-off-by:
-
Tony Lindgren authored
The tc358765 is similar to tc358775. The tc358765 just an earlier version of the hardware, and it's pin and register compatible with tc358775 for most part. From the binding point of view the only difference is that the tc358765 does not have stdby-gpios. Reviewed-by:
-
Tony Lindgren authored
The device uses a clock lane, and 1 to 4 DSI data lanes. Let's add the data-lanes property starting at 1 similar to what the other bridge bindings are doing. Let's also drop the data-lanes properties in the example for the DSI host controller to avoid confusion. The configuration of the DSI host depends on the controller used and is unrelated to the bridge binding. Reviewed-by:
-
