Hi,
On Thu 13 Jul 23, 16:10, Uwe Kleine-König wrote:
> Hello Maxime,
>
> On Thu, Jul 13, 2023 at 01:17:43PM +0200, Maxime Ripard wrote:
> > On Thu, Jul 13, 2023 at 12:39:40PM +0200, Uwe Kleine-König wrote:
> > > On Thu, Jul 13, 2023 at 12:23:50PM +0300, Jani Nikula wrote:
> > > > On Thu, 13 Jul
On Friday, July 14th, 2023 at 12:31, Simon Ser wrote:
> Before this patch, 0..63 are for primary, 64..127 are for control (never
> exposed by the kernel), 128..191 are for render, 2048..2112 are for accel.
> After this patch, 0..127 are for primary, 64..191 are for control (never
> exposed by
Hi
Am 14.07.23 um 12:29 schrieb Dan Carpenter:
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
This entry should never be used by the kernel. Record the historical
context in a comment.
Signed-off-by: Simon Ser
Cc: Christian König
Cc: James Zhu
Cc: Marek Olšák
Cc: Daniel Vetter
---
include/drm/drm_file.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
This makes it easier to figure out what the "type" variable can be
set to when reading the implementation of these functions.
Signed-off-by: Simon Ser
Cc: Christian König
Cc: James Zhu
Cc: Marek Olšák
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 8
1 file changed, 4
This makes it clearer that the values cannot be changed because
they are ABI.
Signed-off-by: Simon Ser
Cc: Christian König
Cc: James Zhu
Cc: Marek Olšák
Cc: Daniel Vetter
---
include/drm/drm_file.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This patch will enable VCN FW workaround using
DRM KEY INJECT WORKAROUND method,
which is helping in fixing the secure playback.
Signed-off-by: sguttula
---
Changes in v2:
-updated commit message as per veera's feedback
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 9 +
Geert Uytterhoeven writes:
> The native display format is R1. Hence change the preferred_depth and
> preferred_bpp to 1, to avoid the overhead of using XR24 and the
> associated conversions when using fbdev emulation and its text console.
>
> Signed-off-by: Geert Uytterhoeven
> ---
(cc Daniel Vetter and Pekka because this change has uAPI repercussions)
On Friday, June 30th, 2023 at 13:56, James Zhu wrote:
> From: Christian König
>
> This makes room for up to 128 DRM devices.
>
> Signed-off-by: Christian König
> Signed-off-by: James Zhu
> ---
>
Geert Uytterhoeven writes:
> Add support for the monochrome light-on-dark buffer format (R1) to the
> fb helper, so this format can be used for fbdev emulation and for the
> text console. This avoids the overhead of using XR24 and the associated
> conversions on display hardware that supports
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
> >
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag
Am 14.07.23 um 12:07 schrieb Asahi Lina:
On 14/07/2023 18.51, Christian König wrote:
Am 14.07.23 um 11:44 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences
are
Geert Uytterhoeven writes:
> drm_fb_helper_single_fb_probe() first calls drm_fb_helper_find_sizes(),
> followed by drm_fbdev_generic_helper_fb_probe():
> - The former tries to find a suitable buffer format, taking into
> account limitations of the whole display pipeline,
> - The latter
Hi
Am 14.07.23 um 12:04 schrieb Geert Uytterhoeven:
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special
On 2023/7/14 15:49, Thomas Zimmermann wrote:
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by:
Am 14.07.23 um 12:06 schrieb Asahi Lina:
On 14/07/2023 18.57, Christian König wrote:
Am 14.07.23 um 11:49 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences
are
Geert Uytterhoeven writes:
> Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
> which uses bpp and depth to guess the wanted buffer format.
> However, drm_client_buffer_addfb() already knows the exact buffer
> format, so there is no need to convert back and forth between
Geert Uytterhoeven writes:
Hello Geert,
Thanks a lot for your patch, this has been on my TODO for some time!
> The native display format is monochrome light-on-dark (R1).
> Hence add support for R1, so monochrome applications can avoid the
> overhead of back-and-forth conversions between R1
On 14/07/2023 06:43, Yang, Fei wrote:
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the
purpose of the function is to return false if the platform/object
has a caching mode where GPU can bypass the LLC.
So far the only platforms which allegedly can do this
On 14/07/2023 06:36, Yang, Fei wrote:
[snip]
@@ -326,10 +330,10 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev,
void *data,
goto out;
}
- if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) ||
- i915_gem_object_has_cache_level(obj,
On 14/07/2023 18.51, Christian König wrote:
Am 14.07.23 um 11:44 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't
On 14/07/2023 18.57, Christian König wrote:
Am 14.07.23 um 11:49 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit
[AMD Official Use Only - General]
Suresh,
Please modify the commit message to a more meaningful one.
1. add a commit title
2. write about the changes than the effect of the change.
Something like Enabling FW workaround in using shared memory for VCN 4
3. Can you please check if this change is
Am 14.07.23 um 11:49 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the
Geert Uytterhoeven writes:
> Calling ssd130x_buf_alloc() from ssd130x_encoder_helper_atomic_enable()
> is too late, causing a NULL pointer dereference:
>
> ssd130x_update_rect.isra.0+0x13c/0x340
> ssd130x_primary_plane_helper_atomic_update+0x26c/0x284
>
Am 14.07.23 um 11:44 schrieb Asahi Lina:
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the
On 14/07/2023 18.47, Christian König wrote:
Am 14.07.23 um 11:39 schrieb Asahi Lina:
On 14/07/2023 17.40, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
Document the implied lifetime rules of the scheduler (or at least the
intended ones), as well as the expectations of how
Geert Uytterhoeven writes:
> drm_mode_create_dumb() calculates the number of characters per pixel
> from the number of bits per pixel by rounding up, which is not correct
> as the actual value of cpp may be non-integer. While we do not need to
> care here about complex formats like YUV, bpp < 8
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the get_timeline_name() implementation.
Fixes oopses on
CERT-C Characters and Strings (CERT STR31-C)
all_drm_priv[cnt] evaluates to an address that could be at negative
offset of an array.
In mtk_drm_get_all_drm_priv():
Guarantee that storage for strings has sufficient space for character
data and the null terminator.
So change cnt to unsigned int
Add this patch series to fix some mediatek-drm coverity issues.
Change in v4:
1. Fix title and commit message in [PATCH v3 3/4].
Change in v3:
1. swap Fixes and Signed tag.
2. change cast (__u64) to '=' then ' *='.
Change in v2:
1. remove kfree(pkt) in mtk_drm_crtc_create_pkt().
2. change the
1. Instead of multiplying 2 variable of different types. Change to
assign a value of one variable and then multiply the other variable.
2. Add a int variable for multiplier calculation instead of calculating
different types multiplier with dma_addr_t variable directly.
Fixes: 1a64a7aff8da
Fixing the coverity issue of:
mtk_drm_cmdq_pkt_destroy frees address of mtk_crtc->cmdq_handle
So remove the free function.
Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Reviewed-by:
Null-checking state suggests that it may be null, but it has already
been dereferenced on drm_atomic_get_new_plane_state(state, plane).
The parameter state will never be NULL currently, so just remove the
state is NULL flow in this function.
Fixes: 5ddb0bd4ddc3 ("drm/atomic: Pass the full state
Geert Uytterhoeven writes:
> Hi Javier,
>
> On Fri, Jul 14, 2023 at 11:34 AM Javier Martinez Canillas
> wrote:
>> Geert Uytterhoeven writes:
>> > The page height must be taken into account only for vertical coordinates
>> > and heights, not for horizontal coordinates and widths.
>> >
>> >
Am 14.07.23 um 11:39 schrieb Asahi Lina:
On 14/07/2023 17.40, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
Document the implied lifetime rules of the scheduler (or at least the
intended ones), as well as the expectations of how resource acquisition
should be handled.
This patch will fix the secure playback corruption due
to HW bug on VCN4.
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 9 +
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
This patch will enable secure decode playback on VCN4
Signed-off-by: sguttula
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c
index e8c02ae10163..d199f87febd1 100644
---
On 14/07/2023 17.43, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the get_timeline_name() implementation.
Fixes oopses on
Hi Javier,
On Fri, Jul 14, 2023 at 11:34 AM Javier Martinez Canillas
wrote:
> Geert Uytterhoeven writes:
> > The page height must be taken into account only for vertical coordinates
> > and heights, not for horizontal coordinates and widths.
> >
> > Fixes: 179a790aaf2a0127 ("drm/ssd130x: Set
On 14/07/2023 17.40, Christian König wrote:
Am 14.07.23 um 10:21 schrieb Asahi Lina:
Document the implied lifetime rules of the scheduler (or at least the
intended ones), as well as the expectations of how resource acquisition
should be handled.
Signed-off-by: Asahi Lina
---
Geert Uytterhoeven writes:
Hello Geert,
Thanks for your patch!
> The page height must be taken into account only for vertical coordinates
> and heights, not for horizontal coordinates and widths.
>
> Fixes: 179a790aaf2a0127 ("drm/ssd130x: Set the page height value in the
> device info data")
Am 14.07.23 um 10:21 schrieb Asahi Lina:
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the get_timeline_name() implementation.
Fixes oopses on `cat /sys/kernel/debug/dma_buf/bufinfo` when
Am 14.07.23 um 10:21 schrieb Asahi Lina:
Document the implied lifetime rules of the scheduler (or at least the
intended ones), as well as the expectations of how resource acquisition
should be handled.
Signed-off-by: Asahi Lina
---
drivers/gpu/drm/scheduler/sched_main.c | 58
Document the implied lifetime rules of the scheduler (or at least the
intended ones), as well as the expectations of how resource acquisition
should be handled.
Signed-off-by: Asahi Lina
---
drivers/gpu/drm/scheduler/sched_main.c | 58 --
1 file changed, 55
(-)
---
base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
change-id: 20230714-drm-sched-fixes-94bea043bbe7
Thank you,
~~ Lina
A signaled scheduler fence can outlive its scheduler, since fences are
independencly reference counted. Therefore, we can't reference the
scheduler in the get_timeline_name() implementation.
Fixes oopses on `cat /sys/kernel/debug/dma_buf/bufinfo` when shared
dma-bufs reference fences from GPU
drm_sched_fini() currently leaves any pending jobs dangling, which
causes segfaults and other badness when job completion fences are
signaled after the scheduler is torn down.
Explicitly detach all jobs from their completion callbacks and free
them. This makes it possible to write a sensible safe
Patches 1/3 and 2/3 applied to drm-misc-next.
I'll resend patch 3/3 as standalone.
Cheers,
-Paul
Le samedi 08 juillet 2023 à 10:40 +0200, Paul Cercueil a écrit :
> Hi,
>
> Follow-up on my patchset that fixes the display of the Samsung Galaxy
> S2
> when running PostmarketOS.
>
> The first two
Am 13.07.23 um 23:32 schrieb André Almeida:
Log the IB addresses used by the hung job along with the stuck ring
name. Note that due to nested IBs, the one that caused the reset itself
may be in not listed address.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h|
Geert Uytterhoeven writes:
Hello Geert,
> Hi Javier,
>
> On Thu, Jul 13, 2023 at 6:32 PM Javier Martinez Canillas
> wrote:
>> Geert reports that the following NULL pointer dereference happens for him
>> after commit 49d7d581ceaf ("drm/ssd130x: Don't allocate buffers on each
>> plane update"):
Am 13.07.23 um 23:32 schrieb André Almeida:
If a kernel thread caused the reset, the information available to be
logged will be limited, so return early in the dump function.
Why? The register values and vram lost state should still be valid.
Christian.
Signed-off-by: André Almeida
---
Aradhya Bhatia writes:
Hello Aradhya,
> Hi Sam,
>
[...]
>>
>> It would be even better to walk through other implementations of
>> get_input_bus_fmts and update them accordingly.
>>
>> Again, sorry for being late here. Feel free to ignore if you already
>> moved on with something else.
>>
>
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by: Miguel Ojeda
Cc: Helge Deller
---
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_.
v3:
* include board name in commit
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
Am 13.07.23 um 23:32 schrieb André Almeida:
Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.
Signed-off-by: André Almeida
---
v2: Replace
Hey Alex,
On Thu, 2023-07-13 at 17:19 -0300, Fabio Estevam wrote:
> On Wed, May 17, 2023 at 4:08 AM Alexandru Ardelean wrote:
> >
> > From: Bogdan Togorean
> >
> > For ADV7533 and ADV7535 low refresh rate is selected using
> > bits [3:2] of 0x4a main register.
> > So depending on ADV model
Am 13.07.23 um 21:28 schrieb Greg Kroah-Hartman:
On Thu, Jul 13, 2023 at 02:13:16PM -0500, Andrew Davis wrote:
This new export type exposes to userspace the SRAM area as a DMA-BUF Heap,
this allows for allocations of DMA-BUFs that can be consumed by various
DMA-BUF supporting devices.
What
On 14/07/2023 03:21, Jessica Zhang wrote:
DSI 6G v2.5.x+ and DPU 7.x+ support a data-bus widen mode that allows DSI
sm8250 has widebus support in DP and thus in DPU, according to the
published DT. Thus the 'DPU 7.x+' is not fully correct.
to send 48 bits of compressed data per pclk instead
https://bugzilla.kernel.org/show_bug.cgi?id=217664
--- Comment #4 from popus_czy_to_ty (pentelja...@o2.pl) ---
stripped part, might be interesting?
https://pastebin.com/MgpCf7Xf
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee
Am 14.07.23 um 07:35 schrieb shijie...@208suo.com:
Fix one occurrence of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
It's nice to see all those little typos fixed, but I'm not sure how
feasible it is to send patches for each type individually.
Maybe just merge them together
Hi Javier,
On Thu, Jul 13, 2023 at 6:32 PM Javier Martinez Canillas
wrote:
> Geert reports that the following NULL pointer dereference happens for him
> after commit 49d7d581ceaf ("drm/ssd130x: Don't allocate buffers on each
> plane update"):
>
> [drm] Initialized ssd130x 1.0.0 20220131 for
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
>
> hello Sean,
>
> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> > I'd really prefer this patch (series or single) is not accepted. This
> > will cause problems for everyone cherry-picking patches to a
> > downstream kernel
Fix four occurrences of the checkpatch.pl error:
ERROR: open brace '{' following function definitions go on the next line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git
On Thu, Jul 13, 2023 at 04:14:55PM +0100, Tvrtko Ursulin wrote:
>
> On 13/07/2023 16:09, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 13.07.23 um 16:41 schrieb Sean Paul:
> > > On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > > wrote:
> > > >
> > > > hello Sean,
> > > >
> > > > On Wed, Jul
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
will cause problems for everyone cherry-picking
Signed-off-by: ZhiHu
---
.../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index d8a4d773a58c..b99e0a7c96bb
On 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
Signed-off-by: ZhiHu
---
.../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index d8a4d773a58c..b99e0a7c96bb
Fix seventeen occurrences of the checkpatch.pl error:
ERROR: open brace '{' following struct go on the same line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/smu7_discrete.h | 51 +-
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git
Fix eight occurrences of the checkpatch.pl error:
ERROR: that open brace { should be on the previous line
ERROR: space prohibited before that close parenthesis ')'
ERROR: spaces required around that '?' (ctx:VxW)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/sumo_dpm.c | 18
Fix one occurrence of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/uvd_v1_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/uvd_v1_0.c
b/drivers/gpu/drm/radeon/uvd_v1_0.c
index
On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote:
> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > But even with the one-patch-per-rename approach I'd consider the
> > renaming a net win, because ease of understanding code has a big value.
> > It's value is not so easy measurable as
Signed-off-by: ZhiHu
---
.../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index d8a4d773a58c..b99e0a7c96bb
Signed-off-by: ZhiHu
---
.../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index d8a4d773a58c..b99e0a7c96bb
Fix two occurrences of the checkpatch.pl error:
ERROR: spaces required around that '+=' (ctx:VxV)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/r100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c
b/drivers/gpu/drm/radeon/r100.c
index
Fix Nineteen occurrences of the checkpatch.pl error:
ERROR: space prohibited before that ':' (ctx:WxW)
ERROR: trailing statements should be on next line
ERROR: space prohibited before that ':' (ctx:WxW)
ERROR: trailing statements should be on next line
ERROR: space prohibited before that ':'
Fix two occurrences of the checkpatch.pl error:
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space required after that ',' (ctx:WxV)
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/atom-bits.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
> I'd really prefer this patch (series or single) is not accepted. This
> will cause problems for everyone cherry-picking patches to a
> downstream kernel (LTS or distro tree). I usually wouldn't expect
> sympathy here, but
Fix four occurrences of the checkpatch.pl error:
ERROR: open brace '{' following enum go on the same line
Signed-off-by: Jie Shi
---
drivers/gpu/drm/radeon/ni_dpm.h | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni_dpm.h
Mark registered_fb, num_registered_fb, fbcon_registered_fb, and
fbcon_num_registered_fb static to fix the following sparse
warnings:
drivers/video/fbdev/core/fbmem.c:51:16: sparse: warning: symbol 'registered_fb'
was not declared. Should it be static?
drivers/video/fbdev/core/fbmem.c:52:5:
101 - 200 of 213 matches
Mail list logo
