https://bugzilla.kernel.org/show_bug.cgi?id=218841
Bug ID: 218841
Summary: Security issue (VERY old video memory displaying in
Window preview)
Product: Drivers
Version: 2.5
Hardware: Intel
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=218841
--- Comment #1 from Trent Gamblin (trentgamb...@hotmail.com) ---
https://youtube.com/shorts/Wn7kdBeIFdE?si=jJxhXi0UbVmW-xhu
That's the video, it was too big to attach.
--
You may reply to this email to add a comment.
You are receiving this mai
https://bugzilla.kernel.org/show_bug.cgi?id=218841
--- Comment #2 from Trent Gamblin (trentgamb...@hotmail.com) ---
I just installed an AMD RX 6400.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
From: Kuro
New patch description for v8 patch
resolve merge conflict
New patch description for v7 patch
modify code from
it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET, 0x02); to
it6505_set_bits(it6505, REG_VID_BUS_CTRL1, TX_FIFO_RESET,
TX_FIFO_RESET
From: Kuro
ITE added a FIFO reset bit for input video. When system power resume,
the TTL input of it6505 may get some noise before video signal stable
and the hardware function reset is required.
But the input FIFO reset will also trigger error interrupts of output module
rising.
Thus, it6505 ha
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly penalised by incorrectly considering
its migration
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can control the decision on whether
backing store migration will be attempted or not.
Both from code inspection and from e
On Wed, May 15, 2024 at 08:39:49AM UTC, Yannick FERTRE wrote:
> Hi Sean,
>
> thanks for your patch.
>
> Tested-by: Yannick Fertre
>
> I think that a helper could be useful in simplifying this part.
> This might be reworked when a new helper will be implemented.
>
> Best regards
Hi Yannick,
W
Hi Sean,
thanks for your patch.
Tested-by: Yannick Fertre
I think that a helper could be useful in simplifying this part.
This might be reworked when a new helper will be implemented.
Best regards
On 4/22/24 16:05, Sean Nyekjaer wrote:
On Fri, Mar 22, 2024 at 11:47:31AM +0100, Sean Nyekjae
Hi,
On Tue, 14 May 2024 at 19:37, Thorsten Blum wrote:
>
> Merge the identical if/elif code blocks and remove the following two
> warnings reported by make includecheck:
>
> asm/ioctl.h is included more than once
> linux/types.h is included more than once
>
> Signed-off-by: Thorst
Hey,
Den 2024-05-13 kl. 10:55, skrev Hogander, Jouni:
Hello Maintainers,
Could you please ack this patch? I'm planning to merge it via drm-intel
tree.
BR,
Jouni Högander
Acked-by: Maarten Lankhorst
On Tue, May 14, 2024, at 13:08, Niklas Schnelle wrote:
> In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
> compile time. We thus need to #ifdef functions and their callsites which
> unconditionally use these I/O accessors. In the include/video/vga.h
> these are conveniently
On Fri, 2024-05-10 at 12:38 +0300, Jouni Högander wrote:
> This patch set is implementing panel replay selective update support
> for Intel hardware.
These are now merged into drm-intel-next including "drm/panelreplay:
dpcd register definition for panelreplay SU".
Thank you Animesh and Maarten fo
> New patch description for …
* How do you think about to omit a cover letter for a single patch?
* Would it be helpful to specify any email addresses in the message field “To”
(besides “Cc”)?
Regards,
Markus
On 15. May 2024, at 09:43, Luc Ma wrote:
> On Tue, 14 May 2024 at 19:37, Thorsten Blum wrote:
>>
>> Merge the identical if/elif code blocks and remove the following two
>> warnings reported by make includecheck:
>>
>>asm/ioctl.h is included more than once
>>linux/types.h is incl
On 15. May 2024, at 11:22, Thorsten Blum wrote:
> On 15. May 2024, at 09:43, Luc Ma wrote:
>> On Tue, 14 May 2024 at 19:37, Thorsten Blum wrote:
>>>
>>> Merge the identical if/elif code blocks and remove the following two
>>> warnings reported by make includecheck:
>>>
>>> asm/ioctl.h is
; beagleboard.org and upgraded the kernel to their v6.9 package, and
> used the same packages from my MT8173 run. It seemed to run OK, but
> it's possible the kernel doesn't have CONFIG_LOCKDEP enabled.
>
> I'll do some more tests on MT8173 with a release kernel and fewer
On Tue, 14 May 2024, Sui Jingfeng wrote:
> The pointer of 'struct device' can also be used as a key to search drm
> bridge instance from the global bridge list, traditionally, fwnode and
> 'OF' based APIs requires the system has decent fwnode/OF Graph support.
> While the drm_find_bridge_by_dev()
Hi all,
Picking up this long-standing series which added support for Microtips'
and LincolnTech's dual-lvds panels.
Microtips Technology Solutions USA, and Lincoln Technology Solutions are
2 display panel vendors, and the patches 1/6 and 2/6 add their vendor
prefixes.
Patch 3/6 adds panel specif
Add document vendor prefix for Microtips Technology USA (microtips).
Signed-off-by: Aradhya Bhatia
Acked-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetr
Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions'
LCD185-101CT 10.1"[2] panel.
Thes are all dual-lvds panels.
Panel Links:
[0]:
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V
Add support for Microtips Technology USA 13-101HIECAF0-C 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and touch
support (ILITEK 2511).
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf
Signed-off-by: A
Add document vendor prefix for Lincoln Technology Solutions
(lincolntech).
Signed-off-by: Aradhya Bhatia
Acked-by: Krzysztof Kozlowski
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/de
Add support for Lincoln Technology Solutions LCD185-101CT, 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and PCAP
touch support (Goodix GT928).
[0]: Panel Datasheet
https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf
Signed-off-by: Arad
Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
does not support touch.
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf
Signed-off-
On Tue, 14 May 2024, Michal Wajdeczko wrote:
> This drm printer wrapper can be used to increase the robustness of
> the captured output generated by any other drm_printer to make sure
> we didn't lost any intermediate lines of the output by adding line
> numbers to each output line. Helpful for ca
Hi,
On 5/15/24 17:39, Jani Nikula wrote:
On Tue, 14 May 2024, Sui Jingfeng wrote:
The pointer of 'struct device' can also be used as a key to search drm
bridge instance from the global bridge list, traditionally, fwnode and
'OF' based APIs requires the system has decent fwnode/OF Graph suppor
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2023年12月5日 21:19
> To: Keith Zhao
> Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> linux-ker...@vger.kernel.org; linux-ri...@lists.infradead.org;
> a...@eecs.berkeley.edu; suijingf...@loongson.cn; tzimmerm...@suse
On Wed, 15 May 2024, Sui Jingfeng wrote:
> Hi,
>
>
> On 5/15/24 17:39, Jani Nikula wrote:
>> On Tue, 14 May 2024, Sui Jingfeng wrote:
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 584d109330ab..1928d9d0dd3c 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>
Hi Robert,
Am Dienstag, dem 07.05.2024 um 15:10 +0200 schrieb Robert Foss:
> On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
> >
> > Currently the AUX channel support in the Analogix DP driver is severely
> > limited as the AUX block of the bridge is only initialized when the video
> > link is
Hi,
On 5/15/24 18:28, Jani Nikula wrote:
On Wed, 15 May 2024, Sui Jingfeng wrote:
Hi,
On 5/15/24 17:39, Jani Nikula wrote:
On Tue, 14 May 2024, Sui Jingfeng wrote:
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 584d109330ab..1928d9d0dd3c 100644
--- a/drive
On 15/05/2024 08:14, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly pen
On 15/05/2024 08:20, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can control the decision on whether
backing store migration will be attempte
The purpose of this patchset is for MediaTek secure video playback, and
also to enable other potential uses of this in the future. The 'restricted
dma-heap' will be used to allocate dma_buf objects that reference memory
in the secure world that is inaccessible/unmappable by the non-secure
(i.e. ker
Add a binding for describing the dynamic restricted 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. Regarding to the detail TEE command, Please search
MTK_TZCMD_SECMEM
Introduce a FLAG for the restricted memory which means the memory is
protected by TEE or hypervisor, then it's inaccessiable for kernel.
Currently we don't use sg_dma_unmark_restricted, thus this interface
has not been added.
Signed-off-by: Yong Wu
---
include/linux/scatterlist.h | 34 +
Prepare for the restricted heap to reuse, move it out from system_heap.c.
To keep the function name consistent, rename it to sg_dup_table.
Cc: Andrew Morton
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/system_heap.c | 27 +--
include/linux/scatterlist.h | 2
Initialize a restricted heap. Currently just add a null heap, Prepare for
the later patches.
Signed-off-by: Yong Wu
---
drivers/dma-buf/heaps/Kconfig | 9
drivers/dma-buf/heaps/Makefile | 3 +-
drivers/dma-buf/heaps/restricted_heap.c | 67 +
driv
Add "struct restricted_heap_ops". For the restricted memory, totally there
are two steps:
a) alloc: Allocate the buffer in kernel;
b) restrict_buf: Restrict/Protect/Secure that buffer.
The "alloc" is mandatory while "restrict_buf" is optional since it may
be part of "alloc".
Signed-off-by: Yong Wu
Introduce tests for ttm_bo_validate()/ttm_bo_init_validate() that exercise
simple BO placement as well as eviction (including the case where the evict
domain also requires eviction to fit the incoming buffer). Prepare KUnit
helpers to handle such scenarios and add a mock VRAM manager. This series a
DRM KUnit helpers are selected automatically when TTM tests are enabled,
so there's no need to do it directly in the .kunitconfig file.
Signed-off-by: Karolina Stolarek
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/ttm/tests/.kunitconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/
Add the dma_ops for this restricted heap. For restricted buffer,
1) cache_ops/mmap are not allowed, thus return EPERM for them.
2) In map_dma_buf, use DMA_ATTR_SKIP_CPU_SYNC to skip cache sync since
the buffer is protected.
This type buffers are marked by sg_dma_mark_restricted, the user could
c
BOs in a bulk move have to share the same reservation object. That is
not the case in the ttm_bo_unreserve_bulk subtest. Update
ttm_bo_kunit_init() helper to accept dma_resv object so we can define
buffer objects that share the same resv. Update calls to that helper
accordingly.
Fixes: 995279d280d
In commit d393acce7b3f ("drm/tests: Switch to kunit devices"),
DRM test helpers migrated away from using a dummy platform driver
in favour of KUnit device. This means that DMA masks for the device
are not set but are required by ttm_pool_alloc tests.
Set the DMA mask for coherent mappings to unblo
Add a new helper function that also initializes the device. Use it in
ttm_tt test suite and delete the local definition.
Signed-off-by: Karolina Stolarek
Reviewed-by: Matthew Auld
Reviewed-by: Somalapuram, Amaranath
---
drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 14 ++
drivers
Add tests for ttm_bo_init_reserved() and ttm_bo_validate() that use
sys manager. Define a simple move function in ttm_device_funcs. Expose
destroy callback of the buffer object to make testing of
ttm_bo_init_reserved() behaviour easier.
Signed-off-by: Karolina Stolarek
Reviewed-by: Matthew Auld
Add a MediaTek restricted heap which uses TEE service call to restrict
buffer. Currently this restricted heap is NULL, Prepare for the later
patch. Mainly there are two changes:
a) Add a heap_init ops since TEE probe late than restricted heap, thus
initialize the heap when we require the buffer
Add test cases that check how the state of dma fences in BO's
reservation object influence the ttm_bo_validation() flow. Do similar
tests for resource manager's move fence.
Signed-off-by: Karolina Stolarek
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
.../gpu/drm/tt
Add tests for functions that add and release pages to TTs. Test the
swapin operation. Export ttm_tt_unpopulate, ttm_tt_swapin and
ttm_tt_swapout symbols for testing purposes.
Signed-off-by: Karolina Stolarek
Reviewed-by: Somalapuram, Amaranath
Tested-by: Somalapuram, Amaranath
---
drivers/gpu/
List improvements for the test suite with some notes.
Signed-off-by: Karolina Stolarek
---
drivers/gpu/drm/ttm/tests/TODO | 25 +
1 file changed, 25 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/tests/TODO
diff --git a/drivers/gpu/drm/ttm/tests/TODO b/drivers/gpu
Add mock resource manager to test ttm_bo_validate() with non-system
placements. Update KConfig entry to enable DRM Buddy allocator, used
by the mock manager. Update move function to do more than just assign
a resource.
Signed-off-by: Karolina Stolarek
Tested-by: Somalapuram, Amaranath
---
drive
Add TEE service call for MediaTek heap. We have a limited number of
hardware entries to protect memory, therefore we cannot protect memory
arbitrarily, and our secure memory management is actually inside OPTEE.
Totally there are 3 commands:
1) MTK_TZCMD_SECMEM_ZALLOC: The kernel tells the TEE what
Add tests for ttm_bo_validate that focus on BO eviction and swapout.
Update device funcs definition with eviction-related callbacks. Add
alternative funcs where evict_flags() routes eviction to a domain
that can't allocate resources (dubbed "busy manager" in the tests).
Extract the common path of t
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.
When SVP done, cma_release will re
The NPU device consists of two parts: NPU buttress and NPU IP.
Buttress is a platform specific part that integrates the NPU IP with
the CPU.
NPU IP is the platform agnostic part that does the inference.
This refactor enables support for multiple platforms using
a single NPU IP, so for example NPU
From: "Wachowski, Karol"
Move buttress registers to ivpu_hw_btrs_*_reg.h headers.
This is an intermediate step before HW layer refactor.
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek Lawrynowicz
---
drivers/accel/ivpu/ivpu_hw_37xx.c | 153
drivers/accel/ivpu/iv
Use kfifo to pass IRQ sources to IRQ thread so it will be possible to
use IRQ thread by multiple IRQ types.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Wachowski, Karol
---
drivers/accel/ivpu/ivpu_drv.c | 19 +--
drivers/accel/ivpu/ivpu_hw.c| 9 ++---
drivers/accel/
On Wed, 15 May 2024, Sui Jingfeng wrote:
> Yes, you are right, I'll back give another try then.
Thanks, but please do wait until you have feedback on whether the whole
thing is a good idea or not. :)
BR,
Jani.
--
Jani Nikula, Intel
Thomas Zimmermann writes:
Hello Thomas,
> Call fb_deferred_io_cleanup() upon destroying the framebuffer
> device. Releases the internal memory.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 150f431a0831 ("drm/fbdev: Add fbdev-shmem")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc
Thomas Zimmermann writes:
> Call fb_deferred_io_cleanup() upon destroying the framebuffer
> device. Releases the internal memory.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 808a40b69468 ("drm/fbdev-dma: Implement damage handling and deferred
> I/O")
> Cc: Thomas Zimmermann
> Cc: Javier Mart
On MMUv2 cores the linear window is only relevant when starting the FE,
before the MMU has been activated. Once the MMU is active, all accesses
are translated with no way to bypass the MMU via the linear window. Thus
TS ignoring the linear window offset is not an issue on cores with MMUv2
present a
On Tue, 14 May 2024, Thomas Zimmermann wrote:
> Hi
>
> Am 14.05.24 um 14:55 schrieb Jani Nikula:
>> Prefer the struct drm_edid based functions for reading the EDID and
>> updating the connector.
>>
>> Signed-off-by: Jani Nikula
>>
>> ---
>>
>> Cc: Xinliang Liu
>> Cc: Tian Tao
>> Cc: Xinwei Kong
Hi
Am 15.05.24 um 14:34 schrieb Jani Nikula:
On Tue, 14 May 2024, Thomas Zimmermann wrote:
Hi
Am 14.05.24 um 14:55 schrieb Jani Nikula:
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Cc: Xinliang Liu
Cc: Tian Ta
On 15.05.2024 11:56, Jani Nikula wrote:
> On Tue, 14 May 2024, Michal Wajdeczko wrote:
>> This drm printer wrapper can be used to increase the robustness of
>> the captured output generated by any other drm_printer to make sure
>> we didn't lost any intermediate lines of the output by adding li
Am 15.05.24 um 13:59 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Call fb_deferred_io_cleanup() upon destroying the framebuffer
device. Releases the internal memory.
Signed-off-by: Thomas Zimmermann
Fixes: 808a40b69468 ("drm/fbdev-dma: Implement damage handling and deferred
On Wed, 15 May 2024, Michal Wajdeczko wrote:
> On 15.05.2024 11:56, Jani Nikula wrote:
>> On Tue, 14 May 2024, Michal Wajdeczko wrote:
>>> This drm printer wrapper can be used to increase the robustness of
>>> the captured output generated by any other drm_printer to make sure
>>> we didn't lost
Hi Marek,
Thank you for the patch.
On Wed, May 15, 2024 at 08:27:44AM +0200, Marek Vasut wrote:
> The DW HDMI driver core is responsible for parsing the 'ddc-i2c-bus' property,
> move the property description into the DW HDMI common DT schema too, so this
> property can be used on all devices int
Some reserved memory regions might have particular memory setup or
attributes that make them good candidates for heaps.
Let's provide a heap type that will create a new heap for each reserved
memory region flagged as such.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/Kconfig |
The uAPI header has a bunch of constants and structures that might be
handy in drivers.
Let's include the header in the driver-side dma-heap header.
Signed-off-by: Maxime Ripard
---
include/linux/dma-heap.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/dma-heap.h b/include
The /memory device tree bindings allow to store the ECC detection and
correction bits through the ecc-detection-bits and ecc-correction-bits
properties.
Our next patches rely on whether ECC is enabled, so let's add a helper
to retrieve the ECC correction bits from the /memory node.
Signed-off-by:
5 +-
9 files changed, 407 insertions(+), 7 deletions(-)
---
base-commit: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
change-id: 20240515-dma-buf-ecc-heap-28a311d2c94e
Best regards,
--
Maxime Ripard
The system heap has been using its struct dma_heap pointer but wasn't
using it anywhere.
Since we'll need additional parameters to attach to that heap type,
let's create a private structure and set it as the dma_heap drvdata,
removing the global variable in the process.
Signed-off-by: Maxime Ripa
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/system_heap.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma-buf/heaps
Some systems run with ECC enabled on the memory by default, but with
some memory regions with ECC disabled to mitigate the downsides of
enabling ECC (reduced performances, increased memory usage) for buffers
that don't require it.
Let's create some allocation flags to ask for a particular ECC setu
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/cma_heap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/carveout_heap.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/dma-buf
On 15/05/2024 11:51, Aradhya Bhatia wrote:
> Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
> MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions'
> LCD185-101CT 10.1"[2] panel.
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2024/5/15 00:22, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
> > > Because a lot of implementations has already added it into their drived
> > > class, promote it into
Am 15.05.24 um 12:59 schrieb Tvrtko Ursulin:
On 15/05/2024 08:20, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with
buffer
allowed and preferred placements can control the decision on w
Devarsh Thakkar writes:
Hello Devarsh and Maxime,
> Hi Maxime,
>
> On 14/03/24 20:04, Maxime Ripard wrote:
>> Hi,
>>
>> On Wed, Feb 14, 2024 at 09:17:12PM +0530, Devarsh Thakkar wrote:
>>> On 13/02/24 19:34, Maxime Ripard wrote:
On Thu, Feb 08, 2024 at 06:26:17PM +0530, Devarsh Thakkar wro
Hi,
On 5/15/24 22:30, Maxime Ripard wrote:
On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
Hi,
On 2024/5/15 00:22, Maxime Ripard wrote:
Hi,
On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
Because a lot of implementations has already added it into their drived
cl
Hi Lucas,
On Wed, May 15, 2024 at 02:13:58PM +0200, Lucas Stach wrote:
> On MMUv2 cores the linear window is only relevant when starting the FE,
> before the MMU has been activated. Once the MMU is active, all accesses
> are translated with no way to bypass the MMU via the linear window. Thus
> TS
On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
> On 5/15/24 22:30, Maxime Ripard wrote:
> > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
> > > On 2024/5/15 00:22, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng
Hi Linus,
please pull some fixes and cleanups for the fbdev drivers for kernel 6.10-rc1.
Code cleanups for offb, shmobile, sisfb, savage, au1200fb, uvesafb,
omap2 and sh7760fb, as well as the addition of some HAS_IOPORT
dependencies and adjustment of generated logo file to make build
reproducible
On 15/05/2024 15:31, Christian König wrote:
Am 15.05.24 um 12:59 schrieb Tvrtko Ursulin:
On 15/05/2024 08:20, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with
buffer
allowed and pre
On Wed, May 15, 2024 at 10:07:27AM +, Keith Zhao wrote:
>
>
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: 2023年12月5日 21:19
> > To: Keith Zhao
> > Cc: devicet...@vger.kernel.org; dri-devel@lists.freedesktop.org;
> > linux-ker...@vger.kernel.org; linux-ri...@lists.infrad
Hi,
On 5/15/24 22:58, Maxime Ripard wrote:
On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
On 5/15/24 22:30, Maxime Ripard wrote:
On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
On 2024/5/15 00:22, Maxime Ripard wrote:
Hi,
On Tue, May 14, 2024 at 11:40:43PM +080
Hi,
On 5/14/24 23:12, Laurent Pinchart wrote:
Hello,
On Tue, May 14, 2024 at 12:26:15AM +0800, Sui Jingfeng wrote:
On 5/13/24 16:02, Liu Ying wrote:
The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver sh
On Tue, May 14, 2024 at 11:19:47AM -0400, Detlev Casanova wrote:
> Add the documentation for VOP2 video ports reset clocks.
> One reset can be set per video port.
>
> Signed-off-by: Detlev Casanova
Are these resets valid for all VOPs or just the one on 3588?
> ---
> .../display/rockchip/rockch
Because I left habana, Ofir Bitton is now the habanalabs driver
maintainer.
The git repo also changed location to the Habana GitHub website.
Signed-off-by: Oded Gabbay
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index abd4dbe
Hi Dave, Sima.
A few weeks ago I left Habana and Intel. Therefore, I'm stepping down from
the maintainer role of both habanalabs and Xe drivers.
Ofir Bitton from Habana will replace me in the role of habanalabs driver
maintainer and as for the Xe driver, Thomas and Lucas will probably suggest
som
Because I left Intel, I'm removing myself from the list
of Xe driver maintainers.
Signed-off-by: Oded Gabbay
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5bd45a919aff..2469607ff5b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10863,7 +10863
On 11/05/2024 02:21, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur. The entries in the sg_t
I suggest to reconsider the distribution of email addresses over recipient lists
once more.
…
> But the input FIFO reset will also trigger error interrupts of output module
> rising.
> Thus, it6505 have to wait a period can clear those expected error interrupts
> caused by manual hardware reset
On 15/05/2024 13:01, Nikolay Aleksandrov wrote:
> On 11/05/2024 02:21, Mina Almasry wrote:
>> Add a netdev_dmabuf_binding struct which represents the
>> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
>> rx queues on the netdevice. On the binding, the dma_buf_attach
>> & dma_
On 11/05/2024 02:21, Mina Almasry wrote:
> Add an interface for the user to notify the kernel that it is done
> reading the devmem dmabuf frags returned as cmsg. The kernel will
> drop the reference on the frags to make them available for reuse.
>
> Signed-off-by: Willem de Bruijn
> Signed-off-by
Am Mittwoch, 15. Mai 2024, 18:19:29 CEST schrieb Conor Dooley:
> On Tue, May 14, 2024 at 11:19:47AM -0400, Detlev Casanova wrote:
> > Add the documentation for VOP2 video ports reset clocks.
> > One reset can be set per video port.
> >
> > Signed-off-by: Detlev Casanova
>
> Are these resets vali
The pull request you sent on Wed, 15 May 2024 17:12:52 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d34672777da3ea919e8adb0670ab91ddadf7dea0
Thank you!
--
Dee
The pull request you sent on Wed, 15 May 2024 16:20:56 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-05-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/db5d28c0bfe566908719bec8e25443aabecbb802
Thank you!
--
Deet-doot-dot, I am a bot.
ht
Hi, Jani
I love your patch, thanks.
On 2024/5/14 20:55, Jani Nikula wrote:
Prefer the struct drm_edid based functions for reading the EDID and
updating the connector.
Signed-off-by: Jani Nikula
---
Reviewed-by: Sui Jingfeng
--
Best regards,
Sui
1 - 100 of 160 matches
Mail list logo