Use str_enabled_disabled string helpers for better readability and to
fix cocci warning.
Reported-by: kernel test robot
Reported-by: Julia Lawall
Closes: https://lore.kernel.org/r/202410071601.tfpxoqgw-...@intel.com/
Signed-off-by: R Sundar
---
Reported in linux repo:
tree: https://git.kern
This is a note to let you know that I've just added the patch titled
firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of th
This is a note to let you know that I've just added the patch titled
firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of th
> Although the alpha channel in XRGB formats can be ignored, ALPHA_CON
> must be configured accordingly when using XRGB formats or it will still
> affects CRC generation.
affect?
Can such a change description become a bit nicer with an additional
imperative wording?
https://git.kernel.org/pub/
Applied the series. Thanks!
Alex
On Thu, May 30, 2024 at 6:20 AM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 20/05/2024 12:13, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Convert fdinfo memory stats to use the common drm_print_memory_stats
> > helper.
> >
> > This achieves alignment with
On Mon, Oct 07, 2024 at 01:40:21PM +0200, Niklas Schnelle wrote:
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them. In the bochs driver there is optional MMIO support
detected at runtime,
On 03/09/2024 14:40, Robert Foss wrote:
> On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote:
>
>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
>>
>> Like the TFP410, the TDP158 can be set up in 2 different ways:
>> 1) hard-coding its configuration settings using pin-st
On Mon, 7 Oct 2024 at 16:33, Marc Gonzalez wrote:
>
> On 03/09/2024 14:40, Robert Foss wrote:
>
> > On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote:
> >
> >> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
> >>
> >> Like the TFP410, the TDP158 can be set up in 2 differe
Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
length of task comm. Changes in the task comm could result in a destination
string that is overflow. Therefore, we should explicitly ensure the
destination string is always NUL-terminated, regardless of the task comm.
This ap
We want to eliminate the use of __get_task_comm() for the following
reasons:
- The task_lock() is unnecessary
Quoted from Linus [0]:
: Since user space can randomly change their names anyway, using locking
: was always wrong for readers (for writers it probably does make sense
: to have so
On 07/10/2024 16:42, Dmitry Baryshkov wrote:
> On Mon, 7 Oct 2024 at 16:33, Marc Gonzalez wrote:
>>
>> On 03/09/2024 14:40, Robert Foss wrote:
>>
>>> On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote:
>>>
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
Lik
In kstrdup(), it is critical to ensure that the dest string is always
NUL-terminated. However, potential race condition can occur between a
writer and a reader.
Consider the following scenario involving task->comm:
readerwriter
len = strlen(s) + 1;
These three functions follow the same pattern. To deduplicate the code,
let's introduce a common helper __kmemdup_nul().
Suggested-by: Andrew Morton
Signed-off-by: Yafang Shao
Cc: Simon Horman
Cc: Matthew Wilcox
Cc: Alejandro Colomar
---
mm/util.c | 69 ++-
Using strscpy() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
Acked-by: Paul Moore
Reviewed-by: Justin Stitt
Cc: Eric Paris
---
kernel/auditsc
Quoted from Linus [0]:
selinux never wanted a lock, and never wanted any kind of *consistent*
result, it just wanted a *stable* result.
Using get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates f
Let's explicitly ensure the destination string is NUL-terminated. This way,
it won't be affected by changes to the source string.
Signed-off-by: Yafang Shao
Reviewed-by: Quentin Monnet
---
tools/bpf/bpftool/pids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/bpf/bpftool/pids.c b/
To prevent errors from occurring when the src string is longer than the
dst string in strcpy(), we should use strscpy() instead. This
approach also facilitates future extensions to the task comm.
Suggested-by: Justin Stitt
Signed-off-by: Yafang Shao
Acked-by: Daniel Vetter
Reviewed-by: Justin S
On Mon, Oct 7, 2024, at 14:39, Lucas De Marchi wrote:
> as an example:
> $ git grep -lw outb -- drivers/gpu/drm/
> drivers/gpu/drm/gma500/cdv_device.c
> drivers/gpu/drm/i915/display/intel_vga.c
> drivers/gpu/drm/qxl/qxl_cmd.c
> drivers/gpu/drm/qxl/qxl_irq.c
> drivers/gpu/drm/tiny/bochs.c
> drivers/
Use str_on_off string helpers for better readability and to fix cocci
warning.
Reported-by: kernel test robot
Reported-by: Julia Lawall
Closes: https://lore.kernel.org/r/202410071252.cwiljzrh-...@intel.com/
Signed-off-by: R Sundar
---
Reported in linux repo:
tree: https://git.kernel.org/pub/
This is a note to let you know that I've just added the patch titled
drm/sched: Always increment correct scheduler score
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
dr
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/sched: Always increment correct scheduler score
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
dr
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
Hi Greg,
please drop this patch from all backports. It turned out to be broken
and the old handling has been restored by a revert.
Sorry for the noise. The revert should show up in Linus tree by the end
of the week.
Regards,
Christian.
Am 07.10.24 um 19:50 schrieb gre...@linuxfoundation.or
Or wait a second with that.
Tvrtko which one was the patch we had to revert?
Regards,
Christian.
Am 07.10.24 um 19:53 schrieb Christian König:
Hi Greg,
please drop this patch from all backports. It turned out to be broken
and the old handling has been restored by a revert.
Sorry for the no
On 07/10/2024 10:52, Wadim Egorov wrote:
> The SI9022 HDMI transmitter can be configured with a bus-width of 16,
> 18, or 24 bits. Introduce a bus-width property to the input endpoint,
> specifying the number of parallel RGB input bits connected to the
> transmitter.
>
> Signed-off-by: Wadim Egoro
Since kvfree() already checks if its argument is NULL, an additional
check before calling kvfree() is unnecessary and can be removed.
Remove both and the following Coccinelle/coccicheck warnings reported by
ifnullfree.cocci:
WARNING: NULL check before some freeing functions is not needed
WARN
Hi Dave,
On 21.06.2024 17:20, Dave Stevenson wrote:
> From: Maxime Ripard
>
> With the introduction of the BCM2712 support, we will get yet another
> generation of display engine to support.
>
> The binary check of whether it's VC5 or not thus doesn't work anymore,
> especially since some parts o
On Fri, 04 Oct 2024, Werner Sembach wrote:
>
> Am 03.10.24 um 09:59 schrieb Lee Jones:
> > On Wed, 02 Oct 2024, Werner Sembach wrote:
> >
> > > Hi,
> > >
> > > Am 02.10.24 um 14:52 schrieb Lee Jones:
> > > > On Fri, 27 Sep 2024, Werner Sembach wrote:
> > > >
> > > > > Hi,
> > > > > first revis
Add support for pixel format ABGR, which is the default format
on Android devices. This will allow us to use VKMS as the default
display driver in Android Emulator (Cuttlefish) and increase VKMS
adoption.
Signed-off-by: Paz Zcharya
---
drivers/gpu/drm/vkms/vkms_formats.c | 20
On 10/7/24 02:22, Jason-JH Lin (林睿祥) wrote:
>
> Hi Adam, Yassine,
>
> Please try the patches below and check if they can fix the
downgrade
> issue:
> [1] Fix degradation problem of alpha blending series
> -
>
https://patchwork.kernel.org/project/linux-mediatek/list/?series=893634
> [2] drm/me
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them unconditionally. Some 8250 serial drivers support
MMIO only use, so fence only the parts requiring I/O ports and print an
error message if
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them. In the bochs driver there is optional MMIO support
detected at runtime, warn if this isn't taken when HAS_IOPORT is not
defined.
There is
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or fencing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such a
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/bluetooth/Kconfig | 6 +++---
Hi All,
This is a follow up in my long running effort of making inb()/outb() and
similar I/O port accessors compile-time optional. After initially
sending this as a treewide series with the latest revision at[0]
we switched to per subsystem series. Now though as we're left with only
5 patches left
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. As hexagon does not support I/O port access it also
the GENERIC_IOMAP mechanism of dynamically choosing between I/O port and
MMIO access doesn't work so don't select it.
Reviewed-by: Brian Cain
Co-developed-by:
Hi
Am 30.09.24 um 19:54 schrieb Christian König:
I've been running into the same issue as well. Going to take a look.
Any results?
Christian.
Am 30.09.24 um 17:25 schrieb Arthur Marsh:
[ 13.069630] [drm] radeon kernel modesetting enabled.
[ 13.069681] radeon :00:01.0: vgaarb: deac
That's the issue I was working on, give me 10 minutes to send out the fix.
Regards,
Christian.
Am 07.10.24 um 06:49 schrieb Hoi Pok Wu:
Thank you. I am looking at the problem now.
On Mon, Oct 7, 2024 at 1:37 AM Christophe Leroy
wrote:
Le 06/10/2024 à 18:56, Christian Zigotzky a écrit :
On
On Wed, Oct 02, 2024 at 01:32:29PM +0530, Nautiyal, Ankit K wrote:
>
> On 10/2/2024 1:19 PM, Colin Ian King wrote:
> > There is a spelling mistake in a drm_WARN message. Fix it.
> >
> > Signed-off-by: Colin Ian King
> Reviewed-by: Ankit Nautiyal
pushed, thanks
> > ---
> > drivers/gpu/drm/i9
Applied. Thanks!
On Sun, Oct 6, 2024 at 7:28 AM Andrew Kreimer wrote:
>
> Fix typos in comments: "wether -> whether".
>
> Signed-off-by: Andrew Kreimer
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/gfx_v
Hi all,
On Fri, 4 Oct 2024 12:18:00 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-xe tree got a conflict in:
>
> drivers/gpu/drm/xe/xe_guc_submit.c
>
> between commit:
>
> 9286a191abe2 ("drm/xe: Drop GuC submit_wq pool")
>
> from the drm-misc-fixes tree and commit
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch i
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch i
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch i
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Etnaviv assumes that GPU page size is 4KiB, yet on some systems, the CPU
> page size is 16KiB. The size of etnaviv buffer objects will be aligned
> to CPU page size on kernel side, however, userspace still assumes the
> page size is
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Since the GPU VA space is compact in terms of 4KiB unit, map and/or unmap
> the area that doesn't belong to a context breaks the philosophy of PPAS.
> That results in severe errors: GPU hang and MMU fault (page not present)
> and suc
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Print an error message to help debug when such an issue happen, since it's
> not so obvious.
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Lucas Stach
> ---
> v0 -> v1: Use dev_err_ratelimited() to prevent spamming the logs
>
>
On Sun, Oct 6, 2024 at 7:49 PM Janne Grunau wrote:
> Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
> necessary") initializes deferred I/O only if it is used.
> drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()
> unconditionally with struct fb_info.fbdefio == NU
Hi
Am 03.10.24 um 13:33 schrieb Ville Syrjala:
From: Ville Syrjälä
drm_client_firmware_config() is currently picking up the current
mode of the crtc via the legacy crtc->mode, which is not supposed
to be used by atomic drivers at all. We can't simply switch over
to the proper crtc->state->mode
Helo Alex,
On Sun, Oct 06, 2024 at 09:30:06PM -0400, Alex Lanzano wrote:
> +static int sharp_memory_init_pwm_vcom_signal(struct sharp_memory_device *smd)
> +{
> + struct pwm_state pwm_state;
> + struct device *dev = &smd->spi->dev;
> +
> + smd->pwm_vcom_signal = devm_pwm_get(dev, NULL)
Hi
Am 03.10.24 um 13:33 schrieb Ville Syrjala:
From: Ville Syrjälä
Replace the 'unsigned int i' footguns with plain old signed
int. Avoids accidents if/when someone decides they need
to iterate backwards.
Why are signed types preferable here?
Best regards
Thomas
Signed-off-by: Ville Syrj
InvokeV2 request is intended to support multiple enhanced invoke
requests like CRC check, performance counter enablement and polling
mode for RPC invocations. CRC check is getting enabled as part of
this patch. CRC check for input and output argument helps in ensuring
data consistency over a remote
Add support to capture kernel performance counters for different
kernel level operations. These counters collects the information
for remote call and copies the information to a buffer shared
by user.
Collection of DSP performance counters is also added as part of
this change. DSP updates the perf
Poll mode is a feature to be introduced which improves the fastrpc
remote calls latency. For this feature, DSP expects the 4th to 7th
bit of context id to be zero. Prepare context id in such a way that
polling mode can be supported.
Signed-off-by: Ekansh Gupta
---
drivers/misc/fastrpc.c | 8
Similar to commit f2a4bcb25328 ("drm/v3d: Use v3d_perfmon_find()"),
replace the open-coded `vc4_perfmon_find()` with the real thing.
Cc: Christian Gmeiner
Signed-off-by: Maíra Canal
Reviewed-by: Christian Gmeiner
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 6 +-
1 file changed, 1 ins
This patch series adds the listed features that have been missing
in upstream fastRPC driver.
- Add changes to support new enhanced invocation ioctl request.
- Add support for CRC check.
- Add support for DSP and kernel performance counters.
- Add polling mode support.
Userspace change: https://g
For any remote call to DSP, after sending an invocation message,
fastRPC driver waits for glink response and during this time the
CPU can go into low power modes. Adding a polling mode support
with which fastRPC driver will poll continuously on a memory
after sending a message to remote subsystem w
Am 06.10.24 um 19:49 schrieb Janne Grunau:
Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
necessary") initializes deferred I/O only if it is used.
drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()
unconditionally with struct fb_info.fbdefio == NULL. KASAN wit
On 06/10/2024 20:18, Dzmitry Sankouski wrote:
mipi_dsi_compression_mode_multi can help with
error handling.
Signed-off-by: Dzmitry Sankouski
---
drivers/gpu/drm/drm_mipi_dsi.c | 16
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/driv
Il 07/10/24 09:00, Jason-JH.Lin ha scritto:
Refine the comment for ignore_pixel_alpha flag and move it to
if (state->fb) statement to make it less conditional.
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
> This patch series add support for the monochrome Sharp Memory LCD panels.
…
> ---
> Changes in v9:
…
Would you like to benefit from the application of scope-based resource
management
(also for this software component)?
Regards,
Markus
Il 07/10/24 09:00, Jason-JH.Lin ha scritto:
If the constant alpha always enable, the SoCs that is not supported the
ignore pixel alpha bit will still use constant alpha. That will break
the original constant alpha setting of XRGB foramt for blend_modes
unsupported SoCs, such as MT8173.
Note that
Hi,
I noticed a shift/mask issue in dphy_set_pll_reg() in
drivers/gpu/drm/sprd/megacores_pll.c, the expression (pll->kint << 4) &
0xf is
always zero:
...
reg_val[4] = pll->kint >> 12;
reg_val[5] = pll->kint >> 4;
reg_val[6] = pll->out_sel | ((pll->kint << 4) &
On Mon, Oct 07, 2024 at 11:34:13AM +0200, Markus Elfring wrote:
> > This patch series add support for the monochrome Sharp Memory LCD panels.
> …
> > ---
> > Changes in v9:
> …
>
> Would you like to benefit from the application of scope-based resource
> management
> (also for this software compon
Since some SoCs support premultiplied pixel formats but some do not,
the blend_modes parameter is added to mtk_plane_init(), which is
obtained from the mtk_ddp_comp_get_blend_modes function implemented
in different blending supported components.
The blending supported components can use driver dat
Some SoCs do not support the ignore_pixl_alpha flag, which breaks the
XRGB format. Some SoCs do not support pre-multiplied pixel formats
and extending configuration of OVL pre-multiplied color formats,
such as MT8173.
Fix the SoC degradation problem by this sreies.
---
Change in v9:
1. Add th
If the constant alpha always enable, the SoCs that is not supported the
ignore pixel alpha bit will still use constant alpha. That will break
the original constant alpha setting of XRGB foramt for blend_modes
unsupported SoCs, such as MT8173.
Note that ignore pixel alpha bit is suppored if the SoC
Refine the comment for ignore_pixel_alpha flag and move it to
if (state->fb) statement to make it less conditional.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/media
Since we changed MACROs to be consistent with DRM input color format
naming, the comment for ovl_fmt_conver() is no longer needed.
Fixes: 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in OVL")
Signed-off-by: Jason-JH.Lin
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c
OVL_CON_CLRFMT_MAN is a configuration for extending color format
settings of DISP_REG_OVL_CON(n).
It will change some of the original color format settings.
Take the settings of (3 << 12) for example.
- If OVL_CON_CLRFMT_MAN = 0 means OVL_CON_CLRFMT_RGBA.
- If OVL_CON_CLRFMT_MAN = 1 means OVL_
Introduce a bus-width property to define the number of parallel RGB
input pins connected to the transmitter. The input bus formats are updated
accordingly. If the property is not specified, default to 24-bit bus-width.
Signed-off-by: Wadim Egorov
---
v2:
- Use bus-width instead of data-lines as
This patch series introduces a bus-width property for the SI9022 HDMI
transmitter, allowing the input bus format to be configured based on the
number of RGB input pins. The default is set to 24-bit if unspecified.
v2:
- Reorder patches to have dt-bindings go first
- Use bus-width instead of da
The SI9022 HDMI transmitter can be configured with a bus-width of 16,
18, or 24 bits. Introduce a bus-width property to the input endpoint,
specifying the number of parallel RGB input bits connected to the
transmitter.
Signed-off-by: Wadim Egorov
---
v2:
- Use bus-width instead of data-lines a
My r-b still hold for this series. Please merge it through whatever
branch you are comfortable with.
And sorry for the delay, I'm still on sick leave (dentist problems).
Regards,
Christian.
Am 02.10.24 um 13:44 schrieb Thomas Hellström:
Hi, Christian,
Gentle ping on this one as well.
Thanks,
On Mon, Oct 07, 2024 at 02:15:15PM +0530, Ekansh Gupta wrote:
> +struct fastrpc_invoke_v2 {
> + struct fastrpc_invoke inv;
> + __u64 crc;
> + __u32 reserved[16];
I'm sure we have been over this before, but if you have a reserved
field, you HAVE to check that it is zero if you ever want
Hi
Am 04.10.24 um 17:24 schrieb Gonzalo Silvalde Blanco:
The sstfb driver currently depends on CONFIG_FB_DEVICE to create sysfs
entries and access info->dev. This patch wraps the relevant code blocks
with #ifdef CONFIG_FB_DEVICE, allowing the driver to be built and used
even if CONFIG_FB_DEVICE
On Mon, Oct 07, 2024 at 02:15:16PM +0530, Ekansh Gupta wrote:
> Add support to capture kernel performance counters for different
> kernel level operations. These counters collects the information
> for remote call and copies the information to a buffer shared
> by user.
>
> Collection of DSP perfo
Il 07/10/24 08:57, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Fri, 2024-10-04 at 12:22 +0200, AngeloGioacchino Del Regno wrote:
Il 04/10/24 08:03, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-10-01 at 13:33 +0200, AngeloGioacchino Del Regno wrote:
Il 01/10/24 12:07, CK Hu (胡俊光) ha scritto:
Hi Thomas,
I'm on sick leave, but I will try to answer questions and share some
thoughts on this to unblock you.
Am 18.09.24 um 14:57 schrieb Thomas Hellström:
Sima, Christian
I've updated the shrinker series now with a guarded for_each macro
instead:
https://patchwork.freedesktop.org/patch
On 05/10/2024 00:40, Caleb Connolly wrote:
Hi Jocelyn,
On 10/09/2024 08:56, Jocelyn Falempe wrote:
drm_log is a simple logger that uses the drm_client API to print the
kmsg boot log on the screen.
This is not a full replacement to fbcon, as it will only print the kmsg.
It will never handle use
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual dis
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint def
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is a
Changes in v11:
- Added OVL_ADAPTOR_MDP_RDMA to OVL Adaptor exclusive components list
to avoid failures in graphs with MDP_RDMA inside
- Rebased on next-20241004
Changes in v10:
- Removed erroneously added *.orig/*.rej files
Changes in v9:
- Rebased on next-20240910
- Removed redundant as
Use atomic64_inc_return(&ref) instead of atomic64_add_return(1, &ref)
to use optimized implementation and ease register pressure around
the primitive for targets that implement optimized variant.
Signed-off-by: Uros Bizjak
Cc: Sumit Semwal
Cc: "Christian König"
---
drivers/dma-buf/dma-buf.c |
> -Original Message-
> From: Kaustabh Chakraborty
> Sent: Friday, September 20, 2024 12:11 AM
> To: Inki Dae ; Seung-Woo Kim
> ; Kyungmin Park ; David
> Airlie ; Simona Vetter ; Krzysztof
> Kozlowski ; Alim Akhtar ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ; Rob Herring
1 - 100 of 196 matches
Mail list logo
