On 21 September 2024 at 06:15 am, Christian Zigotzky wrote:
Hi All,
The lastest Git kernel doesn't boot anymore after the latest DRM
updates (drm-next-2024-09-19). [1]
I tested it with an AMD Radeon HD 6970 (Cayman XT) and with an AMD
Radeon HD 5870 (Cypress XT).
I reverted the DRM updates
On 9/20/24 9:59 PM, Dmitry Baryshkov wrote:
> On Tue, Sep 17, 2024 at 12:47:10PM GMT, Tejas Vipin wrote:
>> Changes the elida-kd35t133 panel to use multi style functions for
>> improved error handling.
>>
>> Signed-off-by: Tejas Vipin
>> ---
>> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 10
The Rockchip RK3288 SoC contain two different Visual Output Processor
(VOP) blocks, VOP_BIG and VOP_LIT. The VOP blocks support different max
output resolution, 3840x2160 and 2560x1600.
Add support for the compatible used to differentiate between VOP_BIG and
VOP_LIT, support for the old compatible
The Rockchip RK3288 SoC contain two different Visual Output Processor
(VOP) blocks, VOP_BIG and VOP_LIT. The VOP blocks support different max
output resolution, 3840x2160 and 2560x1600.
Change compatible to differentiate between VOP_BIG and VOP_LIT, the old
compatible is kept for backward compatib
The Rockchip RK3288 SoC contain two different Visual Output Processor
(VOP) blocks, VOP_BIG and VOP_LIT. The VOP blocks support different max
output resolution, 3840x2160 and 2560x1600.
Add compatible to differentiate between the two VOP blocks.
Signed-off-by: Jonas Karlman
---
.../display/rock
The Rockchip RK3288 SoC contain two different Visual Output Processor
(VOP) blocks, VOP_BIG and VOP_LIT. The VOP blocks support different max
output resolution, 3840x2160 and 2560x1600.
This series add compatible to differentiate between the two VOP blocks,
backward and forward compatibility is ke
On Thu, Sep 12, 2024 at 03:04:20PM GMT, Shen Lichuan wrote:
> Fixed some spelling errors, the details are as follows:
>
> -in the code comments:
> collpase->collapse
> firwmare->firmware
> everwhere->everywhere
>
> Fixes: 2401a0084614 ("drm/msm: gpu: Add support for the GPMU")
>
The pll_cmp_to_fdata() was never used by the working code. Drop it to
prevent warnings with W=1 and clang.
Reported-by: Jani Nikula
Closes:
https://lore.kernel.org/dri-devel/3553b1db35665e6ff08592e35eb438a574d1ad65.1725962479.git.jani.nik...@intel.com
Signed-off-by: Dmitry Baryshkov
---
driver
On Wed, Sep 11, 2024 at 01:23:23PM GMT, Jani Nikula wrote:
> On Tue, 10 Sep 2024, Marc Gonzalez wrote:
> > On 10/09/2024 16:51, Dmitry Baryshkov wrote:
> >
> >> On Tue, Sep 10, 2024 at 01:03:43PM GMT, Jani Nikula wrote:
> >>
> >>> Building with clang and and W=1 leads to warning about unused
> >>>
On Thu, 12 Sep 2024 16:30:15 +0800, Jinjie Ruan wrote:
> As commit cbe16f35bee6 ("genirq: Add IRQF_NO_AUTOEN for request_irq/nmi()")
> said, reqeust_irq() and then disable_irq() is unsafe. In the small time gap
> between request_irq() and disable_irq(), interrupts can still come.
>
> IRQF_NO_AUTOE
On Fri, Sep 13, 2024 at 06:07:50PM GMT, Dzmitry Sankouski wrote:
> Add support for MIPI-DSI based S6E3HA8 AMOLED panel
> driver. This panel has 1440x2960 resolution, 5.8-inch physical
> size, and can be found in starqltechn device.
> Brightness regulation is not yet supported.
>
> Signed-off-by: D
On Tue, Jul 02, 2024 at 08:22:34PM GMT, Sandor Yu wrote:
> Allow HDMI PHYs to be configured through the generic
> functions through a custom structure added to the generic union.
>
> The parameters added here are based on HDMI PHY
> implementation practices. The current set of parameters
> should
On Mon, Sep 16, 2024 at 02:51:57PM GMT, Tomi Valkeinen wrote:
> Hi,
>
> We have an issue where two devices have dependencies to each other,
> according to drivers/base/core.c's fw_devlinks, and this prevents them from
> probing. I've been adding debugging to the core.c, but so far I don't quite
>
On Mon, Sep 16, 2024 at 03:18:55PM GMT, tjak...@math.uni-bielefeld.de wrote:
> From: Joaquín Ignacio Aramendía
>
> Add quirk orientation for AYA NEO GEEK. The name appears without
> spaces in DMI strings. The board name is completely different to
> the previous models making it difficult to reuse
On Mon, Sep 16, 2024 at 03:18:53PM GMT, tjak...@math.uni-bielefeld.de wrote:
> From: Joaquín Ignacio Aramendía
>
> Add quirk orientation for AYA NEO Founder. The name appears with spaces in
> DMI strings as other devices of the brand. The panel is the same as the
> NEXT and 2021 models. Those cou
On Mon, Sep 16, 2024 at 03:18:51PM GMT, tjak...@math.uni-bielefeld.de wrote:
> From: Joaquín Ignacio Aramendía
>
> Add quirk orientation for AYA NEO 2. The name appears without spaces in
> DMI strings. That made it difficult to reuse the 2021 match. Also the
> display is larger in resolution.
>
On Sat, 21 Sept 2024 at 20:23, Krzysztof Kozlowski wrote:
>
> On 12/09/2024 09:14, Mahadevan wrote:
> >
> > +clocks = <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
> > + <&gcc GCC_DISP_HF_AXI_CLK>,
> > + <&dispcc0 MDSS_DISP_CC_MDSS_MDP_CLK>;
> > +
> > +inter
On 12/09/2024 09:14, Mahadevan wrote:
>
> +clocks = <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
> + <&gcc GCC_DISP_HF_AXI_CLK>,
> + <&dispcc0 MDSS_DISP_CC_MDSS_MDP_CLK>;
> +
> +interrupts = ;
> +interrupt-controller;
> +#interrupt-cells = <
Hi Mary,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-misc/drm-misc-next drm-tip/drm-tip
linus/master v6.11 next-20240920]
[If
Le 20/09/2024 à 19:09, Akhil P Oommen a écrit :
On Wed, Sep 18, 2024 at 09:46:33AM +0200, Neil Armstrong wrote:
Hi,
On 17/09/2024 13:14, Antonino Maniscalco wrote:
This series implements preemption for A7XX targets, which allows the GPU to
switch to an higher priority ring when work is pushed
>
> On Thu, Sep 19, 2024 at 09:54:24AM +, Winkler, Tomas wrote:
> > > On Mon, Sep 16, 2024 at 04:49:17PM +0300, Alexander Usyskin wrote:
>
> > > > @@ -0,0 +1,142 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright(c) 2019-2024, Intel Corporation. All rights re
From: Jernej Skrabec
Like the DE3, the DE33 has a FMT (formatter) module, which
provides YUV444 to YUV422/YUV420 conversion, format re-mapping and color
depth conversion, although the DE33 module appears significantly more
capable, including up to 4K video support.
Add support for the DE33.
Sig
From: Jernej Skrabec
Like earlier DE versions, the DE33 has a CSC (Color Space Correction)
module. which provides color space conversion between BT2020/BT709, and
dynamic range conversion between SDR/ST2084/HLG.
Add support for the DE33.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walkli
From: Jernej Skrabec
The vi_scaler appears to be used in preference to the ui_scaler module
for hardware video scaling in the DE33.
Enable support for this scaler.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 19 +++
From: Jernej Skrabec
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
Notable features (from the H616 datasheet and implemented):
- 4096 x 2048 (4K) output support
- AFBC A
The DE33 is a newer version of the Allwinner Display Engine IP block,
found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
supported by the mainline driver.
The DE33 in the H616 has mixer0 and writeback units. The clocks
and resets required are identical to the H3 and H5 respective
The Allwinner H616 and variants have a new display engine revision
(DE33).
The mixer configuration registers are significantly different to the DE3
and DE2 revisions, being split into separate top and display blocks,
therefore a fallback for the mixer compatible is not provided.
Add a display eng
The Allwinner H616 and variants have a new display engine revision
(DE33).
Add a clock binding for the DE33.
Signed-off-by: Ryan Walklin
Acked-by: Conor Dooley
Reviewed-by: Chen-Yu Tsai
--
Changelog v2..v3:
- Separate content into three patches for three separate subsystems
---
.../devicetre
The Allwinner H616 and variants have a new display engine revision
(DE33).
Add a display engine bus binding for the DE33.
Signed-off-by: Ryan Walklin
Acked-by: Conor Dooley
Reviewed-by: Chen-Yu Tsai
--
Changelog v1..v2:
- Correct DE2 bus enum to reflect fallback devices accurately.
Changelog
From: Jernej Skrabec
Buffers, compressed with AFBC, are supported by the DE3 and above, and
are generally more efficient for memory transfers. Add support for them.
Currently it's implemented only for VI layers, but vendor code and
documentation suggest UI layers can have them too. However, I ha
From: Jernej Skrabec
Use the new blender register lookup function where required in the layer
commit and update code.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
--
Changelog v2..v3:
- Refactor for 6.11 layer init/modesetting changes
---
drivers/gpu/drm/sun4i/sun8i_mixer.c
From: Jernej Skrabec
The DE2 and DE3 engines have a blender register range within the
mixer engine register map, whereas the DE33 separates this out into
a separate display group.
Prepare for this by adding a function to look the blender reference up,
with a subsequent patch to add a conditional
From: Jernej Skrabec
If the video scaler is required, then it is obligatory to set the
relevant register to enable it, so move this to the
sun8i_vi_scaler_setup() function.
This simplifies the alternate case (scaler not required) so replace the
vi_scaler_enable() function with a vi_scaler_disabl
From: Jernej Skrabec
Now that the DE variant can be selected by enum, take the oppportunity
to factor out some common initialisation code to a separate function.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
Reviewed-by: Andre Przywara
--
Changelog v1..v2:
- Combine base register
From: Jernej Skrabec
The Allwinner DE2 and DE3 display engine mixers are currently identified
by a simple boolean flag. This will not scale to support additional DE
variants.
Convert the boolean flag to an enum.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
Reviewed-by: Andre Przy
From: Jernej Skrabec
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun8i_vi_scaler.c | 85 +
1 file changed, 58 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_scaler.c
b/drivers/gpu/drm/sun4i/sun8i_vi_s
From: Jernej Skrabec
Account for U/V channel subsampling by reducing the dot clock and
resolution with a divider in the DE3 timing controller if a YUV format
is selected.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 26 +++-
From: Jernej Skrabec
Add coefficients and support for YUV formats to the display engine
colorspace and dynamic range correction submodule.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sun8i_csc.c | 164 +-
1 file changed, 162
From: Jernej Skrabec
Configuration of the DE3 colorspace and dynamic range correction module
requires knowledge of the current video format and encoding.
Pass the display engine by reference to the csc setup function, rather
than the register map alone, to allow access to this information.
Sign
From: Jernej Skrabec
The mixer in the DE3 display engine supports YUV 8 and 10 bit
formats in addition to 8-bit RGB. Add the required register
configuration and format enumeration callback functions to the mixer,
and store the in-use output format (defaulting to RGB) and color
encoding in engine
From: Jernej Skrabec
Only the DE3 (and newer) display engines have a formatter module. This
could be inferred from the is_de3 flag alone, however this will not
scale with addition of future DE versions in subsequent patches.
Add a separate flag to signal this in the mixer configuration.
Signed-
From: Jernej Skrabec
The DE3 display engine supports YUV formats in addition to RGB.
Add an optional format enumeration function to the engine.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/drm/sun4i/sunxi_engine.h | 29
1 file changed
From: Jernej Skrabec
The display engine formatter (FMT) module is present in the DE3 engine
and provides YUV444 to YUV422/YUV420 conversion, format re-mapping and
color depth conversion.
Add support for this module.
Signed-off-by: Jernej Skrabec
Signed-off-by: Ryan Walklin
---
drivers/gpu/dr
From: Jernej Skrabec
drm_universal_plane_init() can already call some callbacks, like
format_mod_supported, during initialization. Because of that, fields
should be initialized beforehand.
Signed-off-by: Jernej Skrabec
Co-developed-by: Ryan Walklin
Signed-off-by: Ryan Walklin
Reviewed-by: Che
From: Jernej Skrabec
Currently, only VI layer calls CSC setup function. This comes from DE2
limitation, which doesn't have CSC unit for UI layers. However, DE3 has
separate CSC units for each layer. This allows display pipeline to make
output signal in different color spaces. To support both use
From: Jernej Skrabec
At the moment the colour space conversion is handled by two functions:
one to setup the conversion parameters, and another one to enable the
conversion. Merging both into one gives more flexibility for upcoming
extensions to support whole YUV pipelines, in the DE33.
Signed-o
From: Jernej Skrabec
Currently, CSC module takes care only for converting YUV to RGB.
However, DE3 is more suited to work in YUV color space. Change CSC mode
argument to format type to be more neutral. New argument only tells
layer format type and doesn't imply output type.
This commit doesn't m
Hi,
V4 of this patch series adding support for the Allwinner DE33 display engine
variant. V4 is rebased on torvalds/master with the 'drm-next-2024-09-19' branch
merged, with no code changes required. V3 was in turn rebased on top of the
layer init and modesetting changes merged for 6.11. No fun
d019c6cdc948bb4
change-id: 20240921-msm-mdss-ubwc-105589e05f35
Best regards,
--
Dmitry Baryshkov
Follow other msm_mdss_setup_ubwc_dec_nn functions and use individual
bits instead of just specifying the value to be programmed to the
UBWC_STATIC register.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 17 +
drivers/gpu/drm/msm/msm_mdss.h | 1 -
2 files c
Rather than hand-coding UBWC_STATIC value calculation, define
corresponding bitfields and use them to setup the register value.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 36 +++---
drivers/gpu/drm/msm/msm_mdss.h | 3
Move existing register definitions to mdss.xml and use generated defines
for registers access instead of hand-coding everything in the source
file.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 35 +++---
drivers/gpu/drm/msm/registers/di
In preparation of adding more registers, move MDSS-related headers to
the separate top-level file.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/registers/display/mdp5.xml | 16
drivers/gpu/drm/msm/registers/displa
Fix several copypaste mistakes in *_disable_link_output() functions where
an improper function pointer is checked before dereference.
Found by Linux Verification Center (linuxtesting.org) with Svace.
Signed-off-by: Vitaliy Shevtsov
---
drivers/gpu/drm/amd/display/dc/hwss/dce110/dce110_hwseq.c |
[ Upstream commit a309c7194e8a2f8bd4539b9449917913f6c2cd50 ]
User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in per
On Fri, Sep 20, 2024 at 11:28:02AM GMT, Liviu Dudau wrote:
> Since 641bb4394f40 ("fs: move FMODE_UNSIGNED_OFFSET to fop_flags")
> the FMODE_UNSIGNED_OFFSET flag has been moved to fop_flags and renamed,
> but the patch failed to make the changes for the panthor driver.
> When user space opens the re
56 matches
Mail list logo
