[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Thursday, October 20, 2022 10:36 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Deucher, Alexander ; Thomas
> Zimmermann
> Su
Hi Hans,
Thanks for you reply and useful suggestions.
The previous patch v3 may not fully modified. Now I push patch v4.
Please help to review it, thanks.
Thanks,
mingjia
On Wed, 2022-08-24 at 15:02 +0200, Hans Verkuil wrote:
> Hi Mingjia,
>
> On 27/07/2022 08:13, Mingjia Zhang wrote:
> > In o
* Arnd Bergmann [221019 15:11]:
> From: Arnd Bergmann
>
> A number of omap1 based board files got removed, so the corresponding
> framebuffer drivers are no longer used. The remaining ones are for
> ams_delta, osk and palmTE, which are still part of the mainline kernel.
Acked-by: Tony Lindgren
* Arnd Bergmann [221019 15:10]:
> From: Arnd Bergmann
>
> After the removal of the unused board files, I went through the
> omap1 code to look for code that no longer has any callers
> and remove that.
>
> In particular, support for the omap7xx/omap8xx family is now
> completely unused, so I'm
Title: "dependencies"
Regards,
Luben
On 2022-10-14 04:46, Christian König wrote:
> Entirely remove the sync obj in the job.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 21 ++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h | 2 ++
> driver
Title: "dependencies".
Regards,
Luben
On 2022-10-14 04:46, Christian König wrote:
> Instead of putting that into the job sync object.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
"dependencies" in the title.
The rest looks good. I like pulling that sync free code into its own function.
Regards,
Luben
On 2022-10-14 04:46, Christian König wrote:
> Instead of putting that into the job sync object.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdg
On 10/21/22 18:29, Neil Armstrong wrote:
> Hi,
>
> On 21/10/2022 17:02, Laurent Pinchart wrote:
>> Hi Matti,
>>
>> On Fri, Oct 21, 2022 at 04:18:01PM +0300, Matti Vaittinen wrote:
>>> Simplify using the devm_regulator_get_enable_optional(). Also drop the
>>> seemingly unused struct member 'hdmi_su
From: Xinlei Lee
Dpi output needs to adjust the output format to dual edge for MT8186.
Co-developed-by: Jitao Shi
Signed-off-by: Jitao Shi
Signed-off-by: Xinlei Lee
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: N??colas F. R. A. Prado
---
drivers/gpu/drm/mediate
From: Xinlei Lee
Add the compatible because use edge_cfg_in_mmsys in mt8186.
Signed-off-by: Xinlei Lee
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: N??colas F. R. A. Prado
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +
drivers/gpu/drm/medi
From: Xinlei Lee
The difference between MT8186 and other ICs is that when modifying the
output format, we need to modify the mmsys_base+0x400 register to take
effect. So when setting the dpi output format, we need to call
mtk_mmsys_ddp_dpi_fmt_config to set it to MT8186 synchronously.
Commit
From: Xinlei Lee
Base on the branch of linus/master v6.1 rc1.
Change since v12:
1. Add MT8186_ prefix to variables added in mt8186-mmsys.h file.
Change since v11:
1. Rebase on v6.1-rc1. Change nothing.
Change since v10:
1. Modify patch title and add review tag.
Change since v9:
1. Modify the
Felix Kuehling writes:
> On 2022-10-20 19:17, Dan Williams wrote:
>> Felix Kuehling wrote:
>>> Am 2022-10-20 um 17:56 schrieb Dan Williams:
For now this only converts the callers to lookup the pgmap and generate
the pgmap offset, but it does not do the deeper cleanup of teaching
Please also add a
Cc: # 6.0.x
to ensure it gets backported.
On Fri, Oct 21, 2022 at 9:24 AM Joaquín Ignacio Aramendía
wrote:
>
> This file was split in commit 5d945cbcd4b16a29d6470a80dfb19738f9a4319f
> ("drm/amd/display: Create a file dedicated to planes") and the logic in
> dm_plane_format_mo
Hello,
On 10/21/22 00:33, Dmitry Osipenko wrote:
> The drm_client_buffer_delete() wasn't switched to unlocked GEM vunmapping
> by accident when rest of drm_client code transitioned to the unlocked
> variants of the vmapping functions. Make drm_client_buffer_delete() use
> the unlocked variant. Thi
lcdsel_grf_reg is defined as u32, so "< 0" comaprison is always false,
which breaks VOP selection on eg. RK3399. Compare against 0.
Fixes: f3aaa6125b6f ("drm/rockchip: dsi: add rk3568 support")
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 4 +---
1 file chan
On Sun, Oct 23, 2022 at 09:02:49PM +0700, Bagas Sanjaya wrote:
> On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote:
> > In the last couple of months we had a discussion [1] about creating a new
> > subsystem for compute accelerator devices in the kernel.
> >
> > After an analysis that wa
On Sun, Oct 23, 2022 at 12:46:19AM +0300, Oded Gabbay wrote:
> In the last couple of months we had a discussion [1] about creating a new
> subsystem for compute accelerator devices in the kernel.
>
> After an analysis that was done by DRM maintainers and myself, and following
> a BOF session at th
[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to
On Sun, Oct 23, 2022 at 12:46:22AM +0300, Oded Gabbay wrote:
> +/**
> + * accel_open - open method for ACCEL file
> + * @inode: device inode
> + * @filp: file pointer.
> + *
> + * This function must be used by drivers as their &file_operations.open
> method.
> + * It looks up the correct ACCEL dev
On Sun, Oct 23, 2022 at 12:46:20AM +0300, Oded Gabbay wrote:
> Add a new Kconfig for the accel subsystem. The Kconfig currently
> contains only the basic CONFIG_ACCEL option that will be used to
> decide whether to compile the accel registration code as part of the
> drm core functionality.
>
> I
On Sun, Oct 23, 2022 at 12:46:21AM +0300, Oded Gabbay wrote:
> The accelerator devices will be exposed to the user space with a new,
> dedicated major number - 261.
>
> The drm core registers the new major number as a char device and create
> corresponding sysfs and debugfs root entries, same as f
I can't speak to why you are experiencing issues when using the GPU,
but in the examples you gave, the example that is working is using a
SW based GL implementation instead of the real GPU. This can be
determined by looking at the GL_RENDERER string to see if it mentions
a Vivante GPU or something
Hi, this is your Linux kernel regression tracker speaking.
I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it by
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216616 :
> Andreas 2022-10-22 14:2
24 matches
Mail list logo
