Re: [PATCH] video: fbdev: sm501fb: Fix deallocation of buffers order

On Tue, Apr 06, 2021 at 06:35:17PM -0500, Aditya Pakki wrote: > The resource release in sm501fb_remove() is not in the inverse order of > sm501fb_probe(), for the buffers. Release the info object after > deallocating the buffers. > > Signed-off-by: Aditya Pakki > --- > drivers/video/fbdev/sm501f

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue, Apr 20, 2021 at 09:04:51AM +0200, Michal Hocko wrote: > On Mon 19-04-21 18:37:13, Christian König wrote: > > Am 19.04.21 um 18:11 schrieb Michal Hocko: > [...] > > > The question is not whether it is NUMA aware but whether it is useful to > > > know per-numa data for the purpose the counter

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

Am 20.04.21 um 09:04 schrieb Michal Hocko: On Mon 19-04-21 18:37:13, Christian König wrote: Am 19.04.21 um 18:11 schrieb Michal Hocko: [...] The question is not whether it is NUMA aware but whether it is useful to know per-numa data for the purpose the counter is supposed to serve. No, not at

Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

Hi Am 16.04.21 um 15:51 schrieb Christian König: Am 16.04.21 um 15:46 schrieb Christian König: Am 16.04.21 um 15:31 schrieb Thomas Zimmermann: The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline the code. The internal helper ttm_bo_vm_lookup() is now also part of vmwgfx as vm

Re: [PATCH] efifb: Fix runtime pm calls for non PCI efifb device

Gentle Ping! There is boot failure because of this issue with linux-next on few arm platforms with non PCIe efifb. Please review and get the fix merged ASAP so the testing on these platforms can continue with linux-next. On Thu, Apr 15, 2021 at 11:22:24AM +0100, Sudeep Holla wrote: > Commit a6c0fd

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

Am 20.04.21 um 09:46 schrieb Michal Hocko: On Tue 20-04-21 09:32:14, Christian König wrote: Am 20.04.21 um 09:04 schrieb Michal Hocko: On Mon 19-04-21 18:37:13, Christian König wrote: Am 19.04.21 um 18:11 schrieb Michal Hocko: [...] What I am trying to bring up with NUMA side is that the sam

[PATCH] drm/panel: lvds: Drop unnecessary NULL pointer checks for lvds->enable_gpio

gpiod_set_value_cansleep() does NULL pointer check for passed in gpio descriptor's pointer, so it's unnecessary to do that check before calling that function. This patch drops those checks from this panel driver. Cc: Laurent Pinchart Cc: Thierry Reding Cc: Sam Ravnborg Cc: David Airlie Cc: Dan

Re: [PATCH] efifb: Fix runtime pm calls for non PCI efifb device

Hi Sudeep, On Tue, Apr 20, 2021 at 3:53 PM Sudeep Holla wrote: > > Gentle Ping! There is boot failure because of this issue with linux-next > on few arm platforms with non PCIe efifb. Please review and get the fix > merged ASAP so the testing on these platforms can continue with linux-next. It w

Re: [v1 0/3] drm: Add support for backlight control of eDP panel on ti-sn65dsi86 bridge

Cc: Lyude and drm-misc maintainers On Wed, 14 Apr 2021, Rajeev Nandan wrote: > The backlight level of an eDP panel can be controlled through the AUX > channel using DPCD registers of the panel. > > The capability for the Source device to adjust backlight characteristics > within the panel, usin

[PATCH 0/2 V6]Add dma-buf counter

The dma-buf counter is a metric for mapped memory used by it's clients. It is a shared buffer that is typically used for interprocess communication or process to hardware communication. In android we used to have ION,. but it is now replaced with dma-buf. ION had some overview metrics that was simi

[PATCH 1/2 V6] dma-buf: Add DmaBufTotal counter in meminfo

This adds a total used dma-buf memory. Details can be found in debugfs, however it is not for everyone and not always available. dma-buf are indirect allocated by userspace. So with this value we can monitor and detect userspace applications that have problems. Typical usage is to see that system d

[PATCH 2/2 V6] lib/show_mem.c: Add dma-buf counter to show_mem dump.

On system where dma-buf is used it can be many clients that adds up to a lot of memory. This can be relevant for OOM handling when running out of memory or how system handle this memory. It may be to free with a kill. Suggested-by: Michal Hocko Signed-off-by: Peter Enderborg --- lib/show_mem.c

Re: [PATCH] efifb: Fix runtime pm calls for non PCI efifb device

On Tue, Apr 20, 2021 at 04:12:26PM +0800, Kai-Heng Feng wrote: > Hi Sudeep, > > On Tue, Apr 20, 2021 at 3:53 PM Sudeep Holla wrote: > > > > Gentle Ping! There is boot failure because of this issue with linux-next > > on few arm platforms with non PCIe efifb. Please review and get the fix > > merge

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Sat, Apr 17, 2021 at 01:54:08PM +0200, Christian König wrote: > Am 17.04.21 um 13:20 schrieb peter.enderb...@sony.com: > > On 4/17/21 12:59 PM, Christian König wrote: > > > Am 17.04.21 um 12:40 schrieb Peter Enderborg: > > > > This adds a total used dma-buf memory. Details > > > > can be found i

Re: [PATCH 03/12] drm/exynos: Don't set allow_fb_modifiers explicitly

On Tue, Apr 20, 2021 at 03:31:27PM +0900, Inki Dae wrote: > > > 21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글: > > Since > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > Author: Paul Kocialkowski > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > drm: Auto-set allow_fb_modifiers whe

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > Hi Thomas, > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > wrote: > > This patchset adds support for simple-framebuffer platform devices and > > a handover mechanism for native drivers to take-over control of the > >

Re: [PATCH] drm/connector: demote connector force-probes for non-master clients

Ping Daniel Vetter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/7] drm/vmwgfx: Inline ttm_bo_mmap() into vmwgfx driver

On Tue, Apr 20, 2021 at 09:51:27AM +0200, Thomas Zimmermann wrote: > Hi > > Am 16.04.21 um 15:51 schrieb Christian König: > > Am 16.04.21 um 15:46 schrieb Christian König: > > > Am 16.04.21 um 15:31 schrieb Thomas Zimmermann: > > > > The vmwgfx driver is the only remaining user of ttm_bo_mmap(). I

Re: [PATCH 1/2] drm/doc: document drm_mode_get_plane

Hi Leandro, Any chance you could re-spin at least the first patch? Thanks, Simon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 27/40] drm/ttm/ttm_device: Demote kernel-doc abuses

On Fri, Apr 16, 2021 at 05:32:52PM +0200, Christian König wrote: > Am 16.04.21 um 16:37 schrieb Lee Jones: > > Fixes the following W=1 kernel build warning(s): > > > > drivers/gpu/drm/ttm/ttm_device.c:42: warning: Function parameter or > > member 'ttm_global_mutex' not described in 'DEFINE_MUTE

Re: [PATCH v2] drm/drm_bufs.c: In switch, add break in default case

On Sat, Apr 17, 2021 at 06:15:52PM +0200, Fabio M. De Francesco wrote: > Added a "break" in the default case of a switch select statement. > GCC complains, although this "break" is not strictly necessary > for the code to work as expected. Luckily we already have a comment stating that this is al

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: > This adds a total used dma-buf memory. Details > can be found in debugfs, however it is not for everyone > and not always available. dma-buf are indirect allocated by > userspace. So with this value we can monitor and detect > users

Re: [PATCH 2/2] drm/gma500: remove trailing whitespaces

On Mon, Apr 19, 2021 at 10:18:07AM +0200, Krzysztof Kozlowski wrote: > Remove trailing whitespaces. No functional change. > > Signed-off-by: Krzysztof Kozlowski Both patches applied to drm-misc-next, thanks. -Daniel > --- > drivers/gpu/drm/gma500/backlight.c| 4 +-- > drivers/gpu/drm/gma

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

>> But that isn't really system memory at all, it's just allocated device >> memory. > OK, that was not really clear to me. So this is not really accounted to > MemTotal? If that is really the case then reporting it into the oom > report is completely pointless and I am not even sure /proc/meminf

Re: [PATCH 1/2] drm/mediatek: set panel orientation before drm_dev_register().

On Fri, Apr 9, 2021 at 12:53 PM Hsin-Yi Wang wrote: > > drm_dev_register() sets connector->registration_state to > DRM_CONNECTOR_REGISTERED and dev->registered to true. If > drm_connector_set_panel_orientation() is first called after > drm_dev_register(), it will fail several checks and results in

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET wrote: > Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > > For built-in drivers, load order depends on the initcall level and > > link order (how things are lined listed in the Makefile hierarchy). > > > > For loadable modules, thi

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET wrote: > Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > > For built-in drivers, load order depends on the initcall level and > > link order (how things are lined listed in the Makefile hierarchy). > > > > For loadable modules, thi

Re: [PATCH] drm/connector: demote connector force-probes for non-master clients

On Fri, Apr 02, 2021 at 01:22:12PM +0200, Simon Ser wrote: > Force-probing a connector can be slow and cause flickering. As this > affects the global KMS state, let's make it so only the DRM master > can force-probe a connector. > > Non-master DRM clients won't be able to force-probe a connector >

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

Hi Daniel, On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote: > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > > wrote: > > > This patchset adds support for simple-framebuffer platform devices and > > > a handover

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

Hi, > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM helpers > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During > > > > if support for 8-bit frame buffers would be added? > > Is that 8-bit greyscale or 8-bit indexed with 256 entry palett

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 11:12 AM, Michal Hocko wrote: > On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: But that isn't really system memory at all, it's just allocated device memory. >>> OK, that was not really clear to me. So this is not really accounted to >>> MemTotal? If that is really t

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 10:58 AM, Daniel Vetter wrote: > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: >> This adds a total used dma-buf memory. Details >> can be found in debugfs, however it is not for everyone >> and not always available. dma-buf are indirect allocated by >> userspace. So w

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

Hi Gerd, On Tue, Apr 20, 2021 at 11:22 AM Gerd Hoffmann wrote: > > > > Patches 4 to 8 add the simpledrm driver. It's build on simple DRM > > > > helpers > > > > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. > > > > During > > > > > > if support for 8-bit frame buffers

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

Hello Peter, On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote: > On 4/20/21 10:58 AM, Daniel Vetter wrote: > > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: > >> This adds a total used dma-buf memory. Details > >> can be found in debugfs, however it is no

Re: [PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next

Quoting Jani Nikula (2021-04-19 12:53:11) > > Hi Joonas and Rodrigo - > > Here's the gen to ver conversion topic branch to be merged to both > drm-intel-next and drm-intel-gt-next. Pulled. Regards, Joonas > Lots of Cc's for heads up. > > > BR, > Jani. > > > topic/intel-gen-to-ver-2021-04-1

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

Hi Alice, On 4/19/21 7:27 AM, Alice Guo (OSS) wrote: > From: Alice Guo > > Update all the code that use soc_device_match because add support for > soc_device_match returning -EPROBE_DEFER. > > Signed-off-by: Alice Guo > --- > drivers/bus/ti-sysc.c | 2 +- > drivers/cl

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 19.04.21 um 17:48 schrieb Jason Ekstrand: Not going to comment on everything on the first pass... On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how

Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints

Hi, On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote: > I'm working on a Wayland extension [1] that, among other things, allows > compositors to advertise the preferred device to be used by Wayland > clients. > > In general, compositors will send a render node. However, in the case > of split rende

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 12:15 PM Christian König wrote: > > Am 19.04.21 um 17:48 schrieb Jason Ekstrand: > > Not going to comment on everything on the first pass... > > > > On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote: > >> Hi, > >> > >> This is our initial proposal for explicit fences every

[PATCH 1/2] drm/i915: Remove asynchronous vma binding

Commit e3793468b466 ("drm/i915: Use the async worker to avoid reclaim tainting the ggtt->mutex") moves the vma binding to dma_fence_work, but dma_fence_work has has signalling fence semantics. On braswell, we can call stop_machine inside fence_work, causing a splat because memory allocation inside

[PATCH 2/2] drm/i915: Use trylock in shrinker for ggtt on bsw vt-d and bxt, v2.

The stop_machine() lock may allocate memory, but is called inside vm->mutex, which is taken in the shrinker. This will cause a lockdep splat, as can be seen below: <4>[ 462.585762] == <4>[ 462.585768] WARNING: possible circular locking dependen

[PATCH 1/1] drm/amdgpu: make sure we unpin the UVD BO

Releasing pinned BOs is illegal now. UVD 6 was missing from: commit 2f40801dc553 ("drm/amdgpu: make sure we unpin the UVD BO") Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c b/drivers/

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Daniel, are you suggesting that we should skip any deadlock prevention in the kernel, and just let userspace wait for and signal any fence it has access to? Do you have any concern with the deprecation/removal of BO fences in the kernel assuming userspace is only using explicit fences? Any concern

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Mon 19-04-21 18:37:13, Christian König wrote: > Am 19.04.21 um 18:11 schrieb Michal Hocko: [...] > > The question is not whether it is NUMA aware but whether it is useful to > > know per-numa data for the purpose the counter is supposed to serve. > > No, not at all. The pages of a single DMA-bu

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote: > Hi Daniel, > > On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote: > > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann > > > wrote: > > > > This p

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote: > On 4/20/21 10:58 AM, Daniel Vetter wrote: > > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: > >> This adds a total used dma-buf memory. Details > >> can be found in debugfs, however it is not for everyone

Re: Split render/display SoCs, Mesa's renderonly, and Wayland dmabuf hints

Just 2 comments on the kernel aspects here. On Tue, Apr 20, 2021 at 12:18 PM Daniel Stone wrote: > > Hi, > > On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote: >> >> I'm working on a Wayland extension [1] that, among other things, allows >> compositors to advertise the preferred device to be used by

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 07:03:19AM -0400, Marek Olšák wrote: > Daniel, are you suggesting that we should skip any deadlock prevention in > the kernel, and just let userspace wait for and signal any fence it has > access to? Yeah. If we go with userspace fences, then userspace can hang itself. Not

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 1:04 PM, Michal Hocko wrote: > On Tue 20-04-21 09:25:51, peter.enderb...@sony.com wrote: >> On 4/20/21 11:12 AM, Michal Hocko wrote: >>> On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: >> But that isn't really system memory at all, it's just allocated device >> memory.

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 1:14 PM, Daniel Vetter wrote: > On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote: >> On 4/20/21 10:58 AM, Daniel Vetter wrote: >>> On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote: This adds a total used dma-buf memory. Details can be foun

Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge

On 23.02.21 13:07, Daniel Vetter wrote: On Thu, Feb 18, 2021 at 5:02 PM Andrzej Hajda wrote: Hi Michael, W dniu 18.02.2021 o 09:04, Michael Tretter pisze: On Wed, 10 Feb 2021 10:10:37 +0100, Frieder Schrempf wrote: On 04.02.21 18:46, Daniel Vetter wrote: On Thu, Feb 4, 2021 at 6:26 PM Laur

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 09:32:14, Christian König wrote: > Am 20.04.21 um 09:04 schrieb Michal Hocko: > > On Mon 19-04-21 18:37:13, Christian König wrote: > > > Am 19.04.21 um 18:11 schrieb Michal Hocko: [...] > > What I am trying to bring up with NUMA side is that the same problem can > > happen on per-no

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 10:20:43, Mike Rapoport wrote: > On Tue, Apr 20, 2021 at 09:04:51AM +0200, Michal Hocko wrote: > > On Mon 19-04-21 18:37:13, Christian König wrote: > > > Am 19.04.21 um 18:11 schrieb Michal Hocko: > > [...] > > > > The question is not whether it is NUMA aware but whether it is usefu

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On Tue, Apr 20, 2021 at 10:45:21AM +, peter.enderb...@sony.com wrote: > On 4/20/21 11:41 AM, Mike Rapoport wrote: > > Hello Peter, > > > > On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote: > >> On 4/20/21 10:58 AM, Daniel Vetter wrote: > >>> On Sat, Apr 17, 2021 at 06:38

Re: [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER

On Mon, Apr 19, 2021 at 10:20:13AM +0200, Geert Uytterhoeven wrote: > Hi Alice, > > CC Arnd (soc_device_match() author) > > On Mon, Apr 19, 2021 at 6:28 AM Alice Guo (OSS) wrote: > > From: Alice Guo > > > > In i.MX8M boards, the registration of SoC device is later than caam > > driver which nee

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Yeah. If we go with userspace fences, then userspace can hang itself. Not the kernel's problem. Well, the path of inner peace begins with four words. “Not my fucking problem.” But I'm not that much concerned about the kernel, but rather about important userspace processes like X, Wayland, Su

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Mon, Apr 19, 2021 at 06:47:48AM -0400, Marek Olšák wrote: > Hi, > > This is our initial proposal for explicit fences everywhere and new memory > management that doesn't use BO fences. It's a redesign of how Linux > graphics drivers work, and it can coexist with what we have now. > > > *1. Int

Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 1:52 PM, Mike Rapoport wrote: > On Tue, Apr 20, 2021 at 10:45:21AM +, peter.enderb...@sony.com wrote: >> On 4/20/21 11:41 AM, Mike Rapoport wrote: >>> Hello Peter, >>> >>> On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote: On 4/20/21 10:58 AM, Daniel Vette

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi Daniel, Am 20.04.21 um 14:01 schrieb Daniel Vetter: On Mon, Apr 19, 2021 at 06:47:48AM -0400, Marek Olšák wrote: Hi, This is our initial proposal for explicit fences everywhere and new memory management that doesn't use BO fences. It's a redesign of how Linux graphics drivers work, and it c

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 10:00:07, Christian König wrote: > Am 20.04.21 um 09:46 schrieb Michal Hocko: > > On Tue 20-04-21 09:32:14, Christian König wrote: > > > Am 20.04.21 um 09:04 schrieb Michal Hocko: > > > > On Mon 19-04-21 18:37:13, Christian König wrote: > > > > > Am 19.04.21 um 18:11 schrieb Michal

Re: [PATCH 0/2 V6]Add dma-buf counter

On Tue 20-04-21 10:22:18, Peter Enderborg wrote: > The dma-buf counter is a metric for mapped memory used by it's clients. > It is a shared buffer that is typically used for interprocess communication > or process to hardware communication. In android we used to have ION,. but > it is now replaced

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi Marek, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > *2. Explicit synchronization for window systems and modesetting* > > The producer is an application and the consumer is a compositor or a > modesetting driver. > > *2.1. The Present request* > So the 'present request' is an ioctl, rig

Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Fri, Feb 5, 2021 at 9:02 PM Nicolas Boichat wrote: > > On Sat, Feb 6, 2021 at 1:55 AM Rob Herring wrote: > > > > On Tue, 26 Jan 2021 09:17:56 +0800, Nicolas Boichat wrote: > > > Define a compatible string for the Mali Bifrost GPU found in > > > Mediatek's MT8183 SoCs. > > > > > > Signed-off-by

Re: [PATCH v11 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Mon, Jan 25, 2021 at 7:18 PM Nicolas Boichat wrote: > > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > --- > > Changes in v11: > - binding: power-domain-names not power-domainS-names > > Changes in v10: > - Fix the

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: > - We live in a post xf86-video-$vendor world, and all these other > compositors rely on implicit sync. You're not going to be able to get > rid of them anytime soon. What's worse, all the various EGL/vk buffer > sharing things also r

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: > > >> But that isn't really system memory at all, it's just allocated device > >> memory. > > OK, that was not really clear to me. So this is not really accounted to > > MemTotal? If that is really the case then reporting it into the oom >

[PATCH 1/5] drm/i915: Create stolen memory region from local memory

From: CQ Tang Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. v2: - s/drm_info/drm_dbg; userspace likely doesn't care about stolen. - mem->type is only setup after the region probe, so setting the name

[PATCH 3/5] drm/i915/stolen: enforce the min_page_size contract

From: CQ Tang Since stolen can now be device local-memory underneath, we should try to enforce any min_page_size restrictions when allocating pages. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 --- 1 fi

[PATCH 2/5] drm/i915/stolen: treat stolen local as normal local memory

Underneath it's the same stuff, so things like the PTE_LM bits for the GTT should just keep working as-is. Signed-off-by: Matthew Auld Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm

[PATCH 4/5] drm/i915/stolen: pass the allocation flags

From: CQ Tang Stolen memory is always allocated as physically contiguous pages, mark the object flags as such. v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c |

[PATCH 5/5] drm/i915/lmem: Fail driver init if LMEM training failed

From: Matt Roper Boot firmware performs memory training and health assessment during startup. If the memory training fails, the firmware will consider the GPU unusable and will instruct the punit to keep the GT powered down. If this happens, our driver will be unable to communicate with the GT (

[PATCH 2/4] drm/panel: boe-tv101wum-n16 seperate the panel power control

Seperate the panel power control from prepare/unprepare. Signed-off-by: Jitao Shi --- .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 72 +-- 1 file changed, 50 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c b/drivers/gpu/drm/panel/pa

[PATCH 4/4] drm/mediatek: add dsi module reset driver

Reset dsi HW to default when power on. Prevent the setting differet between bootloader and kernel. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dsi.c | 36 +- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c

[PATCH 1/4] drm/panel: seperate panel power control from panel prepare/unprepare

Some dsi panels require the dsi lanes keeping low before panel power on. So seperate the panel power control and the communication with panel. And put the power control in drm_panel_prepare_power and drm_panel_unprepare_power. Put the communication with panel in drm_panel_prepare and drm_panel_unp

[PATCH 3/4] drm/mediatek: fine tune the dsi panel's power sequence

Add the drm_panel_prepare_power and drm_panel_unprepare_power control. Turn on panel power(drm_panel_prepare_power) and control before dsi enable. And then dsi enable, send dcs cmd in drm_panel_prepare, last turn on backlight. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dsi.c | 12

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

Hi Peter, On Fri, 16 Apr 2021 at 13:34, Peter Enderborg wrote: > This adds a total used dma-buf memory. Details > can be found in debugfs, however it is not for everyone > and not always available. dma-buf are indirect allocated by > userspace. So with this value we can monitor and detect > user

Re: [Intel-gfx] [PULL] topic/intel-gen-to-ver -> drm-intel-next and drm-intel-gt-next

On Tue, Apr 20, 2021 at 12:47:36PM +0300, Joonas Lahtinen wrote: > Quoting Jani Nikula (2021-04-19 12:53:11) > > > > Hi Joonas and Rodrigo - > > > > Here's the gen to ver conversion topic branch to be merged to both > > drm-intel-next and drm-intel-gt-next. > > Pulled. Pulled, thanks. (Sorry fo

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 3:34 PM, Daniel Stone wrote: > Hi Peter, > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg > wrote: > > This adds a total used dma-buf memory. Details > can be found in debugfs, however it is not for everyone > and not always available. dma-b

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 3:04 PM Daniel Stone wrote: > > Hi, > > On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote: >> >> - We live in a post xf86-video-$vendor world, and all these other >> compositors rely on implicit sync. You're not going to be able to get >> rid of them anytime soon. What

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 1:59 PM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” > > But I'm not that much concerned about the kerne

Re: [PATCH] drm/i915: fix an error code in intel_overlay_do_put_image()

On Wed, Apr 14, 2021 at 09:02:24AM +0300, Dan Carpenter wrote: > This code should propagate the error from intel_overlay_pin_fb() > but currently it returns success. > > Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane") > Signed-off-by: Dan Carpenter Reviewed-by: Rodrig

Re: [PATCH v2 10/16] drm/exynos: implement a drm bridge

Hi Frieder, On Tue, Apr 20, 2021 at 01:42:05PM +0200, Frieder Schrempf wrote: > On 23.02.21 13:07, Daniel Vetter wrote: > > On Thu, Feb 18, 2021 at 5:02 PM Andrzej Hajda wrote: > >> W dniu 18.02.2021 o 09:04, Michael Tretter pisze: > >>> On Wed, 10 Feb 2021 10:10:37 +0100, Frieder Schrempf wrote:

[PATCH] drm/ttm: fix error handling if no BO can be swapped out

In case that all pre-allocated BOs are busy, just continue to populate BOs since likely half of system memory in total is still free. Signed-off-by: Shiwu Zhang --- drivers/gpu/drm/ttm/ttm_device.c | 4 ++-- drivers/gpu/drm/ttm/ttm_tt.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On Tue, 20 Apr 2021 at 14:46, wrote: > On 4/20/21 3:34 PM, Daniel Stone wrote: > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg > wrote: > > This adds a total used dma-buf memory. Details > > can be found in debugfs, however it is not for everyone > >

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > Deadlock mitigation to recover from segfaults: > - The kernel knows which process is obliged to signal which fence. This > information is part of the Present request and supplied by userspace. > - If the producer crashes, the kernel signals

Re: [PATCH v2] dma-buf: Add DmaBufTotal counter in meminfo

On 4/20/21 4:48 PM, Daniel Stone wrote: > On Tue, 20 Apr 2021 at 14:46, > wrote: > > On 4/20/21 3:34 PM, Daniel Stone wrote: > > On Fri, 16 Apr 2021 at 13:34, Peter Enderborg

Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo

On Tue 20-04-21 09:25:51, peter.enderb...@sony.com wrote: > On 4/20/21 11:12 AM, Michal Hocko wrote: > > On Tue 20-04-21 09:02:57, peter.enderb...@sony.com wrote: > But that isn't really system memory at all, it's just allocated device > memory. > >>> OK, that was not really clear to me.

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, 20 Apr 2021 at 15:58, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 16:53 schrieb Daniel Stone: > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: > >> Deadlock mitigation to recover from segfaults: >> - The kernel knows which process is obliged to signal w

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 16:53 schrieb Daniel Stone: Hi, On Mon, 19 Apr 2021 at 11:48, Marek Olšák > wrote: Deadlock mitigation to recover from segfaults: - The kernel knows which process is obliged to signal which fence. This information is part of the Present req

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

On 16/04/2021 13:38, Neil Armstrong wrote: > On 16/04/2021 11:58, Laurent Pinchart wrote: >> Hi Neil, >> >> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: >>> This adds DW-HDMI driver a glue option to disable loading of the CEC >>> sub-driver. >>> >>> On some SoCs, the CEC functio

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Am 20.04.21 um 17:07 schrieb Daniel Stone: On Tue, 20 Apr 2021 at 15:58, Christian König > wrote: Am 20.04.21 um 16:53 schrieb Daniel Stone: On Mon, 19 Apr 2021 at 11:48, Marek Olšák mailto:mar...@gmail.com>> wrote: Deadlock mitigatio

Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

On 20/04/2021 17:13, Hans Verkuil wrote: > On 16/04/2021 13:38, Neil Armstrong wrote: >> On 16/04/2021 11:58, Laurent Pinchart wrote: >>> Hi Neil, >>> >>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: This adds DW-HDMI driver a glue option to disable loading of the CEC

Re: [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

It's still early in the morning here and I'm not awake yet so sorry if this comes out in bits and pieces... On Tue, Apr 20, 2021 at 7:43 AM Daniel Stone wrote: > > Hi Marek, > > On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote: >> >> 2. Explicit synchronization for window systems and modesetting

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Hi, On Tue, 20 Apr 2021 at 16:16, Christian König < ckoenig.leichtzumer...@gmail.com> wrote: > Am 20.04.21 um 17:07 schrieb Daniel Stone: > > If the compositor no longer has a guarantee that the buffer will be ready > for composition in a reasonable amount of time (which dma_fence gives us, > and

Re: [PATCH 1/5] drm/i915: Create stolen memory region from local memory

On 20/04/2021 14:18, Matthew Auld wrote: From: CQ Tang Add "REGION_STOLEN" device info to dg1, create stolen memory region from upper portion of local device memory, starting from DSMBASE. v2: - s/drm_info/drm_dbg; userspace likely doesn't care about stolen. - mem->type is only set

Re: [PATCH 4/5] drm/i915/stolen: pass the allocation flags

On 20/04/2021 14:18, Matthew Auld wrote: From: CQ Tang Stolen memory is always allocated as physically contiguous pages, mark the object flags as such. v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen Signed-off-by: CQ Tang Signed-off-by: Matthew Auld Cc: Tvrtko Ursulin ---

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

Sorry for the mega-reply but timezones... On Tue, Apr 20, 2021 at 6:59 AM Christian König wrote: > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > the kernel's problem. > > Well, the path of inner peace begins with four words. “Not my fucking > problem.” 🧘 > Bu

Re: [PATCH v3 1/5] dt-bindings: display: mediatek, hdmi: Convert to use graph schema

On Mon, 19 Apr 2021 09:32:40 +0200, Neil Armstrong wrote: > Update the mediatek,dpi binding to use the graph schema. > > Signed-off-by: Neil Armstrong > --- > .../display/mediatek/mediatek,cec.yaml| 51 +++ > .../display/mediatek/mediatek,hdmi-ddc.yaml | 57 > .../displa

Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

On Tue, Apr 20, 2021 at 9:10 AM Daniel Vetter wrote: > > On Tue, Apr 20, 2021 at 1:59 PM Christian König > wrote: > > > > > Yeah. If we go with userspace fences, then userspace can hang itself. Not > > > the kernel's problem. > > > > Well, the path of inner peace begins with four words. “Not my f

Re: [PATCH v3 2/5] dt-bindings: mediatek: add mt8167 to hdmi, hdmi-ddc and cec bindings

On Mon, 19 Apr 2021 09:32:41 +0200, Neil Armstrong wrote: > Add mt8167 SoC compatible to Mediatek hdmi, hdmi-ddc and cec schema bindings. > > Signed-off-by: Neil Armstrong > --- > .../devicetree/bindings/display/mediatek/mediatek,cec.yaml | 1 + > .../devicetree/bindings/display/mediatek/m

  1   2   >