Test looks good.
Regards,
S.Amarnath
amar@amar-Artic:~/amar/drm_misc/drm-misc1$
./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests
[08:20:02] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[08:20:03]
On 5/16/24 20:36, Neil Armstrong wrote:
> On 16/05/2024 13:06, Aradhya Bhatia wrote:
>> Hi Liu,
>>
>> Thanks for reviewing the patch.
>>
>> On 16/05/24 07:49, Liu Ying wrote:
>>> On 5/15/24 17:51, Aradhya Bhatia wrote:
Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel,
From: Kuro Chung
This patch 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
On Thu, 29 Feb 2024 at 23:48, Arnd Bergmann wrote:
>
> On Thu, Feb 29, 2024, at 11:51, Matthew Auld wrote:
> > The drm_buddy minimum page-size requirements should be distinct from the
> > CPU PAGE_SIZE. Only restriction is that the minimum page-size is at
> > least 4K.
> >
> > Signed-off-by:
> >>
> >> (And that kernel version of "6.9.0-08295-gfd39ab3b5289" that is quoted
> >> in the WARN isn't some official kernel, I have about ten private
> >> patches that I keep testing in my tree, so if you wondered what the
> >> heck that git version is, it's not going to match anything you see,
>
On Thu, May 16, 2024 at 02:52:01PM -0500, Lucas De Marchi wrote:
On Thu, May 16, 2024 at 11:33:54AM GMT, Umesh Nerlige Ramappa wrote:
On Wed, May 15, 2024 at 02:42:56PM -0700, Lucas De Marchi wrote:
gt->info.engine_mask used to indicate the available engines, but that
is not always true
On 24.04.2024 18:34, Liviu Dudau wrote:
> Hello,
>
> On Tue, Apr 23, 2024 at 10:32:36PM +0100, Adrián Larumbe wrote:
> > When vm-binding an already-created BO, the entirety of its virtual size is
> > then backed by system memory, so its RSS is always the same as its virtual
> > size.
>
> How is
Hi Daniel,
On 02.05.2024 10:09, Daniel Vetter wrote:
> On Wed, May 01, 2024 at 07:50:43PM +0100, Adrián Larumbe wrote:
> > Up to this day, all fdinfo-based GPU profilers must traverse the entire
> > /proc directory structure to find open DRM clients with fdinfo file
> > descriptors. This is
On 5/17/2024 12:01 AM, Alex Deucher wrote:
On Thu, May 16, 2024 at 2:02 PM Linus Torvalds
wrote:
On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
Here is the buddy allocator fix I picked up from the list, please apply.
So I removed my reverts, and am running a kernel that includes the
From: Tim Van Patten
The following commit updated gmc->noretry from 0 to 1 for GC HW IP
9.3.0:
commit 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1")
This causes the device to hang when a page fault occurs, until the
device is rebooted. Instead, revert back to gmc->noretry=0 so
From: "Dr. David Alan Gilbert"
'gamma_curve_segment' looks like it has never been used.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 5 -
1 file changed, 5 deletions(-)
diff --git
On Thu, May 16, 2024 at 11:33:54AM GMT, Umesh Nerlige Ramappa wrote:
On Wed, May 15, 2024 at 02:42:56PM -0700, Lucas De Marchi wrote:
gt->info.engine_mask used to indicate the available engines, but that
is not always true anymore: some engines are reserved to kernel and some
may be exposed as
Applied. Thanks!
Alex
On Thu, May 16, 2024 at 3:46 PM Tim Van Patten wrote:
>
> From: Tim Van Patten
>
> The following commit updated gmc->noretry from 0 to 1 for GC HW IP
> 9.3.0:
>
> commit 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1")
>
> This causes the device to hang when
On Thu, May 16, 2024 at 8:18 AM Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Reduced re-spin of my previous series after Christian corrected a few
> misconceptions that I had. So lets see if what remains makes sense or is still
> misguided.
>
> To summarise, the series address the
On Wed, May 15, 2024 at 02:42:58PM -0700, Lucas De Marchi wrote:
Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:
1) loop through all the exec queues for the current client and
accumulate the runtime, per engine class.
On Wed, May 15, 2024 at 02:42:57PM -0700, Lucas De Marchi wrote:
Get the first available engine from a gt, which helps in the case any
engine serves as a context, like when reading RING_TIMESTAMP.
Signed-off-by: Lucas De Marchi
Reviewed-by: Umesh Nerlige Ramappa
---
On Thu, May 16, 2024 at 08:20:05PM GMT, Akhil P Oommen wrote:
> On Thu, May 16, 2024 at 08:15:34AM -0500, Andrew Halaney wrote:
> > On Wed, May 15, 2024 at 12:08:49AM GMT, Akhil P Oommen wrote:
> > > On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> > > > Memory barriers help ensure
On Wed, May 15, 2024 at 02:42:56PM -0700, Lucas De Marchi wrote:
gt->info.engine_mask used to indicate the available engines, but that
is not always true anymore: some engines are reserved to kernel and some
may be exposed as a single engine (e.g. with ccs_mode).
Runtime changes only happen
On Thu, May 16, 2024 at 2:02 PM Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
> >
> > Here is the buddy allocator fix I picked up from the list, please apply.
>
> So I removed my reverts, and am running a kernel that includes the
> merge 972a2543e3dd ("Merge tag
On Thu, 16 May 2024, Michal Wajdeczko wrote:
> There is no point in maintaining a separate print function, while
> there is __drm_dev_dbg() function that can work with a NULL device.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Jani Nikula
Reviewed-by: Jani Nikula
> ---
>
From: Ville Syrjälä
Make life easier for drivers by filtering out unwanted YCbCr 4:2:0
only modes prior to calling the connector->mode_valid() hook.
Currently drivers will still see YCbCr 4:2:0 only modes in said
hook, which will likely come as a suprise when the driver has
declared no support
On Wed, 15 May 2024 at 19:54, Dave Airlie wrote:
>
> Here is the buddy allocator fix I picked up from the list, please apply.
So I removed my reverts, and am running a kernel that includes the
merge 972a2543e3dd ("Merge tag 'drm-next-2024-05-16' of
https://gitlab.freedesktop.org/drm/kernel;) but
Am Freitag, dem 26.01.2024 um 17:46 +0100 schrieb Lucas Stach:
> The etnaviv devcoredump is created in the GPU reset path, which
> must make forward progress to avoid stalling memory reclaim on
> unsignalled dma fences. The currently used __GFP_NORETRY does not
> prohibit sleeping on direct
Am Donnerstag, dem 25.01.2024 um 12:07 +0100 schrieb Philipp Zabel:
> Turn the etnaviv_is_model_rev() macro into a static inline function.
> Use the raw model number as a parameter instead of the chipModel_GC
> defines. This reduces synchronization requirements for the generated
> headers. For
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 integrating the DW HDMI core.
Am Montag, dem 01.04.2024 um 12:26 +0200 schrieb Christian Gmeiner:
> >
> > Core in platform_driver_register() already sets the .owner, so driver
> > does not need to. Whatever is set here will be anyway overwritten by
> > main driver calling platform_driver_register().
> >
> > Signed-off-by:
Le jeudi 16 mai 2024 à 14:27 +0300, Laurent Pinchart a écrit :
> Hi Nicolas,
>
> On Wed, May 15, 2024 at 01:43:58PM -0400,
> nicolas.dufre...@collabora.corp-partner.google.com wrote:
> > Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > > > You'll hit the same limitation as we
On Thu, May 16, 2024 at 5:22 AM Maxime Ripard wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > I apologize as my worry is mostly born out of seeing vendors really
> > push opaque feature flags in their old ion heaps, so in providing a
> > flags argument, it was mostly
On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > But it makes me a little nervous to add a new generic allocation flag
> > for a feature most hardware doesn't support (yet, at least). So it's
> > hard to weigh how common the
-Original Message-
From: Das, Nirmoy
Sent: Thursday, May 16, 2024 8:14 AM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Das, Nirmoy ; Andi
Shyti ; Janusz Krzysztofik
; Cavitt, Jonathan
Subject: [PATCH] drm/i915/selftests: Set always_coherent to false when
Unfortunately, the G200 ioburst workaround doesn't work on some servers
like Dell poweredge XR11, XR5610, or HPE XL260
In this case completely disabling WC is the only option to achieve
low-latency.
It's probably useless to maintain two workarounds for this,
so I reverted commit bfa4437fd3938
This reverts commit bfa4437fd3938ae2e186e7664b2db65bb8775670.
This workaround doesn't work reliably on all servers.
I'll replace it with an option to disable Write-Combine,
which has more impact on performance, but fix the latency
issue on all hardware.
Signed-off-by: Jocelyn Falempe
---
Unfortunately, the G200 ioburst workaround doesn't work on some servers
like Dell poweredge XR11, XR5610, or HPE XL260
In this case completely disabling WC is the only option to achieve
low-latency.
So this adds a new Kconfig option, to disable WC mapping of the G200
Signed-off-by: Jocelyn
There is no point in maintaining a separate print function, while
there is __drm_dev_dbg() function that can work with a NULL device.
Signed-off-by: Michal Wajdeczko
Cc: Jani Nikula
---
drivers/gpu/drm/drm_print.c | 19 ---
include/drm/drm_print.h | 8 +++-
2 files
The pull request you sent on Thu, 16 May 2024 12:53:52 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-05-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/972a2543e3dd87f7310d65944b857631b4290e12
Thank you!
--
Deet-doot-dot, I am a bot.
The previous commit 'commit 8d4ba9fc1c6c ("drm/i915/selftests: Pick
correct caching mode.")' was not complete as for non LLC sharing platforms
cpu read can happen from LLC which probably doesn't have the latest
changes made by GPU.
Cc: Andi Shyti
Cc: Janusz Krzysztofik
Cc: Jonathan Cavitt
Hi,
On 5/16/24 5:11 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 16.05.24 um 17:03 schrieb Hans de Goede:
>> Hi,
>>
>> On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
>>> CC Hans who has been doing the majority of the ACPI video work.
>>>
>>> On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann
>>>
On Wed, May 15, 2024 at 07:22:22PM GMT, Oded Gabbay wrote:
Because I left Intel, I'm removing myself from the list
of Xe driver maintainers.
Signed-off-by: Oded Gabbay
Acked-by: Lucas De Marchi
thanks
Lucas De Marchi
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi
Am 16.05.24 um 17:03 schrieb Hans de Goede:
Hi,
On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
CC Hans who has been doing the majority of the ACPI video work.
On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
Hi,
On 5/16/24 14:26, Markus Elfring wrote:
…
fullfill the implement under the new framework.
fulfil the implementation?
Please improve your change descriptions another bit.
OK, despite has a few typos. but the quality of the patch itself
can be guaranteed. The first version is mainly
Hi,
On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
> CC Hans who has been doing the majority of the ACPI video work.
>
> On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
>>
>> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
>> renames the video source files under arch/
drm-misc-next-fixes-2024-05-16:
drm-misc-next-fixes for v6.10-rc1:
- VM_BIND fix for nouveau.
- Lots of panthor fixes:
* Fixes for panthor's heap logical block.
* Reset on unrecoverable fault
* Fix VM references.
* Reset fix.
- xlnx compile and doc fixes.
The following changes since
mtk_find_possible_crtcs() assumes that the main path will always have
the CRTC with id 0, the ext id 1 and the third id 2. This is only true
if the paths are all available. But paths are optional (see also
comment in mtk_drm_kms_init()), e.g. the main path might not be enabled
or available at all.
On Thu, May 16, 2024 at 4:12 AM Gregory Carter wrote:
>
> This problem on this particular machine can be avoided by using the kernel
> command line option amdgpu.mcbp=0
Something else must be going on. mcbp is disabled by default except
for SR-IOV virtual functions.
Alex
-Original Message-
From: Intel-xe On Behalf Of Lucas De
Marchi
Sent: Wednesday, May 15, 2024 2:43 PM
To: intel...@lists.freedesktop.org
Cc: Tvrtko Ursulin ; Nerlige Ramappa, Umesh
; dri-devel@lists.freedesktop.org; De Marchi,
Lucas
Subject: [PATCH v4 6/8] drm/xe: Cache data about
On Thu, May 16, 2024 at 08:15:34AM -0500, Andrew Halaney wrote:
> On Wed, May 15, 2024 at 12:08:49AM GMT, Akhil P Oommen wrote:
> > On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> > > Memory barriers help ensure instruction ordering, NOT time and order
> > > of actual write
Applied. Thanks!
On Thu, May 16, 2024 at 4:47 AM Jiapeng Chong
wrote:
>
> ./drivers/gpu/drm/amd/amdgpu/amdgpu.h: amdgpu_umsch_mm.h is included more
> than once.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9063
> Signed-off-by: Jiapeng Chong
> ---
>
On Thu, May 16, 2024, Dave Airlie wrote:
> On Thu, 16 May 2024 at 08:56, Linus Torvalds
> wrote:
> > If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
> > sets CONFIG_DRM_WERROR or not. It's a no-op. It's pointless.
+1
> It's also possible it's just that hey there's a few
On 5/8/2024 14:34, Jani Nikula wrote:
> On Wed, 08 May 2024, Farah Kassabri wrote:
>> On 4/29/2024 18:32, Lucas De Marchi wrote:
>>> On Mon, Apr 29, 2024 at 02:02:28PM GMT, Jani Nikula wrote:
On Wed, 24 Apr 2024, Farah Kassabri wrote:
> Add the last driver sha to the existing log
Hi,
On Thu, May 16, 2024 at 6:43 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, May 15, 2024 at 11:55 PM wrote:
> >
> > On 16/05/2024 08:43, cong yang wrote:
> > > Hi:
> > >
> > > If it is determined that a separately patch needs to be sent, then I
> > > will remove this patch in V8 series?
> > >
Hi,
On Wed, May 15, 2024 at 11:55 PM wrote:
>
> On 16/05/2024 08:43, cong yang wrote:
> > Hi:
> >
> > If it is determined that a separately patch needs to be sent, then I
> > will remove this patch in V8 series?
> >
> > Doug Anderson 于2024年5月16日周四 05:28写道：
> >
> >>
> >> Hi,
> >>
> >> On Wed,
On Thu, May 16, 2024 at 08:57:48AM GMT, Tvrtko Ursulin wrote:
On 15/05/2024 22:42, Lucas De Marchi wrote:
Print the accumulated runtime for client when printing fdinfo.
Each time a query is done it first does 2 things:
1) loop through all the exec queues for the current client and
Hi,
On Thu, May 16, 2024 at 12:21 AM Cong Yang
wrote:
>
> Discussion with Doug and Linus in V1, we need a
> separate driver to enable the hx83102 controller.
>
> So this series this series mainly Break out as separate driver
> for Starry-himax83102-j02 panels from boe tv101wum driver.
>
> Then
Apologies for missing v1 ...
On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote:
> DRM hotplug bridge driver
> =
>
> DRM natively supports pipelines whose display can be removed, but all the
> components preceding it (all the display controller and any bridges)
Thanks to the WRITE_LINE macro, adding the format XRGB210101010 is trivial.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 12
drivers/gpu/drm/vkms/vkms_writeback.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git
As stated in [2], the write_line functions are very similar and force code
duplication. This patch add a macro to avoid code repetition.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 107 ++
drivers/gpu/drm/vkms/vkms_writeback.c | 4
1]:
https://lore.kernel.org/all/20240516-b4-new-color-formats-v1-0-74cf9fe07...@bootlin.com/
Signed-off-by: Louis Chauvet
---
Louis Chauvet (3):
drm/vkms: Re-introduce line-by-line algorithm for writeback
drm/vkms: Add a macro for write_line functions
drm/vkms: Add support for X
Re-introduce a line-by-line writeback algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
write.
Line-by-line writeback was introduced by [1] but rewritten back to
pixel-by-pixel algorithm in [2]. At this time, nobody noticed the impact
on
The format RGB565 was already supported. Add the support for:
- BGR565
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 25 -
drivers/gpu/drm/vkms/vkms_plane.c | 1 +
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git
The formats XRGB16161616 and ARGB16161616 were already supported.
Add the support for:
- ABGR16161616
- XBGR16161616
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 ++-
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
Add the support for:
- RGB888
- BGR888
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 +++
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index
The callback functions for line conversion are almost identical for
some format. The generic READ_LINE macro generate all the required
boilerplate to process a line.
Two overrides of this macro have been added to avoid duplication of
the same arguments every time.
Signed-off-by: Louis Chauvet
.
This series must be applied on top of [1].
[1] https://lore.kernel.org/all/20240516-yuv-v8-0-cf8d6f864...@bootlin.com/
Signed-off-by: Louis Chauvet
---
Louis Chauvet (5):
drm/vkms: Create helpers macro to avoid code duplication in format
callbacks
drm/vkms: Add support for ARGB
The formats XRGB and ARGB were already supported.
Add the support for:
- XBGR
- RGBX
- BGRX
- ABGR
- RGBA
- BGRA
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 18 ++
drivers/gpu/drm/vkms/vkms_plane.c | 6 ++
2 files
On Wed, May 15, 2024 at 12:08:49AM GMT, Akhil P Oommen wrote:
> On Wed, May 08, 2024 at 07:46:31PM +0200, Konrad Dybcio wrote:
> > Memory barriers help ensure instruction ordering, NOT time and order
> > of actual write arrival at other observers (e.g. memory-mapped IP).
> > On architectures
From: Arthur Grillo
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts, updated the commit message]
Acked-by: Pekka Paalanen
Signed-off-by:
As all the rotation are now supported by VKMS, this simplification does
not make sense anymore, so remove it.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
From: Arthur Grillo
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/gpu/vkms.rst
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
-
This add the support for:
- R1/R2/R4/R8
R1 format was tested with [1] and [2].
[1]:
https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
[2]:
https://lore.kernel.org/igt-dev/20240306-b4-kms_tests-v1-0-8fe451efd...@bootlin.com/
Reviewed-by: Pekka Paalanen
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12/NV16/NV24
- NV21/NV61/NV42
- YUV420/YUV422/YUV444
- YVU420/YVU422/YVU444
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a
Re-introduce a line-by-line composition algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
read. This patch is focused on readability of the code.
Line-by-line composition was introduced by [1] but rewritten back to
pixel-by-pixel algorithm in
As the pixel_read and pixel_write function should never modify the input
buffer, mark those pointers const.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
drivers/gpu/drm/vkms/vkms_formats.c | 24
The pixel_read_direction enum is useful to describe the reading direction
in a plane. It avoids using the rotation property of DRM, which not
practical to know the direction of reading.
This patch also introduce two helpers, one to compute the
pixel_read_direction from the DRM rotation property,
The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
different concepts (coordinate calculation and color management), extract
the x_limit and x_dst computation outside of this helper.
It also increases the maintainability by grouping the computation related
to coordinates in the
Introduce the usage of block_h/block_w to compute the offset and the
pointer of a pixel. The previous implementation was specialized for
planes with block_h == block_w == 1. To avoid confusion and allow easier
implementation of tiled formats. It also remove the usage of the
deprecated format field
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Signed-off-by: Louis Chauvet
Acked-by: Pekka Paalanen
---
drivers/gpu/drm/vkms/vkms_composer.c | 7
drivers/gpu/drm/vkms/vkms_drv.h | 15 -
Introduce two callbacks which does nothing. They are used in replacement
of NULL and it avoid kernel OOPS if this NULL is called.
If those callback are used, it means that there is a mismatch between
what formats are announced by atomic_check and what is realy supported by
atomic_update.
Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
compiler to check if the passed functions take the correct arguments.
Such typedefs will help ensuring consistency across the code base in
case of update of these prototypes.
Rename input/output variable in a consistent way
Few no-op changes to remove double spaces and fix wrong alignments.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++
drivers/gpu/drm/vkms/vkms_drv.c
From: Arthur Grillo
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
Acked-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: Louis Chauvet
[Louis Chauvet: Applied review from Maíra]
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
During the development of this series Pekka and Arthur found an issue in
drm core. The YUV part of this series depend on the fix [9]. I'll let
Arthur extract it and
On Thu, May 16, 2024 at 4:42 AM Jani Nikula wrote:
>
> On Wed, 15 May 2024, Linus Torvalds wrote:
> > On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
> >> AMDGPU, I915 and XE all have !COMPILE_TEST on their variants
> >
> > Hmm. It turns out that I didn't notice the AMDGPU one because my
> >
CC Hans who has been doing the majority of the ACPI video work.
On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
>
> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
> renames the video source files under arch/ such that they does not
> refer to fbdev any longer. The
On Wed, May 15, 2024 at 04:45:09PM +0200, Javier Martinez Canillas wrote:
> 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
: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
patch link:
https://lore.kernel.org/r/20240515-dma-buf-ecc-heap-v1-7-54cbbd049511%40kernel.org
patch subject: [PATCH 7/8] dma-buf: heaps: cma: Handle ECC flags
config: mips-allmodconfig
(https://download.01.org/0day-ci/archive/20240516/202405162048.cexrv8yy
Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
renames the video source files under arch/ such that they does not
refer to fbdev any longer. The new files named video.o conflict with
ACPI's video.ko module. Modprobing the ACPI module can then fail with
warnings about missing
On Thu, May 16, 2024 at 12:56:27PM +0200, Daniel Vetter wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > > This series is the follow-up of the discussion that John and I had a few
> > > months ago here:
> > >
> > >
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also
Hi,
On 5/16/24 16:33, Jani Nikula wrote:
If WERROR is already enabled, there's no point in enabling DRM_WERROR or
asking users about it.
Reported-by: Linus Torvalds
Closes:
https://lore.kernel.org/r/CAHk-=whxT8D_0j=bjtrvj-O=veojn6gw8gk4j2v+biduntz...@mail.gmail.com
Fixes: f89632a9e5fa
On 16/05/2024 13:06, Aradhya Bhatia wrote:
Hi Liu,
Thanks for reviewing the patch.
On 16/05/24 07:49, Liu Ying wrote:
On 5/15/24 17: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'
On Thu, May 16, 2024 at 5:01 AM Liu Ying wrote:
>
> Commit f3d9683346d6 ("drm/bridge: adv7511: Allow IRQ to share GPIO pins")
> fails to consider the case where adv7511->i2c_main->irq is zero, i.e.,
> no interrupt requested at all.
Sorry about that.
>
> Without interrupt,
Hi John,
Thanks for your feedback
On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > This series is the follow-up of the discussion that John and I had a few
> > months ago here:
> >
> >
Need secure buffer size to convert secure handle to secure
pa in optee-os, re-construct the vsi struct to store each
secure buffer size.
Separate svp and normal wait interrupt condition for svp mode
waiting hardware interrupt in optee-os.
Signed-off-by: Yunfei Dong
---
Need to initialize msg and vsi information before sending to optee-os, then
calling optee invoke command to send the information to optee-os.
For the optee communication interface is different with scp, using
flag to separate them.
Signed-off-by: Yunfei Dong
---
The hardware can parse syntax to get nal_info, needn't to use cpu.
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_h264_req_multi_if.c| 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git
Allocate two share memory for each lat and core hardware used to share
information with optee-os. Msg buffer used to send ipi command and get ack
command with optee-os, data buffer used to store vsi information which
used for hardware decode.
Signed-off-by: Yunfei Dong
---
From: Xiaoyong Lu
Change av1 driver to support secure video playback(svp) for
mt8188. Need to map shared memory with optee interface and
wait interrupt in optee-os.
Signed-off-by: Xiaoyong Lu
Signed-off-by: Yunfei Dong
---
.../vcodec/decoder/vdec/vdec_av1_req_lat_if.c | 97
Adding capture formats to support V4L2_PIX_FMT_MS21. This format has
one plane and only be used for secure video playback at current period.
Signed-off-by: Yunfei Dong
---
.../platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c| 4 +++-
.../mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
1 - 100 of 188 matches
Mail list logo
