Am 30.01.23 um 11:12 schrieb Matthew Auld:
Sparse complains with:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse:
expected restricted vm_fault_t [assigned] [usertype] ret
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int
Fixes: 516198d317d8 ("drm/i915: audit bo->
Hi Guchun,
no, that doesn't make any sense at all.
The ready flag indicates that the scheduler is fully prepared for hw
submissions from userspace and is unrelated to the initialization
status. It's set to true after IB testing was successful and only set to
false only when a GPU reset fails
Am 30.01.23 um 13:55 schrieb Maíra Canal:
Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
memory and, if the test fails, print the result in a human-friendly
format. Therefore, use KUNIT_EXPECT_MEMEQ to compa
Hi,
I am new to the Linux and DRM framework in Linux. I was going through some
reference drivers like VC4, exynos, etnaviv, Renesas (rcar-du), rockchip.
Almost in all these cases, they use a component helpers to glue together the
different IPs under the hood of a pseudo master driver. It should
Hi Olivier,
On Fri, 27 Jan 2023 at 16:24, Olivier Masse wrote:
>
> Hi Joakim,
> Hi Etienne,
>
> Let me bring back this pull request for OPTEE Linux driver.
>
> Last feedback was from Christian König and Sumit Garg.
> From Christian:
> > Just two comments:
> >
> > 1. Dmitry is working on a change
On Mon, 30 Jan 2023 at 20:58, Maíra Canal wrote:
>
> Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
> KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
> memory and, if the test fails, print the result in a human-friendly
> format. Therefore, use KUNIT_EXPECT_
Hi all,
On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
wrote:
>
> On 1/31/2023 04:44, Andy Shevchenko wrote:
> > On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> >>
> >> Today's linux-next merge of the usb tree got a conflict in:
> >>
> >>drivers/gpu/drm/i915/gt/intel_
On Tue, Jan 31, 2023 at 6:01 AM Tvrtko Ursulin
wrote:
>
>
> On 25/01/2023 20:04, T.J. Mercier wrote:
> > On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> On 25/01/2023 11:52, Michal Hocko wrote:
> >>> On Tue 24-01-23 19:46:28, Shakeel Butt wrote:
> On Tu
On Mon, 30 Jan 2023 15:15:44 +0100, Luca Ceresoli wrote:
> The Tegra20 VI peripheral can receive parallel input from the VIP parallel
> input module. Add it to the allowed properties and augment the existing
> nvidia,tegra20-vi example to show a 'vip' property.
>
> Signed-off-by: Luca Ceresoli
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Various bits of the driver used raw ttm_buffer_object instead of the
> driver specific vmw_bo object. All those places used to duplicate
> the mapped bo caching policy of vmw_bo.
>
> Instead of duplicating all of that code and special ca
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Problem with explicit placement selection in vmwgfx is that by the time
> the buffer object needs to be validated the information about which
> placement was supposed to be used is lost. To workaround this the driver
> had a bunch of stat
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Rename dummy to is_iomem because that's what it is even if we're not
> activelly using it. Makes the code easier to read.
>
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
> 1 file changed
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Base mapped count is useless because the ttm unmap functions handle
> null maps just fine so completely remove all the code related to it.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/vmwg
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Only the legacy display unit requires pinning of the fb memory in vram.
> Both the screen objects and screen targets can present from any buffer.
> That makes the pinning abstraction pointless. Simplify all of the code
> and move it to th
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> The rest of the drivers which are using ttm have mostly standardized on
> driver_prefix_bo as the name for subclasses of the TTM buffer object.
> Make vmwgfx match the rest of the drivers and follow the same naming
> semantics.
>
> This
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Remove the explicit bo_free parameter which was switching between
> vmw_bo_bo_free and vmw_gem_destroy which had exactly the same
> implementation.
>
> It makes no sense to keep parameter which is always the same, remove it
> and all cod
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Before vmwgfx supported gem it needed to implement the entire mmap logic
> explicitly. With GEM support that's not needed and the generic code
> can be used by simply setting the vm_ops to vmwgfx specific ones on the
> gem object itself.
On 1/31/2023 2:18 PM, Douglas Anderson wrote:
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking p
On Wed, 25 Jan 2023 16:13:56 -0600, Rob Herring wrote:
> 'memory-region' is a common property and already has a type.
>
> Signed-off-by: Rob Herring
> ---
> Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks!
On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote:
> Atm, drm_dp_remove_payload() uses the same payload state to both get the
> vc_start_slot required for the payload removal DPCD message and to
> deduct time_slots from vc_start_slot of all payloads after the one being
> removed.
>
> The above is
There is no need for this driver to be OF-specific, so switch it to
use device_get_match_data() and stop including various of-related
headers.
Signed-off-by: Dmitry Torokhov
---
drivers/video/backlight/hx8357.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
This makes driver use standard property name for the reset gpio
("reset-gpios" vs "gpios-reset"), however there is a quirk in gpiolib
to also recognize the legacy na
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 +++
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling with regards to dsi_mgr_bridge_power_on()
got a bit worse. Specifically if we failed to power the bridge on then
nothing would really notice. The modeset function couldn't return an
error and thus we'd
Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
order"). This should allow us to revert commit ec7981e6c614
("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
commit 7d8e9a90509f ("drm/msm/dsi: m
Just recently we switched over to new GuC oriented log macros but in
the meantime yet another message was added that we missed to update.
While around improve that new message by adding engine name and use
existing helpers to check for context state.
Signed-off-by: Michal Wajdeczko
Cc: John Harr
Hi,
On Thu, Jan 26, 2023 at 4:52 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 18, 2023 at 1:34 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Jan 5, 2023 at 7:01 PM Stephen Boyd wrote:
> > >
> > > The unprepare sequence has started to fail after moving to panel bridge
> > > code in the
Jonathan Neuschäfer writes:
> To make it easier to find the dma-buf documentation when looking through
> tables-of-contents etc., put the name "dma-buf" in the title.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
> Documentation/driver-api/dma-buf.rst | 4 ++--
> 1 file changed, 2 insertions(+),
On Tue, Jan 31, 2023 at 10:01 AM Sasha Levin wrote:
>
> From: Dave Airlie
>
> [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ]
>
> This fixes the build here locally on my 32-bit arm build.
>
> Signed-off-by: Dave Airlie
> Signed-off-by: Sasha Levin
This patch is only applicable to
My apologies, I accidentally mangled the version history. It should
actually read:
v2:
* Rebase and resolve merge conflicts with the AFBC patch.
v3:
* Moved 10-bit support detection to mtk_disk_ovl.c
v4:
* Moved formats to mtk_disp_ovl.c and mtk_disp_rdma.c
v5:
* Minor style adjustments per ch
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
edit1
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
drivers/gpu
Add support for overlays with pixel formats AR30 and BA30 on MT8195.
Tested using "modetest -P" on an MT8195 device.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 49 -
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
This patch series adds support for 10-bit overlays to the Mediatek DRM driver.
Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and
lay the groundwork for supporting more 10-bit formats on more devices.
1. Refactor plane initialization logic to allow individual DDP compone
In order to turn the API more expansible to other DRM objects, such as
the struct drm_connector, make the struct drm_debugfs_entry hold a void
pointer and cast the void pointer to the struct drm_device when needed.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
include/dr
Currently, the drivers need to access the struct drm_debugfs_entry to
get the proper device on the show callback. There is no need for such
thing, as you can wrap the show callback in order to provide to the
driver the proper parameters: the struct seq_file, the struct drm_device
and the driver-spe
Create a helper to encapsulate the code that creates a new debugfs files
from a linked list related to an object. Moreover, the helper also
provides more flexibily on the type of the object.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 25 +
1 file chang
Create a helper to encapsulate the code that adds a new debugfs file to
a linked list related to a object. Moreover, the helper also provides
more flexibily, as the parameter is a struct drm_debugfs_files.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 11 ---
1 file chan
Introduce a struct wrapper for all the debugfs-related stuff: the list
of debugfs files and the mutex that protects it. This will make it
easier to initialize all the debugfs list in a DRM object and will
create a good abstraction for a possible implementation of the debugfs
infrastructure for KMS
This series is the first step to introduce a debugfs structure to KMS objects
and it is inspired by the feedback provided in [1]. Thanks, Jani and Daniel for
all the feedback provided!
This first step is making the current API more generic and preparing it to
receive the KMS objects in the future.
The struct drm_debugfs_files encapsulates all the debugfs-related
objects, so that they can be initialized and destroyed with two helpers.
Therefore, make the struct drm_device use the struct drm_debugfs_files
instead of instantiating the debugfs list and mutex separated.
Signed-off-by: Maíra Cana
Hi,
I cannot comment much on the internal workings of the vmwgfx driver, but
feel free to add
Acked-by: Thomas Zimmermann
to the patches that don't already have my r-b.
Best regards
Thomas
Am 31.01.23 um 04:35 schrieb Zack Rusin:
From: Zack Rusin
v2: Fix all the issues which Thomas poin
From: Martin Krastev
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Various bits of the driver used raw ttm_buffer_object instead of the
driver specific vmw_bo object. All those places used to duplicate
the mapped bo caching
On Tue, Jan 31, 2023 at 1:23 PM Guilherme G. Piccoli
wrote:
>
> On 31/01/2023 14:52, Alex Deucher wrote:
> > [...]
> >> (b) We can't use sched.ready, which would make sense...but amdgpu
> >> overrides its meaning, the driver manipulates this value for its own
> >> purposes of tracking ring init, o
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_cs.c
between commit:
5bc4b43d5c6c ("drm/i915: Fix up locking around dump
On 31/01/2023 14:52, Alex Deucher wrote:
> [...]
>> (b) We can't use sched.ready, which would make sense...but amdgpu
>> overrides its meaning, the driver manipulates this value for its own
>> purposes of tracking ring init, or something like that.
>>
>> This is the tangential topic: what should we
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.
Signed-off-by: Zack Rusin
---
driv
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Problem with explicit placement selection in vmwgfx is that by the time
the buffer object needs to be validated the information about which
placement was supp
On Tue, Jan 31, 2023 at 9:32 AM Guilherme G. Piccoli
wrote:
>
> On 31/01/2023 10:58, Chen, Guchun wrote:
> > Hi Christian,
> >
> > Do you think if it makes sense that we can set 'ring->sched.ready' to be
> > true in each ring init, even if before executing/setting up drm_sched_init
> > in amdgpu
On Tue, Jan 31, 2023 at 5:58 AM Christian König
wrote:
>
> Am 31.01.23 um 10:17 schrieb Chen, Guchun:
> > Hi Piccoli,
> >
> > Please ignore my request of full dmesg log. I can reproduce the issue and
> > get the same failure callstack by returning early with an error code prior
> > to amdgpu_dev
Applied. Thanks!
Alex
On Tue, Jan 31, 2023 at 9:40 AM Harry Wentland wrote:
>
> On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> > This is a very trivial code clean-up related to commit 5468c36d6285
> > ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> > added a validati
+Suraj
On Tue, Jan 31, 2023 at 12:16:44PM -0500, Rodrigo Vivi wrote:
>
> +Suraj who is also working on HDCP related code that even can conflict
> wit this.
>
> On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> > From: Sean Paul
>
> First of all, Sean, please accept my public apo
Applied. Thanks!
Alex
On Thu, Jan 26, 2023 at 3:50 PM Tom Rix wrote:
>
> cppcheck reports
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 1396. [multiCondition]
>} e
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 80bd9028fecadae4e8e3a278cd32d74badc2a6e0 Add linux-next specific
files for 20230131
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com
https
Applied. Thanks!
On Thu, Jan 26, 2023 at 8:38 PM Tom Rix wrote:
>
> checkpatch reports
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 2895. [multiCondition]
> } el
Applied. Thanks!
Alex
On Fri, Jan 27, 2023 at 8:39 PM wrote:
>
> From: ye xingchen
>
> opp.h is included more than once.
>
> Signed-off-by: ye xingchen
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc
+Suraj who is also working on HDCP related code that even can conflict
wit this.
On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> From: Sean Paul
First of all, Sean, please accept my public apologies here. I just noticed
now that you had pinged me 9 *months* ago!
I noticed while
Applied. Thanks!
On Sun, Jan 29, 2023 at 10:18 AM Jonathan Neuschäfer
wrote:
>
> Spell it as "broadcast".
>
> Signed-off-by: Jonathan Neuschäfer
> ---
> drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/df_v
Hi Maíra,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
next-20230131]
[cannot apply to drm-intel/for-linux-next-fixes linus/master v6.2-rc6]
[If your patch is applied to
[AMD Official Use Only - General]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, January 31, 2023 10:00 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Dave Airlie ; Sasha Levin ;
> Wentland, Harry ; Li, Sun peng (Leo)
> ; Siqueira, Rodrigo ;
> Deucher, Alex
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by si
A follow-up patch adds a workaround for a payload allocation problem in
a DELL monitor. For this the driver needs to reset the payload table in
the monitor's MST hub, factor out a helper to do this.
While at it use DP_PAYLOAD_TABLE_SIZE in the reset command, instead of
open coding it.
Cc: Lyude P
Add a way for drivers to query if allocating time slots for any payloads
in a given MST topology failed. This is needed by a follow-up i915 patch
verifying the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
In a follow-up workaround for a payload allocation problem the driver
uses DP_PAYLOAD_TABLE_SIZE to determine when the workaround is needed,
so export the definition.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_d
The DELL P2715Q monitor's MST hub has a payload allocation problem,
where the VCPI used to reserve the last two time slots (at position
0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for
later payload configurations. To work around the problem in a follow-up
patch the driver need
Add a function drivers can use to verify the MST payload state tracking
and compare this to the sink's payload table.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 169 ++
includ
Add helper functions to query the virtual channel and time slots for a
payload and the current payload count and total allocated time slots in
an MST topology. These are needed by a follow-up i915 patch verifying
the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-d
Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/g
Add a function to get the old MST topology state, required by a
follow-up i915 patch.
While at it clarify the code comment of
drm_atomic_get_new_mst_topology_state() and add _new prefix
to the new state pointer to remind about its difference from the old
state.
v2: Use old_/new_ prefixes for the
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
vers
Hi Chun-Kuang,
Thanks for the review! Will try to have a new patch out later today.
Re MT8195 RDMA: Yes, the MT8195 RDMA has a 10 bit mode, but I left
this unimplemented because I have no means of testing it
unfortunately; ChromeOS does not use this hardware.
I also wanted to mention, I think thi
From: Dave Airlie
[ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ]
This fixes the build here locally on my 32-bit arm build.
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff -
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why&How]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue
From: Dave Airlie
[ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ]
This fixes the build here locally on my 32-bit arm build.
Signed-off-by: Dave Airlie
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 insertions(+)
diff -
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why&How]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue
On Sun, Jan 29, 2023 at 04:17:40PM +0100, Samuel Thibault wrote:
> blit_x and blit_y are u32, so fbcon currently cannot support fonts
> larger than 32x32.
>
> The 32x32 case also needs shifting an unsigned int, to properly set bit
> 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_fon
On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> This is a very trivial code clean-up related to commit 5468c36d6285
> ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> added a validation on driver probe to prevent invalid TMDS modes, but one
> of the fake properties (swizzl
On 31/01/2023 10:58, Chen, Guchun wrote:
> Hi Christian,
>
> Do you think if it makes sense that we can set 'ring->sched.ready' to be true
> in each ring init, even if before executing/setting up drm_sched_init in
> amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler
> struct
On Tue, Jan 31, 2023 at 7:29 PM Maxime Ripard wrote:
>
> On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote:
> > On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote:
> > >
> > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripa
On 25/01/2023 20:04, T.J. Mercier wrote:
On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin
wrote:
Hi,
On 25/01/2023 11:52, Michal Hocko wrote:
On Tue 24-01-23 19:46:28, Shakeel Butt wrote:
On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote:
On Mon 23-01-23 19:17:23, T.J. Mercier
Applied to drm-misc-next. Thanks.
On 26.01.2023 17:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With extra warnings enabled, gcc warns about two assignments
> of the same .mmap callback:
>
> In file included from drivers/accel/ivpu/ivpu_drv.c:10:
> include/drm/drm_accel.h:31:27: error: in
On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote:
> On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote:
> >
> > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote:
> > > >
> > > > On Fri, Jan 27, 2023 at 11:09:26PM +053
Hi Christian,
Do you think if it makes sense that we can set 'ring->sched.ready' to be true
in each ring init, even if before executing/setting up drm_sched_init in
amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler
structure.
Regards,
Guchun
-Original Message-
Fro
On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote:
>
> On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote:
> > >
> > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote:
> > > > Hi,
> > > >
> > > > On Thu, Jan 26, 2023 at
On 30/01/2023 17:11, Vinod Polimera wrote:
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: D
Applied to drm-misc-next.
Thanks.
On 24.01.2023 11:41, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Sign
On Tue, 31 Jan 2023 11:21:18 +
Simon Ser wrote:
> On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen
> wrote:
>
> > On Tue, 31 Jan 2023 10:06:39 +
> > Simon Ser wrote:
> >
> > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen
> > > wrote:
> > >
> > > > indeed, wha
On 30/01/2023 17:11, Vinod Polimera wrote:
From: Sankeerth Billakanti
Updated frames get queued if self_refresh_aware is set when the
sink is in psr. To support bridge enable and avoid queuing of update
frames, reset the self_refresh_aware state after entering psr.
Signed-off-by: Sankeerth Bil
On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote:
> >
> > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote:
> > > Hi,
> > >
> > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki
> > > wrote:
> > > >
> > > > On Thu, Jan 26, 202
On 30/01/2023 17:11, Vinod Polimera wrote:
Changes in v2:
- Use dp bridge to set psr entry/exit instead of dpu_enocder.
- Don't modify whitespaces.
- Set self refresh aware from atomic_check.
- Set self refresh aware only if psr is supported.
- Provide a stub for msm_dp_display_set
On 30/01/2023 17:11, Vinod Polimera wrote:
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the usb tree got a conflict in:
>
> drivers/gpu/drm/i915/gt/intel_engine_cs.c
>
> between commit:
>
> 5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
>
> from
On 31/01/2023 14:10, Dmitry Baryshkov wrote:
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
-
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp
On Tue, Jan 24, 2023 at 12:42 PM Geert Uytterhoeven
wrote:
>
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytt
On Tue, Jan 24, 2023 at 11:41:45AM +0100, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Gee
On 30/01/2023 23:51, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rathe
On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen
wrote:
> On Tue, 31 Jan 2023 10:06:39 +
> Simon Ser wrote:
>
> > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen
> > wrote:
> >
> > > indeed, what about simply using a 1x1 framebuffer for real? Why was that
> > > approach r
On 27/01/2023 00:55, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Signed-off-by: Dmitry Baryshkov
Idea seems okay but then we s
On Tue, 31 Jan 2023 10:06:39 +
Simon Ser wrote:
> On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen
> wrote:
>
> > indeed, what about simply using a 1x1 framebuffer for real? Why was that
> > approach rejected?
>
> Ideally we don't want to allocate any GPU memory for the solid-fil
1 - 100 of 118 matches
Mail list logo
