https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #24 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Alex Deucher from comment #23)
> I'll just revert it. It is more important for kernels with the the
> drm_buddy changes.
Right thing to do for now, I guess. If I can find a
Building the kernel documentation causes this warning 7 times.
Fix it by adding a " *" line instead of a blank line.
drivers/gpu/drm/drm_connector.c:1849: warning: bad line:
Fixes: 7d63cd8526f1 ("drm/connector: Add TV standard property")
Signed-off-by: Randy Dunlap
Cc: Maxime Ripard
Cc:
Fix a kernel-doc warning and other kernel-doc formatting for
drm_atomic_helper_connect_tv_check().
drivers/gpu/drm/drm_atomic_state_helper.c:560: warning: Cannot understand *
@drm_atomic_helper_connector_tv_check: Validate an analog TV connector state
on line 560 - I thought it was a doc line
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_hpd.c:140 get_hpd_line()
warn: inconsistent indenting.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3787
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Variable value0 is not effectively used, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:1222:11:
warning: variable ‘value0’ set but not used.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3783
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Variable optc is not effectively used, so delete it.
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c:325:27: warning:
variable ‘optc’ set but not used.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3782
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
Hi all,
The following commit is also in the drm-misc tree as a different commit
(but the same patch):
06b19f46455c ("drm/nouveau/fb/ga102: Replace zero-length array of trailing
structs with flex-array")
This is commit
54d47689c6e3 ("drm/nouveau/fb/ga102: Replace zero-length array of
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct
> dmar_domain *domain,
>
> return __domain_mapping(domain, first_vpfn,
> first_vpfn, last_vpfn - first_vpfn + 1,
> -
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu
> *iommu,
> if (!old_ce)
> goto out;
>
> - new_ce =
On Fri, Jan 13, 2023 at 10:57:18AM +0200, Dmitry Baryshkov wrote:
> On 13/01/2023 06:23, Dmitry Baryshkov wrote:
> > On 13/01/2023 06:10, Bjorn Andersson wrote:
> > > Invoking drm_bridge_hpd_notify() on a drm_bridge with a HPD-enabled
> > > bridge_connector ends up in drm_bridge_connector_hpd_cb()
On 1/16/2023 18:47, Guilherme G. Piccoli wrote:
On 16/01/2023 20:00, Alex Deucher wrote:
[...]
It's not clear to me when this would be used. We only disable it
briefly during new asic bring up, after that we never touch it again.
No end user on production hardware should ever have to change
16.01.2023 18:11, Christian König пишет:
>
>
>> mmapping the memory with that new offset should still work. The
>> imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
>> supports mapping of SG BOs.
>
> Actually it shouldn't. This can go boom really easily.
On 16/01/2023 20:00, Alex Deucher wrote:
> [...]
>
> It's not clear to me when this would be used. We only disable it
> briefly during new asic bring up, after that we never touch it again.
> No end user on production hardware should ever have to change it and
> doing so would break VCN on their
On Mon, Jan 16, 2023 at 5:34 PM Guilherme G. Piccoli
wrote:
>
> On 16/01/2023 19:27, Liu, Leo wrote:
> > Secure part requires PSP load VCN boot sequence which is with indirect
> > sram mode.
> >
> > Regards,
> > Leo
>
> With that said, and with the plans of just setting the indirect sram
> mode
On 2023-01-16 17:12, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Chen,
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-...@lists.freedesktop.org;
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 219 --
1 file
V8:
- Squash first and last patch to fix bisectability
link:
https://lore.kernel.org/linux-arm-msm/167388664232.594279.4607492026981202284.r...@kernel.org/T/#u
V7:
- The bulk of the patches for this series have been merged.
There are still four patches to be pushed/updated.
- Adds clocks for
On 2023-01-16 17:11, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc:
This panel communicates brightness in big endian. This is not a quirk of
the panels themselves, but rather, a part of the MIPI standard. Use the
new mipi_dsi_dcs_set_display_brightness_large() function that properly
handles 16-bit brightness instead of bypassing the brightness functions
entirely.
From: Daniel Mentz
The MIPI DCS specification demands that brightness values are sent in
big endian byte order. It also states that one parameter (i.e. one byte)
shall be sent/received for 8 bit wide values, and two parameters shall
be used for values that are between 9 and 16 bits wide.
Add
These panels communicate brightness in big endian. This is not a quirk
of the panels themselves, but rather, a part of the MIPI standard. Use
the new mipi_dsi_dcs_set_display_brightness_large() function that
properly handles 16-bit brightness instead of doing special processing
of the brightness
Changes since v2 (20230114010006.50471-1-mailingrad...@gmail.com):
- patch vtdr6130 to use _large (3/3)
- remove Change-Id again (1/3)
- change patch subject (1-2/3)
- correct function name in patch description (2/3)
- add Tested-by tags (1-2/3)
Changes since v1
On 16/01/2023 19:27, Liu, Leo wrote:
> Secure part requires PSP load VCN boot sequence which is with indirect
> sram mode.
>
> Regards,
> Leo
With that said, and with the plans of just setting the indirect sram
mode nevertheless (with no switch/cases anymore - I'll submit the V2
tomorrow if
Secure part requires PSP load VCN boot sequence which is with indirect sram
mode.
Regards,
Leo
From: Alex Deucher
Sent: January 16, 2023 4:50 PM
To: Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org ; Jiang, Sonny
; ker...@gpiccoli.net ; Pan, Xinhui
;
On 2023-01-16 17:04, Errabolu, Ramesh wrote:
[AMD Official Use Only - General]
A minor comment, unrelated to the patch. The comments are inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Chen,
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Koenig, Christian
Subject:
[AMD Official Use Only - General]
Comment inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian
Subject:
[AMD Official Use Only - General]
A minor comment, unrelated to the patch. The comments are inline.
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Monday, January 16, 2023 15:54
> To: Limonciello, Mario
> Cc: Guilherme G. Piccoli ; amd-
> g...@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ;
On Mon, Jan 16, 2023 at 4:51 PM Guilherme G. Piccoli
wrote:
>
> On 16/01/2023 18:41, Alex Deucher wrote:
> > [...]
> >> + case IP_VERSION(4, 0, 0): /* Vega10 */
> >
> > This comment is incorrect. Vega10 does not have VCN (it has UVD and VCE).
> >
> > Alex
>
> Thanks Alex! I'll
On 16/01/2023 18:49, Limonciello, Mario wrote:
> [...]
>
> The problem with adding a comment about which platform it's in is that
> this will probably go stale. Some IP blocks are re-used in multiple ASICs.
>
> VCN 3, 1, 1 is a great example. This is used in both Yellow Carp (Rembrandt)
> as
On Mon, Jan 16, 2023 at 4:49 PM Limonciello, Mario
wrote:
>
> [Public]
>
>
>
> > -Original Message-
> > From: Alex Deucher
> > Sent: Monday, January 16, 2023 15:42
> > To: Guilherme G. Piccoli
> > Cc: amd-...@lists.freedesktop.org; Jiang, Sonny ;
> > ker...@gpiccoli.net; Pan, Xinhui ;
On 16/01/2023 18:41, Alex Deucher wrote:
> [...]
>> + case IP_VERSION(4, 0, 0): /* Vega10 */
>
> This comment is incorrect. Vega10 does not have VCN (it has UVD and VCE).
>
> Alex
Thanks Alex! I'll resubmit V2 with this comment removed.
I've stolen it from
On Mon, Jan 16, 2023 at 4:21 PM Guilherme G. Piccoli
wrote:
>
> Currently the FW loading path perform some checks based on IP model
> and in case it is advertised as supported, the VCN indirect SRAM
> mode is used.
>
> Happens that in case there's any issue on FW and this mode ends-up
> not being
[Public]
> -Original Message-
> From: Alex Deucher
> Sent: Monday, January 16, 2023 15:42
> To: Guilherme G. Piccoli
> Cc: amd-...@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ; Limonciello,
> Mario ;
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
wrote:
>
> Currently both conditionals checked to enable indirect SRAM are
> repeated for all HW/IP models. Let's just simplify it a bit so
> code is more compact and readable.
>
> While at it, add the legacy names as a comment per case block,
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
wrote:
>
> This is an incredibly trivial fix, just for the sake of
> "aesthetical" organization of the defines. Some were space based,
> most were tab based and there was a lack of "alignment", now it's
> all the same and aligned.
>
> Cc: James
Currently the FW loading path perform some checks based on IP model
and in case it is advertised as supported, the VCN indirect SRAM
mode is used.
Happens that in case there's any issue on FW and this mode ends-up
not being properly supported, the driver probe fails [0]. Debugging
this requires
Currently both conditionals checked to enable indirect SRAM are
repeated for all HW/IP models. Let's just simplify it a bit so
code is more compact and readable.
While at it, add the legacy names as a comment per case block, to
help whoever is reading the code and doesn't have much experience
This is an incredibly trivial fix, just for the sake of
"aesthetical" organization of the defines. Some were space based,
most were tab based and there was a lack of "alignment", now it's
all the same and aligned.
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #23 from Alex Deucher (alexdeuc...@gmail.com) ---
I'll just revert it. It is more important for kernels with the the drm_buddy
changes.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #22 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
Thanks for trying.
Another idea that might be feasible to do to identify it is a proper bisect
between v6.0 and v6.1 but manually applying
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #21 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Mario Limonciello (AMD) from comment #19)
> Assuming it's within amdgpu and not DRM helpers it's still ~800 commits to
> sift through. Even though 6.0.y is EOL now, I think it
Use drmm_mode_config_init() instead of drm_mode_config_init(), as it allows
us to assure that the resource will be properly cleaned.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit destroy hook in struct drm_crtc_funcs.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vkms/vkms_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Hi Thomas.
On Mon, Jan 16, 2023 at 02:12:13PM +0100, Thomas Zimmermann wrote:
> A lot of source files include drm_crtc_helper.h for its contained
> include statements. This leads to excessive compile-time dependencies.
>
> Where possible, remove the include statements for drm_crtc_helper.h
> and
On Mon, Jan 16, 2023 at 02:12:31PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
On Mon, Jan 16, 2023 at 02:12:18PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
On Mon, Jan 16, 2023 at 02:12:16PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
>
> Directly include required headers and drop
Hi Thomas.
On Mon, Jan 16, 2023 at 02:12:15PM +0100, Thomas Zimmermann wrote:
> Several DRM core and helper source files include drm_crtc_helper.h
> without needing it or only to get its transitive include statements;
> leading to unnecessary compile-time dependencies.
>
> Directly include
Hi Vinay,
On Mon, Jan 16, 2023 at 11:35:41AM -0800, Belgaumkar, Vinay wrote:
>
> On 1/16/2023 10:58 AM, Andi Shyti wrote:
> > Hi,
> >
> > On Thu, Jan 12, 2023 at 08:48:11PM -0800, Belgaumkar, Vinay wrote:
> > > On 1/12/2023 8:37 PM, Dixit, Ashutosh wrote:
> > > > On Thu, 12 Jan 2023 20:26:34
On 1/16/2023 10:58 AM, Andi Shyti wrote:
Hi,
On Thu, Jan 12, 2023 at 08:48:11PM -0800, Belgaumkar, Vinay wrote:
On 1/12/2023 8:37 PM, Dixit, Ashutosh wrote:
On Thu, 12 Jan 2023 20:26:34 -0800, Belgaumkar, Vinay wrote:
I think the ABI was changed by the patch mentioned in the commit
Hi Rodrigo,
On Wed, Jan 11, 2023 at 12:06:24PM -0500, Rodrigo Vivi wrote:
> On Wed, Jan 11, 2023 at 04:39:36PM +0100, Andi Shyti wrote:
> > Hi Rodrigo,
> >
> > On Wed, Jan 11, 2023 at 10:25:56AM -0500, Rodrigo Vivi wrote:
> > > On Wed, Jan 11, 2023 at 11:44:47AM +0100, Andi Shyti wrote:
> > > >
On 16/01/2023 12:40, Konrad Dybcio wrote:
> SM6375 has a single 7nm DSI PHY. Document it.
>
> Signed-off-by: Konrad Dybcio
> ---
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Hi,
On Thu, Jan 12, 2023 at 08:48:11PM -0800, Belgaumkar, Vinay wrote:
>
> On 1/12/2023 8:37 PM, Dixit, Ashutosh wrote:
> > On Thu, 12 Jan 2023 20:26:34 -0800, Belgaumkar, Vinay wrote:
> > > I think the ABI was changed by the patch mentioned in the commit
> > > (a8a4f0467d70).
> > The ABI was
Hi Nirmoy,
On Fri, Jan 13, 2023 at 01:00:53PM +0100, Nirmoy Das wrote:
> From: Chris Wilson
>
> Make sure that upon error after we have acquired the wakeref we do
> release it again.
>
> Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
> Reviewed-by: Matthew Auld
On Mon, Jan 16, 2023 at 6:54 AM Thomas Zimmermann wrote:
>
> (was: drm: Generic fbdev and vga-switcheroo)
>
> This patchset fixes how fbdev helpers interact with vga-switcheroo. The
> first two patches are bug fixes for the existing code. The third patch
> cleans up the drivers.
>
> Patch 1 fixes
On Mon, Jan 16, 2023 at 11:20 AM Jani Nikula
wrote:
>
> On Mon, 16 Jan 2023, Thomas Zimmermann wrote:
> > A lot of source files include drm_crtc_helper.h for its contained
> > include statements. This leads to excessive compile-time dependencies.
> >
> > Where possible, remove the include
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #20 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Mario Limonciello (AMD) from comment #19)
> Assuming it's within amdgpu and not DRM helpers it's still ~800 commits to
> sift through. Even though 6.0.y is EOL now, I think it
On Fri, Jan 06, 2023 at 05:15:28PM +, Robin Murphy wrote:
> However, echoing the recent activity over on the DMA API side of things, I
> think it's still worth proactively constraining the set of permissible
> flags, lest we end up with more weird problems if stuff that doesn't really
> make
[ Back from travel, so trying to make sense of this series.. ]
On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park wrote:
>
> I've been developing a tool for detecting deadlock possibilities by
> tracking wait/event rather than lock(?) acquisition order to try to
> cover all synchonization machanisms.
Applied. Thanks!
On Mon, Jan 16, 2023 at 8:13 AM Thomas Zimmermann wrote:
>
> Align a closing brace and remove trailing whitespaces. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
This is already fixed.
Thanks,
Alex
On Sun, Jan 15, 2023 at 4:32 AM Deepak R Varma wrote:
>
> The member variable set_odm_combine is already initialized and hence the
> reinitialization instruction can be removed. Issue identified using the
> dubleinit.cocci Coccinelle semantic patch script.
>
Applied. Thanks!
On Sun, Jan 15, 2023 at 4:26 AM Deepak R Varma wrote:
>
> Use swap() helper macro instead of open coded swap instructions. The
> change also facilitates code cleanup and realignment for improved
> readability. Issue identified using swap.cocci Coccinelle semantic
> patch
Applied. Thanks!
Alex
On Sun, Jan 15, 2023 at 9:27 PM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
> Series is reviewed-by: Evan Quan
>
> > -Original Message-
> > From: Deepak R Varma
> > Sent: Sunday, January 15, 2023 3:16 PM
> > To: Quan, Evan ; Deucher, Alexander
> >
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #19 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
Assuming it's within amdgpu and not DRM helpers it's still ~800 commits to sift
through. Even though 6.0.y is EOL now, I think it would be easier to check the
missing
Hi Dave,
A couple more fixes for the v6.3 cycle, which were meant to be part of
the previous fixes pull, but I fumbled at git when applying the tag.
The following changes since commit f4a75b5933c998e60fd812a7680e0971eb1c7cee:
drm/msm/a6xx: Avoid gx gbit halt during rpm suspend (2023-01-05
On Sat, Jan 14, 2023 at 08:10:43PM +0530, Deepak R Varma wrote:
> Hello,
> It appears that the callback function disable() of struct nvkm_devinit_func
> does
> not need return U64 and can be transformed to be a void. This will impact a
> few
> drivers that have currently implementation of this
Hi Alex,
On Sun, 15 Jan 2023 10:35:57 -0500 Alex Deucher wrote:
> On Sat, Jan 14, 2023 at 2:48 PM SeongJae Park wrote:
> >
> > Some subsystem documents are missing SPDX license identifiers. Add
> > those.
>
> It would be good to split this up per subsystem.
Thank you for the comment, will
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: c12e2e5b76b2e739ccdf196bee960412b45d5f85 Add linux-next specific
files for 20230116
Error/Warning: (recently discovered and may have been fixed)
drivers/gpu/drm/ttm/ttm_bo_util.c:364:32: error
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #18 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Alex Deucher from comment #16)
> (In reply to Rainer Fiebig from comment #15)
> > (In reply to Mario Limonciello (AMD) from comment #13)
> > > Can we please confirm it's
On Sun, Jan 15, 2023 at 11:49 AM Matthias Reichl wrote:
>
> I noticed some of the used HP Z240 workstations I recently bought had a
> Barco MXRT-5600 branded FirePro W5100 card installed - some others came with
> an unbranded W5100 (with the standard 6449 PCI ID).
>
> Except for a large Barco
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #17 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Alex Deucher from comment #16)
> (In reply to Rainer Fiebig from comment #15)
> > (In reply to Mario Limonciello (AMD) from comment #13)
> > > Can we please confirm it's
On Mon, 16 Jan 2023 15:21:25 +, Bryan O'Donoghue wrote:
> Currently we do not differentiate between the various users of the
> qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
> compatible string but, the hardware does have some significant differences
> in the number of
On Mon, Jan 16, 2023 at 5:24 PM Karol Herbst wrote:
>
> On Wed, Jan 4, 2023 at 1:52 AM Gustavo A. R. Silva
> wrote:
> >
> > On Tue, Jan 03, 2023 at 03:48:36PM -0800, Kees Cook wrote:
> > > Zero-length arrays are deprecated[1] and are being replaced with
> > > flexible array members in support of
On Wed, Jan 4, 2023 at 1:52 AM Gustavo A. R. Silva
wrote:
>
> On Tue, Jan 03, 2023 at 03:48:36PM -0800, Kees Cook wrote:
> > Zero-length arrays are deprecated[1] and are being replaced with
> > flexible array members in support of the ongoing efforts to tighten the
> > FORTIFY_SOURCE routines on
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #16 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Rainer Fiebig from comment #15)
> (In reply to Mario Limonciello (AMD) from comment #13)
> > Can we please confirm it's actually broken in 5.15.y before going through
> >
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #15 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Mario Limonciello (AMD) from comment #13)
> Can we please confirm it's actually broken in 5.15.y before going through
> that effort?
I have tested this with 5.15.87/88. Error
On Mon, 16 Jan 2023, Thomas Zimmermann wrote:
> A lot of source files include drm_crtc_helper.h for its contained
> include statements. This leads to excessive compile-time dependencies.
>
> Where possible, remove the include statements for drm_crtc_helper.h
> and include the required source
https://bugzilla.kernel.org/show_bug.cgi?id=216917
Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:
What|Removed |Added
Status|REOPENED
https://bugzilla.kernel.org/show_bug.cgi?id=216917
Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:
What|Removed |Added
Status|RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #13 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
Can we please confirm it's actually broken in 5.15.y before going through that
effort?
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=216917
Rainer Fiebig (j...@mailbox.org) changed:
What|Removed |Added
CC||j...@mailbox.org
---
On 16/01/2023 07:33, Dmitry Baryshkov wrote:
Rewrite dpu_hw_ctl_setup_blendstage() to use static data configuration
rather than using a switch-case. This simplifies adding support for new
pipes.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 156
On 16/01/2023 07:33, Dmitry Baryshkov wrote:
Extract the common expression in the dpu_hw_ctl_setup_blendstage()
function.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git
On 16/01/2023 07:33, Dmitry Baryshkov wrote:
SM8550 uses new register to map SSPP_DMA4 and SSPP_DMA5 units to blend
stages. Add proper support for this register to allow using these two
planes for image processing.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Cc: Neil Armstrong
Add the list of current compats absent the deprecated qcm2290 to the list
of dsi compats listed here.
Several MDSS yaml files exist which document the dsi sub-node.
For each existing SoC MDSS yaml, provide the right dsi compat string.
Signed-off-by: Bryan O'Donoghue
---
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 219 --
1 file
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following
V7:
- The bulk of the patches for this series have been merged.
There are still four patches to be pushed/updated.
- Adds clocks for msm8974 - Dmitry
- Adds compat strings for sm8150, sm8350, sm8450, sm8550 - Dmitry
- Changes last patch in series to state - Rob
compatible:
contains:
CLK_CTRL_DMA4,
+ DPU_CLK_CTRL_DMA5,
DPU_CLK_CTRL_CURSOR0,
DPU_CLK_CTRL_CURSOR1,
DPU_CLK_CTRL_INLINE_ROT0_SSPP,
Reviewed-by: Neil Armstrong
Tested-by: Neil Armstrong # on SM8550 on top of
next-20230116
Am 16.01.23 um 15:52 schrieb Felix Kuehling:
Am 2023-01-16 um 06:42 schrieb Christian König:
[SNIP]
When the BO is imported into the same GPU, you get a reference to
the same BO, so the imported BO has the same mmap_offset as the
original BO.
When the BO is imported into a different GPU, it
Am 2023-01-16 um 06:42 schrieb Christian König:
[SNIP]
When the BO is imported into the same GPU, you get a reference to
the same BO, so the imported BO has the same mmap_offset as the
original BO.
When the BO is imported into a different GPU, it is a new BO with a
new mmap_offset.
That
Reviewed-by: Karol Herbst
will push in a moment
On Thu, Jan 12, 2023 at 11:49 PM Kees Cook wrote:
>
> On Mon, Jan 09, 2023 at 07:39:30PM -0600, Gustavo A. R. Silva wrote:
> > Zero-length arrays are deprecated[1] and we are moving towards
> > adopting C99 flexible-array members instead. So,
Am 16.01.23 um 13:13 schrieb Thomas Zimmermann:
I'd add a Fixes tag, but don't know the commit when this was introduced.
Mhm, that code is 10+ years old. My educated guess is that we somehow
pulled in vmap/vunmap through a header which was now cleaned up.
Anyway your patch looks good to me,
On 16.01.2023 13:52, Dmitry Baryshkov wrote:
> On Mon, 16 Jan 2023 at 13:51, Konrad Dybcio wrote:
>>
>> On some SoCs (hello SM6375) vdds-supply is not wired to any smd-rpm
>> or rpmh regulator, but instead powered by the VDD_MX/mx.lvl line,
>> which is voted for in the DSI ctrl node.
>
> I
Hi Stephen
On Fri, 13 Jan 2023 at 21:12, Stephen Boyd wrote:
>
> Quoting Dave Stevenson (2023-01-13 08:27:29)
> > Hi Stephen
> >
> > On Fri, 6 Jan 2023 at 03:01, Stephen Boyd wrote:
> > >
> > > The unprepare sequence has started to fail after moving to panel bridge
> > > code in the msm drm
1 - 100 of 190 matches
Mail list logo
