Hi Maxime,
kernel test robot noticed the following build warnings:
[auto build test WARNING on a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6]
url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/dma-buf-heaps-Introduce-a-new-heap-for-reserved-memory/20240515-215850
base
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 2024年5月15日 23:17
> 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;
Hi Linus,
Here is the buddy allocator fix I picked up from the list, please apply.
Dave.
drm-next-2024-05-16:
drm urgent for 6.10-rc1 merge:
buddy:
- fix breakage in buddy allocator.
The following changes since commit 275654c02f0ba09d409c36d71dc238e470741e30:
Merge tag
On Thu, 16 May 2024 at 10:06, Dave Airlie wrote:
>
> On Thu, 16 May 2024 at 09:50, Dave Airlie wrote:
> >
> > On Thu, 16 May 2024 at 06:29, Linus Torvalds
> > wrote:
> > >
> > > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> > > wrote:
> > > >
> > > > I have to revert both
> > > >
> > > >
On Tue, May 14, 2024 at 3:00 AM Christian König
wrote:
>
> Am 14.05.24 um 06:15 schrieb Zack Rusin:
>
> On Mon, May 13, 2024 at 1:09 PM Christian König
> wrote:
>
> Am 10.05.24 um 18:34 schrieb Zack Rusin:
>
> Hey,
>
> so this is a bit of a silly problem but I'd still like to solve it
>
https://bugzilla.kernel.org/show_bug.cgi?id=218841
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On 5/15/24 17:51, Aradhya Bhatia wrote:
> 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
>
Hi,
On 5/16/24 04:30, Markus Elfring wrote:
In some display subsystems, the functionality of a PCI(e) device may too
…
of the functionality into child devices can helps to achieve better
modularity, eaiser for understand and maintain.
Add the loongson_create_platform_device() function to
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'
> LCD185-101CT 10.1"[2] panel.
>
> Thes are all dual-lvds panels.
>
> Panel Links:
> [0]:
>
Hi,
On Wed, 15 May 2024 at 17:31, Thorsten Blum wrote:
>
> 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
Add @width and @height descriptions for drm_plane_size_hint
along with a reference to more info.
Add a short description for drm_mode_closefb.
Change 7 macros not to be marked as kernel-doc notation to prevent
warnings.
Fixes these kernel-doc warnings:
drm_mode.h:877: warning: Function
Fix a struct member name in drm_dp_as_sdp.
Add Returns: kernel-doc syntax for 4 functions.
In the Returns: sections, spell "%true" and "%false" consistently.
Fixes these kernel-doc warnings:
drm_dp_helper.h:126: warning: Function parameter or struct member 'mode' not
described in
On Thu, 16 May 2024 at 09:50, Dave Airlie wrote:
>
> On Thu, 16 May 2024 at 06:29, Linus Torvalds
> wrote:
> >
> > On Wed, 15 May 2024 at 13:24, Linus Torvalds
> > wrote:
> > >
> > > I have to revert both
> > >
> > > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > >
On Wed, 15 May 2024 at 16:51, Dave Airlie wrote:
>
> > Let's see if the machine ends up being stable now. It took several
> > hours for the "scary messages" state to turn into the "hung machine"
> > state, so they *could* have been independent issues, but it seems a
> > bit unlikely.
>
> This
On Wed, 15 May 2024 at 16:17, Dave Airlie wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And
On Thu, 16 May 2024 at 06:29, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
> wrote:
> >
> > I have to revert both
> >
> > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to
On Thu, 16 May 2024 at 06:29, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 13:24, Linus Torvalds
> wrote:
> >
> > I have to revert both
> >
> > a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> > e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
> >
> > to
Hi all,
On Mon, 13 May 2024 12:03:12 +1000 Stephen Rothwell
wrote:
>
> On Tue, 7 May 2024 12:51:32 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the drm-msm tree got a conflict in:
> >
> > drivers/gpu/drm/msm/Makefile
> >
> > between commit:
> >
> > 7c972986689b
On Thu, 16 May 2024 at 08:56, Linus Torvalds
wrote:
>
> On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
> >
> > The drm subsystem enables more warnings than the kernel default,
> > so
> > this config option is disabled by default.
>
> Irrelevant.
>
> If the *main*
On Wed, 15 May 2024 at 15:45, Dave Airlie wrote:
>
> The drm subsystem enables more warnings than the kernel default, so
> this config option is disabled by default.
Irrelevant.
If the *main* CONFIG_WERROR is on, then it does NOT MATTER if somebody
sets CONFIG_DRM_WERROR or
On Thu, 16 May 2024 at 06:43, Linus Torvalds
wrote:
>
> On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
> >
> > This is the main pull request for the drm subsystems for 6.10.
>
> .. and now that I look more at this pull request, I find other things wrong.
>
> Why is the DRM code asking if I
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
---
drivers/gpu/drm/xe/xe_gt.c | 11 +++
drivers/gpu/drm/xe/xe_gt.h | 7 +++
2 files changed, 18 insertions(+)
diff
Just like CTX_TIMESTAMP is used to calculate runtime, add a helper to
get the timestamp for the engine so it can be used to calculate the
"engine time" with the same unit as the runtime is recorded.
Reviewed-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
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. CTX_TIMESTAMP is used for
that, being read from the context image.
2)
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 when no clients exist, so it's safe to cache
the list of engines in
From: Umesh Nerlige Ramappa
Add a helper to capture CTX_TIMESTAMP from the context image so it can
be used to calculate the runtime.
v2: Add kernel-doc to clarify expectation from caller
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Lucas De Marchi
---
Move it out of the sysfs compilation unit so it can be re-used in other
places.
Reviewed-by: Nirmoy Das
Reviewed-by: Oak Zeng
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/xe_hw_engine.c | 18 ++
drivers/gpu/drm/xe/xe_hw_engine.h | 2 ++
From: Umesh Nerlige Ramappa
Add a helper to accumulate per-client runtime of all its
exec queues. This is called every time a sched job is finished.
v2:
- Use guc_exec_queue_free_job() and execlist_job_free() to accumulate
runtime when job is finished since xe_sched_job_completed() is not
XE_ENGINE_CLASS_OTHER was missing from the str conversion. Add it and
remove the default handling so it's protected by -Wswitch.
Currently the only user is xe_hw_engine_class_sysfs_init(), which
already skips XE_ENGINE_CLASS_OTHER, so there's no change in behavior.
Reviewed-by: Nirmoy Das
v4 of
https://lore.kernel.org/all/20240507224510.442971-1-lucas.demar...@intel.com
Add per-client usage statistics to xe. This ports xe to use the common
method in drm to export the usage to userspace per client (where 1
client == 1 drm fd open).
However instead of using the current format
Hi,
On Wed, May 15, 2024 at 2:16 PM wrote:
>
> Hi,
>
> On 15/05/2024 03:46, Cong Yang wrote:
> > DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
> > Since the arm64 defconfig had the BOE panel driver enabled, let's also
> > enable the himax driver.
> >
> >
Hi,
On Wed, 15 May 2024 15:21:27 +0530, Aradhya Bhatia wrote:
> 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
On 15/05/2024 11:51, Aradhya Bhatia wrote:
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
On 15/05/2024 11:51, Aradhya Bhatia wrote:
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
On 15/05/2024 11:51, Aradhya Bhatia wrote:
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
Hi,
On 15/05/2024 03:46, Cong Yang wrote:
DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6.
Since the arm64 defconfig had the BOE panel driver enabled, let's also
enable the himax driver.
Signed-off-by: Cong Yang
Reviewed-by: Douglas Anderson
---
Hi,
On Tue, May 14, 2024 at 6:47 PM Cong Yang
wrote:
>
> +static int hx83102_prepare(struct drm_panel *panel)
> +{
> + struct hx83102 *ctx = panel_to_hx83102(panel);
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = >dev;
> + int ret;
> +
> +
On 14/05/2024 11:07, Krzysztof Kozlowski wrote:
On 14/05/2024 10:44, Neil Armstrong wrote:
On 13/05/2024 18:41, Dmitry Baryshkov wrote:
On Mon, 13 May 2024 at 16:17, Rob Herring wrote:
On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote:
Hi,
Cleanups for display panel
Hi,
On Tue, 14 May 2024 10:20:50 -0700, Douglas Anderson wrote:
> The consensus of many DRM folks is that we want to move away from DSI
> drivers defining tables of init commands. Instead, we want to move to
> init functions that can use common DRM functions. The issue thus far
> has been that
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate
> In some display subsystems, the functionality of a PCI(e) device may too
…
> of the functionality into child devices can helps to achieve better
> modularity, eaiser for understand and maintain.
>
> Add the loongson_create_platform_device() function to pove the way …
Please avoid typos in such
On Wed, 15 May 2024 at 13:24, Linus Torvalds
wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build cleanly. Next step: see if it boots and fixes the
>
On Wed, 15 May 2024 at 13:21, Linus Torvalds
wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amdgpu: Enable clear page
On Wed, 15 May 2024 at 13:06, Linus Torvalds
wrote:
>
> Hmm. There's something seriously wrong with amdgpu.
>
> I'm getting a ton of__force_merge warnings:
>
> WARNING: CPU: 0 PID: 1069 at drivers/gpu/drm/drm_buddy.c:199
> __force_merge+0x14f/0x180 [drm_buddy]
Adding likely culprits to the
On Tue, 14 May 2024 at 23:21, Dave Airlie wrote:
>
> In drivers the main thing is a new driver for ARM Mali firmware based
> GPUs, otherwise there are a lot of changes to amdgpu/xe/i915/msm and
> scattered changes to everything else.
Hmm. There's something seriously wrong with amdgpu.
I'm
Le mardi 14 mai 2024 à 23:42 +0300, Laurent Pinchart a écrit :
> > You'll hit the same limitation as we hit in GStreamer, which is that KMS
> > driver
> > only offer allocation for render buffers and most of them are missing
> > allocators
> > for YUV buffers, even though they can import in
Hi Sui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.9 next-20240515]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
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:
>
> https://lore.kernel.org/all/candhncqujn6bh3kxkf65bwitylvqsd9892-xtfdhhqqyrro...@mail.gmail.com/
>
> The initial problem we were discussing was
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
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
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.
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!
--
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
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
>
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
>> &
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 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
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
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
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
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?
> ---
>
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
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
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;
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
changed, 407 insertions(+), 7 deletions(-)
---
base-commit: a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6
change-id: 20240515-dma-buf-ecc-heap-28a311d2c94e
Best regards,
--
Maxime Ripard
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.
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
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
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
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
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
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
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
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
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
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
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
>
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
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 ++---
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
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
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
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
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
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
---
1 - 100 of 153 matches
Mail list logo
