On 06/10/2020 21:33, Enric Balletbo i Serra wrote:
From: Yongqiang Niu
MMSYS is the driver which controls the routing of these DDP components,
so the definition of the mtk_ddp_comp_id enum should be placed in mtk-mmsys.h
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-b
Hi Sam,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20201127]
[also build test ERROR on v5.10-rc5]
[cannot apply to tegra-drm/drm/tegra/for-next soc/for-next linus/master
drm/drm-next v5.10-rc5 v5.10-rc4 v5.10-rc3]
[If your patch is applied to the wrong git tree
On Fri, Nov 27, 2020 at 11:00:54AM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> komeda_component_get_old_state() technically can return a NULL
> pointer. komeda_compiz_set_input() even warns when this happens, but
> then proceeeds to use that NULL pointer tocompare mem
On Fri, Nov 27, 2020 at 11:00:27AM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> ret is not actually read after this (only written in one case then
> returned), so this assign line is useless. This removes that assignment.
>
> Signed-off-by: Carsten Haitzler
Acked-by
On 27/11/2020 15:42, Chun-Kuang Hu wrote:
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
Hi Chun-Kuang,
On 20/11/2020 00:46, Chun-Kuang Hu wrote:
Hi, Matthias:
I've provided the example for why of this patch. How do you think
about this patch?
Patch looks good to me. If you
Hi Joe.
On Fri, Nov 27, 2020 at 01:16:41PM -0800, Joe Perches wrote:
> On Fri, 2020-11-27 at 20:57 +0100, Sam Ravnborg wrote:
> > Replacing DPRINTK() statements with pr_debug fixes
> > W=1 warnings.
> > And moves to a more standard logging setup at the same time.
> []
> > diff --git a/drivers/vide
On 27/11/2020 17:37, Ivaylo Dimitrov wrote:
> With 5.9.11 and the patch on top, n900 boots fine, albeit display remains
> blank, could be related to
> brightness, we're still investigating.
Ok. A DSS regdump for a working version and the latest one would be good too.
There's a omapdss
debugfs d
On Fri, 2020-11-27 at 20:57 +0100, Sam Ravnborg wrote:
> Replacing DPRINTK() statements with pr_debug fixes
> W=1 warnings.
> And moves to a more standard logging setup at the same time.
[]
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
[]
> @@ -1015,9 +1007,9
The filter definition is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).
Signed-off-by: Jianxin Xiong
---
tests/utils.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/test_mr.py | 239
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Add a method to buildlib for building modules with mixed Cython and C
source.
Signed-off-by: Jianxin Xiong
---
buildlib/pyve
This is the third version of the patch series. Change log:
v3:
* Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API
* Change the way of allocating dma-buf object - use /dev/dri/renderD*
instead of /dev/dri/card* and use GEM object instead of dumb buffer
* Add cmake function to allow buildin
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 +
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
kernel-headers/rdma/ib_user_verbs.h | 14 --
2 files changed, 14 insertions(+), 14 deletio
Quoting Pandey, Hariom (2020-10-28 11:55:04)
> Ok, I have initiated the steps to upgrade the CI machine's silicon & BIOS.
The single ehl we have in CI is still failing to enter rc6, both in the
selftest and runtime testing. And I note that RAPL doesn't recognise it,
so it doesn't report the power
The pull request you sent on Fri, 27 Nov 2020 18:37:15 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-27-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6910b676898934c2abe9f3ff3d60f4d4bc8afda8
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
Fix W=1 warnings by avoiding local variables and use direct references.
Signed-off-by: Sam Ravnborg
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Jani Nikula
---
drivers/video/fbdev/tmiofb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/tmiofb.c b/driv
Fix several W=1 warnings.
This removes a little unused code and avoids an assignment by moving
the use inside the conditional block.
Signed-off-by: Sam Ravnborg
Cc: Aditya Pakki
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 12 +++-
1
Fix following W=1 warnings:
- Fix unused variables for variables used only for logging.
Fixed by introducing no_printk() to trick compiler to think variables
are used
- Fix kernel-doc warning by deleting an empty comment line
Signed-off-by: Sam Ravnborg
Cc: Kristoffer Ericson
---
drivers/vi
Fix warnings:
- fix kernel-doc
- delete unused code
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimemrmann
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Daniel Vetter
Cc: Saeed Mirzamohammadi
Cc: Jani Nikula
Cc: Mike Rapoport
---
drivers/video/fbdev/cirrusfb.c | 20 +---
1 fil
Fix several W=1 warnings
- Updated kernel-doc as needed
- Deleted unused local variable, it was assigned but never used
Signed-off-by: Sam Ravnborg
Cc: Jingoo Han
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/s3c-fb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Fix W=1 warning by deleting unused local variable.
Signed-off-by: Sam Ravnborg
Cc: Michal Januszewski
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/uvesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uve
Fix a few W=1 warnings about unused assignments.
Drop the unused error code.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Qilong Zhang
Cc: "Alexander A. Klimov"
Cc: Daniel Vetter
---
drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 4 ++--
drivers/video/fbdev/omap2/omapfb/dss/hdmi5_co
Fixed a few kernel-doc issues to fix the warnings.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Randy Dunlap
Cc: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz
Cc: Jani Nikula
---
drivers/video/fbdev/pm2fb.c | 8
1 file changed, 4 insertions(+), 4 deleti
Two W=1 string related warnings.
- Using strncpy to copy string wihtout null-termination is not good.
Use memcpy to copy only the relevant chars
- Fix a potential bug with a very long string, subtract one from the
length to make room for the termination null.
Signed-off-by: Sam Ravnborg
Cc:
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused code
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Arnd Bergmann
Cc: Joe Perches
---
drivers/video/fbdev/tgafb.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
Fix W=1 warnings by introducing no_printk variants for the
internal logging system for this driver.
Fix a new warning that popped up now that logging was checked for
correct printf format strings.
A more invasive fix had been to replace all the internal logging with
standard logging primitives -
Fix warnings by deleting unused code
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/nvidia/nv_setup.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c
b/drivers/video/fbdev/
Fix W=1 warnigns by removing unused code
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Andrew Morton
Cc: Evgeny Novikov
Cc: Jani Nikula
Cc: Mike Rapoport
---
drivers/video/fbdev/neofb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/fb
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused code/variables
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Xiaofei Tan
Cc: Arnd Bergmann
---
drivers/video/fbdev/mx3fb.c | 13 -
1 file changed, 8 insertions(+), 5 delet
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused variables/code
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/riva/fbdev.c | 9 -
drivers/video/fbdev/riva/riva_hw.c | 28
2 files changed, 12 insert
Fix kernel-doc comments.
Signed-off-by: Sam Ravnborg
Cc: Ferenc Bakonyi
Cc: linux-nvi...@lists.surfsouth.com
---
drivers/video/fbdev/hgafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
index a45fcff1461f..69af
Fix W=1 warning by commenting unused SiS_TVDelay* variables.
The SiS_TVDelay* variables seem to contain some magic numbers
so looks like data worth keeping around but not as code we build.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/oem310.h | 2 ++
1 file c
Fix W=1 warnings about unused assignment.
Fixed by dropping the assignment and deleting the local variable.
Signed-off-by: Sam Ravnborg
Cc: Florian Tobias Schandinat
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/via/lcd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Fix W=1 warning about unused assignment.
Fix by dropping the local variable.
Signed-off-by: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Arnd Bergmann
---
drivers/video/fbdev/tdfxfb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
init.h define static symbols, so should only be included
once. Drop the include from sis.h as it is not needed.
This fixes a lot of warnings seen with a W=1 build.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/sis.h | 1 -
1 file changed, 1 deletion(-)
diff --
Fix several W=1 warnings.
This removes a lot of unused code - which is always a good thing to do.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/init.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/driver
Fix W=1 warning by dropping unused variable
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/sis_main.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index 03c7
Fix W=1 about variables assigned but never used.
- One variable is only used when CONFIG_FB_ATY_GENERIC_LCD is defined
Fix so variable is only defined with CONFIG_FB_ATY_GENERIC_LCD
- Several variables was only assigned by a call to aty_ld_le32().
Drop the variables but keep the call to aty_ld_
Quoting Matthew Auld (2020-11-27 12:04:42)
> From: Daniele Ceraolo Spurio
>
> These functions are independent from the backend used and can therefore
> be split out of the exelists submission file, so they can be re-used by
> the upcoming GuC submission backend.
>
> Based on a patch by Chris Wil
Fix W=1 warnings about variables assigned but never used.
- Drop variables that was never used
- Avoid using a local variable by moving the expression to an if
condition
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Joe Perches
Cc: Vaibhav
Fix W=1 about variable that is asssigned a value but never used.
The variable was indeed never used so delete it.
Keep the call to radeon_probe_i2c_connector() as it may have
side-effects. It is unlikely but I could not verify that is was safe to
drop the call.
Signed-off-by: Sam Ravnborg
Cc: Be
Fix W=1 warnings by updating kernel-doc to follow the correct syntax.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Alexander A. Klimov"
---
drivers/video/fbdev/core/fb_notify.c | 3 ++-
drivers/video/fbdev/core/fbmon.c
Replacing DPRINTK() statements with pr_debug fixes
W=1 warnings.
And moves to a more standard logging setup at the same time.
Signed-off-by: Sam Ravnborg
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Jiri Slaby
Cc: Peilin Ye
Cc: Tetsuo Handa
Cc
Fix trivial W=1 warnings.
Update kernel-doc to avoid the warnings.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: linux-fb...@vger.kernel.org
---
drivers/video/of_display_timing.c | 1 +
drivers/video/of_videomode.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --g
Following the great work of Lee Jones in other subsystems
here is a set of patches that address all remaining W=1
warnings in drivers/video/.
Lee Jones already fixed all warnings in video/backlight/ so
this is mostly fbdev related fixes.
The general approach used were:
- Fix kernel-doc, this is of
Quoting Matthew Auld (2020-11-27 12:04:41)
> From: Chris Wilson
>
> We want to separate the utility functions for controlling the logical
> ring context from the execlists submission mechanism (which is an
> overgrown scheduler).
>
> This is similar to Daniele's work to split up the files, but b
Quoting Matthew Auld (2020-11-27 12:04:40)
> From: Chris Wilson
>
> Cleanup intel_lrc.h by moving some of the residual common register
> definitions into intel_lrc_reg.h, prior to rebranding and splitting off
> the submission backends.
>
> v2: keep the SCHEDULE enum in the old file, since it is
Quoting Matthew Auld (2020-11-27 12:04:37)
> In igt_ppgtt_sanity_check we should also exercise the non-contiguous
> option for LMEM, since this will give us slightly different sg layouts
> and alignment.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
-Chris
___
Quoting t...@redhat.com (2020-11-27 16:28:28)
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device
Quoting Matthew Auld (2020-11-27 12:06:08)
> +int
> +i915_gem_create_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct create_ext ext_data = { .i915 = i915 };
> + struct drm_i9
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on char-misc/char-misc-testing v5.10-rc5]
[cannot apply to hnaz-linux-mm/master next-20201127]
[If your patch is applied to the wrong git tree, kindly drop us a note
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c | 2 +-
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentati
On Fri, Nov 27, 2020 at 04:19:20PM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> > Hi Daniel, Jani,
> >
> > is it ok to merge this patch along with 2/2 via the i915 tree?
>
> Ack from mesa (userspace in general, but mesa is kinda mandatory) is
> missin
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire u
Both Christoph Hellwig and Jason Gunthorpe suggested that usage of
follow_pfn by modules should be locked down more. To do so callers
need to be able to pass the mmu_notifier subscription corresponding
to the mm_struct to follow_pfn().
This patch does the rote work of doing that in the kvm subsyst
The only safe way for non core/arch code to use follow_pfn() is
together with an mmu_notifier subscription. follow_pfn() is already
marked as _GPL and the kerneldoc explains this restriction.
This patch here enforces all this by adding a mmu_notifier argument
and verifying that it is registered fo
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedic
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.
But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, sinc
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings,
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is lo
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from ded
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Hans Verkuil
Acked-by: Mauro Carvalho Chehab
Acked-by: T
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical se
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: And
These are persistent, not just for the duration of a dma operation.
Reviewed-by: Oded Gabbay
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
C
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pt
Hi all
Another update of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2:
https://lore.kernel.org/dri-devel/20201009075934.35090
Purely conjecture, but I think the original locking inversion with the
legacy page flip code between flipping and ttm's bo move function
shoudn't exist anymore with atomic: With atomic the bo pinning and
actual modeset commit is completely separated in the code patsh.
This annotation was originall
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index e67cec8f
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f9c81bc21ba4..301e93c9e
On 11/27/20 9:59 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
On 11/25/20 11:36 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
Am 25.11.20 um 11:40 schrieb Daniel Vetter:
On Tue, Nov 24, 2020 at 05:44:0
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
komeda_component_get_old_state() technically can return a NULL
pointer. komeda_compiz_set_input() even warns when this happens, but
then proceeeds to use that NULL pointer tocompare memory content there
agains the
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
ret is not actually read after this (only written in one case then
returned), so this assign line is useless. This removes that assignment.
Signed-off-by: Carsten Haitzler
Reviewed-by: Steven Price
---
dri
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
> Hi Tomi,
>
> On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
>> Hi Aaro, Ivaylo,
>>
>> On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
>>
>>> Is there any progress on the issue? I tried 5.9.1 and still nothing
>>> displayed.
>>
>> Can you test the attached
On Wed, Oct 28, 2020 at 01:11:51PM +0100, Christian König wrote:
> Am 28.10.20 um 12:31 schrieb Daniel Vetter:
> > Not technically a problem for ttm, but very likely a driver bug and
> > pretty big time confusing for reviewing code.
> >
> > So warn about it, both at cleanup time (so we catch these
On Fri, Nov 27, 2020 at 09:12:25AM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote:
> > I feel like this is ready for some wider soaking. Since the remaining bits
> > are all kinda connnected probably simplest if it all goes through -mm.
>
> Did you fi
On 11/27/20 10:04 AM, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote:
On 11/25/20 4:04 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
wrote:
On 11/24/20 9:49 AM, Daniel Vetter wrote:
On Sat, Nov 21, 2020 at 12:21:20AM -050
On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> Hi Daniel, Jani,
>
> is it ok to merge this patch along with 2/2 via the i915 tree?
Ack from mesa (userspace in general, but mesa is kinda mandatory) is
missing I think. With that
Acked-by: Daniel Vetter
>
> --Imre
>
> On Mon, Nov
On Fri, Nov 27, 2020 at 10:15:49AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 27, 2020 at 4:18 AM Randy Dunlap wrote:
> > It looks like SPARC64 requires FB_ATY_CT to build without errors,
> > so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
> > instead of using "default y if
On Fri, Nov 27, 2020 at 11:14:42AM +0800, Tian Tao wrote:
> if the driver uses drmm_vram_helper_init, there is no need to
> call drm_vram_helper_release_mm when the drm module get unloaded,
> as this will done automagically.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/vboxvideo/vbox_ttm.
On Fri, Nov 27, 2020 at 03:49:31PM +0100, Christian König wrote:
> Am 27.11.20 um 15:46 schrieb Daniel Vetter:
> > On Fri, Nov 27, 2020 at 3:10 PM Christian König
> > wrote:
> > > Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > > > Oops sorry for delay LGTM
> > > >
> > > > Reviewed-by: Dave Airlie
On Fri, Nov 27, 2020 at 03:11:05PM +0100, Christian König wrote:
> Ping? Daniel any more ideas on this or should we push it?
Occasionally I bit more prose would be nice about why things changed or
so. Iirc the reason I asked about using ttm_sg_tt_init is that it makes it
easier to convince ourselv
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 4:04 AM, Daniel Vetter wrote:
> > On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky
> > wrote:
> > >
> > > On 11/24/20 9:49 AM, Daniel Vetter wrote:
> > > > On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzo
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote:
>
> On 11/25/20 11:36 AM, Daniel Vetter wrote:
> > On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote:
> > > Am 25.11.20 um 11:40 schrieb Daniel Vetter:
> > > > On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König
Hi Dave,
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.10-rc7
for you to fetch changes up to bf3a3cdcad40e592
On Thu, Nov 26, 2020 at 09:44:02AM +, Jonas Mark (BT-FIR/ENG1-Grb) wrote:
> Hi Daniel,
>
> > > Thank you very much for your feedback. We appreciate it.
> > >
> > > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > >>> index 9bf5ad6d1
Am 27.11.20 um 15:46 schrieb Daniel Vetter:
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
Am 27.11.20 um 09:31 schrieb Dave Airlie:
Oops sorry for delay LGTM
Reviewed-by: Dave Airlie
Thanks.
On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 3:34 PM Chri
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
>
> Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > Oops sorry for delay LGTM
> >
> > Reviewed-by: Dave Airlie
>
> Thanks.
>
> >
> > On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
> >> On Wed, Nov 25, 2020 at 3:34 PM Christian König
> >>
Quoting Matthew Auld (2020-11-27 12:07:16)
> From: Venkata Ramana Nayana
>
> This is to fix a bug in upstream
> commit a6326a4f8ffb ("drm/i915/gt: Keep a no-frills swappable copy of the
> default context state")
>
> We allocate context state obj ce->state from lmem, so in
> __engines_record_de
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
>
> Hi Chun-Kuang,
>
> On 20/11/2020 00:46, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > I've provided the example for why of this patch. How do you think
> > about this patch?
> >
>
> Patch looks good to me. If you want to take it throu
Quoting Matthew Auld (2020-11-27 12:07:13)
> From: Tvrtko Ursulin
>
> Current code uses jiffie time to do the accounting and then does:
>
> diff = jiffies - start;
> msec = diff * 1000 / HZ;
> ...
> atomic_long_add(msec, &i915->time_swap_out_ms);
>
> If we assume jiffie can be as non-gr
Quoting Matthew Auld (2020-11-27 12:07:06)
> From: CQ Tang
>
> When cache_level is NONE, we check HAS_LLC(i915).
> But additionally for DGFX, we also need to check
> HAS_SNOOP(i915) on system memory object to use
> I915_BO_CACHE_COHERENT_FOR_READ. on dg1, has_llc=0, and
> has_snoop=1. Otherwise,
Quoting Matthew Auld (2020-11-27 12:07:04)
> From: Venkata Ramana Nayana
>
> In suspend mode use blitter eviction before disable the runtime
> interrupts and in resume use blitter after the gem resume happens.
Consider add it to the suspend prepare function.
-Chris
__
1 - 100 of 337 matches
Mail list logo
