> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Friday, November 10, 2023 3:40 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Sharma, Swati2 ; Kulkarni, Vandita
> ; Kandpal, Suraj ;
> suijingf...@loongson.cn
> Subject: [PATCH 11/11]
> Subject: [PATCH 10/11] drm/i916/dp_mst: Iterate over the DSC bpps as per
> DSC precision support
>
> Currently we iterate over the bpp_x16 in step of 16.
> Use DSC fractional bpp precision supported by the sink to compute the
> appropriate steps to iterate over the bpps.
>
LGTM.
Reviewed-by:
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Friday, November 10, 2023 3:40 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Sharma, Swati2 ; Kulkarni, Vandita
> ; Kandpal, Suraj ;
> suijingf...@loongson.cn
> Subject: [PATCH 09/11]
On Wed, Nov 8, 2023 at 8:02 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> The arch_jump_label_transform_static() function in csky was originally meant
> to
> override the generic __weak function, but that got changed to an #ifndef
> check.
>
> This showed up as a missing-prototype
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Yong-Wu/dma-buf-heaps-Initialize-a-secure-heap/2023-192115
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
The strncpy_from_user() returns number of copied bytes and not zero on
success. The non-zero return value of ioctl is treated as error. Return
zero on success instead of the number of copied bytes.
Fixes: 7add80126bce ("drm/uapi: add explicit virtgpu context debug name")
Signed-off-by: Dmitry
On 10/18/23 21:17, Gurchetan Singh wrote:
> + case VIRTGPU_CONTEXT_PARAM_DEBUG_NAME:
> + if (vfpriv->explicit_debug_name) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> +
On 10/18/23 21:17, Gurchetan Singh wrote:
> There are two problems with the current method of determining the
> virtio-gpu debug name.
>
> 1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a
>Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though,
>Android/FreeBSD get
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Yong-Wu/dma-buf-heaps-Initialize-a-secure-heap/2023-192115
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
On 11/10/23 7:26 AM, Pavel Begunkov wrote:
> On 11/7/23 23:03, Mina Almasry wrote:
>> On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote:
>>>
>>> On 11/7/23 3:10 PM, Mina Almasry wrote:
On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>
> On 11/5/23 7:44 PM, Mina Almasry wrote:
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Yong-Wu/dma-buf-heaps-Initialize-a-secure-heap/2023-192115
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
On Sat, Nov 11, 2023 at 03:20:17PM +0100, Krzysztof Kozlowski wrote:
> Qualcomm SM8150 MDSS comes with a bit different 7nm DSI PHY with its own
> compatible. DTS already use it:
>
> sa8155p-adp.dtb: display-subsystem@ae0: phy@ae94400:compatible:0:
> 'qcom,dsi-phy-7nm' was expected
>
>
On 11/11/23 11:41, Dario Binacchi wrote:
This series was created with the intention of fixing the left margin
setting. At the same time, I made some changes with the aim of making
the code more readable, as well as removing the errors/warnings
reported by checkpatch.
applied to fbdev for-next
https://bugzilla.kernel.org/show_bug.cgi?id=218134
--- Comment #2 from Gerhard Mack (gm...@innerfire.net) ---
I have discovered this happens when there are two monitors plugged into my
displayport switch. If I run monitor 4 on hdmi directly, the crash stops
happening.
--
You may reply to this
Qualcomm SM8150 MDSS comes with a bit different 7nm DSI PHY with its own
compatible. DTS already use it:
sa8155p-adp.dtb: display-subsystem@ae0: phy@ae94400:compatible:0:
'qcom,dsi-phy-7nm' was expected
Signed-off-by: Krzysztof Kozlowski
---
To maximize per cpu execution context for the work items, use the
recommended settings i.e. WQ_DFL_ACTIVE(256). There is no apparent
reason to throttle to 16 while process tear down.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/ttm/ttm_device.c | 2 +-
1 file changed, 1 insertion(+), 1
Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.
To optimize the memory clearing operation when a TTM BO gets freed by
the delayed_delete worker, scheduling it closer to a NUMA node where the
memory was
On 11/11/2023 12:15, Yong Wu wrote:
> Add a binding for describing the secure CMA reserved memory range. The
> memory range also will be defined in the TEE firmware. It means the TEE
> will be configured with the same address/size that is being set in this
> DT node.
>
> Signed-off-by: Yong Wu
>
Hi,
this is ontop of Linus' tree from the 4th (lemme know if I should try
the latest) on one of my test boxes:
nouveau :01:00.0: vgaarb: deactivate vga console
Console: switching to colour dummy device 80x25
nouveau :01:00.0: NVIDIA GT218 (0a8280b1)
CE: hpet increased min_delta_ns to
https://bugzilla.kernel.org/show_bug.cgi?id=218134
Gerhard Mack (gm...@innerfire.net) changed:
What|Removed |Added
CC||gm...@innerfire.net
https://bugzilla.kernel.org/show_bug.cgi?id=218134
Bug ID: 218134
Summary: Null pointer when rearranging screen layout in XFCE.
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity:
On Sat, 11 Nov 2023, Luben Tuikov wrote:
> From Jani:
> The drm_print.[ch] facilities use very few pr_*() calls directly. The
> users of pr_*() calls do not necessarily include at
> all, and really don't have to.
>
> Even the ones that do include it, usually have includes
> first, and includes
Add a normal CMA heap which use the standard cma allocate.
Signed-off-by: Yong Wu
---
Hi Vijay and Jaskaran,
For this heap,
1) It uses sec_heap_buf_ops currently. I guess we cann't use the
cma_heap_buf_ops. since if it is secure buffer, some operations such
as mmap should not be allowed.
2) I
Create a new MediaTek CMA heap from the CMA reserved buffer.
In this heap, When the first allocating buffer, use cma_alloc to prepare
whole the CMA range, then send its range to TEE to protect and manage.
For the later allocating, we just adds the cma_used_size_mtk.
This CMA flow may be
Add a binding for describing the secure CMA reserved memory range. The
memory range also will be defined in the TEE firmware. It means the TEE
will be configured with the same address/size that is being set in this
DT node.
Signed-off-by: Yong Wu
---
.../reserved-memory/secure_cma_region.yaml
Add the dma_ops for this secure heap.
a) For secure buffer, cache_ops/mmap are not allowed, thus return
EPERM for them.
b) The secure buffer can't be accessed in kernel, thus it doesn't
have va/dma_address for it. Use the dma_address property to save the
"secure handle".
Signed-off-by: Yong Wu
Add TEE service call. In the case of MediaTek, secure memory management is
located within the TEE. The kernel just needs to tell TEE what size it
needs and the TEE will return a "security handle" to kernel.
To be consistent with the cma heap later, we put the tee ops into the ops
of
The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
here since this is not a platform driver, therefore initialize the TEE
context/session while we allocate the first secure buffer.
Add our special UUID and tee type in the private data.
If the uuid is zero, it means that it
For the secure memory, there are two steps:
a) Allocate buffers in kernel side;
b) Secure that buffer.
Different heaps may have different buffer allocation methods and
different memory protection methods. Here abstract the memory
allocation and securing operations.
Signed-off-by: Yong Wu
---
Initialize a secure heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 7 +++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/secure_heap.c | 98 +
3 files changed,
This patchset adds three secure heaps:
1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
The buffer is reserved for the secure world after bootup and it is used
for vcodec's ES/working buffer;
2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
Linux kernel coding style uses '*/' on a separate line at the end of
multi line comments.
Fix block comments by moving '*/' at the end of block comments on a
separate line as reported by checkpatch:
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Dario Binacchi
---
Resolve the following warning reported by checkpatch:
WARNING: Prefer using '"%s...", __func__' to using 'imxfb_blank', this
function's name, in a string
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Resolve the following warning reported by checkpatch:
WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
This made it necessary to move the 'fbi->pdev = pdev' setting to the
beginning of the driver's probing.
The patch gets rid of magic numbers replacing them with appropriate
macros.
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index
Fix the following checkpatch error:
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index
Resolve the following warning reported by checkpatch.pl:
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
The patch also removes some license info made redundant by the addition
of the SPDX tag.
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 5 +
1
Resolve the following warning reported by checkpatch:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
Replace opencoded masking and shifting, with BIT(), GENMASK(),
FIELD_GET() and FIELD_PREP() macros.
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 113 +++-
1 file changed, 59 insertions(+), 54 deletions(-)
diff --git
The previous setting did not take into account the CSTN mode.
For the H_WAIT_2 bitfield (bits 0-7) of the LCDC Horizontal Configuration
Register (LCDCR), the IMX25RM manual states that:
In TFT mode, it specifies the number of SCLK periods between the end of
HSYNC and the beginning of OE signal,
The patch moves the bitfields of the PCR register near the macro that
defines its offset, just like for all the other registers.
Signed-off-by: Dario Binacchi
---
drivers/video/fbdev/imxfb.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git
This series was created with the intention of fixing the left margin
setting. At the same time, I made some changes with the aim of making
the code more readable, as well as removing the errors/warnings
reported by checkpatch.
Dario Binacchi (10):
fbdev: imxfb: fix left margin setting
fbdev:
On Sat, 11 Nov 2023 at 20:10, Javier Martinez Canillas
wrote:
>
> > On Sat, 11 Nov 2023 at 15:30, Andrew Worsley wrote:
> >>
> >>The simpledrm.c does not call aperture_remove_conflicting_devices() in
> >> it's probe
> >>function as the drivers/video/aperture.c documentation says it
Andrew Worsley writes:
> It's inline - part of the email - not an attachment?
>
> I can see it in the copy that went to me...
>
> Andrew
>
> On Sat, 11 Nov 2023 at 15:30, Andrew Worsley wrote:
>>
>>The simpledrm.c does not call aperture_remove_conflicting_devices() in
>> it's probe
>>
Luben Tuikov writes:
Hello Luben,
> From Jani:
> The drm_print.[ch] facilities use very few pr_*() calls directly. The
> users of pr_*() calls do not necessarily include at
> all, and really don't have to.
>
> Even the ones that do include it, usually have includes
> first, and includes
Andrew Worsley writes:
> It's inline - part of the email - not an attachment?
>
> I can see it in the copy that went to me...
>
I see it now as another thread. There is something weird with the threading
since your first email was shown as first email in a thread with no subject.
> Andrew
>
>
>From Jani:
The drm_print.[ch] facilities use very few pr_*() calls directly. The
users of pr_*() calls do not necessarily include at
all, and really don't have to.
Even the ones that do include it, usually have includes
first, and includes next. Notably, includes
.
And, of course, defines
It's inline - part of the email - not an attachment?
I can see it in the copy that went to me...
Andrew
On Sat, 11 Nov 2023 at 15:30, Andrew Worsley wrote:
>
>The simpledrm.c does not call aperture_remove_conflicting_devices() in
> it's probe
>function as the drivers/video/aperture.c
Luben Tuikov writes:
Hello Luben,
> This reverts commit 36245bd02e88e68ac5955c2958c968879d7b75a9.
>
You should include a commit message explaining why this commit should
be reverted. I noticed that was asked by Jani so I would include what
he mentioned in the other email thread.
>
This patch fix's the failure of the frame buffer driver on my Asahi kernel
which prevented X11 from starting on my Apple M1 laptop. It seems like a
straight
forward failure to follow the procedure described in drivers/video/aperture.c
to remove the ealier driver. This patch is very simple and
The simpledrm.c does not call aperture_remove_conflicting_devices() in it's
probe
function as the drivers/video/aperture.c documentation says it should.
Consequently
it's request for the FB memory fails.
...
[3.085302] simple-framebuffer bd58dc000.framebuffer: [drm] *ERROR* could
Hi everyone,
On 11/10/23 06:52, Kai-Heng Feng wrote:
On Fri, Nov 10, 2023 at 2:19 PM Hans de Goede wrote:
On 11/10/23 07:09, Kai-Heng Feng wrote:
On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisler wrote:
#regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0
#regzbot link:
Andrew Worsley writes:
Hello Andrew,
>This patch fix's the failure of the frame buffer driver on my Asahi kernel
> which prevented X11 from starting on my Apple M1 laptop. It seems like a
> straight
> forward failure to follow the procedure described in drivers/video/aperture.c
> to remove
https://bugzilla.kernel.org/show_bug.cgi?id=218133
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Kernel Version|Linux version |6.5.0-10-generic
https://bugzilla.kernel.org/show_bug.cgi?id=218133
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
55 matches
Mail list logo
