Hi Dave,
On Wed, Mar 10, 2021 at 09:50:29AM +1000, Dave Airlie wrote:
> I'm mostly sending this to the -misc maintainers because
> drm-misc-fixes is based on rc1 at present.
>
> This needs to be *rebased* not merged up to 5.12-rc2. Merging will
> still have the bad landmine commits in the bisect
The driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/g
The driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/drm_writeback.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/d
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c:76:14-15: WARNING
comparing pointer to 0.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote:
> Hey
>
> On request of Noralf, I picked up the patches and prepared v5. Works fine with
> Xorg, if configured according to:
> https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
> If anyone knows how to ma
On Tue, Mar 09, 2021 at 04:53:48PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Minchan Kim
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/powerpc/platforms/pseries/cmm.c | 2 +-
> drivers/dma-buf/d
hi,
sorry the option is actually -cl-no-stdinc. you can add it to
'target_compiler_options'.
I should have a patch ready soon(tm), but time is scarce.
Jan
On Sun, Mar 7, 2021 at 9:51 PM Dieter Nützel wrote:
> Hello Jan,
>
> I very much appreciate your advice.
> Tried several places...
> ...whe
From: Quanyang Wang
The Runtime PM subsystem will force the device "fd4a.zynqmp-display"
to enter suspend state while booting if the following conditions are met:
- the usage counter is zero (pm_runtime_get_sync hasn't been called yet)
- no 'active' children (no zynqmp-dp-snd-xx node under dp
Noralf Trønnes wrote:
> > The u16 index parameter to gud_usb_transfer() and at least also
> > gud_usb_{get,set,get_u8,set_u8}() is eventually passed in u16 value
> > in the call to gud_usb_control_msg(), which had me confused for a bit.
> >
> > What do you think about renaming all of those parame
On Tue, Mar 09, 2021 at 04:53:39PM +0100, Christoph Hellwig wrote:
> this series first renames the existing alloc_anon_inode to
> alloc_anon_inode_sb to clearly mark it as requiring a superblock.
>
> It then adds a new alloc_anon_inode that works on the anon_inode
> file system super block, thus r
Hi Alistair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on s390/features]
[also build test ERROR on linus/master v5.12-rc2 next-20210309]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
Hi Alistair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on s390/features]
[also build test ERROR on kselftest/next linus/master v5.12-rc2 next-20210309]
[cannot apply to hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note
Hey maintainers,
I'm mostly sending this to the -misc maintainers because
drm-misc-fixes is based on rc1 at present.
This needs to be *rebased* not merged up to 5.12-rc2. Merging will
still have the bad landmine commits in the bisect history. This is a
very special case.
But otherwise to any oth
Some NVIDIA GPUs do not support direct atomic access to system memory
via PCIe. Instead this must be emulated by granting the GPU exclusive
access to the memory. This is achieved by replacing CPU page table
entries with special swap entries that fault on userspace access.
The driver then grants th
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouve
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > I think the proper fix would be to not rely on custom hooks into a
> > particular
> > IOMMU driver, but to instead ensure that the amdgpu driver can do everything
> > it needs through the regular linux/iommu.h interface
https://bugzilla.kernel.org/show_bug.cgi?id=212107
Martin (martin...@gmx.com) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You may reply to
https://bugzilla.kernel.org/show_bug.cgi?id=212107
Martin (martin...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=212107
--- Comment #8 from Martin (martin...@gmx.com) ---
(In reply to Dieter Nützel from comment #7)
> Addendum (@Alex)
> Maybe we could do someting about the reported fan speed.
> Zero (0) if stopped.
>
> @Martin
> You can verify the fan speed (raise)
On Tue, Mar 09, 2021 at 04:53:41PM +0100, Christoph Hellwig wrote:
> Add a new alloc_anon_inode helper that allocates an inode on
> the anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Gao Xiang
Thanks,
Gao Xiang
___
dri-dev
On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
>
> Signed-off-by: Christoph Hellwig
> ---
That is a nice idea as well to avoid sb by introducing an unique
f
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.11.4 |5.11.5
--
You may reply
Am 09.03.21 um 18:59 schrieb Alex Deucher:
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
wrote:
Hi Felix,
On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
I think the proper fix would be to not rely on custom hooks into a particular
IOMMU driver, but to instead ensure t
Den 09.03.2021 19.07, skrev Noralf Trønnes:
>
>
> Den 09.03.2021 15.02, skrev Peter Stuge:
>> Hello Noralf,
>>
>> I've made some progress with my test device. I'm implementing R1
>> first and once that works I'll test RGB111 as well. Along the way
>> I've found a couple of things in the code:
>
Den 09.03.2021 15.02, skrev Peter Stuge:
> Hello Noralf,
>
> I've made some progress with my test device. I'm implementing R1
> first and once that works I'll test RGB111 as well. Along the way
> I've found a couple of things in the code:
>
> Noralf Trønnes wrote:
>> +++ b/drivers/gpu/drm/gud/g
On Tue, Mar 9, 2021 at 12:55 PM Jean-Philippe Brucker
wrote:
>
> Hi Felix,
>
> On Tue, Mar 09, 2021 at 11:30:19AM -0500, Felix Kuehling wrote:
> > > I think the proper fix would be to not rely on custom hooks into a
> > > particular
> > > IOMMU driver, but to instead ensure that the amdgpu driver
Neil Armstrong writes:
> On 09/03/2021 18:13, Kevin Hilman wrote:
>> Hi Neil,
>>
>> Neil Armstrong writes:
>>
>>> On 02/03/2021 05:22, Artem Lapkin wrote:
Problem: random stucks on reboot stage about 1/20 stuck/reboots
// debug kernel log
[4.496660] reboot: kernel restart pr
On 09/03/2021 18:13, Kevin Hilman wrote:
> Hi Neil,
>
> Neil Armstrong writes:
>
>> On 02/03/2021 05:22, Artem Lapkin wrote:
>>> Problem: random stucks on reboot stage about 1/20 stuck/reboots
>>> // debug kernel log
>>> [4.496660] reboot: kernel restart prepare CMD:(null)
>>> [4.498114]
Hi Neil,
Neil Armstrong writes:
> On 02/03/2021 05:22, Artem Lapkin wrote:
>> Problem: random stucks on reboot stage about 1/20 stuck/reboots
>> // debug kernel log
>> [4.496660] reboot: kernel restart prepare CMD:(null)
>> [4.498114] meson_ee_pwrc c883c000.system-controller:power-contro
Hi drm-misc maintainers,
I have this series:
GUD USB Display driver
https://patchwork.freedesktop.org/series/87044/#rev3
That depends on this drm-misc-fixes commit:
3a3fe21242a3 ("drm: Use USB controller's DMA mask when importing dmabufs")
I would would be nice if it would show up in drm-misc-
On Tue, Mar 09, 2021 at 04:53:39PM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series first renames the existing alloc_anon_inode to
> alloc_anon_inode_sb to clearly mark it as requiring a superblock.
>
> It then adds a new alloc_anon_inode that works on the anon_inode
> file system super
Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in functi
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/misc/vmw_balloon.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw
Am 2021-03-09 um 3:58 a.m. schrieb Arnd Bergmann:
> On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
>> against the exported functions. If the GPU driver is built-in but the
>> IOMMU driver is a loadable module, the kfd_
On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
>
> Signed-off-by: Christoph Hellwig
> arch/powerpc/platforms/pseries/cmm.c | 27 ++-
> 1 file changed, 2 insertions(+), 25 deletions(-)
>
> diff --git a/arc
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
drivers/virtio/virtio_balloon.c | 30 +++---
1 file changed, 3 insertions(+), 27 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/
On 09.03.21 16:53, Christoph Hellwig wrote:
Just use the generic anon_inode file system.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/c
On 09.03.21 16:53, Christoph Hellwig wrote:
Add a new alloc_anon_inode helper that allocates an inode on
the anon_inode file system.
Signed-off-by: Christoph Hellwig
---
fs/anon_inodes.c| 15 +--
include/linux/anon_inodes.h | 1 +
2 files changed, 14 insertions(+),
On 09.03.21 16:53, Christoph Hellwig wrote:
Rename alloc_inode to free the name for a new variant that does not
need boilerplate to create a super_block first.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/platforms/pseries/cmm.c | 2 +-
drivers/dma-buf/dma-buf.c| 2 +-
driv
https://bugzilla.kernel.org/show_bug.cgi?id=212107
--- Comment #7 from Dieter Nützel (die...@nuetzel-hh.de) ---
Addendum (@Alex)
Maybe we could do someting about the reported fan speed.
Zero (0) if stopped.
@Martin
You can verify the fan speed (raise) if you put load on your gfx card.
--
You ma
https://bugzilla.kernel.org/show_bug.cgi?id=212107
--- Comment #6 from Dieter Nützel (die...@nuetzel-hh.de) ---
(In reply to Martin from comment #5)
> (In reply to Alex Deucher from comment #4)
> > The driver turns off the fans for acoustic reasons if the OEM enabled
> > support for the feature in
https://bugzilla.kernel.org/show_bug.cgi?id=212107
--- Comment #5 from Martin (martin...@gmx.com) ---
(In reply to Alex Deucher from comment #4)
> The driver turns off the fans for acoustic reasons if the OEM enabled
> support for the feature in the vbios. They will still go on when the
> tempera
On 3/9/21 3:49 AM, Peter Zijlstra wrote:
On Mon, Mar 08, 2021 at 03:54:55PM -0500, Zack Rusin wrote:
Add an interruptible version of down_write. It's the other
side of the already implemented down_read_interruptible.
It allows drivers which used custom locking code to
support interruptible rw se
Hi Rob,
Thanks for your comments.
>> Add binding changes for HDCP in the MHDP8546 DPI/DP bridge binding.
>> This binding is not used in any upstreamed DTS yet, so changing
>> index of property 'j721e-intg' should not affect anything.
>
>TI folks might disagree, but weren't Cc'ed.
Kishon and Nikhi
Hello,
syzbot found the following issue on:
HEAD commit:144c79ef Merge tag 'perf-tools-fixes-for-v5.12-2020-03-07'..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16972ea2d0
kernel config: https://syzkaller.appspot.com/x/.config?x=9008fb06fa15d749
das
Rob,
Any feedback on this? The patches were sent about two weeks ago.
On Thu, 25 Feb 2021 at 01:47, Dmitry Baryshkov
wrote:
>
> Fix setting min/max DSI PLL rate for the V4.1 7nm DSI PLL (used on
> sm8250). Current code checks for pll->type before it is set (as it is
> set in the msm_dsi_pll_init
Hello Noralf,
I've made some progress with my test device. I'm implementing R1
first and once that works I'll test RGB111 as well. Along the way
I've found a couple of things in the code:
Noralf Trønnes wrote:
> +++ b/drivers/gpu/drm/gud/gud_drv.c
..
> +static int gud_probe(struct usb_interface *
Neatly reduce displayid boilerplate in code. Remove excessive debug
logging while at it, no other functional changes.
The old displayid iterator becomes unused; remove it as well as make
drm_find_displayid_extension() static.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 6 +
Neatly reduce displayid boilerplate in code. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fbaa7d679cb2.
Neatly reduce displayid boilerplate in code. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 58e61f792bc7..f
Iterating DisplayID blocks across sections (in EDID extensions) is
unnecessarily complicated for the caller. Implement DisplayID iterators
to go through all blocks in all sections.
Usage example:
const struct displayid_block *block;
struct displayid_iter iter;
displayid_i
We'll be adding more DisplayID specific functions going forward, so
start off by splitting out a few functions to a separate file.
We don't bother with exporting the functions; at least for now they
should be needed solely within drm.ko.
No functional changes.
Signed-off-by: Jani Nikula
---
dr
If there's no need to change it, it should be const. There's more to be
done, but start off with changes that make follow-up work easier. No
functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 58 ++---
include/drm/drm_displayid.h | 4
Iterating DisplayID is overcomplicated as it is, and it's not getting
easier when we eventually add support for DisplayID from DDC 0xA4
instead of EDID extensions. Prepare by abstracting the complexities away
from EDID code.
Untested, let's see what our CI thinks. ;)
Jani Nikula (6):
drm/edid:
>-Original Message-
>From: dri-devel On Behalf Of
>Dave Airlie
>Sent: Sunday, March 7, 2021 8:49 PM
>To: dri-devel@lists.freedesktop.org
>Cc: skeg...@gmail.com
>Subject: [PATCH] drm/nouveau: fix dma syncing for loops
>
>From: Dave Airlie
>
>The index variable should only be increased in
On Fri, Mar 05, 2021 at 11:18:19PM +0800, xndcn wrote:
> virtio_gpu_object array is not freed or unlocked in some
> failed cases.
Pushed to drm-misc-next.
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskt
On Tue, Mar 09, 2021 at 11:14:58PM +1100, Alistair Popple wrote:
> -static inline struct page *migration_entry_to_page(swp_entry_t entry)
> -{
> - struct page *p = pfn_to_page(swp_offset(entry));
> - /*
> - * Any use of migration entries may only occur while the
> - * correspondin
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 126 +-
lib/test_hmm_uapi.h| 2 +
tools/testing/selfte
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the rest of the unmap
functionality of try_to_unma
The behaviour of try_to_unmap_one() is difficult to follow because it
performs different operations based on a fairly large set of flags used
in different combinations.
TTU_MUNLOCK is one such flag. However it is exclusively used by
try_to_munlock() which specifies no other flags. Therefore rather
Both migration and device private pages use special swap entries that
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for both read and write entry
creation.
Signed-off-by
Remove the migration and device private entry_to_page() and
entry_to_pfn() inline functions and instead open code them directly.
This results in shorter code which is easier to understand.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
---
v4:
* Added pfn_swap_entry_to_page()
* Rei
This is the fifth version of a series to add support to Nouveau for atomic
memory operations on OpenCL shared virtual memory (SVM) regions.
The main changes since v4 are a rebase onto v5.12-rc2, the removal of
check_device_exclusive_range() and the addition of MMU_NOTIFY_EXCLUSIVE
which makes the
Hi Carsten, (+James for komeda)
Thanks for typing this up.
On Fri, Mar 05, 2021 at 04:38:53PM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> When setting up a readback conenctor that writes data back to memory
s/readback conenctor/writeback connector/ (similar in the
Fix the following coccicheck warnings:
./drivers/scsi/csiostor/csio_scsi.c:150:9-10: WARNING: return of 0/1 in
function 'csio_scsi_itnexus_loss_error' with return type bool.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/scsi/csiostor/csio_scsi.c | 4 ++--
1 file changed, 2
On Mon, 8 Mar 2021 13:34:21 +0100
Simon Ser wrote:
> Document all of the DRM_CAP_* defines.
>
> v2 (Pekka):
> - Describe what the bit depth is
> - Expand on preferred dumb buffer memory access patterns
> - Explain what a PRIME buffer is
> - Mention DRM_IOCTL_PRIME_FD_TO_HANDLE and DRM_IOCTL_PRI
On Mon, 8 Mar 2021 16:52:58 -0800
"Navare, Manasi" wrote:
> On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote:
> > On Wed, 3 Mar 2021 12:44:33 -0800
> > "Navare, Manasi" wrote:
> >
> > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote:
> > > > On Tue, 2 Mar 2021
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
>
On Mon, Mar 08, 2021 at 03:54:55PM -0500, Zack Rusin wrote:
> Add an interruptible version of down_write. It's the other
> side of the already implemented down_read_interruptible.
> It allows drivers which used custom locking code to
> support interruptible rw semaphores to switch over
> to rwsem.
On 02/03/2021 05:22, Artem Lapkin wrote:
> Problem: random stucks on reboot stage about 1/20 stuck/reboots
> // debug kernel log
> [4.496660] reboot: kernel restart prepare CMD:(null)
> [4.498114] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [4.503949]
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c:896:68-73:
WARNING: conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c | 2 +-
1 file changed, 1 insertion
>> >>> Is this a property of the hardware, that is, are there multiple versions
>> >>> of this IP core covered by the same compatible string that support HDCP
>> >>> 1.4 only, DHCP 2.2 only or both ? Or is it a way to select what a given
>> >>> system will offer ?[]
>> >>
>> >> MHDP hardware suppor
74 matches
Mail list logo
