- 24 Apr, 2024 12 commits
-
-
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Anatoliy Klymenko <anatoliy.klymenko@amd.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Anatoliy Klymenko authored
Add a helper function capturing the first connected live display layer discovery logic. Signed-off-by:
Tomi Valkeinen <tomi.valkainen@ideasonboard.com> 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 <krzysztof.kozlowski@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240330202741.83867-2-krzysztof.kozlowski@linaro.orgSigned-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 20 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:
Robert Foss <rfoss@kernel.org> Signed-off-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:
-
Michael Walle authored
For a normal operation, the stby GPIO is not needed. The reset pin is required because once the PPI (PHY protocol interface) is started, it can only be stopped by asserting the reset pin. Signed-off-by:
-
Dharma Balasubiramani authored
Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by:
Dharma Balasubiramani <dharma.b@microchip.com> Reviewed-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240421011050.43265-4-dharma.b@microchip.comSigned-off-by:
-
Dharma Balasubiramani authored
Add a new LVDS controller driver for sam9x7 which does the following: - Prepares and enables the LVDS Peripheral clock - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself to the global bridge list. - Identifies its output endpoint as panel and adds it to the encoder display pipeline - Enables the LVDS serializer Signed-off-by:
Manikandan Muralidharan <manikandan.m@microchip.com> Signed-off-by:
Hari Prasath Gujulan Elango <hari.prasathge@microchip.com> Reviewed-by:
-
Dharma Balasubiramani authored
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage Differential Signaling (LVDS) Controller found on some Microchip's sam9x7 series System-on-Chip (SoC) devices. This binding will be used to define the properties and configuration for the LVDS Controller in DT. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240421011050.43265-2-dharma.b@microchip.comSigned-off-by:
-
Maxime Ripard authored
Maíra needs a backmerge to apply v3d patches, and Danilo for some nouveau patches. Signed-off-by:Maxime Ripard <mripard@kernel.org>
-
- 22 Apr, 2024 8 commits
-
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Acked-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/56ee6b7c3c018df55f5fe48a3e6d705dbad5ef74.1713273659.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Acked-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Acked-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/c519a9b9d3c3c9a413de33b99b97a1120f774f2d.1713273659.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Acked-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Acked-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Reviewed-by:
-
Jani Nikula authored
Prefer struct drm_edid based functions over struct edid. Reviewed-by:
-
