On 7/15/2022 3:54 PM, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for
On 16/07/2022 19:25, Melissa Wen wrote:
AMD GPU display manager (DM) maps DRM pixel blend modes (None,
Pre-multiplied, Coverage) to MPC hw blocks through blend configuration
options. Describe relevant elements and how to set and test them to get
the expected DRM blend mode on DCN hw.
On 16/07/2022 19:25, Melissa Wen wrote:
Describe structs and enums used to set blend mode properties to MPC
blocks. Some pieces of information are already available as code
comments, and were just formatted. Others were collected and summarised
from discusssions on AMD issue tracker[1][2].
Hi all,
On Mon, 11 Jul 2022 10:05:45 +0200 Christian König
wrote:
>
> Am 11.07.22 um 04:47 schrieb Stephen Rothwell:
> >
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> >drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >
> > between commit:
> >
> >925b6e59138c
On 16/07/2022 19:25, Melissa Wen wrote:
Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0 (converted
to svg from the original png) is included to
Hi Geert,
On 12/07/22 03:50, Geert Uytterhoeven wrote:
Hi all,
This patch series contains miscellaneous fixes and cleanups for the
Atari frame buffer device driver, which were identified while working on
the Atari DRM driver.
Most of them have been tested on ARAnyM, and should be
On 16/07/2022 19:25, Melissa Wen wrote:
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
v2:
- rebase to amd-staging-drm-next
Reviewed-by:
On 7/15/22 18:58, Christian König wrote:
> Am 15.07.22 um 17:36 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 15.07.22 um 13:15 schrieb Christian König:
>>> I've stumbled over this while reviewing patches for DMA-buf and it looks
>>> like we completely messed the locking up here.
>>>
>>> In general
The pull request you sent on Sun, 17 Jul 2022 14:59:42 -0400:
> git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-07-17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/55ea9bd666887ed4159df38d1494c204246cf2bc
Thank you!
--
Deet-doot-dot, I am a
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #83 from Danil (s48g...@gmail.com) ---
Log from what I described above - "fixed just by switching to
system-terminal(ctrl+alt+f1)", nothing crash even GPU apps keep working, just
huge mouse+UI freeze and switching to F1 terminal and
On 7/17/22 11:43, Maíra Canal wrote:
The igt_check_drm_format_min_pitch() function had a lot of
KUNIT_EXPECT_* calls, all of which ended up allocating and initializing
various test assertion structures on the stack.
This behavior was producing -Wframe-larger-than warnings on PowerPC, i386,
and
Hi Dave and Daniel (and Linus),
Our 'dim' flow has a problem with fixes of fixes getting missed.
We need to take a look on that later.
Meanwhile, please allow me to quickly propagate this fix
here upstream.
Here goes drm-intel-fixes-2022-07-17:
- Fix 32b build
Thanks,
Rodrigo.
The following
On Sun, 2022-07-17 at 09:20 -0700, Guenter Roeck wrote:
> Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
> introduces
> an additional parameter to i915_rsgt_from_mm_node(). The parameter is
> used
> to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
> divisor.
On Sat, 2022-07-16 at 15:08 -0700, Linus Torvalds wrote:
> On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
> wrote:
> >
> > That said, even those type simplifications do not fix the
> > fundamental
> > issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> > although now it's at
The igt_check_drm_format_min_pitch() function had a lot of
KUNIT_EXPECT_* calls, all of which ended up allocating and initializing
various test assertion structures on the stack.
This behavior was producing -Wframe-larger-than warnings on PowerPC, i386,
and MIPS architectures, such as:
Add todo in the hope someone will help updating the bridge drivers.
v2:
- Updated descriptions in todo.rst
Signed-off-by: Sam Ravnborg
Acked-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Likewise update enable/disable to their atomic variants.
With these changes omapdrm now
All users are converted over to drm_bridge_funcs.atomic_check()
so it is safe to drop the mode_fixup support.
Update the comment for atomic_check with relevant parts from mode_fixup.
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
The driver implements the state operations, so no other changes
are required for the replacement.
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: linux-renesas-...@vger.kernel.org
The implementation of drm_bridge_funcs.mode_fixup is optional
so there is no need to provide an empty implementation.
Drop mtk_hdmi_bridge_mode_fixup() so the driver no longer uses the
deprecated drm_bridge_funcs.mode_fixup() operation.
Signed-off-by: Sam Ravnborg
Cc: Chun-Kuang Hu
Cc: Philipp
On 7/14/22 21:03, Daniel Latypov wrote:
> On Thu, Jul 14, 2022 at 4:51 PM Guenter Roeck wrote:
>>
>> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
>>> Considering the current adoption of the KUnit framework, convert the
>>> DRM format selftest to the KUnit API.
>>>
>>> Tested-by:
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc:
Replace the deprecated drm_bridge_funcs.mode_fixup() with
drm_bridge_funcs.atomic_check().
drm_bridge_funcs.atomic_check() requires the atomic state operations,
update these to the default implementations.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc:
When atomic_check() is defined, then mode_fixup() is ignored,
so it had no effect that drm_bridge_funcs.mode_fixup was assigned.
Embed the original implementation in the caller and drop the function.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Robert Foss
Cc: Laurent
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v2:
- Init state operations in
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
This is a collection of bridge patches that I had left unfinished
more than a year ago. Now where I have some spare time I dusted them
off for review and testing.
The patches builds, but has seen no run-time testing.
The patches are grouped like this:
1+2:
- Updates parade-ps8640 for atomic
José Expósito wrote:
> I already fixed the warning and added the reviewed by tags, however, I
> noticed that rebasing the series on the latest drm-misc-next show this
> error:
> [...]
Sorry for the extra email. I forgot to mention that the error is only
present in UML. Running in other
Hi David,
On Sat, Jul 16, 2022 at 05:32:51PM +0800, David Gow wrote:
> On Sat, Jul 9, 2022 at 7:58 PM José Expósito
> wrote:
> >
> > Extend the existing test cases to test the conversion from XRGB to
> > RGB565.
> >
> > The documentation and the color picker available on [1] are useful
> >
Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction") introduces
an additional parameter to i915_rsgt_from_mm_node(). The parameter is used
to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
divisor. So far segment_pages was a constant and handled without divide
On 7/16/22 20:17, Sam Ravnborg wrote:
> To have more of the dri1 specific support in one place move the dri1
> core files to the dri1 folder.
> The files continue to be part of the drm module, we just refer to the files
> with a folder name.
>
> Signed-off-by: Sam Ravnborg
> ---
This patch
On 7/16/22 20:17, Sam Ravnborg wrote:
> Move the DRI1 section from drm/Kconfig to a new Kconfig
> file that lives in the dri1/ directory.
> This isolates more of the DRI1 functionality.
>
> Signed-off-by: Sam Ravnborg
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
I wonder if we should just squash patches 03/11 to 09/11 into a
single patch.
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
> Used the opportunity to rename the file to via.c to match the
> name of the driver.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
Ditto here and other patches.
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux
On 7/16/22 20:17, Sam Ravnborg wrote:
> drm/dri1 is the new home for all the legacy DRI1 drivers.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Javier Martinez Canillas
I believe these should be chronological and so the order inverted.
Reviewed-by: Javier Martinez Canillas
--
Best
On 7/16/22 20:17, Sam Ravnborg wrote:
> The rename is done to make it more obvious what is DRI1 drivers
> and what is other type of legacy.
>
> Signed-off-by: Sam Ravnborg
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
Hello Sam,
Thanks a lot for working on this patch-set.
On 7/16/22 20:17, Sam Ravnborg wrote:
> "legacy" is a general term - be specific and use the term dri1.
> The first step is to rename DRIVER_LEGACY to DRIVER_DRI1.
>
> Suggested-by: Javier Martinez Canillas
IIRC it was Thomas who
config: loongarch-randconfig-s052-20220715
(https://download.01.org/0day-ci/archive/20220717/202207172035.mterdlaw-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 12.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #82 from Danil (s48g...@gmail.com) ---
Afteer using this PC for few days with AMD Vega 8 (integrated) as main GPU I
see no freezes at all. (before in 2021 it was freeze every 10-20 mins so I had
to use Nvidia as main GPU)
(works with
Hi!
> Going forward, I'll be using my kernel.org for upstream work.
>
Acked-by: Pavel Machek
Let me know if you want to take it through the LED tree.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine
Hi!
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> a display bias
Folks,
> Laurent Pinchart (6):
> dt-bindings: media: Add macros for video interface bus types
> dt-bindings: Use new video interface bus type macros in examples
> ARM: dts: freescale: Use new media bus type macros
> ARM: dts: omap: Use new media bus type macros
> ARM: dts: renesas: Use
49 matches
Mail list logo
