tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e2425464bc87159274879ab30f9d4fe624b9fcd2 Add linux-next specific
files for 20240105
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202401061458.1ympozgi-...@intel.com
Error
[Public]
Hi Dan Carpenter,
This was fixed in
https://patchwork.freedesktop.org/patch/573477/?series=128249=1
Thank you!
Regards,
Srini
-Original Message-
From: amd-gfx On Behalf Of Dan Carpenter
Sent: Friday, January 5, 2024 7:04 PM
To: Lee, Peyton
Cc:
Remove the @funcs entry from struct drm_vram_mm to quieten the kernel-doc
warning.
Use the "define" kernel-doc keyword and an '\' line continuation
to fix another kernel-doc warning.
drm_gem_vram_helper.h:129: warning: missing initial short description on line:
* DRM_GEM_VRAM_PLANE_HELPER_FUNCS
Quieten an "Excess struct member" kernel-doc warning by removing
the extraneous line.
drm_dp_mst_helper.h:156: warning: Excess struct member 'vcpi' description in
'drm_dp_mst_port'
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Maarten
drm_gem_vram_helper.h:129: warning: missing initial short description on line:
* DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs' description in
'drm_vram_mm'
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc:
Hi Jocelyn,
kernel test robot noticed the following build errors:
[auto build test ERROR on 50a3c772bd927dd409c484832ddd9f6bf00b7389]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-format-helper-Add-drm_fb_blit_from_r1-and-drm_fb_fill/20240105-001038
base
Hi Adam,
Thanks for moving this forward.
On Fri, Jan 5, 2024 at 10:56 PM Adam Ford wrote:
>
> From: Lucas Stach
>
> Add binding for the i.MX8MP HDMI parallel video interface block.
>
> Signed-off-by: Lucas Stach
> Reviewed-by: Laurent Pinchart
> Reviewed-by: Conor Dooley
You missed your
From: Lucas Stach
This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
full timing generator and can switch between different video sources. On
the i.MX8MP however the only supported source is the LCDIF. The block
just needs to be powered up and told about the polarity of
From: Lucas Stach
Add binding for the i.MX8MP HDMI parallel video interface block.
Signed-off-by: Lucas Stach
Reviewed-by: Laurent Pinchart
Reviewed-by: Conor Dooley
---
V5: I tried to help move this along, so I took Lucas' patch and
attempted to apply fixes based on feedback. I
On Fri, 5 Jan 2024 at 16:29, Luca Weiss wrote:
>
> Add support for the 2340x1080 LCD DJN panel bundled with a HX83112A
> driver IC, as found on the Fairphone 4 smartphone.
>
> Signed-off-by: Luca Weiss
> ---
> drivers/gpu/drm/panel/Kconfig| 9 +
>
On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip wrote:
>
>
> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> > For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
> > possible to support this platform via the DPU driver (e.g. to provide
> > support for DP, multirect, etc). Add a
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms
We have several reports of vblank timeout messages. However after some
debugging it was found that there might be different causes to that.
Include the actual CTL_FLUSH value into the timeout message. This allows
us to identify the DPU block that gets stuck.
Signed-off-by: Dmitry Baryshkov
---
Bring in hardware support for the SDM660 and SDM630 platforms, which
belong to the same DPU generation as MSM8998.
Note, by default these platforms are still handled by the MDP5 driver
unless the `msm.prefer_mdp5=false' parameter is provided.
Co-developed-by: Konrad Dybcio
Signed-off-by: Konrad
For some of the platforms (e.g. SDM660, SDM630, MSM8996, etc.) it is
possible to support this platform via the DPU driver (e.g. to provide
support for DP, multirect, etc). Add a modparam to be able to switch
between these two drivers.
All platforms supported by both drivers are by default handled
Older (mdp5) platforms do not use per-SoC compatible strings. Instead
they use a single compat entry 'qcom,mdss'. To facilitate migrating
these platforms to the DPU driver provide a way to generate the MDSS /
UBWC data at runtime, when the DPU driver asks for it.
It is not possible to generate
Existing MDP5 devices have slightly different bindings. The main
register region is called `mdp_phys' instead of `mdp'. Also vbif
register regions are a part of the parent, MDSS device. Add support for
handling this binding differences.
Signed-off-by: Dmitry Baryshkov
---
: 39676dfe52331dba909c617f213fdb21015c8d10
change-id: 20240105-fd-migrate-mdp5-6a2aa51bc83b
Best regards,
--
Dmitry Baryshkov
Hello,
I'm currently trying to patch the DRM system to expose min_vfreq and max_vfreq.
This is useful information for game engines. I am trying to expose it
to SDL3: https://github.com/libsdl-org/SDL/issues/8772
I am aware of the DebugFS implementation however this requires debugFS and root.
On 1/5/2024 3:22 AM, Jacek Lawrynowicz wrote:
Imported buffer from another VPU context will now have just reference
increased and there will be a single sgt fixing above problem but
buffers still can't be shared among VPU contexts because each context
have its own MMU mapping and ivpu_bo
Hi Dave, Sima,
Few fixes for 6.8 from the last few weeks.
The following changes since commit 669080888691c312cc926322a7b24600121c90fb:
drm/amd/display: Revert " drm/amd/display: Use channel_width = 2 for vram
table 3.0" (2023-12-15 12:17:19 -0500)
are available in the Git repository at:
smatch warnings:
amdgpu_dm_update_plane_color_mgmt() warn: inconsistent indenting
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202401051643.ppdbmg1u-...@intel.com/
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 2 +-
1
Ping on this series again?
Alex
On Wed, Dec 13, 2023 at 4:13 PM Alex Deucher wrote:
>
> On Thu, Dec 7, 2023 at 1:03 PM Alex Deucher wrote:
> >
> > We had a request to add shared buffer stats to fdinfo for amdgpu and
> > while implementing that, Christian mentioned that just looking at
> > the
The pull request you sent on Fri, 5 Jan 2024 13:31:53 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2024-01-05
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2b5bd1498da5537e3d130b3862bccdd9aedd6c84
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 5 Jan 2024 19:40:06 +0200, Cristian Ciocaltea wrote:
> Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
> introduced a variable which ended up being unused:
>
> rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not
> used [-Wunused-but-set-variable]
On Fri, Jan 05, 2024 at 03:20:22PM +0300, Dan Carpenter wrote:
> Drop the ">lock" before returning.
>
> Fixes: 24f947d58fe5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted
> objects")
> Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/xe/xe_vm.c | 7
On Fri, Jan 05, 2024 at 03:22:23PM +0300, Dan Carpenter wrote:
> This error path should clean up before returning.
>
> Smatch detected this bug:
> drivers/gpu/drm/xe/xe_device.c:487 xe_device_probe() warn: missing unwind
> goto?
>
> Fixes: 4cb12b71923b ("drm/xe/xe2: Determine bios enablement
On Fri, Jan 05, 2024 at 03:20:35PM +0300, Dan Carpenter wrote:
> Check if "bo" is an error pointer before calling xe_bo_lock() on it.
>
> Fixes: d6abc18d6693 ("drm/xe/xe2: Modify xe_bo_test for system memory")
> Signed-off-by: Dan Carpenter
Reviewed-by: Matthew Brost
> ---
>
Javier Martinez Canillas writes:
> The helper is generic, it doesn't use the opaque EDID type struct drm_edid
> and is also used by drivers that only support non-probeable displays such
> as fixed panels.
>
> These drivers add a list of modes using drm_mode_probed_add() and then set
> a
On 1/4/2024 12:34, Daniele Ceraolo Spurio wrote:
On 1/2/2024 2:22 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A failure to load the HuC is occasionally observed where the cause is
believed to be a low GT frequency leading to very long load times.
So a) increase the timeout so
On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> This series allow user space to notify KVM of noncoherent DMA status so as
> to let KVM honor guest memory types in specified memory slot ranges.
>
> Motivation
> ===
> A virtio GPU device may want to configure GPU hardware to work in
>
> Date: Tue, 11 Apr 2023 14:36:36 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5)
> amdgpu: Move a variable assignment behind a null pointer check in
> amdgpu_ras_interrupt_dispatch()
> display: Move three variable
On Fri, Jan 05, 2024 at 06:22:18PM +0100, Philipp Stanner wrote:
> Some drivers want to use (request) a region exclusively but nevertheless
> create several mappings within that region.
>
> Currently, there is no managed devres function to request a region
> without mapping it.
>
> Add the
On Thu, Jan 4, 2024 at 9:42 AM Dario Binacchi
wrote:
> The initialization commands are taken from the STMicroelectronics driver
> found at [1].
> To ensure backward compatibility, flags have been added to enable gamma
> correction setting and display control. In other cases, registers have
>
On Thu, Jan 4, 2024 at 9:42 AM Dario Binacchi
wrote:
> This patch, preparatory for future developments, move the hardwired
> parameters to configuration data to allow the addition of new
> NT35510-based panels.
>
> Signed-off-by: Dario Binacchi
I tested this patch on the NT35510-based Skomer
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Co-developed-by: Boris Brezillon
Signed-off-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 4 +-
drivers/gpu/drm/panfrost/Makefile | 1 -
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest
Turn sanity warnings about DRM-SHMEM API misuse into a error conditions
for cases where imported GEM is used when it shouldn't be used.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Prepare to addition of memory shrinker support by pinning display
framebuffer BO pages in memory while they are in use by display on host.
Shrinker is free to relocate framebuffer BO pages if it doesn't know that
pages are in use, thus pin the pages to disallow shrinker to move them.
Acked-by:
Prepare for addition of memory shrinker support by attaching shmem pages
to host dynamically on first use. Previously the attachment vq command
wasn't fenced and there was no vq kick made in the BO creation code path,
hence the attachment already was happening dynamically, but implicitly.
Making
Don't free shmem object if it has pages that are in use at the time of
the GEM's freeing if DRM driver doesn't manage GEM/pages lifetime properly.
This prevents memory corruption due to the use-after-free bug in exchange
to leaking GEM.
Signed-off-by: Dmitry Osipenko
---
SGT isn't refcounted. Once SGT pointer has been obtained, it remains the
same for both locked and unlocked get_pages_sgt(). Return cached SGT
directly without taking a potentially expensive lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 12
1 file
Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
shrinker during GEM swap-in operation done under the held reservation lock.
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 22 +-
In a preparation to addition of drm-shmem memory shrinker support, change
the SGT allocation policy in this way:
1. SGT can be allocated only if shmem pages are pinned at the
time of allocation, otherwise allocation fails.
2. Drivers must ensure that pages are pinned during the time of SGT usage
Introduce common drm-shmem shrinker for DRM drivers.
To start using drm-shmem shrinker drivers should do the following:
1. Implement evict() callback of GEM object where driver should check
whether object is purgeable or evictable using drm-shmem helpers and
perform the shrinking action
We're moving away from implicit get_pages() that is done by
get_pages_sgt() to simplify the refcnt handling. Drivers will have
to pin pages while they use sgt. VirtIO-GPU doesn't support shrinker,
hence pages are pinned and sgt is valid as long as pages' use-count > 0.
Reviewed-by: Boris
To simplify the drm-shmem refcnt handling, we're moving away from
the implicit get_pages() that is used by get_pages_sgt(). From now on
drivers will have to pin pages while they use sgt. V3D driver doesn't
support shrinker, hence pages are pinned and sgt is valid as long as
pages' use-count > 0.
We're going to move away from having implicit get_pages() done by
get_pages_sgt() to simplify refcnt handling. Drivers will manage
get/put_pages() by themselves. Expose the drm_gem_shmem_get_pages()
in a public drm-shmem API.
Signed-off-by: Dmitry Osipenko
---
To simplify the drm-shmem refcnt handling, we're moving away from
the implicit get_pages() that is used by get_pages_sgt(). From now on
drivers will have to pin pages while they use sgt. Panfrost's shrinker
doesn't support swapping out BOs, hence pages are pinned and sgt is valid
as long as pages'
From: Boris Brezillon
If some the pages or sgt allocation failed, we shouldn't release the
pages ref we got earlier, otherwise we will end up with unbalanced
get/put_pages() calls. We should instead leave everything in place
and let the BO release function deal with extra cleanup when the object
All drivers will be moved to get/put pages explicitly and then the last
put_pages() will be invoked during gem_free() time by some drivers.
We can't touch reservation lock when GEM is freed because that will cause
a spurious warning from lockdep when shrinker support will be added.
Lockdep doesn't
We're going to move away from having implicit get_pages() done by
get_pages_sgt() to ease simplify refcnt handling. Drivers will manage
get/put_pages() by themselves. Add drm_gem_shmem_put_pages().
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 20
To simplify the drm-shmem refcnt handling, we're moving away from
the implicit get_pages() that is used by get_pages_sgt(). From now on
drivers will have to pin pages while they use sgt. Lima driver doesn't
have shrinker, hence pages are pinned and sgt is valid as long as pages'
use-count > 0.
Prepare drm_gem_shmem_free() to addition of memory shrinker support
to drm-shmem by adding and using variant of put_pages() that doesn't
touch reservation lock. Reservation shouldn't be touched because lockdep
will trigger a bogus warning about locking contention with fs_reclaim
code paths that
Use refcount_t helper for vmap_use_count to make refcounting consistent
with pages_use_count and pages_pin_count that use refcount_t. This also
makes vmapping to benefit from the refcount_t's overflow checks.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Add lockless drm_gem_shmem_get_pages() helper that skips taking reservation
lock if pages_use_count is non-zero, leveraging from atomicity of the
refcount_t. Make drm_gem_shmem_mmap() to utilize the new helper.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
The vmapped pages shall be pinned in memory and previously get/put_pages()
were implicitly hard-pinning/unpinning the pages. This will no longer be
the case with addition of memory shrinker because pages_use_count > 0 won't
determine anymore whether pages are hard-pinned (they will be
Add separate pages_pin_count for tracking of whether drm-shmem pages are
moveable or not. With the addition of memory shrinker support to drm-shmem,
the pages_use_count will no longer determine whether pages are hard-pinned
in memory, but whether pages exist and are soft-pinned (and could be
Use atomic refcount_t helper for pages_use_count to optimize pin/unpin
functions by skipping reservation locking while GEM's pin refcount > 1.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
Make drm/gem API function names consistent by having locked function
use the _locked postfix in the name, while the unlocked variants don't
use the _unlocked postfix. Rename drm_gem_v/unmap() function names to
make them consistent with the rest of the API functions.
Acked-by: Maxime Ripard
Add locked and remove unlocked postfixes from drm-shmem function names,
making names consistent with the drm/gem core code.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 60 +--
Everything that uses the mapped buffer should be agnostic to is_iomem.
The only reason for the is_iomem test is that we're setting shmem->vaddr
to the returned map->vaddr. Now that the shmem->vaddr code is gone, remove
the obsoleted is_iomem test to clean up the code.
Acked-by: Maxime Ripard
Make all drm-shmem exported symbols GPL to make them consistent with
the rest of drm-shmem symbols.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 16
1 file changed, 8 insertions(+), 8
The vmap/vunmap/evict GEM callbacks are always invoked with a held GEM's
reservation lock. Document this locking rule for clarity.
Signed-off-by: Dmitry Osipenko
---
include/drm/drm_gem.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_gem.h
Add _locked postfix to drm_gem functions that have unlocked counterpart
functions to make GEM functions naming more consistent and intuitive in
regards to the locking requirements.
Acked-by: Maxime Ripard
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-off-by: Dmitry Osipenko
This series:
1. Adds common drm-shmem memory shrinker
2. Moves drm-shmem drivers to new SGT usage policy
3. Enables shrinker for VirtIO-GPU driver
4. Switches Panfrost driver to the common shrinker
5. Fixes bugs and improves/refactors drm-shmem code
Mesa:
On Fri, Jan 5, 2024 at 1:15 PM Markus Elfring wrote:
>
> > Date: Sun, 18 Sep 2016 18:38:48 +0200
> >
> > Some update suggestions were taken into account
> > from static source code analysis.
> >
> > Markus Elfring (5):
> > Use kmalloc_array() in amdgpu_debugfs_gca_config_read()
> > Improve
> Date: Sun, 18 Sep 2016 18:38:48 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5):
> Use kmalloc_array() in amdgpu_debugfs_gca_config_read()
> Improve determination of sizes in two functions
> Rename a jump label in
Hi Andy,
On 1/5/24 11:13, Andy Yan wrote:
> Hi Cristian:
>
> On 1/5/24 03:12, Cristian Ciocaltea wrote:
>> Hi Heiko,
>>
>> On 1/4/24 17:58, Heiko Stübner wrote:
>>> Hi Christian, Andy,
>>>
>>> Am Donnerstag, 4. Januar 2024, 15:39:50 CET schrieb Cristian Ciocaltea:
Commit 5a028e8f062f
On Thu, Jan 4, 2024 at 9:42 AM Dario Binacchi
wrote:
> The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the
> Novatek NT35510-based panel family.
>
> Signed-off-by: Dario Binacchi
v4 looks very nice, thanks!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Currently, when using non-blocking commits, we can see the following
kernel warning:
[ 110.908514] [ cut here ]
[ 110.908529] refcount_t: underflow; use-after-free.
[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87
refcount_dec_not_one+0xb8/0xc0
[
Am Freitag, 5. Januar 2024, 18:33:34 CET schrieb Alex Bee:
>
> Am 05.01.24 um 18:02 schrieb Heiko Stübner:
> > Am Freitag, 5. Januar 2024, 17:47:21 CET schrieb Alex Bee:
> >> Hi Heiko,
> >>
> >>
> >> Am 04.01.24 um 09:14 schrieb Heiko Stuebner:
> >>> On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee
On 1/5/24 11:57, Heiko Stübner wrote:
> Hi,
>
> Am Freitag, 5. Januar 2024, 10:04:55 CET schrieb Andy Yan:
>> On 1/4/24 23:58, Heiko Stübner wrote:
>>> Am Donnerstag, 4. Januar 2024, 15:39:50 CET schrieb Cristian Ciocaltea:
Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
Commit 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
introduced a variable which ended up being unused:
rockchip_drm_vop2.c:1688:23: warning: variable ‘if_dclk_rate’ set but not used
[-Wunused-but-set-variable]
This has been initially used as part of a formula to compute the clock
Am 05.01.24 um 18:02 schrieb Heiko Stübner:
Am Freitag, 5. Januar 2024, 17:47:21 CET schrieb Alex Bee:
Hi Heiko,
Am 04.01.24 um 09:14 schrieb Heiko Stuebner:
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
This is version 4 of my series that aims to add support for the display
On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
DRM_IVPU_PARAM_CONTEXT_PRIORITY has been deprecated because it
has been replaced with DRM_IVPU_JOB_PRIORITY levels set with
submit IOCTL and was unused anyway.
Signed-off-by: Wachowski, Karol
Signed-off-by: Jacek
dcss currently allocates and ioremaps quite a few resources in its probe
function's call graph. Devres now provides convenient functions which
perform the same task but do the cleanup automatically.
Port all memory allocations and ioremap() calls to the devres
counterparts.
Signed-off-by:
The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.
Implement the region-request through the corresponding managed
devres-function.
Signed-off-by: Philipp Stanner
---
Some drivers want to use (request) a region exclusively but nevertheless
create several mappings within that region.
Currently, there is no managed devres function to request a region
without mapping it.
Add the function devm_platform_get_resource()
Signed-off-by: Philipp Stanner
---
Patch #1 adds a new devres function that I found could be useful for the
driver dcss in drm. Patch #2 makes that driver use the new function.
I compiled this successfully but unfortunately don't have the hardware
to test it for dcss.
So you might want to have a closer look.
Greetings,
P.
On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
Make debug logs more readable and consistent:
- don't print handle as it is not always available for all buffers
- use hashed ivpu_bo ptr as main buffer identifier
- remove unused fields from ivpu_bo_print_info()
Signed-off-by: Jacek
Am Freitag, 5. Januar 2024, 17:47:21 CET schrieb Alex Bee:
> Hi Heiko,
>
>
> Am 04.01.24 um 09:14 schrieb Heiko Stuebner:
> > On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
> >> This is version 4 of my series that aims to add support for the display
> >> controller (VOP) and the HDMI
On Tue, 14 Nov 2023, Thomas Zimmermann wrote:
> If I'm not mistaken, the correct pattern is to read the EDID block in
> the detect callback and only parse it for modes in get_modes. If so, you
> might also inline this helper into its only caller in mgag200. I'll
> later split it up into detect
Remove the unused drm_connector_helper_get_modes_from_ddc()
function. Most drivers should probably have this functionality split to
detect and get modes parts, so the helper is not the best abstraction.
Suggested-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
Convert mgag200_vga_connector_helper_get_modes() to use struct drm_edid
based functions directly.
Suggested-by: Thomas Zimmermann
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git
Convert mgag200 to use struct drm_edid directly, and drop
drm_connector_helper_get_modes_from_ddc(), as suggested by Thomas.
This supersedes [1].
BR,
Jani.
[1] https://lore.kernel.org/all/20231114105815.4188901-1-jani.nik...@intel.com/
Jani Nikula (2):
drm/mgag200: convert get modes to
On Fri, Jan 05, 2024 at 05:11:03PM +0100, Manuel Traut wrote:
> On Wed, Jan 03, 2024 at 10:42:54AM +0100, Ondřej Jirman wrote:
> > Hello Manuel,
> >
> > a few more things I noticed:
> >
> > On Tue, Jan 02, 2024 at 05:15:47PM +0100, Manuel Traut wrote:
> > > From: Alexander Warnecke
> > >
> > >
Hi Heiko,
Am 04.01.24 um 09:14 schrieb Heiko Stuebner:
On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
This is version 4 of my series that aims to add support for the display
controller (VOP) and the HDMI controller block of RK3128 (which is very
similar to the one found in RK3036). The
Hi Jonas,
On Wed, Jan 03, 2024 at 03:19:25PM +0100, Jonas Karlman wrote:
> Hi Manuel,
>
> On 2024-01-03 14:40, Manuel Traut wrote:
> > Hi Jonas and Ondřej,
> >
> + {
> +pinctrl-names = "default";
> +pinctrl-0 = <_dual_io_pins>;
> +status = "okay";
>
On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
This was not supported properly. A buffer was imported to another VPU
context as a separate buffer object with duplicated sgt.
Both exported and imported buffers could be DMA mapped causing a double
mapping on the same device.
Imported buffer from
Add support to chroma subsampling. This should be noop, as all supported
formats do not have chroma subsampling.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/vkms/vkms_formats.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
This patchset aims to add support for additional buffer YUV formats.
More specifically, it adds support to:
Semi-planar formats:
- NV12
- NV16
- NV24
- NV21
- NV61
- NV42
Planar formats:
- YUV440
- YUV422
- YUV444
- YVU440
- YVU422
- YVU444
These formats have more than one plane, and most
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/vkms/Kconfig | 15 +++
drivers/gpu/drm/vkms/tests/.kunitconfig | 4 +
Create range and encoding properties. This should be noop, as none of
the conversion functions need those properties.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/vkms/vkms_drv.h | 3 ++-
drivers/gpu/drm/vkms/vkms_formats.c | 20 ++--
drivers/gpu/drm/vkms/vkms_plane.c
Add support to multy-planar formats by adding an index argument to the
framebuffer data access functions.
Also, give all the planes to the conversion functions. This, for now,
should be noop, as all the supported formats have only one plane.
Signed-off-by: Arthur Grillo
---
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index ba04ac7c2167..13b866c3617c
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
---
drivers/gpu/drm/vkms/vkms_drv.h | 3 ---
drivers/gpu/drm/vkms/vkms_formats.c | 12 +++-
drivers/gpu/drm/vkms/vkms_plane.c | 3 ---
Add support to the YUV formats bellow:
- NV12
- NV16
- NV24
- NV21
- NV61
- NV42
- YUV420
- YUV422
- YUV444
- YVU420
- YVU422
- YVU444
The conversion matrices of each encoding and range were obtained by
rounding the values of the original conversion matrices multiplied by
2^8. This is done to
On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
Call dma_unmap() on all buffers before to VPU is unbinded to avoid
to -> the ?
"device driver has pending DMA allocations while released from device"
warning when DMA-API debug is enabled.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey
On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
Limit number of iterations in ivpu_mmu_irq_evtq_handler() and
ivpu_ipc_irq_handler().
"potential infinite loops" sounds like something that has not been
observed. Has a problem actually occurred?
Are you concerned that the FW is broken and
1 - 100 of 169 matches
Mail list logo
