Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230425]
[cannot apply to v6.3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Tue, Apr 25, 2023 at 11:17:14PM -0700, Chia-I Wu wrote:
> mgr->ctx_handles should be protected by mgr->lock.
>
> v2: improve commit message
>
> Signed-off-by: Chia-I Wu
> Cc: sta...@vger.kernel.org
What commit id does this fix? How far back in stable kernels should
this go?
thanks,
greg k
On Tue, Apr 25, 2023 at 9:58 PM Greg KH wrote:
>
> On Tue, Apr 25, 2023 at 05:48:27PM -0700, Chia-I Wu wrote:
> > Signed-off-by: Chia-I Wu
> > Cc: sta...@vger.kernel.org
>
> I know I can not take patches without any changelog text at all, maybe
> the DRM developers are more lax, but it's not a go
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, ha
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by a
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: F
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a def
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI changes,
1. end support for set caching ioctl [PA
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
mgr->ctx_handles should be protected by mgr->lock.
v2: improve commit message
Signed-off-by: Chia-I Wu
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/d
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: F
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, ha
From: Fei Yang
These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/
This series refactor the cache policy programming so that the PTE
encode functions can be unified across all GEN12 platforms. This
refactor is also important in implementing the design which a
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by a
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230425]
[cannot apply to v6.3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
Hey Dave, Daniel,
Complementary pull request for drm-misc-next-fixes!
~Maarten
drm-misc-next-fixes-2023-04-26:
drm-misc-next-fixes for v6.4-rc1:
- Revert uAPI from accel/qaic.
- Fix TTM build on archs where PMD_SHIFT is not constant.
- Improve error handling in nt35950.
- Fix double unregister
Hi Dave, Daniel,
drm-misc-fixes pull request for rc1. drm-misc-next-fixes coming up.. next
~Maarten
drm-misc-fixes-2023-04-26:
drm-misc-fixes for v6.4-rc1:
- Fix DSC macros.
- Fix VESA format for simplefb.
- Prohibit potential out-of-bounds access in generic fbdev emulation.
- Improve AST2500+
Looks you can drop macro 'AMDGPU_DEFAULT_GTT_SIZE_MB' as well.
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of
> Mukul Joshi
> Sent: Wednesday, April 26, 2023 9:53 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Joshi, Mukul ; Kuehling, Fel
Lo!
Sometimes the regression tracker runs into regressions himself... :-D
On 11.04.23 08:47, Stephen Rothwell wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/ttm/ttm_pool.c:73:29: error: variably modified
> 'global_
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230425]
[cannot apply to v6.3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
On Tue, Apr 25, 2023 at 05:48:27PM -0700, Chia-I Wu wrote:
> Signed-off-by: Chia-I Wu
> Cc: sta...@vger.kernel.org
I know I can not take patches without any changelog text at all, maybe
the DRM developers are more lax, but it's not a good idea at all.
thanks,
greg k-h
From: Dave Airlie
In order to add a new macro, Luis suggested converting some docs
for the new ones.
This tries to keep exisiting module_init, module_exit where they are,
and adds the new docs to the module section.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Cc: Luis Chamberlain
Cc: li
From: Dave Airlie
This adds a tag that will go into the module info, only one firmware from
the group given needs to be available for this driver to work. This allows
dracut to avoid adding in firmware that aren't needed.
This just brackets a module list in the modinfo, the modules in the list
w
added a newline for block comment
checkpatch.pl output:
---
drivers/gpu/drm/vkms/vkms_drv.c
---
WARNING: Block comments use a trailing */ on a separate line
+* which ix XRGB in all cases. */
total: 0 errors, 1 warnings, 274 line
On Tue, Apr 25, 2023 at 7:27 PM Chen, Guchun wrote:
>
> From coding style's perspective, this lock/unlock handling should be put into
> amdgpu_ctx_priority_override.
The locking is to protect mgr->ctx_handles.
>
> Regards,
> Guchun
>
> > -Original Message-
> > From: amd-gfx On Behalf Of
>From coding style's perspective, this lock/unlock handling should be put into
>amdgpu_ctx_priority_override.
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of Chia-
> I Wu
> Sent: Wednesday, April 26, 2023 8:48 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Pan, Xinhui
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: f600e0bbde8562a06bee31b3eb1b69d49acac4c5 Add linux-next specific
files for 20230425
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com
https
We're doing/planning on doing similar or related work here at chromium.
https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both
Here's the stuff we have now (we're currently rebasing and touching it up,
myself and @Yi Xie will be taking over
After reviewing this whole history, maybe attached patch is able to fix your
problem. Can you have a try please?
Regards,
Guchun
> -Original Message-
> From: amd-gfx On Behalf Of
> Mikhail Gavrilov
> Sent: Tuesday, April 25, 2023 9:20 PM
> To: Koenig, Christian
> Cc: Daniel Vetter ; dr
Use the helper function in TTM to get TTM memory
limit and set KFD's internal mem limit. This ensures
that KFD's TTM mem limit and actual TTM mem limit are
exactly same.
Signed-off-by: Mukul Joshi
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 3 ++-
drivers/
Use the helper function in TTM to get TTM mem limit and
set GTT size to be equal to TTL mem limit.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdg
Add a helper function to get TTM memory limit. This is
needed by KFD to set its own internal memory limits.
Signed-off-by: Mukul Joshi
---
drivers/gpu/drm/ttm/ttm_tt.c | 6 ++
include/drm/ttm/ttm_tt.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/t
Signed-off-by: Chia-I Wu
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
index e9b45089a28a6..863b2a34b2d64 1006
Use the new efficient frequency toggling interface. Also
create a helper function to restore the frequencies after
the test is done.
v2: Restore max freq first and then min.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 42 ++---
1 file change
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it throu
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fix
On 4/25/2023 4:05 PM, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent con
On 26/04/2023 03:06, Dmitry Baryshkov wrote:
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
catalog files by setting the intr_tear_rd_ptr
On 26/04/2023 02:06, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.
Signed-off-by: Marijn Suijten
---
driv
On 26/04/2023 02:06, Marijn Suijten wrote:
Instead of hardcoding many register defines for every INTF and AD4 index
with a fixed stride, turn the defines into singular chunks of math that
compute the address using the base and this fixed stride multiplied by
the index given as argument to the def
On 26/04/2023 02:05, Marijn Suijten wrote:
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes:
The pull request you sent on Mon, 24 Apr 2023 15:41:41 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-04-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c8cc58e289ed3b5bc50258f52776cf3dfa3bad66
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On 2023-04-25 15:37:44, Abhinav Kumar wrote:
>
>
> On 4/25/2023 3:15 PM, Marijn Suijten wrote:
> > On 2023-04-25 14:55:56, Abhinav Kumar wrote:
> >
> >>> I'll see whether I can include these fixes before sending v3 (got all
> >>> the other changes in and am all-ready to send it): is there any ot
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via debugfs.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Marijn Suijten
Reviewed-by:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
Inst
Some of these members were initialized while never read, while others
were not even assigned any pointer value at all. Drop them to save some
space, and above all confusion when looking at or accidentally
dereferencing these members.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
Revi
Doing a for loop in every DPU HW block driver init to find a catalog
entry matching the given ID is rather useless if the init function
called by RM already has that catalog entry pointer, and uses exactly
its ID to drive this init and for loop. Remove all that machinery to
drop quite some lines o
Now that newer DPU platforms use a readpointer-done interrupt on the
INTF block, stop providing the unused interrupt on the PINGPONG block.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8 ++
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit arguments depend on one of multiple
interrupt registe
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now replaced with a more obvious
disable_tearcheck()
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn Suijten
Reviewed-by: Dmitry Baryshkov
---
drivers
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. The new interrupts are
described in dpu_hw_interrupts.c, now wire them up in individual SoC
catalog files by setting the intr_tear_rd_ptr to the IRQ index spcified
in the offset tabl
From: Konrad Dybcio
Now that newer SoCs since DPU 5.0.0 manage tearcheck in the INTF instead
of PINGPONG block, move the struct definition to a common file. Also,
bring in documentation from msm-4.19 techpack while at it.
Signed-off-by: Konrad Dybcio
[Marijn: Also move dpu_hw_pp_vsync_info]
Sig
Instead of hardcoding many register defines for every INTF and AD4 index
with a fixed stride, turn the defines into singular chunks of math that
compute the address using the base and this fixed stride multiplied by
the index given as argument to the definitions.
MDP_SSPP_TOP0_OFF is dropped as th
A bunch of registers were appended at the end in e.g. commit
91143873a05d ("drm/msm/dpu: Add MISR register support for interface")
rather than being inserted in a place that maintains numerical sorting:
restore said numerical sorting.
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Revi
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up the IRQ register
masks in the interrupt table for enabling, reading and clearing them.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted downstream via the
DPU/SDE_MDP_VSYNC_SEL feature
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
-
According to downstream sources this DITHER sub-block sits at an offset
of 0xe0 with version 0x2. The PP_BLK_DITHER macro is _not_ used as
downstream still says the size of the PINGPONG block is 0xd4 and not 0.
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280XP")
Fixes: 0e91bcbb0016 ("drm/
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusion.
Note that downstream enables the PPSPLIT
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG blocks used by hardware prior
to 5.0.0.
The exist
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE support. To clean this
up, move the logic i
Use tabs for consistency with the other interrupt register definitions,
rather than spaces.
Fixes: ed6154a136e4 ("drm/msm/disp/dpu1: add intf offsets for SC7280 target")
Fixes: 89688e2119b2 ("drm/msm/dpu: Add more of the INTF interrupt regions")
Fixes: 4a352c2fc15a ("drm/msm/dpu: Introduce SC8280X
SM8550 exclusively has a DITHER sub-block inside the PINGPONG block and
no other registers, hence the DITHER name of the macro and a
corresponding PINGPONG block length of zero. However, the PP_BLK_ macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybc
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290 MDSS")
Signed-off-by: Marijn Suijten
Reviewe
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and the #define keyword.
Signed-off-by: Marijn Sui
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts. Additionally, disable previous register writes and remove
unused interrupt
On 4/25/2023 3:15 PM, Marijn Suijten wrote:
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
I'll see whether I can include these fixes before sending v3 (got all
the other changes in and am all-ready to send it): is there any other
SoC you're seeing this issue on?
Thats alright, you can have
On 2023-04-25 14:32:51, Abhinav Kumar wrote:
> > We can return NULL from dpu_hw_foo_init(), which would mean that the
> > block was skipped or is not present.
>
> An then replace the `if INTF_NONE continue` logic in dpu_rm_init with a
> check for NULL that skips, and a check
On 2023-04-25 14:55:56, Abhinav Kumar wrote:
> > I'll see whether I can include these fixes before sending v3 (got all
> > the other changes in and am all-ready to send it): is there any other
> > SoC you're seeing this issue on?
> >
>
> Thats alright, you can have it in a separate series not v3
On 4/25/2023 2:53 PM, Marijn Suijten wrote:
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:
On 2023-04-25 14:37:21, Abhinav Kumar wrote:
>
>
> On 4/25/2023 1:43 PM, Marijn Suijten wrote:
> > On 2023-04-25 09:47:30, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> >>> On 2023-04-25 09:18:58, Abhinav Kumar wrote:
>
>
> On 4/24/2023 11:54 PM,
On 4/25/2023 1:43 PM, Marijn Suijten wrote:
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block sho
On 4/19/2023 7:41 AM, Arnaud Vrac wrote:
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
---
Reviewed-by: Abhinav Kumar
On 4/25/2023 2:09 PM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
wrote:
On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
On 25/04/2023 10:16, Marijn Suijten wrote
On Tue, 25 Apr 2023 at 19:11, Abhinav Kumar wrote:
>
>
>
> On 4/25/2023 7:26 AM, Dmitry Baryshkov wrote:
> > On Tue, 25 Apr 2023 at 11:55, Marijn Suijten
> > wrote:
> >>
> >> On 2023-04-25 10:54:47, Dmitry Baryshkov wrote:
> >>> On 25/04/2023 10:16, Marijn Suijten wrote:
> On 2023-04-24 16:2
On 2023-04-25 09:47:30, Abhinav Kumar wrote:
>
>
> On 4/25/2023 9:33 AM, Marijn Suijten wrote:
> > On 2023-04-25 09:18:58, Abhinav Kumar wrote:
> >>
> >>
> >> On 4/24/2023 11:54 PM, Marijn Suijten wrote:
> >>> On 2023-04-24 16:09:45, Abhinav Kumar wrote:
> >>>
> >> dither block should be pre
Hi,
> Andrzej Hajda (7):
> lib/ref_tracker: add unlocked leak print helper
> lib/ref_tracker: improve printing stats
> lib/ref_tracker: add printing to memory buffer
> lib/ref_tracker: remove warnings in case of allocation failure
> drm/i915: Correct type of wakeref v
Hi John,
> Dan Carpenter pointed out that 'err' was not being set in the case
> where the GuC firmware version range check fails. Fix that.
>
> Note that while this is bug fix for a previous patch (see Fixes tag
is _a_ bug fix.
> below). It is an exceedingly low risk bug. The range check is
> a
Hi Andrzej,
On Tue, Apr 25, 2023 at 12:05:43AM +0200, Andrzej Hajda wrote:
> Beside reusing existing code, the main advantage of ref_tracker is
> tracking per instance of wakeref. It allows also to catch double
> put.
> On the other side we lose information about the first acquire and
> the last r
On 4/25/23 16:28, Thomas Zimmermann wrote:
Make fbdev's built-in helpers for reading and writing I/O and system
memory available to DRM. Replace DRM's internal helpers.
The first patch resolves a bug that's been in the fbdev code for
more than 15 years. Makes the read/write helpers work successf
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use GEN9 as a prefix for register lists that contain all GEN8
> registers.
alan:snip
alan: This patch as a stand-along looks good, so I'll provide the RB but take
note of the comment below
that s
The last 3 comments in this thread contain arguments that are false and
were specifically pointed out as false 6 comments ago: Soft resets are just
as fatal as hard resets. There is nothing better about soft resets. If the
VRAM is lost completely, that's a different story, and if the hard reset is
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Fix Xe_LP name.
>
> Signed-off-by: John Harrison
alan:snip
> -/* GEN9/XE_LPD - Render / Compute Per-Engine-Instance */
> +/* GEN8+ Render / Compute Per-Engine-Instance */
alan: two comments on this:
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use 'xe_lp*' prefixes for register lists that are common with
> Gen8.
alan:snip
> @@ -177,32 +177,32 @@ static const struct __guc_mmio_reg_descr
> empty_regs_list[] = {
> static const struct _
On Sat, 22 Apr 2023 22:50:01 +0200, Sebastian Reichel wrote:
> Add compatible value for Inanbo t28cp45tn89 and make reset GPIO non
> mandatory, since it might not be connected to the CPU.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../devicetree/bindings/display/panel/sitronix,st7789v.yaml
On Thu, 2023-04-06 at 15:26 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Remove 99% duplicated steered register list code. Also, include the
> pre-Xe steered registers in the pre-Xe list generation.
>
> Signed-off-by: John Harrison
alan: Nice work - good cleanup. Thanks so
On 2023-04-25 06:41:54, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
>
> Quoting Jordan Justen (2023-04-24 20:13:00)
> > On 2023-04-24 02:08:43, Tvrtko Ursulin wrote:
> > >
> > > Being able to "list" supported extensions sounds like a reasonable
On Fri, Apr 21, 2023 at 05:43:05PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "ilitek,ili9805" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/ilitek,ili9805.yaml | 60 +++
>
On Fri, Apr 21, 2023 at 05:43:02PM +0200, Dario Binacchi wrote:
> From: Michael Trimarchi
>
> Add documentation for "synaptics,r63353" panel.
>
> Signed-off-by: Michael Trimarchi
> Signed-off-by: Dario Binacchi
> ---
>
> .../display/panel/synaptics,r63353.yaml | 58 +++
On Thu, 2023-04-06 at 15:26 -0700, Harrison, John C wrote:
> From: John Harrison
>
> A pair of pre-Xe registers were being included in the Xe capture list.
> GuC was rejecting those as being invalid and logging errors about
> them. So, stop doing it.
>
alan:snip
> #define COMMON_GEN9BASE_GLOBAL
On Tue, 2023-04-25 at 16:41 +0300, Joonas Lahtinen wrote:
> (+ Faith and Daniel as they have been involved in previous discussions)
An orthogonal (but losely related) question: Is PXP the only subsystem that has
the unique problem of: Uses a delayed worker to complete all dependencies for
init..
b
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
> a/Documentation/devicetree/b
Hi Arnd,
On Mon, Apr 17, 2023 at 11:04:11PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The empty stub functions are defined as global functions, which
> causes a warning because of missing prototypes:
>
> drivers/gpu/drm/exynos/exynos_drm_g2d.h:37:5: error: no previous prototype
> f
On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
> Document the SM6350 DPU.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
> ++
> 1 file changed, 94 insertions(+)
>
> diff --git
> a/Documentation/devicetree/b
Thomas Zimmermann writes:
> Implement DRM fbdev helpers for reading and writing framebuffer
> memory with the respective fbdev functions. Removes duplicate
> code.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_fb_helper.c | 174 +---
> 1 file chang
On 4/25/2023 9:33 AM, Marijn Suijten wrote:
On 2023-04-25 09:18:58, Abhinav Kumar wrote:
On 4/24/2023 11:54 PM, Marijn Suijten wrote:
On 2023-04-24 16:09:45, Abhinav Kumar wrote:
dither block should be present on many other chipsets too but looks like
on sm8550 was enabling it. Not sure
1 - 100 of 161 matches
Mail list logo
