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
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
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
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
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
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
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
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 |
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
---
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
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
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
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.
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
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
---
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
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
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 ++--
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
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
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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,
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
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
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
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
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:
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
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:
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
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
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:
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
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
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
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
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
---
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
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
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
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
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
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
> ---
>
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
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
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
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
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
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
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
>
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
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, >time_swap_out_ms);
>
> If we assume jiffie can be as
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
