Hello Heiko,
Thanks for the patch. Please, see a couple of comments below.
On 2024-11-08 15:44, Heiko Stuebner wrote:
From: Heiko Stuebner
DRM_DEV_ERROR is deprecated and using dev_err_probe saves quite a
number
of lines too, so convert the error prints for the dsi-driver.
Signed-off-by:
On Mon, 21 Oct 2024 15:28:06 +0800, Andy Yan wrote:
> From: Andy Yan
>
> The 'state' can't be NULL, we should check crtc_state.
>
> Fix warning:
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096
> vop_plane_atomic_async_check() warn: variable dereferenced before check
> 'state' (see line 1077)
On Tue, 5 Nov 2024 14:38:16 +0100, Thomas Zimmermann wrote:
> The code for detecting and updating the connector status in
> cdn_dp_pd_event_work() has a number of problems.
>
> - It does not aquire the locks to call the detect helper and update
> the connector status. These are struct drm_mode_con
On Fri, 01 Nov 2024 19:01:17 +, Piotr Zalewski wrote:
> Add support for gamma LUT in VOP2 driver. The implementation was inspired
> by one found in VOP1 driver. Blue and red channels in gamma LUT register
> write were swapped with respect to how gamma LUT values are written in
> VOP1. Gamma LUT
On Mon, 28 Oct 2024 15:41:34 +0800, Andy Yan wrote:
> From: Andy Yan
>
> Demote the error message to drm_dbg_kms to only print the message
> if the respective debug messages are enabled.
>
>
Applied, thanks!
[1/1] drm/rockchip: vop2: Don't spam logs in atomic update
commit: 712ec5de382d
Hi Dmitry,
kernel test robot noticed the following build errors:
[auto build test ERROR on 929beafbe7acce3267c06115e13e03ff6e50548a]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-display-hdmi-add-generic-mode_valid-helper/20241109-203557
base
Hi Dmitry,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 929beafbe7acce3267c06115e13e03ff6e50548a]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-display-hdmi-add-generic-mode_valid-helper/20241109-203557
base
On Sat, Nov 09, 2024 at 09:27:36AM +0200, Dmitry Baryshkov wrote:
> On Fri, Nov 08, 2024 at 05:11:25PM +, Karan Sanghavi wrote:
> > The left shift operation followed by a mask with 0xf will
> > always result in 0. To correctly evaluate the expression for
> > the bitwise OR operation, use a righ
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/backlight to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new().
The motivation for this series comes from pending UMD submission work by
AMD [1], ARM [3], and the Xe team, who are also beginning to look at
this. Sima has suggested [4] some common driver preemptive fences and
semantics, which we all agree on. This is the first attempt to implement
them, based on
Use the new DMA_RESV_USAGE_PREEMPT dma-resv slots in Xe for preemptive
fences, and call them in dma-resv/scheduler rather than open-coding the
enabling of signaling before waiting.
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo
Update drm_sched_job_add_dependency to detect dma_fence_preempt and
correctly store it in the dedicated preemptive fence xarray ensuring
preempt fence semantics are followed.
Cc: Philipp Stanner
Cc: Danilo Krummrich
Cc: Luben Tuikov
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Sign
Use the dma_fence_preempt base class in Xe instead of open-coding the
preemption implementation.
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_guc_submit.c | 3 +
drivers/gpu/drm/xe/xe_hw_engine_group.c | 4 +-
dri
Follow the semantics of DMA_RESV_USAGE_PREEMPT in the DRM scheduler by
storing preemptive fences in a dedicated xarray, which is waited on
after all other fences are signaled. In addition to following these
semantics, pipeline preemptive fences by enabling signaling on all
preemptive fences before
Add a dma_fence_preempt base class with driver ops to implement
preemption, based on the existing Xe preemptive fence implementation.
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Signed-off-by: Matthew Brost
---
drivers/dma-buf/Makefile| 2 +-
drivers/dma-buf/dma-fence
Add a new DMA reservation slot, which is the highest priority and used
exclusively for preemptive fences. The semantics of this slot require
that all other fences in other slots must be signaled before any fences
in the preemptive slot enable signaling. These semantics exist to avoid
deadlocks duri
> On Nov 8, 2024, at 8:30 PM, Yu Kuai wrote:
>
> Hi,
>
> 在 2024/11/08 21:23, Chuck Lever III 写道:
>>> On Nov 7, 2024, at 8:19 PM, Yu Kuai wrote:
>>>
>>> Hi,
>>>
>>> 在 2024/11/07 22:41, Chuck Lever 写道:
On Thu, Nov 07, 2024 at 08:57:23AM +0800, Yu Kuai wrote:
> Hi,
>
> 在 2024
Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec
framework. This enables programming of Audio InfoFrames using the HDMI
Connector interface and also enables support for the missing features,
including the ELD retrieval and better hotplug support.
Signed-off-by: Dmitry Barys
Extend drm_bridge_connector code to read the EDID and use it to update
connector status if the bridge chain implements HDMI bridge. Performing
it from the generic location minimizes individual bridge's code and
enforces standard behaviour from all corresponding drivers.
Signed-off-by: Dmitry Barys
The HDMI Connectors need to perform a variety of tasks when the HDMI
connector state changes. Such tasks include setting or invalidating CEC
address, notifying HDMI codec driver, updating scrambler data, etc.
Implementing such tasks in a driver-specific callbacks is error prone.
Start implementing
Add necessary glue code to be able to use new HDMI codec framework from
the DRM bridge drivers. The drm_bridge implements a limited set of the
hdmi_codec_ops interface, with the functions accepting both
drm_connector and drm_bridge instead of just a generic void pointer.
This framework is integrat
Several DRM drivers implement HDMI codec support (despite its name it
applies to both HDMI and DisplayPort drivers). Implement generic
framework to be used by these drivers. This removes a requirement to
implement get_eld() callback and provides default implementation for
codec's plug handling.
Th
The no_capture_mute flag might differ from platform to platform,
especially in the case of the wrapping implementations, like the
upcoming DRM HDMI Codec framework. Move the flag next to all other flags
in struct hdmi_codec_pdata.
Acked-by: Mark Brown
Signed-off-by: Dmitry Baryshkov
---
drivers
The upcoming DRM connector HDMI codec implementation is going to use
codec-specific data in the .get_dai_id to get drm_connector. Pass data
to the callback, as it is done with other hdmi_codec_ops callbacks.
Acked-by: Mark Brown
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/adv7511
While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
framework, I stumbled upon an issue while handling the Audio InfoFrames.
The HDMI codec callbacks weren't receiving the drm_atomic_state, so
there was no simple way to get the drm_connector that stayed at the end
of the bridge cha
Use new drm_hdmi_connector_mode_valid() helper instead of a
module-specific copy.
Reviewed-by: Chen-Yu Tsai
Acked-by: Dave Stevenson
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4
Replace .mode_valid() callback with .hdmi_tmds_char_rate_valid(). It is
more generic and is used in other mode validation paths. The rate
validation for .mode_valid() will be performed by the
drm_bridge_connector code.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Ba
Replace sun4i_hdmi_connector_atomic_check(), which performs just TMDS
char rate check, with drm_atomic_helper_connector_hdmi_check(), which
performs additional checks basing on the HDMI Connector's state.
Suggested-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/sun4i/sun4
Add drm_hdmi_connector_mode_valid(), generic helper for HDMI connectors.
It can be either used directly or as a part of the .mode_valid callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 21 +++
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c |
Drop manual check of the TMDS char rate in the mode_valid callback. This
check is now being performed by the core.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 4 +---
1 file changed, 1 insertion(+), 3 deleti
Use new drm_hdmi_connector_mode_valid() helper instead of a
module-specific copy.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdm
Use new drm_bridge_connector_mode_valid() helper if there is a HDMI
bridge in the bridge chain. This removes the need to perform TMDS char
rate check manually in the bridge driver.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/
Several HDMI drivers have common code pice in the .mode_valid function
that validates RGB / 8bpc rate using the TMDS char rate callbacks.
Move this code piece to the common helper and remove the need to perform
this check manually. In case of DRM_BRIDGE_OP_HDMI bridges, they can
skip the check in
On Fri, Nov 08, 2024 at 08:04:36PM +, Mithil Bavishi wrote:
> Add samsung-espresso7 codename for the 7 inch variant
>
> Signed-off-by: Mithil Bavishi
> ---
> Documentation/devicetree/bindings/arm/ti/omap.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/
On 08/11/2024 21:04, Mithil Bavishi wrote:
> Add samsung-espresso10 codename for the 10 inch variant
>
> Signed-off-by: Mithil Bavishi
> ---
> Documentation/devicetree/bindings/arm/ti/omap.yaml | 1 +
Squash it. Really, these are just one liners for similar devices.
Best regards,
Krzysztof
On Fri, Nov 08, 2024 at 08:04:34PM +, Mithil Bavishi wrote:
> The LTN101AL03 is a 10.1 inch 800x1280, 24 bit, VESA Compatible, TFT display
> panel
>
> Signed-off-by: Mithil Bavishi
> ---
Squash it with previous patch. Each of such trivial one-liners for
similar device is review step for me.
On Fri, Nov 08, 2024 at 08:04:33PM +, Mithil Bavishi wrote:
> The LTN070NL01 is a 7.0 inch 1024x600, 24 bit, VESA Compatible, TFT display
> panel
Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/
On Fri, Nov 08, 2024 at 08:04:32PM +, Mithil Bavishi wrote:
> Add compatible strings for the Doestek DTC34LM85AM Flat Panel Display
> Transmitter
>
> Signed-off-by: Mithil Bavishi
> ---
> Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
> 1 file changed, 1 insertion(+)
On Fri, Nov 08, 2024 at 08:04:31PM +, Mithil Bavishi wrote:
> Add vendor prefix for Doestek Co., Ltd.
> Link: http://www.doestek.co.kr/
>
> Signed-off-by: Mithil Bavishi
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysz
kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
patch link:
https://lore.kernel.org/r/20241106093429.157131-3-manikandan.m%40microchip.com
patch subject: [PATCH v5 2/4] drm/bridge: add Microchip DSI controller support
for sam9x7 SoC series
config: nios2-randconfig-r133-202411
40 matches
Mail list logo
