-misc-next
patch link:
https://lore.kernel.org/r/20241004152429.4329-1-gonzalo.silvalde%40gmail.com
patch subject: [PATCH v2] fbdev: sstfb: Make CONFIG_FB_DEVICE optional
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20241007/202410072022.orquf7dt-...@intel.com/config)
compil
On Mon, Oct 7, 2024, at 11:40, Niklas Schnelle wrote:
> 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 su
Hi
Am 04.10.24 um 12:01 schrieb Ville Syrjälä:
On Fri, Oct 04, 2024 at 11:17:02AM +0200, Thomas Zimmermann wrote:
Hi
Am 02.10.24 um 18:15 schrieb Luck, Tony:
Thanks for the bug report. Can you provide the output of 'sudo lspci
-vvv' for the graphics device?
Thomas,
Sure. Here's the output (
Hi Vignesh,
On Fri, 4 Oct 2024 at 09:31, Vignesh Raman wrote:
> +.software-driver:
> + stage: software-driver
> + extends:
> +- .test-gl
> +- .test-rules
> + timeout: "1h30m"
> + tags:
> +- kvm
> + script:
> +- ln -sf $CI_PROJECT_DIR/install /install
> +- mv install/bzIma
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/dma after the previous
conversion commits apart from the wireless drivers to use .remove(),
with
The formats NV 12/16/24/21/61/42 were already supported.
Add support for:
- P010
- P012
- P016
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 ++-
drivers/gpu/drm/vkms/vkms_plane.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/
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 a/drivers/gpu/drm/v
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 e34
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Add support for the YUV format P010
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 3 ++-
drivers/gpu/drm/vkms/vkms_formats.c | 22
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
The callback functions for line conversion are almost identical for
semi-planar formats. The generic READ_LINE_YUV_SEMIPLANAR macro
generate all the required boilerplate to process a line from a
semi-planar format.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 75 +++
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
--
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 | 11 ---
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 10 insertions(+), 3 deletions(
| 14 ++
4 files changed, 195 insertions(+), 146 deletions(-)
---
base-commit: 82fe69e63d2b5a5e86ea94c7361c833d3848ab69
change-id: 20240312-b4-new-color-formats-1be9d688b21a
prerequisite-message-id: <20241007-yuv-v12-0-01c1ada6f...@bootlin.com>
prerequisite-pa
On Mon, Oct 07, 2024 at 02:50:11PM +, Arnd Bergmann wrote:
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/q
_ABGR to integrate it (with your signed-off-by
obviously)?
In any case, if you have time to test, or even better review [1], [2] or
[3], it could be amazing!
Thank you,
Louis Chauvet
[1]:https://lore.kernel.org/all/20241007-yuv-v12-0-01c1ada6f...@bootlin.com/
[2]:https://lore.kernel.org/all/202
On 10/4/24 10:02, Maíra Canal wrote:
When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address
052004a4
[ 55.008368] Mem abort info:
[ 55.0083
On 10/4/24 09:36, Maíra Canal wrote:
Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.
If we open a new file descr
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]
Signed-off-by
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 betw
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
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 | 20 ++--
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, an
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 subm
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
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 b/Documentati
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)
- c
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 [
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
Signed-off-by
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 sa
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
b/drivers/
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 spec
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: Louis
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 b/Documentation/gpu/vkms.
m/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20241004152429.4329-1-gonzalo.silvalde%40gmail.com
patch subject: [PATCH v2] fbdev: sstfb: Make CONFIG_FB_DEVICE optional
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20241007/202410071957.gjrykfof-...@intel.
Am 07.10.24 um 14:58 schrieb Lee Jones:
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 revision integrating Ar
On 10/6/2024 10:15 PM, Lizhi Hou wrote:
On 10/4/24 10:34, Jeffrey Hugo wrote:
On 9/11/2024 12:05 PM, Lizhi Hou wrote:
+struct create_ctx_req {
+ __u32 aie_type;
+ __u8 start_col;
+ __u8 num_col;
+ __u16 reserved;
+ __u8 num_cq_pairs_requested;
+ __u8 reserve
On 10/6/2024 11:02 PM, Lizhi Hou wrote:
On 10/4/24 10:50, Jeffrey Hugo wrote:
On 9/11/2024 12:05 PM, Lizhi Hou wrote:
diff --git a/drivers/accel/amdxdna/aie2_ctx.c
b/drivers/accel/amdxdna/aie2_ctx.c
new file mode 100644
index ..52a71661f887
--- /dev/null
+++ b/drivers/accel/amdxdn
…
> premultiplied supported in current platform.
…
format would be?
Regards,
Markus
On 10/4/24 09:35, Maíra Canal wrote:
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
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 6 +-
1 file changed, 1 inse
This is a different issue related to the radeon ttm to gem conversion.
@Christian Koenig is working on the fix.
Alex
On Mon, Oct 7, 2024 at 4:23 AM Christophe Leroy
wrote:
>
>
>
> Le 06/10/2024 à 18:56, Christian Zigotzky a écrit :
> > On 03 October 2024 at 08:06 am, Wu Hoi Pok wrote:
> >> This
On Sat, Oct 05, 2024 at 05:08:53PM +0100, Adrián Larumbe wrote:
> Rearrange lookup of recommended OPP for the Mali GPU device and its refcnt
> decremental to make sure no OPP object leaks happen in the error path.
>
> Signed-off-by: Adrián Larumbe
> Fixes: fac9b22df4b1 ("drm/panthor: Add the devf
On Mon, Oct 07, 2024 at 01:01:48AM GMT, Jonathan Marek wrote:
> drm_mode_vrefresh() can introduce a large rounding error, avoid it.
>
> Fixes: 7c9e4a554d4a ("drm/msm/dsi: Reduce pclk rate for compression")
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
> 1 fil
On Mon, Oct 07, 2024 at 01:01:49AM GMT, Jonathan Marek wrote:
> When (mode->clock * 1000) is larger than (1<<31), int to unsigned long
> conversion will sign extend the int to 64 bits and the pclk_rate value
> will be incorrect.
>
> Fix this by making the result of the multiplication unsigned.
>
On Mon, Oct 07, 2024 at 02:15:14PM GMT, Ekansh Gupta wrote:
> This patch series adds the listed features that have been missing
> in upstream fastRPC driver.
please use sensible subject for the cover letter too. Ideally it should
start with the corresponding subsys name or otherwise point out the
Am 04.10.24 um 16:46 schrieb Ilpo Järvinen:
On Fri, 4 Oct 2024, Werner Sembach wrote:
Am 03.10.24 um 12:54 schrieb Ilpo Järvinen:
On Wed, 2 Oct 2024, Werner Sembach wrote:
Am 02.10.24 um 11:52 schrieb Ilpo Järvinen:
On Tue, 1 Oct 2024, Werner Sembach wrote:
The TUXEDO Sirius 16 Gen1 and T
On Sun, Oct 6, 2024 at 6:31 AM kernel test robot wrote:
>
> Hi Vamsi,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on 7ec462100ef9142344ddbf86f2c3008b97acddbe]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Vamsi-Krishna-Brahmajosyula/gpu-drm-
atmel_hlcdc_plane_update_buffers: may use an uninitialized
sr variable when the if condition remains unsatisfied.
The variable may contain an arbitrary value left from earlier computations.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202409240320.m
…
> Make the constatnt alpha only enable when having a vliad blend_mode or
…
Another wording suggestion:
Enable the constant alpha channel only when having a valid blending mode?
…
> Signed-off-by: Jason-JH.Lin
Does a dot really belong to this personal name?
https://git.kernel.org/pub/scm/linu
Am 05.10.24 um 09:05 schrieb Advait Dhamorikar:
Hi Sathish,
Please collate the changes together with Lijo's suggestion as well,
"1ULL <<" instead of typecast, there are 3 occurrences of the error in
f0b19b84d391.
I could only observe two instances of this error in f0b19b84d391 at:
'mask = (1 <
On Mon, Oct 07, 2024 at 03:28:22PM +0300, Yonatan Maman wrote:
>
>
> On 30/09/2024 14:20, Danilo Krummrich wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, Sep 23, 2024 at 01:54:58PM +, Yonatan Maman wrote:
> > > A copy push command might fail, causing
On Mon, Oct 07, 2024 at 04:26:59PM +0300, Yonatan Maman wrote:
> From: Yonatan Maman
>
> When `nouveau_dmem_copy_one` is called, the following error occurs:
>
> [272146.675156] nouveau :06:00.0: fifo: PBDMA9: 0004 [HCE_PRIV]
> ch 1 0300 3386
>
> This indicates that a copy push c
On Mon, Oct 07, 2024 at 02:15:15PM GMT, Ekansh Gupta wrote:
> 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
On Mon, Oct 07, 2024 at 07:53:26PM +0200, Christian König wrote:
> 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.
W
Hi,
Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
On Oct 01 2024, Werner Sembach wrote:
Hi Benjamin,
Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
[...]
PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
all of the requirements here:
- need to be dynamic
- still uns
On 10/7/24 7:01 PM, Isaac Scott wrote:
Hi Marek,
Hi,
On Sat, 2024-07-06 at 02:16 +0200, Marek Vasut wrote:
On 6/24/24 11:19 AM, Alexander Stein wrote:
Am Freitag, 31. Mai 2024, 22:27:21 CEST schrieb Marek Vasut:
In case an upstream bridge modified the required clock frequency
in its .atomi
Hi Marek
On Mon, 7 Oct 2024 at 12:59, Marek Szyprowski wrote:
>
> 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
Am 07.10.24 um 19:59 schrieb Greg KH:
On Mon, Oct 07, 2024 at 07:53:26PM +0200, Christian König wrote:
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
Hi Biju,
Thank you for the patch.
On Sat, Oct 05, 2024 at 04:37:31PM +0100, Biju Das wrote:
> As per the RZ/G2UL hardware manual Table 33.4 Clock List, the maximum
> dot clock for the DPI interface is 83.5 MHz. Add mode_valid callback
> to reject modes greater than 83.5 MHz.
>
> Signed-off-by: B
Hi Ulf,
On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> On Fri, 4 Oct 2024 at 11:41, Sakari Ailus
> wrote:
> >
> > Hello everyone,
> >
> > This set will switch the users of pm_runtime_put_autosuspend() to
> > __pm_runtime_put_autosuspend() while the former will soon be re-purposed
On Mon, 7 Oct 2024, Niklas Schnelle wrote:
> diff --git a/drivers/tty/serial/8250/8250_pci.c
> b/drivers/tty/serial/8250/8250_pci.c
> index
> 6709b6a5f3011db38acc58dc7223158fe4fcf72e..6a638feb44e443a1998980dd037748f227ec1bc8
> 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tt
, kindly drop us a note.
And when submitting 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/Ekansh-Gupta/misc-fastrpc-Add-CRC-support-using-invokeV2-request/20241007-1
us a note.
And when submitting 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/Ekansh-Gupta/misc-fastrpc-Add-CRC-support-using-invokeV2-request/20241007-164734
ba
us a note.
And when submitting 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/Ekansh-Gupta/misc-fastrpc-Add-CRC-support-using-invokeV2-request/20241007-164734
ba
Hi Christian,
I am not sure if I correctly understood what you meant, just to clarify
When you say this
>No, all of this are numerical problems where not taken into account the
>size of the destination type.
>Saying that all of that are basically just style cleanups which doesn't
>need to be ba
Simona Vetter writes:
> On Wed, Sep 25, 2024 at 01:44:37PM +0200, Simona Vetter wrote:
>> On Tue, Sep 24, 2024 at 04:42:19PM +, Matthew Brost wrote:
>> > On Tue, Sep 24, 2024 at 01:48:29PM +0200, Simona Vetter wrote:
>> > > On Fri, Sep 20, 2024 at 09:59:51PM +, Matthew Brost wrote:
>> >
Add support for the monochrome Sharp Memory LCDs.
Co-developed-by: Mehdi Djait
Signed-off-by: Mehdi Djait
Signed-off-by: Alex Lanzano
Reviewed-by: Dmitry Baryshkov
---
MAINTAINERS | 6 +
drivers/gpu/drm/tiny/Kconfig| 20 +
drivers/gpu/drm/tiny/Makefile
Add device tree bindings for the monochrome Sharp Memory LCD
Co-developed-by: Mehdi Djait
Signed-off-by: Mehdi Djait
Signed-off-by: Alex Lanzano
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/display/sharp,ls010b7dh04.yaml | 92 +++
1 file changed, 92 insertions(+)
creat
This patch series add support for the monochrome Sharp Memory LCD
panels. This series is based off of the work done by Mehdi Djait.
References:
https://lore.kernel.org/dri-devel/71a9dbf4609dbba46026a31f60261830163a0b99.1701267411.git.mehdi.dj...@bootlin.com/
https://www.sharpsde.com/fileadmin/prod
On Mon, Oct 7, 2024 at 3:01 PM Jason-JH.Lin wrote:
>
> 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
Hi Ulf,
On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus wrote:
> > > >
> > > > Hello everyone,
> > > >
> > > > This s
On Tue, 8 Oct 2024 at 00:25, Laurent Pinchart
wrote:
>
> Hi Ulf,
>
> On Tue, Oct 08, 2024 at 12:08:24AM +0200, Ulf Hansson wrote:
> > On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart wrote:
> > > On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > > > On Fri, 4 Oct 2024 at 11:41, Sakari
On 10/4/24 10:56, Jeffrey Hugo wrote:
On 9/11/2024 12:05 PM, Lizhi Hou wrote:
+/**
+ * struct amdxdna_drm_create_bo - Create a buffer object.
+ * @flags: Buffer flags. MBZ.
+ * @type: Buffer type.
+ * @pad1: MBZ.
+ * @vaddr: User VA of buffer if applied. MBZ.
+ * @size: Size in bytes.
+ * @han
On 10/4/24 11:01, Jeffrey Hugo wrote:
On 9/11/2024 12:06 PM, Lizhi Hou wrote:
+enum amdxdna_cmd_type {
+ AMDXDNA_CMD_SUBMIT_EXEC_BUF = 0,
+ AMDXDNA_CMD_SUBMIT_DEPENDENCY,
+ AMDXDNA_CMD_SUBMIT_SIGNAL,
+};
+
+/**
+ * struct amdxdna_drm_exec_cmd - Execute command.
+ * @ext: MBZ.
+ * @ext
Hi Uwe,
On 10/7/24 18:35, Uwe Kleine-König wrote:
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/dma after the previous
conversion commits ap
Hi,
On Mon, Oct 7, 2024 at 1:14 PM Aleksandrs Vinarskis
wrote:
>
> Introduce low-res IPS and OLED panels for mentioned device.
>
> SHP panel's timings were picked experimentally, without this patch or with
> `delay_200_500_e50` panel sometimes fails to boot/stays black on startup.
>
> LGD panel's
On Mon, 7 Oct 2024 at 20:49, Laurent Pinchart
wrote:
>
> Hi Ulf,
>
> On Fri, Oct 04, 2024 at 04:38:36PM +0200, Ulf Hansson wrote:
> > On Fri, 4 Oct 2024 at 11:41, Sakari Ailus
> > wrote:
> > >
> > > Hello everyone,
> > >
> > > This set will switch the users of pm_runtime_put_autosuspend() to
> >
On 07/10/24 8:39 pm, Advait Dhamorikar wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> atmel_hlcdc_plane_update_buffers: may use an uninitialized
> sr variable when the if condition remains unsatisfied.
> The variable may contain an arbitr
On Tue, Oct 08, 2024 at 12:33:51PM +1100, Alistair Popple wrote:
>
> Simona Vetter writes:
>
> > On Wed, Sep 25, 2024 at 01:44:37PM +0200, Simona Vetter wrote:
> >> On Tue, Sep 24, 2024 at 04:42:19PM +, Matthew Brost wrote:
> >> > On Tue, Sep 24, 2024 at 01:48:29PM +0200, Simona Vetter wrote
On 10/4/24 11:08, Jeffrey Hugo wrote:
On 9/11/2024 12:06 PM, Lizhi Hou wrote:
+static int amdxdna_rpmops_suspend(struct device *dev)
+{
+ struct amdxdna_dev *xdna = pci_get_drvdata(to_pci_dev(dev));
+ int ret;
+
+ mutex_lock(&xdna->dev_lock);
+ WARN_ON(!list_empty(&xdna->client_lis
Hi Sasha,
Am 04.10.24 um 20:17 schrieb Sasha Levin:
From: Christian König
[ Upstream commit 7181faaa4703705939580abffaf9cb5d6b50dbb7 ]
This was only used as workaround for recovering the page tables after
VRAM was lost and is no longer necessary after the function
amdgpu_vm_bo_reset_state_mac
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 v10:
1. Fix
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
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_
OVL_CON_AEN is for alpha blending enable.
For the SoC that is supported the blend_modes, OVL_CON_AEN will always
enabled to use constant alpha and then use the ignore_pixel_alpha bit
to do the alpha blending for XRGB format.
Note that ignore pixel alpha bit is not supported if the SoC is not
su
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
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
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +-
1 file changed, 9 inse
On Tue, Oct 8, 2024 at 2:47 PM Jason-JH.Lin wrote:
>
> 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
Am 08.10.24 um 05:38 schrieb Advait Dhamorikar:
Hi Christian,
I am not sure if I correctly understood what you meant, just to clarify
When you say this
No, all of this are numerical problems where not taken into account the
size of the destination type.
Saying that all of that are basically j
On Tue, Oct 08, 2024 at 08:30:40AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 07.10.24 um 18:35 schrieb Uwe Kleine-König:
> > After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
> > return void") .remove() is (again) the right callback to implement for
> > platform drivers.
> >
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/panthor.rst:10: WARNING: duplicate label
panfrost-usage-stats, other instance in Documentation/gpu/panfrost.rst
Introduced by commit
6a797bdfde77 ("drm/panthor: add sysfs kno
Hi
Am 07.10.24 um 18:35 schrieb Uwe Kleine-König:
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/dma after the previous
conversion commits ap
101 - 196 of 196 matches
Mail list logo
