Re: don't base trees on 5.12-rc1
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 history. This is a > very special case. I'm sorry, I'm not entirely sure I get this. -rc1 is still in the -rc2 history, so how would that change anything in the bisect history? Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb: Use simple encoder
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/gpu/drm/mxsfb/mxsfb_kms.c
index 300e7bab..0975930 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "mxsfb_drv.h"
@@ -390,14 +391,6 @@ static const struct drm_crtc_funcs mxsfb_crtc_funcs = {
};
/*
-
- * Encoder
- */
-
-static const struct drm_encoder_funcs mxsfb_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
-/*
-
* Planes
*/
@@ -584,6 +577,5 @@ int mxsfb_kms_init(struct mxsfb_drm_private *mxsfb)
return ret;
encoder->possible_crtcs = drm_crtc_mask(crtc);
- return drm_encoder_init(mxsfb->drm, encoder, _encoder_funcs,
- DRM_MODE_ENCODER_NONE, NULL);
+ return drm_simple_encoder_init(mxsfb->drm, encoder,
DRM_MODE_ENCODER_NONE);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: writeback: Use simple encoder
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/drm_writeback.c
index dccf4504..dea9b25 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
/**
@@ -145,10 +146,6 @@ static int create_writeback_properties(struct drm_device
*dev)
return 0;
}
-static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
/**
* drm_writeback_connector_init - Initialize a writeback connector and its
properties
* @dev: DRM device
@@ -190,9 +187,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
return PTR_ERR(blob);
drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, _connector->encoder,
- _writeback_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
+ ret = drm_simple_encoder_init(dev, _connector->encoder,
+ DRM_MODE_ENCODER_VIRTUAL);
if (ret)
goto fail;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: fix warning comparing pointer to 0
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 --git a/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c b/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c index c6a1cd8..69211f5 100644 --- a/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c +++ b/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c @@ -73,7 +73,7 @@ static void get_qp_set(qp_set qps, enum colour_mode cm, enum bits_per_comp bpc, TABLE_CASE(420, 12, min); } - if (table == 0) + if (!table) return; index = (bpp - table[0].bpp) * 2; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] drm: add simpledrm driver
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 make Xorg pick it up dynamically without such a static > configuration, please let me know. > > Thanks > David > > David Herrmann (7): > x86/sysfb: add support for 64bit EFI lfb_base > x86/sysfb: fix lfb_size calculation > of/platform: expose of_platform_device_destroy() > video: add generic framebuffer eviction > drm: switch to sysfb_evict_conflicts() > drm: add SimpleDRM driver > drm/simpledrm: add fbdev fallback support > > MAINTAINERS | 6 + > arch/x86/kernel/sysfb_simplefb.c | 39 ++- > drivers/gpu/drm/Kconfig | 3 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 24 +- > drivers/gpu/drm/bochs/bochs_drv.c| 19 +- > drivers/gpu/drm/i915/i915_drv.c | 73 +--- > drivers/gpu/drm/mgag200/mgag200_drv.c| 27 +- > drivers/gpu/drm/mgag200/mgag200_main.c | 9 - > drivers/gpu/drm/nouveau/nouveau_drm.c| 33 +- > drivers/gpu/drm/radeon/radeon_drv.c | 24 +- > drivers/gpu/drm/simpledrm/Kconfig| 19 ++ > drivers/gpu/drm/simpledrm/Makefile | 9 + > drivers/gpu/drm/simpledrm/simpledrm.h| 91 + > drivers/gpu/drm/simpledrm/simpledrm_damage.c | 194 +++ > drivers/gpu/drm/simpledrm/simpledrm_drv.c| 477 > +++ > drivers/gpu/drm/simpledrm/simpledrm_fbdev.c | 143 > drivers/gpu/drm/simpledrm/simpledrm_gem.c| 109 ++ > drivers/gpu/drm/simpledrm/simpledrm_kms.c| 270 +++ > drivers/gpu/drm/simpledrm/simpledrm_of.c | 265 +++ > drivers/gpu/drm/sun4i/sun4i_drv.c| 24 +- > drivers/gpu/drm/vc4/vc4_drv.c| 25 +- > drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 24 +- > drivers/of/platform.c| 35 +- > drivers/video/Kconfig| 4 + > drivers/video/Makefile | 1 + > drivers/video/sysfb.c| 327 ++ > include/linux/of_platform.h | 1 + > include/linux/sysfb.h| 34 ++ > 29 files changed, 2054 insertions(+), 256 deletions(-) > create mode 100644 drivers/gpu/drm/simpledrm/Kconfig > create mode 100644 drivers/gpu/drm/simpledrm/Makefile > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm.h > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_damage.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_drv.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_fbdev.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_gem.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_kms.c > create mode 100644 drivers/gpu/drm/simpledrm/simpledrm_of.c > create mode 100644 drivers/video/sysfb.c > create mode 100644 include/linux/sysfb.h > > Hi I am kind of curious as I do have interest in seeing this merged as well. There is an email in this thread from 2018, but when I tried to import an mbox file from the whole month for August 2018, for some reason, kmail doesn't see the sender and mailing list recipient in that one, so I will reply to this one, because I was able to import this into my mail client. https://www.spinics.net/lists/dri-devel/msg185519.html I was able to get this to build against Linux 4.8, but not against a newer version, some headers seem to have been split, and some things are off by 8 and other things. I could NOT find a git repo, but I was able to find the newest patches I could find, and import those with git am against 4.8 with some tweaks. If that is needed, I can link it, but only if you want. However in QEMU I wasn't able to figure out how to make it create a /dev/dri/card0 device, even after blacklisting the other modules for qxl, cirrus, etc, and then modprobe-ing simpledrm In my view something like this is would be useful. There still could be hardware devices that don't have modesetting support (like vmvga in qemu/virt-manager as an example). And most wayland servers need a /dev/dri/card0 device as well as a potential user-mode TTY replacement would also need /dev/dri/card0 I will admit I unfortunately failed to get it to build against master. I couldn't figure out some of the changes, where some new structs were off by a factor of 8. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] zsmalloc: remove the zsmalloc file system
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.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb
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/dma-buf.c| 2 +-
> drivers/gpu/drm/drm_drv.c| 2 +-
> drivers/misc/cxl/api.c | 2 +-
> drivers/misc/vmw_balloon.c | 2 +-
> drivers/scsi/cxlflash/ocxl_hw.c | 2 +-
> drivers/virtio/virtio_balloon.c | 2 +-
> fs/aio.c | 2 +-
> fs/anon_inodes.c | 4 ++--
> fs/libfs.c | 2 +-
> include/linux/fs.h | 2 +-
> kernel/resource.c| 2 +-
> mm/z3fold.c | 2 +-
> mm/zsmalloc.c| 2 +-
> 14 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/cmm.c
> b/arch/powerpc/platforms/pseries/cmm.c
> index 45a3a3022a85c9..6d36b858b14df1 100644
> --- a/arch/powerpc/platforms/pseries/cmm.c
> +++ b/arch/powerpc/platforms/pseries/cmm.c
> @@ -580,7 +580,7 @@ static int cmm_balloon_compaction_init(void)
> return rc;
> }
>
> - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + b_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
> if (IS_ERR(b_dev_info.inode)) {
> rc = PTR_ERR(b_dev_info.inode);
> b_dev_info.inode = NULL;
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb4..dedcc9483352dc 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -445,7 +445,7 @@ static inline int is_dma_buf_file(struct file *file)
> static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
> {
> struct file *file;
> - struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
> + struct inode *inode = alloc_anon_inode_sb(dma_buf_mnt->mnt_sb);
>
> if (IS_ERR(inode))
> return ERR_CAST(inode);
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 20d22e41d7ce74..87e7214a8e3565 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -519,7 +519,7 @@ static struct inode *drm_fs_inode_new(void)
> return ERR_PTR(r);
> }
>
> - inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
> + inode = alloc_anon_inode_sb(drm_fs_mnt->mnt_sb);
> if (IS_ERR(inode))
> simple_release_fs(_fs_mnt, _fs_cnt);
>
> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
> index b493de962153ba..2efbf6c98028ef 100644
> --- a/drivers/misc/cxl/api.c
> +++ b/drivers/misc/cxl/api.c
> @@ -73,7 +73,7 @@ static struct file *cxl_getfile(const char *name,
> goto err_module;
> }
>
> - inode = alloc_anon_inode(cxl_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(cxl_vfs_mount->mnt_sb);
> if (IS_ERR(inode)) {
> file = ERR_CAST(inode);
> goto err_fs;
> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> index b837e7eba5f7dc..5d057a05ddbee8 100644
> --- a/drivers/misc/vmw_balloon.c
> +++ b/drivers/misc/vmw_balloon.c
> @@ -1900,7 +1900,7 @@ static __init int vmballoon_compaction_init(struct
> vmballoon *b)
> return PTR_ERR(vmballoon_mnt);
>
> b->b_dev_info.migratepage = vmballoon_migratepage;
> - b->b_dev_info.inode = alloc_anon_inode(vmballoon_mnt->mnt_sb);
> + b->b_dev_info.inode = alloc_anon_inode_sb(vmballoon_mnt->mnt_sb);
>
> if (IS_ERR(b->b_dev_info.inode))
> return PTR_ERR(b->b_dev_info.inode);
> diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
> index 244fc27215dc79..40184ed926b557 100644
> --- a/drivers/scsi/cxlflash/ocxl_hw.c
> +++ b/drivers/scsi/cxlflash/ocxl_hw.c
> @@ -88,7 +88,7 @@ static struct file *ocxlflash_getfile(struct device *dev,
> const char *name,
> goto err2;
> }
>
> - inode = alloc_anon_inode(ocxlflash_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(ocxlflash_vfs_mount->mnt_sb);
> if (IS_ERR(inode)) {
> rc = PTR_ERR(inode);
> dev_err(dev, "%s: alloc_anon_inode failed rc=%d\n",
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 8985fc2cea8615..cae76ee5bdd688 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -916,7 +916,7 @@ static int virtballoon_probe(struct virtio_device *vdev)
> }
>
> vb->vb_dev_info.migratepage = virtballoon_migratepage;
> - vb->vb_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + vb->vb_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
> if (IS_ERR(vb->vb_dev_info.inode)) {
> err = PTR_ERR(vb->vb_dev_info.inode);
> goto
Re: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile
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... > ...where to put it? > > Dieter > > Am 06.03.2021 17:56, schrieb Jan Vesely: > > Not Marek, but hope this answer will help. > > libclc uses clang CLC preprocessor on .ll files, llvm/clang-13 started > > including clc declarations by default (clang > > cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce), > > thus corrupting any .ll assembly files that are used by libclc. > > Inclusion of the default declarations can be turned off using a > > cmdline switch but that remains to be implemented in the libclc build > > system. > > manually adding '-cl-no-stdinc' should work as a workaround. > > > > Jan > > > > On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel > > wrote: > > > >> Hello Marek, > >> > >> can't compile anything, here. > >> Poor Intel Nehalem X3470. > >> > >> Trying LLVM 12-rc2 later. > >> > >> Greetings, > >> Dieter > >> > >> llvm-project/libclc> cd build && cmake ../ > >> -- The CXX compiler identification is GNU 10.2.1 > >> -- Detecting CXX compiler ABI info > >> -- Detecting CXX compiler ABI info - done > >> -- Check for working CXX compiler: /usr/bin/c++ - skipped > >> -- Detecting CXX compile features > >> -- Detecting CXX compile features - done > >> LLVM version: 13.0.0git > >> LLVM system libs: > >> LLVM libs: -lLLVM-13git > >> LLVM libdir: /usr/local/lib > >> LLVM bindir: /usr/local/bin > >> LLVM ld flags: -L/usr/local/lib > >> LLVM cxx flags: > >> > > > -I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions > >> > >> clang: /usr/local/bin/clang > >> llvm-as: /usr/local/bin/llvm-as > >> llvm-link: /usr/local/bin/llvm-link > >> opt: /usr/local/bin/opt > >> llvm-spirv: /usr/local/bin/llvm-spirv > >> > >> -- Check for working CLC compiler: /usr/local/bin/clang > >> -- Check for working CLC compiler: /usr/local/bin/clang -- works > >> -- Check for working LLAsm compiler: /usr/local/bin/llvm-as > >> -- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- > >> broken > >> CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message): > >> The LLAsm compiler "/usr/local/bin/llvm-as" is not able to > >> compile a > >> simple > >> test program. > >> > >> It fails with the following output: > >> > >> Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp > >> > >> Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && > >> /usr/bin/gmake > >> -f > >> CMakeFiles/cmTC_87af9.dir/build.make > >> CMakeFiles/cmTC_87af9.dir/build > >> > >> gmake[1]: Verzeichnis > >> „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird > >> betreten > >> > >> Building LLAsm object > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > >> > >> /usr/local/bin/clang -E -P -x cl > >> > >> > > /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll > >> > >> -o > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > >> > >> /usr/local/bin/llvm-as -o > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > >> > >> /usr/local/bin/llvm-as: > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error: > >> expected > >> top-level entity > >> > >> typedef unsigned char uchar; > >> > >> ^ > >> > >> gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86: > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1 > >> > >> gmake[1]: Verzeichnis > >> „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird > >> verlassen > >> > >> gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2 > >> > >> CMake will not be able to correctly generate this project. > >> Call Stack (most recent call first): > >> CMakeLists.txt:127 (enable_language) > >> > >> -- Configuring incomplete, errors occurred! > >> See also > >> "/opt/llvm-project/libclc/build/CMakeFiles/CMakeOutput.log". > >> See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeError.log". > >> > >> CMakeError.log > >> Determining if the LLAsm compiler works failed with the following > >> output: > >> Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp > >> > >> Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && > >> /usr/bin/gmake > >> -f CMakeFiles/cmTC_87af9.dir/build.make > >> CMakeFiles/cmTC_87af9.dir/build > >> gmake[1]: Verzeichnis > >> „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird > >> betreten > >> Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > >> /usr/local/bin/clang -E -P -x cl > >> > > /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll > >> > >> -o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > >> /usr/local/bin/llvm-as -o > >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > >>
[PATCH] drm: xlnx: call pm_runtime_get_sync before setting pixel clock
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 dpsub node)
- no other device in the same power domain (dpdma node has no
"power-domains = <_firmware PD_DP>" property)
So there is a scenario as below:
1) DP device enters suspend state <- call zynqmp_gpd_power_off
2) zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG
3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear
previous
VPLL_FRAC_CFG configuration
4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG
configuration is corrupted
>From above, we can see that pm_runtime_get_sync may clear register
VPLL_FRAC_CFG configuration and result the failure of clk enabling.
Putting pm_runtime_get_sync at the very beginning of the function
zynqmp_disp_crtc_atomic_enable can resolve this issue.
Signed-off-by: Quanyang Wang
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 148add0ca1d6..909e6c265406 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1445,9 +1445,10 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode = >state->adjusted_mode;
int ret, vrefresh;
+ pm_runtime_get_sync(disp->dev);
+
zynqmp_disp_crtc_setup_clock(crtc, adjusted_mode);
- pm_runtime_get_sync(disp->dev);
ret = clk_prepare_enable(disp->pclk);
if (ret) {
dev_err(disp->dev, "failed to enable a pixel clock\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/3] drm: Add GUD USB Display driver
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 parameters to wValue,
>
> Only connector requests use this value and in that case it's the
> connector index. I need to get this driver applied now, and can't
> spend more time polishing it, so I'll just keep it as-is.
Okay.
> > I found this because I can't get my device to send 0 bytes IN when
> > the host requests more, if I provide no data the request STALLs. This
> > is for sure a bug in my device
..
> > What do you think about formalizing this, adding an actual dummy property?
>
> I want to avoid that.
Ack. I too prefer not adding workarounds, this needs to be fixed in
my device, but I wanted to bring it up.
> I'd rather add a descriptor flag GUD_DISPLAY_FLAG_CANT_RETURN_ZERO or
> something for such devices.
> Also this property warning is just a debug message so not a very big
> problem.
I'd rather not squat a currently-unused property that may be allocated
later.
> Worse is EDID if you don't want to support that since it prints
> an error in that case.
I'll fix my device. If that proves impossible I can still add EDID bytes.
> > Or maybe adding flags to the display descriptor for "I have properties",
> > "I have connector properties" and "I have EDID" ?
>
> Then I might as well go back to the previous version and have count in
> the structs won't I ;)
That's true. Forget the workarounds.
> gud_xrgb_to_color() handles that, although broken in this version
> for partial updates. Here's the fix:
> https://gist.github.com/notro/a94d381cf98b7e15fcddbc90e4af0a21
Thanks.
> I've chosen to only print probe errors, flush errors and devices
> returning incorrect reply lengths. I hate drivers that fill the logs
> with errors, but I might have gone to far on the silent side, I don't
> know. But one nice thing about DRM is that debug is always builtin and
> can be enabled.
I think you've struck a good balance. The error messages I've seen were
all unique and immediately led me to the right place in the driver.
That's really helpful.
> > Finally, here's the drm debug output when I connect my device:
..
> > It looks good, I think? However, neither GUD_REQ_SET_CONTROLLER_ENABLE
> > nor GUD_REQ_SET_DISPLAY_ENABLE is ever called, and there is no bulk
> > output if I write to /dev/fb0.
> >
> > Can you tell what's missing?
>
> IIRC you need ioctl FBIOPUT_VSCREENINFO to enable the pipeline. You can
> use 'con2fbmap' to put a console on the fbdev or use 'fbi' to show an
> image. They will do the necessary ioctls.
Thanks for the hints! I've used fbi, but remembered writing directly
to /dev/fb0 without ioctl:s. I think that must have been after the
console had already been moved to the framebuffer and thus activated
the pipe. I dug up a version of fbset which calls that ioctl.
> I use modetest for simple testing:
> https://github.com/notro/tinydrm/wiki/Development#modetest
Ack, libdrm just has an inconveniently long dependency tail for my
test environment. But fbset + dd works.
> I have made tool that employs usbmon to show what happens just outside
> the wire (runs on the host):
> https://github.com/notro/gud/blob/master/tools/monitor.py
> I haven't got a proper USB analyser, so this was second best.
Nice idea! I've been using usbmon as well during development, it's great.
I find a hardware analyzer is only really neccessary for lowlevel problems
like my no-0-bytes bug.
> Depending on how long it takes for the DMA mask dependency patch to show
> up in drm-misc-next, I will either publish a new version or apply the
> current and provide patches with the necessary fixes.
I look forward to it landing.
> This is one of those things that would never have happened if I knew
> how long it would take :)
Thanks again for working on this great idea! I'm happy that I can help.
Noralf Trønnes wrote:
> > Depending on how long it takes for the DMA mask dependency patch to show
> > up in drm-misc-next, I will either publish a new version or apply the
> > current and provide patches with the necessary fixes.
>
> In case I apply this version, are you happy enough with it that you want
> to give an ack or r-b?
I've now tested R1 and RGB111 and I think I've found two more things:
I didn't receive the expected bits/bytes for RGB111 on the bulk endpoint,
I think because of how components were extracted in gud_xrgb_to_color().
Changing to the following gets me the expected (X R1 G1 B1 X R2 G2 B2) bytes:
r = (*pix32 >> 8) & 0xff;
g = (*pix32 >> 16) & 0xff;
b = (*pix32++ >> 24) & 0xff;
Then, gud_xrgb_to_color() and maybe even gud_xrgb_to_r124() seem
to be host endian dependent, at least because of that pix32, but maybe
Re: make alloc_anon_inode more useful
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 removing tons of boilerplate code.
>
> The few remainig callers of alloc_anon_inode_sb all use alloc_file_pseudo
> later, but might also be ripe for some cleanup.
On a somewhat related note, could I get you to look at
drivers/video/fbdev/core/fb_defio.c?
As far as I can tell, there's no need for fb_deferred_io_aops to exist.
We could just set file->f_mapping->a_ops to NULL, and set_page_dirty()
would do the exact same thing this code does (except it would get the
return value correct).
But maybe that would make something else go wrong that distinguishes
between page->mapping being NULL and page->mapping->a_ops->foo being NULL?
Completely untested patch ...
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index a591d291b231..441ec31d3e4d 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -151,17 +151,6 @@ static const struct vm_operations_struct
fb_deferred_io_vm_ops = {
.page_mkwrite = fb_deferred_io_mkwrite,
};
-static int fb_deferred_io_set_page_dirty(struct page *page)
-{
- if (!PageDirty(page))
- SetPageDirty(page);
- return 0;
-}
-
-static const struct address_space_operations fb_deferred_io_aops = {
- .set_page_dirty = fb_deferred_io_set_page_dirty,
-};
-
int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
vma->vm_ops = _deferred_io_vm_ops;
@@ -212,14 +201,6 @@ void fb_deferred_io_init(struct fb_info *info)
}
EXPORT_SYMBOL_GPL(fb_deferred_io_init);
-void fb_deferred_io_open(struct fb_info *info,
-struct inode *inode,
-struct file *file)
-{
- file->f_mapping->a_ops = _deferred_io_aops;
-}
-EXPORT_SYMBOL_GPL(fb_deferred_io_open);
-
void fb_deferred_io_cleanup(struct fb_info *info)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 06f5805de2de..c4ba76359f22 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1415,10 +1415,7 @@ __releases(>lock)
if (res)
module_put(info->fbops->owner);
}
-#ifdef CONFIG_FB_DEFERRED_IO
- if (info->fbdefio)
- fb_deferred_io_open(info, inode, file);
-#endif
+ file->f_mapping->a_ops = NULL;
out:
unlock_fb_info(info);
if (res)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ecfbcc0553a5..a8dccd23c249 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32
d_pitch,
/* drivers/video/fb_defio.c */
int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
extern void fb_deferred_io_init(struct fb_info *info);
-extern void fb_deferred_io_open(struct fb_info *info,
- struct inode *inode,
- struct file *file);
extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/8] mm: Device exclusive memory access
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 '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alistair-Popple/Add-support-for-SVM-atomics-in-Nouveau/20210310-064003
base: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/f16159aa0e930d32501682bca18bd840f4afd7f1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Alistair-Popple/Add-support-for-SVM-atomics-in-Nouveau/20210310-064003
git checkout f16159aa0e930d32501682bca18bd840f4afd7f1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Note: the
linux-review/Alistair-Popple/Add-support-for-SVM-atomics-in-Nouveau/20210310-064003
HEAD 1c7d3a45d0693d661c4d9fbd8d25745b1db4fcbb builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/gpu/drm/nouveau/nouveau_svm.c: In function
'nouveau_svmm_invalidate_range_start':
>> drivers/gpu/drm/nouveau/nouveau_svm.c:268:12: error: 'const struct
>> mmu_notifier_range' has no member named 'migrate_pgmap_owner'
268 | update->migrate_pgmap_owner == svmm->vmm->cli->drm->dev)
|^~
drivers/gpu/drm/nouveau/nouveau_svm.c: In function 'nouveau_pfns_map':
drivers/gpu/drm/nouveau/nouveau_svm.c:814:6: warning: variable 'ret' set but
not used [-Wunused-but-set-variable]
814 | int ret;
| ^~~
vim +268 drivers/gpu/drm/nouveau/nouveau_svm.c
eeaf06ac1a5584 Ben Skeggs 2018-07-05 244
eeaf06ac1a5584 Ben Skeggs 2018-07-05 245 static int
c625c274ee0058 Jason Gunthorpe 2019-11-12 246
nouveau_svmm_invalidate_range_start(struct mmu_notifier *mn,
1f961807925032 Ralph Campbell 2019-07-25 247
const struct mmu_notifier_range *update)
eeaf06ac1a5584 Ben Skeggs 2018-07-05 248 {
c625c274ee0058 Jason Gunthorpe 2019-11-12 249 struct nouveau_svmm
*svmm =
c625c274ee0058 Jason Gunthorpe 2019-11-12 250
container_of(mn, struct nouveau_svmm, notifier);
eeaf06ac1a5584 Ben Skeggs 2018-07-05 251 unsigned long start =
update->start;
eeaf06ac1a5584 Ben Skeggs 2018-07-05 252 unsigned long limit =
update->end;
eeaf06ac1a5584 Ben Skeggs 2018-07-05 253
1f961807925032 Ralph Campbell 2019-07-25 254 if
(!mmu_notifier_range_blockable(update))
eeaf06ac1a5584 Ben Skeggs 2018-07-05 255 return -EAGAIN;
eeaf06ac1a5584 Ben Skeggs 2018-07-05 256
eeaf06ac1a5584 Ben Skeggs 2018-07-05 257 SVMM_DBG(svmm,
"invalidate %016lx-%016lx", start, limit);
eeaf06ac1a5584 Ben Skeggs 2018-07-05 258
eeaf06ac1a5584 Ben Skeggs 2018-07-05 259
mutex_lock(>mutex);
c625c274ee0058 Jason Gunthorpe 2019-11-12 260 if
(unlikely(!svmm->vmm))
c625c274ee0058 Jason Gunthorpe 2019-11-12 261 goto out;
c625c274ee0058 Jason Gunthorpe 2019-11-12 262
f8477ce6b5923e Ralph Campbell 2020-07-23 263 /*
f8477ce6b5923e Ralph Campbell 2020-07-23 264 * Ignore invalidation
callbacks for device private pages since
f8477ce6b5923e Ralph Campbell 2020-07-23 265 * the invalidation is
handled as part of the migration process.
f8477ce6b5923e Ralph Campbell 2020-07-23 266 */
f8477ce6b5923e Ralph Campbell 2020-07-23 267 if (update->event ==
MMU_NOTIFY_MIGRATE &&
f8477ce6b5923e Ralph Campbell 2020-07-23 @268
update->migrate_pgmap_owner == svmm->vmm->cli->drm->dev)
f8477ce6b5923e Ralph Campbell 2020-07-23 269 goto out;
f8477ce6b5923e Ralph Campbell 2020-07-23 270
eeaf06ac1a5584 Ben Skeggs 2018-07-05 271 if (limit >
svmm->unmanaged.start && start < svmm->unmanaged.limit) {
eeaf06ac1a5584 Ben Skeggs 2018-07-05 272 if (start <
svmm->unmanaged.start) {
eeaf06ac1a5584 Ben Skeggs 2018-07-05 273
nouveau_svmm_invalidate(svmm, start,
eeaf06ac1a5584 Ben Skeggs 2018-07-05 274
svmm->
Re: [PATCH v5 1/8] mm: Remove special swap entry functions
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. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Alistair-Popple/Add-support-for-SVM-atomics-in-Nouveau/20210310-064003 base: https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git features config: s390-randconfig-r021-20210308 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project cd9a69289c7825d54450cb6829fef2c8e0f1963a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://github.com/0day-ci/linux/commit/d262b019576bfc423b79d789df09702fde6f1abc git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Alistair-Popple/Add-support-for-SVM-atomics-in-Nouveau/20210310-064003 git checkout d262b019576bfc423b79d789df09702fde6f1abc # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:20:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0xff00UL) << 8) |\ ^ In file included from arch/s390/mm/pgtable.c:12: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In file included from include/linux/writeback.h:14: In file included from include/linux/blk-cgroup.h:23: In file included from include/linux/blkdev.h:26: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:80: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ ^ In file included from arch/s390/mm/pgtable.c:12: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In file included from include/linux/writeback.h:14: In file included from include/linux/blk-cgroup.h:23: In file included from include/linux/blkdev.h:26: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:80: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0xff00UL) >> 24))) ^ In file included from arch/s390/mm/pgtable.c:12: In file included from include/linux/swap.h:9: In file included from include/linux/memcontrol.h:22: In file included from include/linux/writeback.h:14: In file included from include/linux/blk-c
don't base trees on 5.12-rc1
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 other maintainers reading this, please avoid 5.12-rc1 as the base for any trees for this cycle. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 8/8] nouveau/svm: Implement atomic SVM access
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 the GPU permission to update the page undergoing
atomic access via the GPU page tables. When CPU access to the page is
required a CPU fault is raised which calls into the device driver via
MMU notifiers to revoke the atomic access. The original page table
entries are then restored allowing CPU access to proceed.
Signed-off-by: Alistair Popple
---
v4:
* Check that page table entries haven't changed before mapping on the
device
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 +
drivers/gpu/drm/nouveau/nouveau_svm.c | 102 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 ++
4 files changed, 101 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index d6dd40f21eed..9c7ff56831c5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -77,6 +77,7 @@ struct nvif_vmm_pfnmap_v0 {
#define NVIF_VMM_PFNMAP_V0_APER 0x00f0ULL
#define NVIF_VMM_PFNMAP_V0_HOST 0xULL
#define NVIF_VMM_PFNMAP_V0_VRAM 0x0010ULL
+#define NVIF_VMM_PFNMAP_V0_A 0x0004ULL
#define NVIF_VMM_PFNMAP_V0_W 0x0002ULL
#define NVIF_VMM_PFNMAP_V0_V 0x0001ULL
#define NVIF_VMM_PFNMAP_V0_NONE 0xULL
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index cd7b47c946cf..16b07d7589d2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
struct nouveau_svm {
struct nouveau_drm *drm;
@@ -265,7 +266,7 @@ nouveau_svmm_invalidate_range_start(struct mmu_notifier *mn,
* the invalidation is handled as part of the migration process.
*/
if (update->event == MMU_NOTIFY_MIGRATE &&
- update->migrate_pgmap_owner == svmm->vmm->cli->drm->dev)
+ update->owner == svmm->vmm->cli->drm->dev)
goto out;
if (limit > svmm->unmanaged.start && start < svmm->unmanaged.limit) {
@@ -421,9 +422,9 @@ nouveau_svm_fault_cmp(const void *a, const void *b)
return ret;
if ((ret = (s64)fa->addr - fb->addr))
return ret;
- /*XXX: atomic? */
- return (fa->access == 0 || fa->access == 3) -
- (fb->access == 0 || fb->access == 3);
+ /* Atomic access (2) has highest priority */
+ return (-1*(fa->access == 2) + (fa->access == 0 || fa->access == 3)) -
+ (-1*(fb->access == 2) + (fb->access == 0 || fb->access == 3));
}
static void
@@ -487,6 +488,10 @@ static bool nouveau_svm_range_invalidate(struct
mmu_interval_notifier *mni,
struct svm_notifier *sn =
container_of(mni, struct svm_notifier, notifier);
+ if (range->event == MMU_NOTIFY_EXCLUSIVE &&
+ range->owner == sn->svmm->vmm->cli->drm->dev)
+ return true;
+
/*
* serializes the update to mni->invalidate_seq done by caller and
* prevents invalidation of the PTE from progressing while HW is being
@@ -555,6 +560,73 @@ static void nouveau_hmm_convert_pfn(struct nouveau_drm
*drm,
args->p.phys[0] |= NVIF_VMM_PFNMAP_V0_W;
}
+static int nouveau_atomic_range_fault(struct nouveau_svmm *svmm,
+ struct nouveau_drm *drm,
+ struct nouveau_pfnmap_args *args, u32 size,
+ struct svm_notifier *notifier)
+{
+ unsigned long timeout =
+ jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
+ struct mm_struct *mm = svmm->notifier.mm;
+ struct page *page;
+ unsigned long start = args->p.addr;
+ unsigned long notifier_seq;
+ int ret = 0;
+
+ ret = mmu_interval_notifier_insert(>notifier, mm,
+ args->p.addr, args->p.size,
+ _svm_mni_ops);
+ if (ret)
+ return ret;
+
+ while (true) {
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ notifier_seq = mmu_interval_read_begin(>notifier);
+ mmap_read_lock(mm);
+ make_device_exclusive_range(mm, start, start + PAGE_SIZE,
+
[PATCH v5 7/8] nouveau/svm: Refactor nouveau_range_fault
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/nouveau/nouveau_svm.c | 34 ---
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index f18bd53da052..cd7b47c946cf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -567,18 +567,27 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
unsigned long hmm_pfns[1];
struct hmm_range range = {
.notifier = >notifier,
- .start = notifier->notifier.interval_tree.start,
- .end = notifier->notifier.interval_tree.last + 1,
.default_flags = hmm_flags,
.hmm_pfns = hmm_pfns,
.dev_private_owner = drm->dev,
};
- struct mm_struct *mm = notifier->notifier.mm;
+ struct mm_struct *mm = svmm->notifier.mm;
int ret;
+ ret = mmu_interval_notifier_insert(>notifier, mm,
+ args->p.addr, args->p.size,
+ _svm_mni_ops);
+ if (ret)
+ return ret;
+
+ range.start = notifier->notifier.interval_tree.start;
+ range.end = notifier->notifier.interval_tree.last + 1;
+
while (true) {
- if (time_after(jiffies, timeout))
- return -EBUSY;
+ if (time_after(jiffies, timeout)) {
+ ret = -EBUSY;
+ goto out;
+ }
range.notifier_seq = mmu_interval_read_begin(range.notifier);
mmap_read_lock(mm);
@@ -587,7 +596,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
if (ret) {
if (ret == -EBUSY)
continue;
- return ret;
+ goto out;
}
mutex_lock(>mutex);
@@ -606,6 +615,9 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(>mutex);
+out:
+ mmu_interval_notifier_remove(>notifier);
+
return ret;
}
@@ -727,14 +739,8 @@ nouveau_svm_fault(struct nvif_notify *notify)
}
notifier.svmm = svmm;
- ret = mmu_interval_notifier_insert(, mm,
- args.i.p.addr, args.i.p.size,
- _svm_mni_ops);
- if (!ret) {
- ret = nouveau_range_fault(svmm, svm->drm, ,
- sizeof(args), hmm_flags, );
- mmu_interval_notifier_remove();
- }
+ ret = nouveau_range_fault(svmm, svm->drm, ,
+ sizeof(args), hmm_flags, );
mmput(mm);
limit = args.i.p.addr + args.i.p.size;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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 interfaces. I realize this > > is more work, > > but I wonder if you've tried that, and why it didn't work out. > > As far as I know this hasn't been tried. I see that intel-iommu has its > own SVM thing, which seems to be similar to what our IOMMUv2 does. I > guess we'd have to abstract that into a common API. The common API was added in 26b25a2b98e4 and implemented by the Intel driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU ops: .dev_has_feat() .dev_feat_enabled() .dev_enable_feat() .dev_disable_feat() .sva_bind() .sva_unbind() .sva_get_pasid() And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) followed by iommu_sva_bind_device(). If I remember correctly the biggest obstacle for KFD is the PASID allocation, done by the GPU driver instead of the IOMMU driver, but there may be others. Thanks, Jean ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
https://bugzilla.kernel.org/show_bug.cgi?id=212107 Martin (martin...@gmx.com) changed: What|Removed |Added Status|RESOLVED|CLOSED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
https://bugzilla.kernel.org/show_bug.cgi?id=212107 Martin (martin...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
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) if you put load on your gfx card. I've just rebooted into 5.11.5. The gpu fan went into max speed for one second or so. After the computer finished booting sensors still showed over 3000rpm, even though at that point the fan was already off: amdgpu-pci-0100 Adapter: PCI adapter vddgfx: 825.00 mV fan1:3601 RPM (min =0 RPM, max = 3500 RPM) edge: +47.0°C (crit = +97.0°C, hyst = -273.1°C) power1:7.15 W (cap = 36.00 W) I waited a couple of minutes and then watched 4k vid. The fan turned on and sensors started showing this: amdgpu-pci-0100 Adapter: PCI adapter vddgfx: 962.00 mV fan1:1004 RPM (min =0 RPM, max = 3500 RPM) edge: +57.0°C (crit = +97.0°C, hyst = -273.1°C) power1: 12.03 W (cap = 36.00 W) So there is a change in reported fan speed. After turning of the video the fan turned off again but the reported fan speed stayed at roughly 900 RPM. I played a bit of Xonotic. Again, fan turned on but the reported fan speed remained roughly the same, around 900 RPM. I have no way of measuring the actual fan speed while playing a game or watching a video so I don't know if what sensors are reporting is accurate. sensors --version outputs the following: sensors version 3.6.0 with libsensors version 3.6.0 For the CPU fan speed it does seem to report the actual speed. I've recently switched to a new CPU cooler with a new fan and both this new one and the old one were reporting speed change that corresponded to actual cpu fan speed. The old cooler had manual fan control so I could see the reported speed change live. ps. I'm in UTC+1 and I probably won't be able to post more tonight. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] fs: add an argument-less alloc_anon_inode
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-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb
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 fs... Reviewed-by: Gao Xiang Thanks, Gao Xiang ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
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 to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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 that the amdgpu driver can do everything it needs through the regular linux/iommu.h interfaces. I realize this is more work, but I wonder if you've tried that, and why it didn't work out. As far as I know this hasn't been tried. I see that intel-iommu has its own SVM thing, which seems to be similar to what our IOMMUv2 does. I guess we'd have to abstract that into a common API. The common API was added in 26b25a2b98e4 and implemented by the Intel driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU ops: .dev_has_feat() .dev_feat_enabled() .dev_enable_feat() .dev_disable_feat() .sva_bind() .sva_unbind() .sva_get_pasid() And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) followed by iommu_sva_bind_device(). If I remember correctly the biggest obstacle for KFD is the PASID allocation, done by the GPU driver instead of the IOMMU driver, but there may be others. IIRC, we tried to make the original IOMMUv2 functionality generic but other vendors were not interested at the time, so it ended up being AMD specific and since nothing else was using the pasid allocations we put them in the GPU driver. I guess if this is generic now, it could be moved to a common API and taken out of the driver. There has been quite some effort for this already for generic PASID interface etc.. But it looks like that effort is stalled by now. Anyway at least I'm perfectly fine to have the IOMMUv2 || !IOMMUv2 dependency on the core amdgpu driver for x86. That should solve the build problem at hand quite nicely. Regards, Christian. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/3] drm: Add GUD USB Display driver
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: >> > Depending on how long it takes for the DMA mask dependency patch to show > up in drm-misc-next, I will either publish a new version or apply the > current and provide patches with the necessary fixes. In case I apply this version, are you happy enough with it that you want to give an ack or r-b? Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/3] drm: Add GUD USB Display driver
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/gud_drv.c
> ..
>> +static int gud_probe(struct usb_interface *intf, const struct usb_device_id
>> *id)
> ..
>> +if (format == GUD_DRM_FORMAT_R1)
>> +continue; /* Internal not for userspace */
>
> You already found RGB111 missing here.
>
>
>> +static int gud_usb_control_msg(struct usb_interface *intf, bool in,
>> + u8 request, u16 value, void *buf, size_t len)
> ..
>> +static int gud_usb_transfer(struct gud_device *gdrm, bool in, u8 request,
>> u16 index,
> ..
>> +ret = gud_usb_control_msg(intf, in, request, index, buf, len);
>
> 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 parameters to wValue,
> to show that and where they are part of the control request? I think
> it would help make the protocol more clear.
>
Only connector requests use this value and in that case it's the
connector index. I need to get this driver applied now, and can't spend
more time polishing it, so I'll just keep it as-is.
>
> Finally, an actual bug:
>
>> +ret = gud_get_properties(gdrm);
>> +if (ret) {
>> +dev_err(dev, "Failed to get properties (error=%d)\n", ret);
>> +return ret;
>> +}
>
> If gud_get_properties() and gud_connector_add_properties() receive
> and process (only!) one or more unknown properties then they return
> the number of bytes received from the device rather than 0.
>
> I fixed this by setting ret = 0; before the for() loop, but maybe you
> want to do it another way.
>
I'll do that.
>
> I found this because I can't get my device to send 0 bytes IN when
> the host requests more, if I provide no data the request STALLs. This
> is for sure a bug in my device and I'll come back to it, but for now
> I added a dummy 65535 property as a workaround.
>
> What do you think about formalizing this, adding an actual dummy property?
>
I want to avoid that. I'd rather add a descriptor flag
GUD_DISPLAY_FLAG_CANT_RETURN_ZERO or something for such devices.
Also this property warning is just a debug message so not a very big
problem. Worse is EDID if you don't want to support that since it prints
an error in that case.
> Or maybe adding flags to the display descriptor for "I have properties",
> "I have connector properties" and "I have EDID" ?
>
Then I might as well go back to the previous version and have count in
the structs won't I ;)
>
>> +++ b/drivers/gpu/drm/gud/gud_pipe.c
> ..
>> +static int gud_prep_flush(struct gud_device *gdrm, struct drm_framebuffer
>> *fb,
> ..
>> +/*
>> + * Imported buffers are assumed to be write-combined and thus uncached
>> + * with slow reads (at least on ARM).
>> + */
>> +if (format != fb->format) {
>> +if (format->format == GUD_DRM_FORMAT_R1) {
>> +len = gud_xrgb_to_r124(buf, format, vaddr, fb,
>> rect);
>> +if (!len) {
>> +ret = -ENOMEM;
>> +goto end_cpu_access;
>> +}
>> +} else if (format->format == DRM_FORMAT_RGB565) {
>> +drm_fb_xrgb_to_rgb565(buf, vaddr, fb, rect,
>> gud_is_big_endian());
>> +} else {
>> +len = gud_xrgb_to_color(buf, format, vaddr, fb,
>> rect);
>> +}
>
> Does this section also need a RGB111 case?
>
gud_xrgb_to_color() handles that, although broken in this version
for partial updates. Here's the fix:
https://gist.github.com/notro/a94d381cf98b7e15fcddbc90e4af0a21
>
>> +void gud_pipe_update(struct drm_simple_display_pipe *pipe,
> ..
>> +if (fb && (crtc->state->mode_changed ||
>> crtc->state->connectors_changed))
>> +gud_usb_set(gdrm, GUD_REQ_SET_STATE_COMMIT, 0, NULL, 0);
>
> You mentioned that commit must not fail; what happens/should happen
> if a request does fail in pipe_update()? Some reasons could be that
> the device was unplugged, a bad cable is glitchy or even that some
> device doesn't even implement STATE_COMMIT or does it incorrectly and
> will report back failure?
>
The failure is just ignored since there's nothing to be done. The error
counter for the debufgs file is increased, making it somewhat visible.
I've chosen to only print probe errors, flush errors and devices
returning incorrect reply lengths. I hate drivers that fill the logs
with errors, but I might have gone to far on the silent side, I don't
know. But one nice thing about DRM is that debug is always builtin and
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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 can do > > > everything > > > it needs through the regular linux/iommu.h interfaces. I realize this > > > is more work, > > > but I wonder if you've tried that, and why it didn't work out. > > > > As far as I know this hasn't been tried. I see that intel-iommu has its > > own SVM thing, which seems to be similar to what our IOMMUv2 does. I > > guess we'd have to abstract that into a common API. > > The common API was added in 26b25a2b98e4 and implemented by the Intel > driver in 064a57d7ddfc. To support it an IOMMU driver implements new IOMMU > ops: > .dev_has_feat() > .dev_feat_enabled() > .dev_enable_feat() > .dev_disable_feat() > .sva_bind() > .sva_unbind() > .sva_get_pasid() > > And a device driver calls iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA) > followed by iommu_sva_bind_device(). > > If I remember correctly the biggest obstacle for KFD is the PASID > allocation, done by the GPU driver instead of the IOMMU driver, but there > may be others. IIRC, we tried to make the original IOMMUv2 functionality generic but other vendors were not interested at the time, so it ended up being AMD specific and since nothing else was using the pasid allocations we put them in the GPU driver. I guess if this is generic now, it could be moved to a common API and taken out of the driver. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
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 prepare CMD:(null)
[4.498114] meson_ee_pwrc c883c000.system-controller:power-controller:
shutdown begin
[4.503949] meson_ee_pwrc c883c000.system-controller:power-controller:
shutdown domain 0:VPU...
...STUCK...
Solution: add shutdown function to meson_drm driver
// debug kernel log
[5.231896] reboot: kernel restart prepare CMD:(null)
[5.246135] [drm:meson_drv_shutdown]
...
[5.259271] meson_ee_pwrc c883c000.system-controller:power-controller:
shutdown begin
[5.274688] meson_ee_pwrc c883c000.system-controller:power-controller:
shutdown domain 0:VPU...
[5.338331] reboot: Restarting system
[5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
bl31 reboot reason: 0xd
bl31 reboot reason: 0x0
system cmd 1.
...REBOOT...
Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
and Odroid boards, WeTek Play2 (GXBB)
Tested-by: Christian Hewitt
Signed-off-by: Artem Lapkin
---
drivers/gpu/drm/meson/meson_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 42c5d3246..693bb1293 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device
*pdev,
return count;
}
+static void meson_drv_shutdown(struct platform_device *pdev)
+{
+ struct meson_drm *priv = dev_get_drvdata(>dev);
+ struct drm_device *drm = priv->drm;
+
+ DRM_DEBUG_DRIVER("\n");
+ drm_kms_helper_poll_fini(drm);
+ drm_atomic_helper_shutdown(drm);
+}
+
static int meson_drv_probe(struct platform_device *pdev)
{
struct component_match *match = NULL;
@@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
static struct platform_driver meson_drm_platform_driver = {
.probe = meson_drv_probe,
+ .shutdown = meson_drv_shutdown,
.driver = {
.name = "meson-drm",
.of_match_table = dt_match,
>>>
>>> Applied to drm-misc-fixes,
>>
>> Could you submit this as a fix to stable (v5.10+) also?
>
> It should be done automagically since I added the Fixes tag
Oh, I didn't see the fixes tag, sorry.
Thanks!
Kevin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
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] meson_ee_pwrc c883c000.system-controller:power-controller:
>>> shutdown begin
>>> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller:
>>> shutdown domain 0:VPU...
>>> ...STUCK...
>>>
>>> Solution: add shutdown function to meson_drm driver
>>> // debug kernel log
>>> [5.231896] reboot: kernel restart prepare CMD:(null)
>>> [5.246135] [drm:meson_drv_shutdown]
>>> ...
>>> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller:
>>> shutdown begin
>>> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller:
>>> shutdown domain 0:VPU...
>>> [5.338331] reboot: Restarting system
>>> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
>>> bl31 reboot reason: 0xd
>>> bl31 reboot reason: 0x0
>>> system cmd 1.
>>> ...REBOOT...
>>>
>>> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
>>> and Odroid boards, WeTek Play2 (GXBB)
>>>
>>> Tested-by: Christian Hewitt
>>> Signed-off-by: Artem Lapkin
>>>
>>> ---
>>> drivers/gpu/drm/meson/meson_drv.c | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>>> b/drivers/gpu/drm/meson/meson_drv.c
>>> index 42c5d3246..693bb1293 100644
>>> --- a/drivers/gpu/drm/meson/meson_drv.c
>>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>>> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device
>>> *pdev,
>>> return count;
>>> }
>>>
>>> +static void meson_drv_shutdown(struct platform_device *pdev)
>>> +{
>>> + struct meson_drm *priv = dev_get_drvdata(>dev);
>>> + struct drm_device *drm = priv->drm;
>>> +
>>> + DRM_DEBUG_DRIVER("\n");
>>> + drm_kms_helper_poll_fini(drm);
>>> + drm_atomic_helper_shutdown(drm);
>>> +}
>>> +
>>> static int meson_drv_probe(struct platform_device *pdev)
>>> {
>>> struct component_match *match = NULL;
>>> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>>>
>>> static struct platform_driver meson_drm_platform_driver = {
>>> .probe = meson_drv_probe,
>>> + .shutdown = meson_drv_shutdown,
>>> .driver = {
>>> .name = "meson-drm",
>>> .of_match_table = dt_match,
>>>
>>
>> Applied to drm-misc-fixes,
>
> Could you submit this as a fix to stable (v5.10+) also?
It should be done automagically since I added the Fixes tag
neil
>
> Thanks,
>
> Kevin
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
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-controller:
>> shutdown begin
>> [4.503949] meson_ee_pwrc c883c000.system-controller:power-controller:
>> shutdown domain 0:VPU...
>> ...STUCK...
>>
>> Solution: add shutdown function to meson_drm driver
>> // debug kernel log
>> [5.231896] reboot: kernel restart prepare CMD:(null)
>> [5.246135] [drm:meson_drv_shutdown]
>> ...
>> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller:
>> shutdown begin
>> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller:
>> shutdown domain 0:VPU...
>> [5.338331] reboot: Restarting system
>> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
>> bl31 reboot reason: 0xd
>> bl31 reboot reason: 0x0
>> system cmd 1.
>> ...REBOOT...
>>
>> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
>> and Odroid boards, WeTek Play2 (GXBB)
>>
>> Tested-by: Christian Hewitt
>> Signed-off-by: Artem Lapkin
>>
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index 42c5d3246..693bb1293 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device
>> *pdev,
>> return count;
>> }
>>
>> +static void meson_drv_shutdown(struct platform_device *pdev)
>> +{
>> +struct meson_drm *priv = dev_get_drvdata(>dev);
>> +struct drm_device *drm = priv->drm;
>> +
>> +DRM_DEBUG_DRIVER("\n");
>> +drm_kms_helper_poll_fini(drm);
>> +drm_atomic_helper_shutdown(drm);
>> +}
>> +
>> static int meson_drv_probe(struct platform_device *pdev)
>> {
>> struct component_match *match = NULL;
>> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>>
>> static struct platform_driver meson_drm_platform_driver = {
>> .probe = meson_drv_probe,
>> +.shutdown = meson_drv_shutdown,
>> .driver = {
>> .name = "meson-drm",
>> .of_match_table = dt_match,
>>
>
> Applied to drm-misc-fixes,
Could you submit this as a fix to stable (v5.10+) also?
Thanks,
Kevin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Need -fixes commit in drm-misc-next
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-next soon.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: make alloc_anon_inode more useful
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 block, thus removing tons of boilerplate code. > > The few remainig callers of alloc_anon_inode_sb all use alloc_file_pseudo > later, but might also be ripe for some cleanup. I like it For a submission plan can we have this on a git branch please? I will need a copy for RDMA and Alex will need one for vfio.. Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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 function
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to
`amd_iommu_free_device'
Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.
Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it
conditional")
Reported-by: Arnd Bergmann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..9318936aa805 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
#include
#include
#include
@@ -355,3 +359,5 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device
*kdev)
return 0;
}
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..afd420b01a0c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
#ifndef __KFD_IOMMU_H__
#define __KFD_IOMMU_H__
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)
+#include
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
#define KFD_SUPPORT_IOMMU_V2
@@ -46,6 +48,9 @@ static inline int kfd_iommu_check_device(struct kfd_dev *kfd)
}
static inline int kfd_iommu_device_init(struct kfd_dev *kfd)
{
+#if IS_MODULE(CONFIG_AMD_IOMMU_V2)
+ WARN_ONCE(1, "iommu_v2 module is not usable by built-in KFD");
+#endif
return 0;
}
@@ -73,6 +78,6 @@ static inline int kfd_iommu_add_perf_counters(struct
kfd_topology_device *kdev)
return 0;
}
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */
+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
#endif /* __KFD_IOMMU_H__ */
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] vmw_balloon: remove the balloon-vmware file system
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_balloon.c
index 5d057a05ddbee8..be4be32f858253 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -16,6 +16,7 @@
//#define DEBUG
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -1735,20 +1736,6 @@ static inline void vmballoon_debugfs_exit(struct
vmballoon *b)
#ifdef CONFIG_BALLOON_COMPACTION
-
-static int vmballoon_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, BALLOON_VMW_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type vmballoon_fs = {
- .name = "balloon-vmware",
- .init_fs_context= vmballoon_init_fs_context,
- .kill_sb= kill_anon_super,
-};
-
-static struct vfsmount *vmballoon_mnt;
-
/**
* vmballoon_migratepage() - migrates a balloon page.
* @b_dev_info: balloon device information descriptor.
@@ -1878,8 +1865,6 @@ static void vmballoon_compaction_deinit(struct vmballoon
*b)
iput(b->b_dev_info.inode);
b->b_dev_info.inode = NULL;
- kern_unmount(vmballoon_mnt);
- vmballoon_mnt = NULL;
}
/**
@@ -1895,13 +1880,8 @@ static void vmballoon_compaction_deinit(struct vmballoon
*b)
*/
static __init int vmballoon_compaction_init(struct vmballoon *b)
{
- vmballoon_mnt = kern_mount(_fs);
- if (IS_ERR(vmballoon_mnt))
- return PTR_ERR(vmballoon_mnt);
-
b->b_dev_info.migratepage = vmballoon_migratepage;
- b->b_dev_info.inode = alloc_anon_inode_sb(vmballoon_mnt->mnt_sb);
-
+ b->b_dev_info.inode = alloc_anon_inode();
if (IS_ERR(b->b_dev_info.inode))
return PTR_ERR(b->b_dev_info.inode);
Same comment regarding BALLOON_VMW_MAGIC and includes (mount.h,
pseudo_fs.h).
Apart from that looks good.
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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_iommu.c file is indeed >> built but does not work: >> >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_bind_process_to_device': >> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_unbind_process': >> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_suspend': >> kfd_iommu.c:(.text+0x966): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to >> `amd_iommu_free_device' >> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function >> `kfd_iommu_resume': >> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to >> `amd_iommu_bind_pasid' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to >> `amd_iommu_set_invalidate_ctx_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to >> `amd_iommu_set_invalid_ppr_cb' >> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to >> `amd_iommu_free_device' >> >> Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols >> are reachable by the amdkfd driver. Output a warning if they are not, >> because that may not be what the user was expecting. > This would fix the compile-time failure, but it still fails my CI > because you introduce > a compile-time warning. Can you change it into a runtime warning instead? Sure. > > Neither type of warning is likely to actually reach the person trying > to debug the > problem, so you still end up with machines that don't do what they should, > but I can live with the runtime warning as long as the build doesn't break. OK. > > 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 interfaces. I realize this > is more work, > but I wonder if you've tried that, and why it didn't work out. As far as I know this hasn't been tried. I see that intel-iommu has its own SVM thing, which seems to be similar to what our IOMMUv2 does. I guess we'd have to abstract that into a common API. Regards, Felix > >Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] powerpc/pseries: remove the ppc-cmm file system
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/arch/powerpc/platforms/pseries/cmm.c
> b/arch/powerpc/platforms/pseries/cmm.c
> index 6d36b858b14df1..9d07e6bea7126c 100644
> +++ b/arch/powerpc/platforms/pseries/cmm.c
> @@ -6,6 +6,7 @@
> * Author(s): Brian King (brk...@linux.vnet.ibm.com),
> */
>
> +#include
> #include
> #include
> #include
> @@ -502,19 +503,6 @@ static struct notifier_block cmm_mem_nb = {
> };
>
> #ifdef CONFIG_BALLOON_COMPACTION
> -static struct vfsmount *balloon_mnt;
> -
> -static int cmm_init_fs_context(struct fs_context *fc)
> -{
> - return init_pseudo(fc, PPC_CMM_MAGIC) ? 0 : -ENOMEM;
Should we clean these unusued magic constants too?
include/uapi/linux/magic.h:#define PPC_CMM_MAGIC0xc7571590
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] virtio_balloon: remove the balloon-kvm file system
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/drivers/virtio/virtio_balloon.c
index cae76ee5bdd688..1efb890cd3ff09 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -6,6 +6,7 @@
* Copyright 2008 Rusty Russell IBM Corporation
*/
+#include
#include
#include
#include
@@ -42,10 +43,6 @@
(1 << (VIRTIO_BALLOON_HINT_BLOCK_ORDER + PAGE_SHIFT))
#define VIRTIO_BALLOON_HINT_BLOCK_PAGES (1 << VIRTIO_BALLOON_HINT_BLOCK_ORDER)
-#ifdef CONFIG_BALLOON_COMPACTION
-static struct vfsmount *balloon_mnt;
-#endif
-
enum virtio_balloon_vq {
VIRTIO_BALLOON_VQ_INFLATE,
VIRTIO_BALLOON_VQ_DEFLATE,
@@ -805,18 +802,6 @@ static int virtballoon_migratepage(struct balloon_dev_info
*vb_dev_info,
return MIGRATEPAGE_SUCCESS;
}
-
-static int balloon_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, BALLOON_KVM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type balloon_fs = {
- .name = "balloon-kvm",
- .init_fs_context = balloon_init_fs_context,
- .kill_sb= kill_anon_super,
-};
-
#endif /* CONFIG_BALLOON_COMPACTION */
static unsigned long shrink_free_pages(struct virtio_balloon *vb,
@@ -909,17 +894,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
goto out_free_vb;
#ifdef CONFIG_BALLOON_COMPACTION
- balloon_mnt = kern_mount(_fs);
- if (IS_ERR(balloon_mnt)) {
- err = PTR_ERR(balloon_mnt);
- goto out_del_vqs;
- }
-
vb->vb_dev_info.migratepage = virtballoon_migratepage;
- vb->vb_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
+ vb->vb_dev_info.inode = alloc_anon_inode();
if (IS_ERR(vb->vb_dev_info.inode)) {
err = PTR_ERR(vb->vb_dev_info.inode);
- goto out_kern_unmount;
+ goto out_del_vqs;
}
vb->vb_dev_info.inode->i_mapping->a_ops = _aops;
#endif
@@ -1016,8 +995,6 @@ static int virtballoon_probe(struct virtio_device *vdev)
out_iput:
#ifdef CONFIG_BALLOON_COMPACTION
iput(vb->vb_dev_info.inode);
-out_kern_unmount:
- kern_unmount(balloon_mnt);
out_del_vqs:
#endif
vdev->config->del_vqs(vdev);
@@ -1070,7 +1047,6 @@ static void virtballoon_remove(struct virtio_device *vdev)
if (vb->vb_dev_info.inode)
iput(vb->vb_dev_info.inode);
- kern_unmount(balloon_mnt);
#endif
kfree(vb);
}
... you might know what I am going to say :)
Apart from that LGTM.
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] powerpc/pseries: remove the ppc-cmm file system
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/cmm.c
b/arch/powerpc/platforms/pseries/cmm.c
index 6d36b858b14df1..9d07e6bea7126c 100644
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -6,6 +6,7 @@
* Author(s): Brian King (brk...@linux.vnet.ibm.com),
*/
+#include
#include
#include
#include
@@ -502,19 +503,6 @@ static struct notifier_block cmm_mem_nb = {
};
#ifdef CONFIG_BALLOON_COMPACTION
-static struct vfsmount *balloon_mnt;
-
-static int cmm_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, PPC_CMM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type balloon_fs = {
- .name = "ppc-cmm",
- .init_fs_context = cmm_init_fs_context,
- .kill_sb = kill_anon_super,
-};
-
static int cmm_migratepage(struct balloon_dev_info *b_dev_info,
struct page *newpage, struct page *page,
enum migrate_mode mode)
@@ -573,19 +561,10 @@ static int cmm_balloon_compaction_init(void)
balloon_devinfo_init(_dev_info);
b_dev_info.migratepage = cmm_migratepage;
- balloon_mnt = kern_mount(_fs);
- if (IS_ERR(balloon_mnt)) {
- rc = PTR_ERR(balloon_mnt);
- balloon_mnt = NULL;
- return rc;
- }
-
- b_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
+ b_dev_info.inode = alloc_anon_inode();
if (IS_ERR(b_dev_info.inode)) {
rc = PTR_ERR(b_dev_info.inode);
b_dev_info.inode = NULL;
- kern_unmount(balloon_mnt);
- balloon_mnt = NULL;
return rc;
}
@@ -597,8 +576,6 @@ static void cmm_balloon_compaction_deinit(void)
if (b_dev_info.inode)
iput(b_dev_info.inode);
b_dev_info.inode = NULL;
- kern_unmount(balloon_mnt);
- balloon_mnt = NULL;
}
#else /* CONFIG_BALLOON_COMPACTION */
static int cmm_balloon_compaction_init(void)
I always wondered why that was necessary after all (with my limited fs
knowledge :) ).
a) I assume you want to remove PPC_CMM_MAGIC from
include/uapi/linux/magic.h as well?
b) Do we still need #include , #include
and #include ?
Apart from that looks much cleaner.
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] fs: add an argument-less alloc_anon_inode
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(+), 2 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 4745fc37014332..b6a8ea71920bc3 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -63,7 +63,7 @@ static struct inode *anon_inode_make_secure_inode(
const struct qstr qname = QSTR_INIT(name, strlen(name));
int error;
- inode = alloc_anon_inode_sb(anon_inode_mnt->mnt_sb);
+ inode = alloc_anon_inode();
if (IS_ERR(inode))
return inode;
inode->i_flags &= ~S_PRIVATE;
@@ -225,13 +225,24 @@ int anon_inode_getfd_secure(const char *name, const
struct file_operations *fops
}
EXPORT_SYMBOL_GPL(anon_inode_getfd_secure);
+/**
+ * alloc_anon_inode - create a new anonymous inode
+ *
+ * Create an inode on the anon_inode file system and return it.
+ */
+struct inode *alloc_anon_inode(void)
+{
+ return alloc_anon_inode_sb(anon_inode_mnt->mnt_sb);
+}
+EXPORT_SYMBOL_GPL(alloc_anon_inode);
+
static int __init anon_inode_init(void)
{
anon_inode_mnt = kern_mount(_inode_fs_type);
if (IS_ERR(anon_inode_mnt))
panic("anon_inode_init() kernel mount failed (%ld)\n",
PTR_ERR(anon_inode_mnt));
- anon_inode_inode = alloc_anon_inode_sb(anon_inode_mnt->mnt_sb);
+ anon_inode_inode = alloc_anon_inode();
if (IS_ERR(anon_inode_inode))
panic("anon_inode_init() inode allocation failed (%ld)\n",
PTR_ERR(anon_inode_inode));
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 71881a2b6f7860..b5ae9a6eda9923 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -21,6 +21,7 @@ int anon_inode_getfd_secure(const char *name,
const struct file_operations *fops,
void *priv, int flags,
const struct inode *context_inode);
+struct inode *alloc_anon_inode(void);
#endif /* _LINUX_ANON_INODES_H */
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb
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 +-
drivers/gpu/drm/drm_drv.c| 2 +-
drivers/misc/cxl/api.c | 2 +-
drivers/misc/vmw_balloon.c | 2 +-
drivers/scsi/cxlflash/ocxl_hw.c | 2 +-
drivers/virtio/virtio_balloon.c | 2 +-
fs/aio.c | 2 +-
fs/anon_inodes.c | 4 ++--
fs/libfs.c | 2 +-
include/linux/fs.h | 2 +-
kernel/resource.c| 2 +-
mm/z3fold.c | 2 +-
mm/zsmalloc.c| 2 +-
14 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/cmm.c
b/arch/powerpc/platforms/pseries/cmm.c
index 45a3a3022a85c9..6d36b858b14df1 100644
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -580,7 +580,7 @@ static int cmm_balloon_compaction_init(void)
return rc;
}
- b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
+ b_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
if (IS_ERR(b_dev_info.inode)) {
rc = PTR_ERR(b_dev_info.inode);
b_dev_info.inode = NULL;
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f264b70c383eb4..dedcc9483352dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -445,7 +445,7 @@ static inline int is_dma_buf_file(struct file *file)
static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
{
struct file *file;
- struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
+ struct inode *inode = alloc_anon_inode_sb(dma_buf_mnt->mnt_sb);
if (IS_ERR(inode))
return ERR_CAST(inode);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 20d22e41d7ce74..87e7214a8e3565 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -519,7 +519,7 @@ static struct inode *drm_fs_inode_new(void)
return ERR_PTR(r);
}
- inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
+ inode = alloc_anon_inode_sb(drm_fs_mnt->mnt_sb);
if (IS_ERR(inode))
simple_release_fs(_fs_mnt, _fs_cnt);
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index b493de962153ba..2efbf6c98028ef 100644
--- a/drivers/misc/cxl/api.c
+++ b/drivers/misc/cxl/api.c
@@ -73,7 +73,7 @@ static struct file *cxl_getfile(const char *name,
goto err_module;
}
- inode = alloc_anon_inode(cxl_vfs_mount->mnt_sb);
+ inode = alloc_anon_inode_sb(cxl_vfs_mount->mnt_sb);
if (IS_ERR(inode)) {
file = ERR_CAST(inode);
goto err_fs;
diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
index b837e7eba5f7dc..5d057a05ddbee8 100644
--- a/drivers/misc/vmw_balloon.c
+++ b/drivers/misc/vmw_balloon.c
@@ -1900,7 +1900,7 @@ static __init int vmballoon_compaction_init(struct
vmballoon *b)
return PTR_ERR(vmballoon_mnt);
b->b_dev_info.migratepage = vmballoon_migratepage;
- b->b_dev_info.inode = alloc_anon_inode(vmballoon_mnt->mnt_sb);
+ b->b_dev_info.inode = alloc_anon_inode_sb(vmballoon_mnt->mnt_sb);
if (IS_ERR(b->b_dev_info.inode))
return PTR_ERR(b->b_dev_info.inode);
diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
index 244fc27215dc79..40184ed926b557 100644
--- a/drivers/scsi/cxlflash/ocxl_hw.c
+++ b/drivers/scsi/cxlflash/ocxl_hw.c
@@ -88,7 +88,7 @@ static struct file *ocxlflash_getfile(struct device *dev,
const char *name,
goto err2;
}
- inode = alloc_anon_inode(ocxlflash_vfs_mount->mnt_sb);
+ inode = alloc_anon_inode_sb(ocxlflash_vfs_mount->mnt_sb);
if (IS_ERR(inode)) {
rc = PTR_ERR(inode);
dev_err(dev, "%s: alloc_anon_inode failed rc=%d\n",
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 8985fc2cea8615..cae76ee5bdd688 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -916,7 +916,7 @@ static int virtballoon_probe(struct virtio_device *vdev)
}
vb->vb_dev_info.migratepage = virtballoon_migratepage;
- vb->vb_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
+ vb->vb_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
if (IS_ERR(vb->vb_dev_info.inode)) {
err = PTR_ERR(vb->vb_dev_info.inode);
goto out_kern_unmount;
diff --git a/fs/aio.c b/fs/aio.c
index 1f32da13d39ee6..d1c2aa7fd6de7c 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -234,7 +234,7 @@ static const struct
[Bug 212107] Temperature increase by 15°C on radeon gpu
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 may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
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 the vbios. They will still go on when the > > temperature gets high enough. > > Ok. I checked again and the fan does turn on when playing a game (gzdoom). > > Too bad it's the quietest fan in my PC :) > > I guess I panicked. > > If this is the expected behaviour then this bug can be closed. > > Thank you. It _is_ expected and we waited (very) long for it. ;-) (Did regularly testing with amd-staging-drm-next kernel.) You can close it. (First 'solved', later 'closed'). Greetings Dieter -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 212107] Temperature increase by 15°C on radeon gpu
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 > temperature gets high enough. Ok. I checked again and the fan does turn on when playing a game (gzdoom). Too bad it's the quietest fan in my PC :) I guess I panicked. If this is the expected behaviour then this bug can be closed. Thank you. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] locking/rwsem: Add down_write_interruptible
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 semaphores to switch over to rwsem. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: linux-ker...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org No SoB! Ah, sorry, fixed that locally. Assuning you actually wrote and and simply forgot to add it, the patch does look ok, so: Acked-by: Peter Zijlstra (Intel) Thank you. I didn't want to bother you with the code in vmwgfx, so I only sent it to the lists (it was missing SoB as well): https://lore.kernel.org/patchwork/patch/1391810/ z ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
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 Nikhil from TI are Cc'ed. Hi Kishon / Nikhil, Do you think this can be an issue ? >In any case, it needs a type and constraints on the values. Ok, I will add type and constraints on the values. Regards, Parshuram Thombare ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[syzbot] WARNING in __hrtimer_run_queues
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 dashboard link: https://syzkaller.appspot.com/bug?extid=b0b2da1e0f732c818975 compiler: Debian clang version 11.0.1-2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b0b2da1e0f732c818...@syzkaller.appspotmail.com [ cut here ] raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 10032 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1f/0x30 kernel/locking/irqflag-debug.c:10 Modules linked in: CPU: 1 PID: 10032 Comm: syz-executor.2 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:warn_bogus_irq_restore+0x1f/0x30 kernel/locking/irqflag-debug.c:10 Code: cc cc cc cc cc cc cc cc cc cc cc 80 3d 73 49 54 04 00 74 01 c3 c6 05 69 49 54 04 01 48 c7 c7 60 5d ae 89 31 c0 e8 41 1f fa f7 <0f> 0b c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 41 56 53 48 83 [ cut here ] WARNING: CPU: 1 PID: 10032 at drivers/gpu/drm/vkms/vkms_crtc.c:21 vkms_vblank_simulate+0x2c1/0x320 drivers/gpu/drm/vkms/vkms_crtc.c:21 Modules linked in: CPU: 1 PID: 10032 Comm: syz-executor.2 Not tainted 5.12.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vkms_vblank_simulate+0x2c1/0x320 drivers/gpu/drm/vkms/vkms_crtc.c:21 Code: 00 00 00 48 c7 c6 a0 28 28 8a 31 c0 e8 18 71 ef ff b8 01 00 00 00 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 df e0 13 fd <0f> 0b e9 e8 fd ff ff 89 d9 80 e1 07 38 c1 0f 8c 5c fe ff ff 48 89 RSP: 0018:c9dc04a8 EFLAGS: 00010046 RAX: 8464ccc1 RBX: 0002 RCX: 8880155bb780 RDX: 00010103 RSI: 0002 RDI: 0001 RBP: 8880b9d26260 R08: 8464caa1 R09: fbfff1b6a1e6 R10: fbfff1b6a1e6 R11: R12: dc00 R13: 1110033593d2 R14: 00fe4c00 R15: 888019ac8d30 FS: 01b6c400() GS:8880b9d0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 02e97708 CR3: 1ba55000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __run_hrtimer kernel/time/hrtimer.c:1519 [inline] __hrtimer_run_queues+0x4c9/0xa00 kernel/time/hrtimer.c:1583 hrtimer_interrupt+0x393/0xf70 kernel/time/hrtimer.c:1645 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1089 [inline] __sysvec_apic_timer_interrupt+0xf9/0x270 arch/x86/kernel/apic/apic.c:1106 sysvec_apic_timer_interrupt+0x3e/0xb0 arch/x86/kernel/apic/apic.c:1100 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632 RIP: 0010:console_unlock+0xaab/0xe00 kernel/printk/printk.c:2586 Code: 84 5a f7 ff ff eb 29 e8 73 53 18 00 e8 2e 68 ed 07 4d 85 f6 74 df 66 0f 1f 84 00 00 00 00 00 e8 5b 53 18 00 fb f6 44 24 0f 01 <0f> 84 2f f7 ff ff e8 4a 53 18 00 48 c7 c7 b4 4d 6f 8b be 1b 0a 00 RSP: 0018:c9dc0800 EFLAGS: 0246 RAX: 81605a45 RBX: RCX: 8880155bb780 RDX: 0103 RSI: RDI: RBP: c9dc0918 R08: 81605a02 R09: fbfff1f27aa9 R10: fbfff1f27aa9 R11: R12: dc00 R13: 119ed295 R14: 0200 R15: 119ed28e vprintk_emit+0x1ab/0x270 kernel/printk/printk.c:2098 printk+0x62/0x83 kernel/printk/printk.c:2146 show_opcodes+0xc1/0xe0 arch/x86/kernel/dumpstack.c:129 show_ip arch/x86/kernel/dumpstack.c:150 [inline] show_iret_regs+0x2f/0x60 arch/x86/kernel/dumpstack.c:155 __show_regs+0x29/0x580 arch/x86/kernel/process_64.c:73 show_regs+0x35/0x60 arch/x86/kernel/dumpstack.c:469 __warn+0x12f/0x270 kernel/panic.c:595 report_bug+0x1b1/0x2e0 lib/bug.c:195 handle_bug+0x3d/0x70 arch/x86/kernel/traps.c:239 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:259 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:575 RIP: 0010:warn_bogus_irq_restore+0x1f/0x30 kernel/locking/irqflag-debug.c:10 Code: cc cc cc cc cc cc cc cc cc cc cc 80 3d 73 49 54 04 00 74 01 c3 c6 05 69 49 54 04 01 48 c7 c7 60 5d ae 89 31 c0 e8 41 1f fa f7 <0f> 0b c3 cc cc cc cc cc cc cc cc cc cc cc cc cc cc 41 56 53 48 83 RSP: 0018:c9dc0c78 EFLAGS: 00010246 RAX: 74fd7735e664bd00 RBX: 888019090088 RCX: 8880155bb780 RDX: 0102 RSI: 0102 RDI: RBP: 1920001b8190 R08: 81605e52 R09: ed10173a3f1c R10: ed10173a3f1c R11: R12: 0003 R13: 88823ffe6dc0
Re: [PATCH] drm/msm/dsi: fix check-before-set in the 7nm dsi_pll code
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() after calling device-specific functions.
>
> Cc: Jonathan Marek
> Fixes: 1ef7c99d145c ("drm/msm/dsi: add support for 7nm DSI PHY/PLL")
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 2 +-
> drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 6 --
> drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 5 +++--
> 3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
> index a45fe95aff49..3dc65877fa10 100644
> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.c
> @@ -163,7 +163,7 @@ struct msm_dsi_pll *msm_dsi_pll_init(struct
> platform_device *pdev,
> break;
> case MSM_DSI_PHY_7NM:
> case MSM_DSI_PHY_7NM_V4_1:
> - pll = msm_dsi_pll_7nm_init(pdev, id);
> + pll = msm_dsi_pll_7nm_init(pdev, type, id);
> break;
> default:
> pll = ERR_PTR(-ENXIO);
> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
> index 3405982a092c..bbecb1de5678 100644
> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
> @@ -117,10 +117,12 @@ msm_dsi_pll_10nm_init(struct platform_device *pdev, int
> id)
> }
> #endif
> #ifdef CONFIG_DRM_MSM_DSI_7NM_PHY
> -struct msm_dsi_pll *msm_dsi_pll_7nm_init(struct platform_device *pdev, int
> id);
> +struct msm_dsi_pll *msm_dsi_pll_7nm_init(struct platform_device *pdev,
> + enum msm_dsi_phy_type type, int id);
> #else
> static inline struct msm_dsi_pll *
> -msm_dsi_pll_7nm_init(struct platform_device *pdev, int id)
> +msm_dsi_pll_7nm_init(struct platform_device *pdev,
> + enum msm_dsi_phy_type type, int id)
> {
> return ERR_PTR(-ENODEV);
> }
> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
> index 93bf142e4a4e..c1f6708367ae 100644
> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c
> @@ -852,7 +852,8 @@ static int pll_7nm_register(struct dsi_pll_7nm *pll_7nm)
> return ret;
> }
>
> -struct msm_dsi_pll *msm_dsi_pll_7nm_init(struct platform_device *pdev, int
> id)
> +struct msm_dsi_pll *msm_dsi_pll_7nm_init(struct platform_device *pdev,
> + enum msm_dsi_phy_type type, int id)
> {
> struct dsi_pll_7nm *pll_7nm;
> struct msm_dsi_pll *pll;
> @@ -885,7 +886,7 @@ struct msm_dsi_pll *msm_dsi_pll_7nm_init(struct
> platform_device *pdev, int id)
> pll = _7nm->base;
> pll->min_rate = 10UL;
> pll->max_rate = 35UL;
> - if (pll->type == MSM_DSI_PHY_7NM_V4_1) {
> + if (type == MSM_DSI_PHY_7NM_V4_1) {
> pll->min_rate = 6UL;
> pll->max_rate = (unsigned long)50ULL;
> /* workaround for max rate overflowing on 32-bit builds: */
> --
> 2.30.0
>
--
With best wishes
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/3] drm: Add GUD USB Display driver
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 *intf, const struct usb_device_id
> *id)
..
> + if (format == GUD_DRM_FORMAT_R1)
> + continue; /* Internal not for userspace */
You already found RGB111 missing here.
> +static int gud_usb_control_msg(struct usb_interface *intf, bool in,
> +u8 request, u16 value, void *buf, size_t len)
..
> +static int gud_usb_transfer(struct gud_device *gdrm, bool in, u8 request,
> u16 index,
..
> + ret = gud_usb_control_msg(intf, in, request, index, buf, len);
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 parameters to wValue,
to show that and where they are part of the control request? I think
it would help make the protocol more clear.
Finally, an actual bug:
> + ret = gud_get_properties(gdrm);
> + if (ret) {
> + dev_err(dev, "Failed to get properties (error=%d)\n", ret);
> + return ret;
> + }
If gud_get_properties() and gud_connector_add_properties() receive
and process (only!) one or more unknown properties then they return
the number of bytes received from the device rather than 0.
I fixed this by setting ret = 0; before the for() loop, but maybe you
want to do it another way.
I found this because I can't get my device to send 0 bytes IN when
the host requests more, if I provide no data the request STALLs. This
is for sure a bug in my device and I'll come back to it, but for now
I added a dummy 65535 property as a workaround.
What do you think about formalizing this, adding an actual dummy property?
Or maybe adding flags to the display descriptor for "I have properties",
"I have connector properties" and "I have EDID" ?
> +++ b/drivers/gpu/drm/gud/gud_pipe.c
..
> +static int gud_prep_flush(struct gud_device *gdrm, struct drm_framebuffer
> *fb,
..
> + /*
> + * Imported buffers are assumed to be write-combined and thus uncached
> + * with slow reads (at least on ARM).
> + */
> + if (format != fb->format) {
> + if (format->format == GUD_DRM_FORMAT_R1) {
> + len = gud_xrgb_to_r124(buf, format, vaddr, fb,
> rect);
> + if (!len) {
> + ret = -ENOMEM;
> + goto end_cpu_access;
> + }
> + } else if (format->format == DRM_FORMAT_RGB565) {
> + drm_fb_xrgb_to_rgb565(buf, vaddr, fb, rect,
> gud_is_big_endian());
> + } else {
> + len = gud_xrgb_to_color(buf, format, vaddr, fb,
> rect);
> + }
Does this section also need a RGB111 case?
> +void gud_pipe_update(struct drm_simple_display_pipe *pipe,
..
> + if (fb && (crtc->state->mode_changed ||
> crtc->state->connectors_changed))
> + gud_usb_set(gdrm, GUD_REQ_SET_STATE_COMMIT, 0, NULL, 0);
You mentioned that commit must not fail; what happens/should happen
if a request does fail in pipe_update()? Some reasons could be that
the device was unplugged, a bad cable is glitchy or even that some
device doesn't even implement STATE_COMMIT or does it incorrectly and
will report back failure?
> +++ b/include/drm/gud.h
..
> + #define GUD_STATUS_REQUEST_NOT_SUPPORTED 0x02
Maybe this can be removed? SET_VERSION has been removed so it's no
longer used anywhere, and in any case devices typically signal that
requests are unsupported using a protocol STALL, which comes back
as -EPIPE from the USB stack.
Finally, here's the drm debug output when I connect my device:
Mar 09 14:57:19 vm kernel: usb 1-1: new full-speed USB device number 24 using
uhci_hcd
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_probe] version=1 flags=0x2
compression=0x0 max_buffer_size=0
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_usb_transfer] get:
request=0x40 index=0 len=32
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_usb_transfer] get:
request=0x41 index=0 len=320
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_probe] Ignoring unknown
property: 65535
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_usb_transfer] get:
request=0x50 index=0 len=256
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_get_connectors] Connector:
index=0 type=0 flags=0x0
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_usb_transfer] get:
request=0x51 index=0 len=320
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_get_connectors] property:
65535 = 0(0x0)
Mar 09 14:57:19 vm kernel: gud 1-1:27.0: [drm:gud_get_connectors] Ignoring
unknown property:
[RFC v1 6/6] drm/edid: use the new displayid iterator for tile info
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 +++---
drivers/gpu/drm/drm_edid.c | 37 +++--
include/drm/drm_displayid.h | 12 ---
3 files changed, 10 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 88070267aac9..b146f2d0d72a 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -33,9 +33,9 @@ static int validate_displayid(const u8 *displayid, int
length, int idx)
return 0;
}
-const u8 *drm_find_displayid_extension(const struct edid *edid,
- int *length, int *idx,
- int *ext_index)
+static const u8 *drm_find_displayid_extension(const struct edid *edid,
+ int *length, int *idx,
+ int *ext_index)
{
const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT,
ext_index);
const struct displayid_hdr *base;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4526e2557dca..81d5f2524246 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5969,43 +5969,20 @@ static void drm_parse_tiled_block(struct drm_connector
*connector,
}
}
-static void drm_displayid_parse_tiled(struct drm_connector *connector,
- const u8 *displayid, int length, int idx)
-{
- const struct displayid_block *block;
-
- idx += sizeof(struct displayid_hdr);
- for_each_displayid_db(displayid, block, idx, length) {
- DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
- block->tag, block->rev, block->num_bytes);
-
- switch (block->tag) {
- case DATA_BLOCK_TILED_DISPLAY:
- drm_parse_tiled_block(connector, block);
- break;
- default:
- DRM_DEBUG_KMS("found DisplayID tag 0x%x, unhandled\n",
block->tag);
- break;
- }
- }
-}
-
void drm_update_tile_info(struct drm_connector *connector,
const struct edid *edid)
{
- const void *displayid = NULL;
- int ext_index = 0;
- int length, idx;
+ const struct displayid_block *block;
+ struct displayid_iter iter;
connector->has_tile = false;
- for (;;) {
- displayid = drm_find_displayid_extension(edid, , ,
-_index);
- if (!displayid)
- break;
- drm_displayid_parse_tiled(connector, displayid, length, idx);
+ displayid_iter_edid_begin(edid, );
+ displayid_iter_for_each(block, ) {
+ if (block->tag == DATA_BLOCK_TILED_DISPLAY)
+ drm_parse_tiled_block(connector, block);
}
+ displayid_iter_end();
if (!connector->has_tile && connector->tile_group) {
drm_mode_put_tile_group(connector->dev, connector->tile_group);
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index 27e06c98db17..10ee863f1734 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -96,18 +96,6 @@ struct displayid_detailed_timing_block {
struct displayid_detailed_timings_1 timings[];
};
-#define for_each_displayid_db(displayid, block, idx, length) \
- for ((block) = (const struct displayid_block *)&(displayid)[idx]; \
-(idx) + sizeof(struct displayid_block) <= (length) && \
-(idx) + sizeof(struct displayid_block) + (block)->num_bytes <=
(length) && \
-(block)->num_bytes > 0; \
-(idx) += sizeof(struct displayid_block) + (block)->num_bytes, \
-(block) = (const struct displayid_block *)&(displayid)[idx])
-
-const u8 *drm_find_displayid_extension(const struct edid *edid,
- int *length, int *idx,
- int *ext_index);
-
/* DisplayID iteration */
struct displayid_iter {
const struct edid *edid;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v1 5/6] drm/edid: use the new displayid iterator for finding CEA extension
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..4526e2557dca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3266,35 +3266,28 @@ const u8 *drm_find_edid_extension(const struct edid
*edid,
static const u8 *drm_find_cea_extension(const struct edid *edid)
{
- int length, idx;
const struct displayid_block *block;
+ struct displayid_iter iter;
const u8 *cea;
- const u8 *displayid;
- int ext_index;
+ int ext_index = 0;
/* Look for a top level CEA extension block */
/* FIXME: make callers iterate through multiple CEA ext blocks? */
- ext_index = 0;
cea = drm_find_edid_extension(edid, CEA_EXT, _index);
if (cea)
return cea;
/* CEA blocks can also be found embedded in a DisplayID block */
- ext_index = 0;
- for (;;) {
- displayid = drm_find_displayid_extension(edid, , ,
-_index);
- if (!displayid)
- return NULL;
-
- idx += sizeof(struct displayid_hdr);
- for_each_displayid_db(displayid, block, idx, length) {
- if (block->tag == DATA_BLOCK_CTA)
- return (const u8 *)block;
+ displayid_iter_edid_begin(edid, );
+ displayid_iter_for_each(block, ) {
+ if (block->tag == DATA_BLOCK_CTA) {
+ cea = (const u8 *)block;
+ break;
}
}
+ displayid_iter_end();
- return NULL;
+ return cea;
}
static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 vic)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v1 4/6] drm/edid: use the new displayid iterator for detailed modes
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..fbaa7d679cb2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5333,27 +5333,16 @@ static int add_displayid_detailed_1_modes(struct
drm_connector *connector,
static int add_displayid_detailed_modes(struct drm_connector *connector,
struct edid *edid)
{
- const u8 *displayid;
- int length, idx;
const struct displayid_block *block;
+ struct displayid_iter iter;
int num_modes = 0;
- int ext_index = 0;
-
- for (;;) {
- displayid = drm_find_displayid_extension(edid, , ,
-_index);
- if (!displayid)
- break;
- idx += sizeof(struct displayid_hdr);
- for_each_displayid_db(displayid, block, idx, length) {
- switch (block->tag) {
- case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
- num_modes +=
add_displayid_detailed_1_modes(connector, block);
- break;
- }
- }
+ displayid_iter_edid_begin(edid, );
+ displayid_iter_for_each(block, ) {
+ if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING)
+ num_modes += add_displayid_detailed_1_modes(connector,
block);
}
+ displayid_iter_end();
return num_modes;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v1 3/6] drm/displayid: add new displayid section/block iterators
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_iter_edid_begin(edid, );
displayid_iter_for_each(block, ) {
/* operate on block */
}
displayid_iter_end();
When DisplayID is stored in EDID extensions, the DisplayID sections map
to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID
as an EDID Extension. This is implemented here.
When DisplayID is stored in its dedicated DDC device 0xA4, according to
VESA E-DDC v1.3, different rules apply for the structure. This is not
implemented here, as we don't currently use it, but the idea is you'd
have a different call for beginning the iteration, for example simply:
displayid_iter_begin(displayid, );
instead of displayid_iter_edid_begin(), and everything else would be
hidden away in the iterator functions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 74 +
include/drm/drm_displayid.h | 18
2 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 908bbe6feb61..88070267aac9 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -57,3 +57,77 @@ const u8 *drm_find_displayid_extension(const struct edid
*edid,
return displayid;
}
+
+void displayid_iter_edid_begin(const struct edid *edid,
+ struct displayid_iter *iter)
+{
+ memset(iter, 0, sizeof(*iter));
+
+ iter->edid = edid;
+}
+
+static const struct displayid_block *
+__displayid_iter_block(const struct displayid_iter *iter)
+{
+ const struct displayid_block *block;
+
+ if (!iter->section)
+ return NULL;
+
+ block = (const struct displayid_block *)>section[iter->idx];
+
+ if (iter->idx + sizeof(struct displayid_block) <= iter->length &&
+ iter->idx + sizeof(struct displayid_block) + block->num_bytes <=
iter->length &&
+ block->num_bytes > 0)
+ return block;
+
+ return NULL;
+}
+
+const struct displayid_block *
+__displayid_iter_next(struct displayid_iter *iter)
+{
+ const struct displayid_block *block;
+
+ if (!iter->edid)
+ return NULL;
+
+ if (iter->section) {
+ /* current block should always be valid */
+ block = __displayid_iter_block(iter);
+ if (WARN_ON(!block)) {
+ iter->section = NULL;
+ iter->edid = NULL;
+ return NULL;
+ }
+
+ /* next block in section */
+ iter->idx += sizeof(struct displayid_block) + block->num_bytes;
+
+ block = __displayid_iter_block(iter);
+ if (block)
+ return block;
+ }
+
+ for (;;) {
+ iter->section = drm_find_displayid_extension(iter->edid,
+>length,
+>idx,
+>ext_index);
+ if (!iter->section) {
+ iter->edid = NULL;
+ return NULL;
+ }
+
+ iter->idx += sizeof(struct displayid_hdr);
+
+ block = __displayid_iter_block(iter);
+ if (block)
+ return block;
+ }
+}
+
+void displayid_iter_end(struct displayid_iter *iter)
+{
+ memset(iter, 0, sizeof(*iter));
+}
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index 3c6db22a518a..27e06c98db17 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -108,4 +108,22 @@ const u8 *drm_find_displayid_extension(const struct edid
*edid,
int *length, int *idx,
int *ext_index);
+/* DisplayID iteration */
+struct displayid_iter {
+ const struct edid *edid;
+
+ const u8 *section;
+ int length;
+ int idx;
+ int ext_index;
+};
+
+void displayid_iter_edid_begin(const struct edid *edid,
+ struct displayid_iter *iter);
+const struct displayid_block *
+__displayid_iter_next(struct displayid_iter *iter);
+#define displayid_iter_for_each(__block, __iter) \
+ while (((__block) = __displayid_iter_next(__iter)))
+void displayid_iter_end(struct displayid_iter *iter);
+
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v1 2/6] drm/displayid: add separate drm_displayid.c
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
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_displayid.c | 59 +
drivers/gpu/drm/drm_edid.c | 58 ++--
include/drm/drm_displayid.h | 8 +
include/drm/drm_edid.h | 3 ++
5 files changed, 73 insertions(+), 57 deletions(-)
create mode 100644 drivers/gpu/drm/drm_displayid.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5eb5bf7c16e3..78ef2fd14f10 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -7,7 +7,7 @@ drm-y := drm_auth.o drm_cache.o \
drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_drv.o \
drm_sysfs.o drm_hashtab.o drm_mm.o \
- drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
+ drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o drm_displayid.o \
drm_encoder_slave.o \
drm_trace_points.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
new file mode 100644
index ..908bbe6feb61
--- /dev/null
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+static int validate_displayid(const u8 *displayid, int length, int idx)
+{
+ int i, dispid_length;
+ u8 csum = 0;
+ const struct displayid_hdr *base;
+
+ base = (const struct displayid_hdr *)[idx];
+
+ DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",
+ base->rev, base->bytes, base->prod_id, base->ext_count);
+
+ /* +1 for DispID checksum */
+ dispid_length = sizeof(*base) + base->bytes + 1;
+ if (dispid_length > length - idx)
+ return -EINVAL;
+
+ for (i = 0; i < dispid_length; i++)
+ csum += displayid[idx + i];
+ if (csum) {
+ DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+const u8 *drm_find_displayid_extension(const struct edid *edid,
+ int *length, int *idx,
+ int *ext_index)
+{
+ const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT,
ext_index);
+ const struct displayid_hdr *base;
+ int ret;
+
+ if (!displayid)
+ return NULL;
+
+ /* EDID extensions block checksum isn't for us */
+ *length = EDID_LENGTH - 1;
+ *idx = 1;
+
+ ret = validate_displayid(displayid, *length, *idx);
+ if (ret)
+ return NULL;
+
+ base = (const struct displayid_hdr *)[*idx];
+ *length = *idx + sizeof(*base) + base->bytes;
+
+ return displayid;
+}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d510b827a1f8..58e61f792bc7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1585,8 +1585,6 @@ module_param_named(edid_fixup, edid_fixup, int, 0400);
MODULE_PARM_DESC(edid_fixup,
"Minimum number of valid EDID header bytes (0-8, default 6)");
-static int validate_displayid(const u8 *displayid, int length, int idx);
-
static int drm_edid_block_checksum(const u8 *raw_edid)
{
int i;
@@ -3241,8 +3239,8 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
/*
* Search EDID for CEA extension block.
*/
-static const u8 *drm_find_edid_extension(const struct edid *edid,
-int ext_id, int *ext_index)
+const u8 *drm_find_edid_extension(const struct edid *edid,
+ int ext_id, int *ext_index)
{
const u8 *edid_ext = NULL;
int i;
@@ -3266,32 +3264,6 @@ static const u8 *drm_find_edid_extension(const struct
edid *edid,
return edid_ext;
}
-
-static const u8 *drm_find_displayid_extension(const struct edid *edid,
- int *length, int *idx,
- int *ext_index)
-{
- const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT,
ext_index);
- const struct displayid_hdr *base;
- int ret;
-
- if (!displayid)
- return NULL;
-
- /* EDID extensions block checksum isn't for us */
- *length = EDID_LENGTH - 1;
- *idx = 1;
-
- ret = validate_displayid(displayid, *length, *idx);
- if (ret)
- return NULL;
-
- base = (const struct displayid_hdr *)[*idx];
- *length = *idx +
[RFC v1 1/6] drm/edid: make a number of functions, parameters and variables const
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 +--
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c2bbe7bee7b6..d510b827a1f8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1585,7 +1585,7 @@ module_param_named(edid_fixup, edid_fixup, int, 0400);
MODULE_PARM_DESC(edid_fixup,
"Minimum number of valid EDID header bytes (0-8, default 6)");
-static int validate_displayid(u8 *displayid, int length, int idx);
+static int validate_displayid(const u8 *displayid, int length, int idx);
static int drm_edid_block_checksum(const u8 *raw_edid)
{
@@ -3241,10 +3241,10 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
/*
* Search EDID for CEA extension block.
*/
-static u8 *drm_find_edid_extension(const struct edid *edid,
- int ext_id, int *ext_index)
+static const u8 *drm_find_edid_extension(const struct edid *edid,
+int ext_id, int *ext_index)
{
- u8 *edid_ext = NULL;
+ const u8 *edid_ext = NULL;
int i;
/* No EDID or EDID extensions */
@@ -3253,7 +3253,7 @@ static u8 *drm_find_edid_extension(const struct edid
*edid,
/* Find CEA extension */
for (i = *ext_index; i < edid->extensions; i++) {
- edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
+ edid_ext = (const u8 *)edid + EDID_LENGTH * (i + 1);
if (edid_ext[0] == ext_id)
break;
}
@@ -3267,12 +3267,12 @@ static u8 *drm_find_edid_extension(const struct edid
*edid,
}
-static u8 *drm_find_displayid_extension(const struct edid *edid,
- int *length, int *idx,
- int *ext_index)
+static const u8 *drm_find_displayid_extension(const struct edid *edid,
+ int *length, int *idx,
+ int *ext_index)
{
- u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
- struct displayid_hdr *base;
+ const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT,
ext_index);
+ const struct displayid_hdr *base;
int ret;
if (!displayid)
@@ -3286,18 +3286,18 @@ static u8 *drm_find_displayid_extension(const struct
edid *edid,
if (ret)
return NULL;
- base = (struct displayid_hdr *)[*idx];
+ base = (const struct displayid_hdr *)[*idx];
*length = *idx + sizeof(*base) + base->bytes;
return displayid;
}
-static u8 *drm_find_cea_extension(const struct edid *edid)
+static const u8 *drm_find_cea_extension(const struct edid *edid)
{
int length, idx;
- struct displayid_block *block;
- u8 *cea;
- u8 *displayid;
+ const struct displayid_block *block;
+ const u8 *cea;
+ const u8 *displayid;
int ext_index;
/* Look for a top level CEA extension block */
@@ -3318,7 +3318,7 @@ static u8 *drm_find_cea_extension(const struct edid *edid)
idx += sizeof(struct displayid_hdr);
for_each_displayid_db(displayid, block, idx, length) {
if (block->tag == DATA_BLOCK_CTA)
- return (u8 *)block;
+ return (const u8 *)block;
}
}
@@ -4503,8 +4503,8 @@ static void clear_eld(struct drm_connector *connector)
static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
uint8_t *eld = connector->eld;
- u8 *cea;
- u8 *db;
+ const u8 *cea;
+ const u8 *db;
int total_sad_count = 0;
int mnl;
int dbl;
@@ -4600,7 +4600,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
{
int count = 0;
int i, start, end, dbl;
- u8 *cea;
+ const u8 *cea;
cea = drm_find_cea_extension(edid);
if (!cea) {
@@ -4619,7 +4619,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
}
for_each_cea_db(cea, i, start, end) {
- u8 *db = [i];
+ const u8 *db = [i];
if (cea_db_tag(db) == AUDIO_BLOCK) {
int j;
@@ -4631,7 +4631,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
if (!*sads)
return -ENOMEM;
for (j = 0; j < count; j++) {
- u8 *sad = [1 + j * 3];
+ const u8 *sad = [1 + j * 3];
[RFC v1 0/6] drm/edid: overhaul displayid iterator
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: make a number of functions, parameters and variables const drm/displayid: add separate drm_displayid.c drm/displayid: add new displayid section/block iterators drm/edid: use the new displayid iterator for detailed modes drm/edid: use the new displayid iterator for finding CEA extension drm/edid: use the new displayid iterator for tile info drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_displayid.c | 133 + drivers/gpu/drm/drm_edid.c | 171 +++- include/drm/drm_displayid.h | 28 -- include/drm/drm_edid.h | 3 + 5 files changed, 196 insertions(+), 141 deletions(-) create mode 100644 drivers/gpu/drm/drm_displayid.c -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/nouveau: fix dma syncing for loops
>-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 one place.
>
>Noticed this while trying to track down another oops.
>
>Fixes: f295c8cfec83 ("drm/nouveau: fix dma syncing warning with debugging
>on.")
>Signed-off-by: Dave Airlie
>---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 2375711877cf..4f693843def5 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -556,7 +556,7 @@ nouveau_bo_sync_for_device(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ for (i = 0; i < ttm_dma->num_pages;) {
This took a bit to see how the increment worked.
Would calling it out with a comment be out of line?
With or without the comment:
Reviewed-by: Michael J. Ruhl
M
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>@@ -587,7 +587,7 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo
>*nvbo)
> if (nvbo->force_coherent)
> return;
>
>- for (i = 0; i < ttm_dma->num_pages; ++i) {
>+ for (i = 0; i < ttm_dma->num_pages;) {
> struct page *p = ttm_dma->pages[i];
> size_t num_pages = 1;
>
>--
>2.27.0
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: fix possible leak/unlock virtio_gpu_object_array
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.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/8] mm: Remove special swap entry functions
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
> - * corresponding page is locked
> - */
> - BUG_ON(!PageLocked(compound_head(p)));
> - return p;
> -}
> +static inline struct page *pfn_swap_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
> + * corresponding page is locked
> + */
> + BUG_ON(is_migration_entry(entry) && !PageLocked(compound_head(p)));
> +
> + return p;
> +}
I appreciate you're only moving this code, but PageLocked includes an
implicit compound_head():
1. __PAGEFLAG(Locked, locked, PF_NO_TAIL)
2. #define __PAGEFLAG(uname, lname, policy)\
TESTPAGEFLAG(uname, lname, policy) \
3. #define TESTPAGEFLAG(uname, lname, policy) \
static __always_inline int Page##uname(struct page *page) \
{ return test_bit(PG_##lname, (page, 0)->flags); }
4. #define PF_NO_TAIL(page, enforce) ({\
VM_BUG_ON_PGFLAGS(enforce && PageTail(page), page); \
PF_POISONED_CHECK(compound_head(page)); })
5. #define PF_POISONED_CHECK(page) ({ \
VM_BUG_ON_PGFLAGS(PagePoisoned(page), page);\
page; })
This macrology isn't easy to understand the first time you read it (nor,
indeed, the tenth time), so let me decode it:
Substitute 5 into 4 and remove irrelevancies:
6. #define PF_NO_TAIL(page, enforce) compound_head(page)
Expand 1 in 2:
7. TESTPAGEFLAG(Locked, locked, PF_NO_TAIL)
Expand 7 in 3:
8. static __always_inline int PageLocked(struct page *page)
{ return test_bit(PG_locked, _NO_TAIL(page, 0)->flags); }
Expand 6 in 8:
9. static __always_inline int PageLocked(struct page *page)
{ return test_bit(PG_locked, _head(page)->flags); }
(in case it's not clear, compound_head() is idempotent. that is:
f(f(a)) == f(a))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/8] mm: Selftests for exclusive device memory
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/selftests/vm/hmm-tests.c | 219 +
3 files changed, 346 insertions(+), 1 deletion(-)
diff --git a/lib/test_hmm.c b/lib/test_hmm.c
index 80a78877bd93..305a9d9e2b4c 100644
--- a/lib/test_hmm.c
+++ b/lib/test_hmm.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "test_hmm_uapi.h"
@@ -46,6 +47,7 @@ struct dmirror_bounce {
unsigned long cpages;
};
+#define DPT_XA_TAG_ATOMIC 1UL
#define DPT_XA_TAG_WRITE 3UL
/*
@@ -218,7 +220,7 @@ static bool dmirror_interval_invalidate(struct
mmu_interval_notifier *mni,
* the invalidation is handled as part of the migration process.
*/
if (range->event == MMU_NOTIFY_MIGRATE &&
- range->migrate_pgmap_owner == dmirror->mdevice)
+ range->owner == dmirror->mdevice)
return true;
if (mmu_notifier_range_blockable(range))
@@ -619,6 +621,54 @@ static void dmirror_migrate_alloc_and_copy(struct
migrate_vma *args,
}
}
+static int dmirror_check_atomic(struct dmirror *dmirror, unsigned long start,
+unsigned long end)
+{
+ unsigned long pfn;
+
+ for (pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT); pfn++) {
+ void *entry;
+ struct page *page;
+
+ entry = xa_load(>pt, pfn);
+ page = xa_untag_pointer(entry);
+ if (xa_pointer_tag(entry) == DPT_XA_TAG_ATOMIC)
+ return -EPERM;
+ }
+
+ return 0;
+}
+
+static int dmirror_atomic_map(unsigned long start, unsigned long end,
+ struct page **pages, struct dmirror *dmirror)
+{
+ unsigned long pfn, mapped = 0;
+ int i;
+
+ /* Map the migrated pages into the device's page tables. */
+ mutex_lock(>mutex);
+
+ for (i = 0, pfn = start >> PAGE_SHIFT; pfn < (end >> PAGE_SHIFT);
pfn++, i++) {
+ void *entry;
+
+ if (!pages[i])
+ continue;
+
+ entry = pages[i];
+ entry = xa_tag_pointer(entry, DPT_XA_TAG_ATOMIC);
+ entry = xa_store(>pt, pfn, entry, GFP_ATOMIC);
+ if (xa_is_err(entry)) {
+ mutex_unlock(>mutex);
+ return xa_err(entry);
+ }
+
+ mapped++;
+ }
+
+ mutex_unlock(>mutex);
+ return mapped;
+}
+
static int dmirror_migrate_finalize_and_map(struct migrate_vma *args,
struct dmirror *dmirror)
{
@@ -661,6 +711,71 @@ static int dmirror_migrate_finalize_and_map(struct
migrate_vma *args,
return 0;
}
+static int dmirror_exclusive(struct dmirror *dmirror,
+struct hmm_dmirror_cmd *cmd)
+{
+ unsigned long start, end, addr;
+ unsigned long size = cmd->npages << PAGE_SHIFT;
+ struct mm_struct *mm = dmirror->notifier.mm;
+ struct page *pages[64];
+ struct dmirror_bounce bounce;
+ unsigned long next;
+ int ret;
+
+ start = cmd->addr;
+ end = start + size;
+ if (end < start)
+ return -EINVAL;
+
+ /* Since the mm is for the mirrored process, get a reference first. */
+ if (!mmget_not_zero(mm))
+ return -EINVAL;
+
+ mmap_read_lock(mm);
+ for (addr = start; addr < end; addr = next) {
+ int i, mapped;
+
+ if (end < addr + (ARRAY_SIZE(pages) << PAGE_SHIFT))
+ next = end;
+ else
+ next = addr + (ARRAY_SIZE(pages) << PAGE_SHIFT);
+
+ ret = make_device_exclusive_range(mm, addr, next, pages, NULL);
+ mapped = dmirror_atomic_map(addr, next, pages, dmirror);
+ for (i = 0; i < ret; i++) {
+ if (pages[i]) {
+ unlock_page(pages[i]);
+ put_page(pages[i]);
+ }
+ }
+
+ if (addr + (mapped << PAGE_SHIFT) < next) {
+ mmap_read_unlock(mm);
+ mmput(mm);
+ return -EBUSY;
+ }
+ }
+ mmap_read_unlock(mm);
+ mmput(mm);
+
+ /* Return the migrated data for verification. */
+ ret = dmirror_bounce_init(, start, size);
+ if (ret)
+ return ret;
+ mutex_lock(>mutex);
+ ret = dmirror_do_read(dmirror, start, end, );
+ mutex_unlock(>mutex);
+ if (ret == 0) {
+ if (copy_to_user(u64_to_user_ptr(cmd->ptr), bounce.ptr,
+
[PATCH v5 5/8] mm: Device exclusive memory access
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_EXCLUSIVE). When a SVM range needs to be marked for
exclusive access by a device all page table mappings for the particular
range are replaced with device exclusive swap entries. This causes any
CPU access to the page to result in a fault.
Faults are resovled by replacing the faulting entry with the original
mapping. This results in MMU notifiers being called which a driver uses
to update access permissions such as revoking atomic access. After
notifiers have been called the device will no longer have exclusive
access to the region.
Signed-off-by: Alistair Popple
---
v5:
* Renamed range->migrate_pgmap_owner to range->owner.
* Added MMU_NOTIFY_EXCLUSIVE to allow passing of a driver cookie which
allows notifiers called as a result of make_device_exclusive_range() to
be ignored.
* Added a check to try_to_protect_one() to detect if the pages originally
returned from get_user_pages() have been unmapped or not.
* Removed check_device_exclusive_range() as it is no longer required with
the other changes.
* Documentation update.
v4:
* Add function to check that mappings are still valid and exclusive.
* s/long/unsigned long/ in make_device_exclusive_entry().
---
Documentation/vm/hmm.rst | 19 +++-
include/linux/mmu_notifier.h | 25 -
include/linux/rmap.h | 4 +
include/linux/swap.h | 4 +-
include/linux/swapops.h | 44 +++-
mm/hmm.c | 5 +
mm/memory.c | 107 +-
mm/mprotect.c| 8 ++
mm/page_vma_mapped.c | 9 +-
mm/rmap.c| 203 +++
10 files changed, 417 insertions(+), 11 deletions(-)
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 09e28507f5b2..a5fdee82c037 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -332,7 +332,7 @@ between device driver specific code and shared common code:
walks to fill in the ``args->src`` array with PFNs to be migrated.
The ``invalidate_range_start()`` callback is passed a
``struct mmu_notifier_range`` with the ``event`` field set to
- ``MMU_NOTIFY_MIGRATE`` and the ``migrate_pgmap_owner`` field set to
+ ``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to
the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is
allows the device driver to skip the invalidation callback and only
invalidate device private MMU mappings that are actually migrating.
@@ -405,6 +405,23 @@ between device driver specific code and shared common code:
The lock can now be released.
+Exclusive access memory
+===
+
+Not all devices support atomic access to system memory. To support atomic
+operations to a shared virtual memory page such a device needs access to that
+page which is exclusive of any userspace access from the CPU. The
+``make_device_exclusive_range()`` function can be used to make a memory range
+inaccessible from userspace.
+
+This replaces all mappings for pages in the given range with special swap
+entries. Any attempt to access the swap entry results in a fault which is
+resovled by replacing the entry with the original mapping. A driver gets
+notified that the mapping has been changed by MMU notifiers, after which point
+it will no longer have exclusive access to the page. Exclusive access is
+guranteed to last until the driver drops the page lock and page reference, at
+which point any CPU faults on the page may proceed as described.
+
Memory cgroup (memcg) and rss accounting
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b8200782dede..455e269bf825 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -41,7 +41,12 @@ struct mmu_interval_notifier;
*
* @MMU_NOTIFY_MIGRATE: used during migrate_vma_collect() invalidate to signal
* a device driver to possibly ignore the invalidation if the
- * migrate_pgmap_owner field matches the driver's device private pgmap owner.
+ * owner field matches the driver's device private pgmap owner.
+ *
+ * @MMU_NOTIFY_EXCLUSIVE: to signal a device driver that the device will no
+ * longer have exclusive access to the page. May ignore the invalidation that's
+ * part of make_device_exclusive_range() if the owner field
+ * matches the value passed to make_device_exclusive_range().
*/
enum mmu_notifier_event {
MMU_NOTIFY_UNMAP = 0,
@@ -51,6 +56,7 @@ enum mmu_notifier_event {
MMU_NOTIFY_SOFT_DIRTY,
MMU_NOTIFY_RELEASE,
MMU_NOTIFY_MIGRATE,
+ MMU_NOTIFY_EXCLUSIVE,
};
#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
@@ -269,7 +275,7 @@ struct
[PATCH v5 4/8] mm/rmap: Split migration into its own function
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_unmap_one() and thus splitting it into a
separate function reduces the complexity of try_to_unmap_one() making it
more readable.
Several simplifications can also be made in try_to_migrate_one() based
on the following observations:
- All users of TTU_MIGRATION also set TTU_IGNORE_MLOCK.
- No users of TTU_MIGRATION ever set TTU_IGNORE_HWPOISON.
- No users of TTU_MIGRATION ever set TTU_BATCH_FLUSH.
TTU_SPLIT_FREEZE is a special case of migration used when splitting an
anonymous page. This is most easily dealt with by calling the correct
function from unmap_page() in mm/huge_memory.c - either
try_to_migrate() for PageAnon or try_to_unmap().
Signed-off-by: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
v5:
* Added comments about how PMD splitting works for migration vs.
unmapping
* Tightened up the flag check in try_to_migrate() to be explicit about
which TTU_XXX flags are supported.
---
include/linux/rmap.h | 4 +-
mm/huge_memory.c | 15 +-
mm/migrate.c | 9 +-
mm/rmap.c| 358 ---
4 files changed, 280 insertions(+), 106 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index e26ac2d71346..6062e0cfca2d 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -86,8 +86,6 @@ struct anon_vma_chain {
};
enum ttu_flags {
- TTU_MIGRATION = 0x1, /* migration mode */
-
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
TTU_IGNORE_HWPOISON = 0x20, /* corrupted page is recoverable */
@@ -96,7 +94,6 @@ enum ttu_flags {
* do a final flush if necessary */
TTU_RMAP_LOCKED = 0x80, /* do not grab rmap lock:
* caller holds it */
- TTU_SPLIT_FREEZE= 0x100,/* freeze pte under
splitting thp */
};
#ifdef CONFIG_MMU
@@ -193,6 +190,7 @@ static inline void page_dup_rmap(struct page *page, bool
compound)
int page_referenced(struct page *, int is_locked,
struct mem_cgroup *memcg, unsigned long *vm_flags);
+bool try_to_migrate(struct page *page, enum ttu_flags flags);
bool try_to_unmap(struct page *, enum ttu_flags flags);
/* Avoid racy checks */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 89af065cea5b..eab004331b97 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2357,16 +2357,21 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma,
static void unmap_page(struct page *page)
{
- enum ttu_flags ttu_flags = TTU_IGNORE_MLOCK |
- TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
+ enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD;
bool unmap_success;
VM_BUG_ON_PAGE(!PageHead(page), page);
if (PageAnon(page))
- ttu_flags |= TTU_SPLIT_FREEZE;
-
- unmap_success = try_to_unmap(page, ttu_flags);
+ unmap_success = try_to_migrate(page, ttu_flags);
+ else
+ /*
+* Don't install migration entries for file backed pages. This
+* helps handle cases when i_size is in the middle of the page
+* as there is no need to unmap pages beyond i_size manually.
+*/
+ unmap_success = try_to_unmap(page, ttu_flags |
+ TTU_IGNORE_MLOCK);
VM_BUG_ON_PAGE(!unmap_success, page);
}
diff --git a/mm/migrate.c b/mm/migrate.c
index b752543adb64..cc4612e2a246 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1130,7 +1130,7 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
/* Establish migration ptes */
VM_BUG_ON_PAGE(PageAnon(page) && !PageKsm(page) && !anon_vma,
page);
- try_to_unmap(page, TTU_MIGRATION|TTU_IGNORE_MLOCK);
+ try_to_migrate(page, 0);
page_was_mapped = 1;
}
@@ -1332,7 +1332,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
if (page_mapped(hpage)) {
bool mapping_locked = false;
- enum ttu_flags ttu = TTU_MIGRATION|TTU_IGNORE_MLOCK;
+ enum ttu_flags ttu = 0;
if (!PageAnon(hpage)) {
/*
@@ -1349,7 +1349,7 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
ttu |= TTU_RMAP_LOCKED;
}
- try_to_unmap(hpage, ttu);
+ try_to_migrate(hpage, ttu);
page_was_mapped
[PATCH v5 3/8] mm/rmap: Split try_to_munlock from try_to_unmap
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 than
overload try_to_unmap_one() with unrelated behaviour split this out into
it's own function and remove the flag.
Signed-off-by: Alistair Popple
Reviewed-by: Ralph Campbell
---
Christoph - I didn't add your Reviewed-by from v3 because removal of the
extra VM_LOCKED check in v4 changed things slightly. Let me know if
you're still ok for me to add it. Thanks.
v4:
* Removed redundant check for VM_LOCKED
---
include/linux/rmap.h | 1 -
mm/rmap.c| 40
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index def5c62c93b3..e26ac2d71346 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -87,7 +87,6 @@ struct anon_vma_chain {
enum ttu_flags {
TTU_MIGRATION = 0x1, /* migration mode */
- TTU_MUNLOCK = 0x2, /* munlock mode */
TTU_SPLIT_HUGE_PMD = 0x4, /* split huge PMD if any */
TTU_IGNORE_MLOCK= 0x8, /* ignore mlock */
diff --git a/mm/rmap.c b/mm/rmap.c
index 977e70803ed8..d02bade5245b 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1405,10 +1405,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
struct mmu_notifier_range range;
enum ttu_flags flags = (enum ttu_flags)(long)arg;
- /* munlock has nothing to gain from examining un-locked vmas */
- if ((flags & TTU_MUNLOCK) && !(vma->vm_flags & VM_LOCKED))
- return true;
-
if (IS_ENABLED(CONFIG_MIGRATION) && (flags & TTU_MIGRATION) &&
is_zone_device_page(page) && !is_device_private_page(page))
return true;
@@ -1469,8 +1465,6 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
page_vma_mapped_walk_done();
break;
}
- if (flags & TTU_MUNLOCK)
- continue;
}
/* Unexpected PMD-mapped THP? */
@@ -1784,6 +1778,37 @@ bool try_to_unmap(struct page *page, enum ttu_flags
flags)
return !page_mapcount(page) ? true : false;
}
+static bool try_to_munlock_one(struct page *page, struct vm_area_struct *vma,
+unsigned long address, void *arg)
+{
+ struct page_vma_mapped_walk pvmw = {
+ .page = page,
+ .vma = vma,
+ .address = address,
+ };
+
+ /* munlock has nothing to gain from examining un-locked vmas */
+ if (!(vma->vm_flags & VM_LOCKED))
+ return true;
+
+ while (page_vma_mapped_walk()) {
+ /* PTE-mapped THP are never mlocked */
+ if (!PageTransCompound(page)) {
+ /*
+* Holding pte lock, we do *not* need
+* mmap_lock here
+*/
+ mlock_vma_page(page);
+ }
+ page_vma_mapped_walk_done();
+
+ /* found a mlocked page, no point continuing munlock check */
+ return false;
+ }
+
+ return true;
+}
+
/**
* try_to_munlock - try to munlock a page
* @page: the page to be munlocked
@@ -1796,8 +1821,7 @@ bool try_to_unmap(struct page *page, enum ttu_flags flags)
void try_to_munlock(struct page *page)
{
struct rmap_walk_control rwc = {
- .rmap_one = try_to_unmap_one,
- .arg = (void *)TTU_MUNLOCK,
+ .rmap_one = try_to_munlock_one,
.done = page_not_mapped,
.anon_lock = page_lock_anon_vma_read,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/8] mm/swapops: Rework swap entry manipulation code
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: Alistair Popple
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
---
include/linux/swapops.h | 56 ++---
mm/debug_vm_pgtable.c | 12 -
mm/hmm.c| 2 +-
mm/huge_memory.c| 26 +--
mm/hugetlb.c| 10 +---
mm/memory.c | 10 +---
mm/migrate.c| 26 ++-
mm/mprotect.c | 10 +---
mm/rmap.c | 10 +---
9 files changed, 100 insertions(+), 62 deletions(-)
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 3fd88081107c..81008b0179cc 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -100,35 +100,35 @@ static inline void *swp_to_radix_entry(swp_entry_t entry)
}
#if IS_ENABLED(CONFIG_DEVICE_PRIVATE)
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
- return swp_entry(write ? SWP_DEVICE_WRITE : SWP_DEVICE_READ,
-page_to_pfn(page));
+ return swp_entry(SWP_DEVICE_READ, offset);
}
-static inline bool is_device_private_entry(swp_entry_t entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
- int type = swp_type(entry);
- return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
+ return swp_entry(SWP_DEVICE_WRITE, offset);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline bool is_device_private_entry(swp_entry_t entry)
{
- *entry = swp_entry(SWP_DEVICE_READ, swp_offset(*entry));
+ int type = swp_type(entry);
+ return type == SWP_DEVICE_READ || type == SWP_DEVICE_WRITE;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_DEVICE_WRITE);
}
#else /* CONFIG_DEVICE_PRIVATE */
-static inline swp_entry_t make_device_private_entry(struct page *page, bool
write)
+static inline swp_entry_t make_readable_device_private_entry(pgoff_t offset)
{
return swp_entry(0, 0);
}
-static inline void make_device_private_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_writable_device_private_entry(pgoff_t offset)
{
+ return swp_entry(0, 0);
}
static inline bool is_device_private_entry(swp_entry_t entry)
@@ -136,35 +136,32 @@ static inline bool is_device_private_entry(swp_entry_t
entry)
return false;
}
-static inline bool is_write_device_private_entry(swp_entry_t entry)
+static inline bool is_writable_device_private_entry(swp_entry_t entry)
{
return false;
}
#endif /* CONFIG_DEVICE_PRIVATE */
#ifdef CONFIG_MIGRATION
-static inline swp_entry_t make_migration_entry(struct page *page, int write)
-{
- BUG_ON(!PageLocked(compound_head(page)));
-
- return swp_entry(write ? SWP_MIGRATION_WRITE : SWP_MIGRATION_READ,
- page_to_pfn(page));
-}
-
static inline int is_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_READ ||
swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline int is_write_migration_entry(swp_entry_t entry)
+static inline int is_writable_migration_entry(swp_entry_t entry)
{
return unlikely(swp_type(entry) == SWP_MIGRATION_WRITE);
}
-static inline void make_migration_entry_read(swp_entry_t *entry)
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
{
- *entry = swp_entry(SWP_MIGRATION_READ, swp_offset(*entry));
+ return swp_entry(SWP_MIGRATION_READ, offset);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(SWP_MIGRATION_WRITE, offset);
}
extern void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
@@ -174,21 +171,28 @@ extern void migration_entry_wait(struct mm_struct *mm,
pmd_t *pmd,
extern void migration_entry_wait_huge(struct vm_area_struct *vma,
struct mm_struct *mm, pte_t *pte);
#else
+static inline swp_entry_t make_readable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
+
+static inline swp_entry_t make_writable_migration_entry(pgoff_t offset)
+{
+ return swp_entry(0, 0);
+}
-#define make_migration_entry(page, write) swp_entry(0, 0)
static inline int is_migration_entry(swp_entry_t swp)
{
return 0;
}
-static inline void make_migration_entry_read(swp_entry_t *entryp) { }
static inline void __migration_entry_wait(struct mm_struct *mm,
[PATCH v5 1/8] mm: Remove special swap entry functions
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()
* Reinstated check that migration entries point to locked pages
* Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
builds
---
arch/s390/mm/pgtable.c | 2 +-
fs/proc/task_mmu.c | 23 +-
include/linux/swap.h| 4 +--
include/linux/swapops.h | 69 ++---
mm/hmm.c| 5 ++-
mm/huge_memory.c| 4 +--
mm/memcontrol.c | 2 +-
mm/memory.c | 10 +++---
mm/migrate.c| 6 ++--
mm/page_vma_mapped.c| 6 ++--
10 files changed, 50 insertions(+), 81 deletions(-)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 18205f851c24..aae001096c46 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -691,7 +691,7 @@ static void ptep_zap_swap_entry(struct mm_struct *mm,
swp_entry_t entry)
if (!non_swap_entry(entry))
dec_mm_counter(mm, MM_SWAPENTS);
else if (is_migration_entry(entry)) {
- struct page *page = migration_entry_to_page(entry);
+ struct page *page = pfn_swap_entry_to_page(entry));
dec_mm_counter(mm, mm_counter(page));
}
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 3cec6fbef725..08ee59d945c0 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -514,10 +514,8 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
} else {
mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
}
- } else if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ } else if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
} else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
&& pte_none(*pte))) {
page = xa_load(>vm_file->f_mapping->i_pages,
@@ -549,7 +547,7 @@ static void smaps_pmd_entry(pmd_t *pmd, unsigned long addr,
swp_entry_t entry = pmd_to_swp_entry(*pmd);
if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
if (IS_ERR_OR_NULL(page))
return;
@@ -691,10 +689,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long
hmask,
} else if (is_swap_pte(*pte)) {
swp_entry_t swpent = pte_to_swp_entry(*pte);
- if (is_migration_entry(swpent))
- page = migration_entry_to_page(swpent);
- else if (is_device_private_entry(swpent))
- page = device_private_entry_to_page(swpent);
+ if (is_pfn_swap_entry(swpent))
+ page = pfn_swap_entry_to_page(swpent);
}
if (page) {
int mapcount = page_mapcount(page);
@@ -1383,11 +1379,8 @@ static pagemap_entry_t pte_to_pagemap_entry(struct
pagemapread *pm,
frame = swp_type(entry) |
(swp_offset(entry) << MAX_SWAPFILES_SHIFT);
flags |= PM_SWAP;
- if (is_migration_entry(entry))
- page = migration_entry_to_page(entry);
-
- if (is_device_private_entry(entry))
- page = device_private_entry_to_page(entry);
+ if (is_pfn_swap_entry(entry))
+ page = pfn_swap_entry_to_page(entry);
}
if (page && !PageAnon(page))
@@ -1444,7 +1437,7 @@ static int pagemap_pmd_range(pmd_t *pmdp, unsigned long
addr, unsigned long end,
if (pmd_swp_soft_dirty(pmd))
flags |= PM_SOFT_DIRTY;
VM_BUG_ON(!is_pmd_migration_entry(pmd));
- page = migration_entry_to_page(entry);
+ page = pfn_swap_entry_to_page(entry);
}
#endif
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 4cc6ec3bf0ab..516104b9334b 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -523,8 +523,8 @@ static inline void show_swap_cache_info(void)
{
}
-#define free_swap_and_cache(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
-#define swapcache_prepare(e) ({(is_migration_entry(e) ||
is_device_private_entry(e));})
+/* used to sanity check ptes in zap_pte_range when CONFIG_SWAP=0 */
+#define free_swap_and_cache(e)
[PATCH v5 0/8] Add support for SVM atomics in Nouveau
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 extra check unnecessary. The driver can instead filter notifier updates called as part of make_device_exclusive_range(). Exclusive device access is implemented by adding a new swap entry type (SWAP_DEVICE_EXCLUSIVE) which is similar to a migration entry. The main difference is that on fault the original entry is immediately restored by the fault handler instead of waiting. Restoring the entry triggers calls to MMU notifers which allows a device driver to revoke the atomic access permission from the GPU prior to the CPU finalising the entry. Patches 1 & 2 refactor existing migration and device private entry functions. Patches 3 & 4 rework try_to_unmap_one() by splitting out unrelated functionality into separate functions - try_to_migrate_one() and try_to_munlock_one(). These should not change any functionality, but any help testing would be much appreciated as I have not been able to test every usage of try_to_unmap_one(). Patch 5 contains the bulk of the implementation for device exclusive memory. Patch 6 contains some additions to the HMM selftests to ensure everything works as expected. Patch 7 is a cleanup for the Nouveau SVM implementation. Patch 8 contains the implementation of atomic access for the Nouveau driver. This has been tested using the latest upstream Mesa userspace with a simple OpenCL test program which checks the results of atomic GPU operations on a SVM buffer whilst also writing to the same buffer from the CPU. v5: * Rebased on v5.12-rc2. * Renamed range->migrate_pgmap_owner to range->owner. * Added MMU_NOTIFY_EXCLUSIVE to allow passing of a driver cookie which allows notifiers called as a result of make_device_exclusive_range() to be ignored. * Added a check to try_to_protect_one() to detect if the pages originally returned from get_user_pages() have been unmapped or not. * Removed check_device_exclusive_range() as it is no longer required with the other changes. * Documentation and comments. v4: * Added pfn_swap_entry_to_page() and reinstated the migration entry page lock check. * Added check_device_exclusive_range() for use during mmu range notifier read side critical section when programming device page tables. v3: * Refactored some existing functionality. * Switched to using get_user_pages_remote() instead of open-coding it. * Moved code out of hmm. v2: * Changed implementation to use special swap entries instead of device private pages. Alistair Popple (8): mm: Remove special swap entry functions mm/swapops: Rework swap entry manipulation code mm/rmap: Split try_to_munlock from try_to_unmap mm/rmap: Split migration into its own function mm: Device exclusive memory access mm: Selftests for exclusive device memory nouveau/svm: Refactor nouveau_range_fault nouveau/svm: Implement atomic SVM access Documentation/vm/hmm.rst | 19 +- arch/s390/mm/pgtable.c| 2 +- drivers/gpu/drm/nouveau/include/nvif/if000c.h | 1 + drivers/gpu/drm/nouveau/nouveau_svm.c | 130 +++- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 6 + fs/proc/task_mmu.c| 23 +- include/linux/mmu_notifier.h | 25 +- include/linux/rmap.h | 9 +- include/linux/swap.h | 8 +- include/linux/swapops.h | 123 ++-- lib/test_hmm.c| 126 +++- lib/test_hmm_uapi.h | 2 + mm/debug_vm_pgtable.c | 12 +- mm/hmm.c | 12 +- mm/huge_memory.c | 45 +- mm/hugetlb.c | 10 +- mm/memcontrol.c | 2 +- mm/memory.c | 127 +++- mm/migrate.c | 41 +- mm/mprotect.c | 18 +- mm/page_vma_mapped.c | 15 +- mm/rmap.c | 597 +++--- tools/testing/selftests/vm/hmm-tests.c| 219 +++ 24 files changed, 1313 insertions(+), 260 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Fix off-by-1 when with readback conn due to rounding
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 subject) > rather than to an actual output device (HDMI etc.), rounding was ses s/ses/set/ > to round-down. As the DPU uses a higher internal number of bits when "round-down" isn't really accurate - the rounding mode "rounds" based on the most-significant discarded bit - so can round-up too. Come to think of it, I can't explain 0xff becoming 0xfe, but still, truncation is likely fine. > generating a color value, this round-down back to 8bit ended up with > everything being off-by one. e.g. #ff became #fefefe. This sets > rounding to "round" so things end up correct by turning on the round > flag (LW_TRC). LW_TRC is the truncation flag. 0: Round, 1: Truncate > > Signed-off-by: Carsten Haitzler > --- > drivers/gpu/drm/arm/display/komeda/d71/d71_component.c | 6 +- > drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h | 1 + > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > index 8a02ade369db..d551e79fa0f1 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c > @@ -468,7 +468,11 @@ static void d71_wb_layer_update(struct komeda_component > *c, > struct komeda_layer_state *st = to_layer_st(state); > struct drm_connector_state *conn_st = state->wb_conn->state; > struct komeda_fb *kfb = to_kfb(conn_st->writeback_job->fb); > - u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN; > + /* LW_TRC sets rounding to round not truncate which is needed for > + * the output of writeback to match the input in the most common > + * use cases like RGB888 -> RGB888, so set this bit by default */ /* * Comment style should be like this */ Same as above though - your description is inverted. By setting the LW_TRC bit, you're forcing the hardware to truncate instead of round. > + u32 ctrl = L_EN | LW_OFM | LW_TRC; > + u32 mask = L_EN | LW_OFM | LW_TBU_EN | LW_TRC; Really nitpicking, but I think it'd be good to keep these in the same order as the bits in the register: L_EN | LW_TRC | LW_OFM | LW_TBU_EN Cheers, -Brian > u32 __iomem *reg = c->reg; > > d71_layer_update_fb(c, kfb, st->addr); > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > index e80172a0b320..a8036689d721 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h > @@ -321,6 +321,7 @@ > #define LAYER_WR_FORMAT 0x0D8 > > /* Layer_WR control bits */ > +#define LW_TRC BIT(1) > #define LW_OFM BIT(4) > #define LW_LALPHA(x) (((x) & 0xFF) << 8) > #define LW_A_WCACHE(x) (((x) & 0xF) << 28) > -- > 2.30.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] scsi: csiostor: Assign boolean values to a bool variable
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 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/csiostor/csio_scsi.c b/drivers/scsi/csiostor/csio_scsi.c index 55e74da..56b9ad0 100644 --- a/drivers/scsi/csiostor/csio_scsi.c +++ b/drivers/scsi/csiostor/csio_scsi.c @@ -147,9 +147,9 @@ static int csio_do_abrt_cls(struct csio_hw *, case FW_ERR_RDEV_LOST: case FW_ERR_RDEV_LOGO: case FW_ERR_RDEV_IMPL_LOGO: - return 1; + return true; } - return 0; + return false; } /* -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/uapi: document kernel capabilities
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_PRIME_HANDLE_TO_FD
> - Explicitly reference CLOCK_REALTIME and CLOCK_MONOTONIC
> - Make it clear DRM_CAP_CRTC_IN_VBLANK_EVENT applies to both DRM_EVENT_VBLANK
> and DRM_EVENT_FLIP_COMPLETE
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> ---
> include/uapi/drm/drm.h | 112 +++--
> 1 file changed, 108 insertions(+), 4 deletions(-)
Hi,
this all looks good to me for what I know, so:
Reviewed-by: Pekka Paalanen
Thanks,
pq
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 0827037c5484..79e9c9d5e7a9 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -625,30 +625,134 @@ struct drm_gem_open {
> __u64 size;
> };
>
> +/**
> + * DRM_CAP_DUMB_BUFFER
> + *
> + * If set to 1, the driver supports creating dumb buffers via the
> + * _IOCTL_MODE_CREATE_DUMB ioctl.
> + */
> #define DRM_CAP_DUMB_BUFFER 0x1
> +/**
> + * DRM_CAP_VBLANK_HIGH_CRTC
> + *
> + * If set to 1, the kernel supports specifying a CRTC index in the high bits
> of
> + * _wait_vblank_request.type.
> + */
> #define DRM_CAP_VBLANK_HIGH_CRTC 0x2
> +/**
> + * DRM_CAP_DUMB_PREFERRED_DEPTH
> + *
> + * The preferred bit depth for dumb buffers.
> + *
> + * The bit depth is the number of bits used to indicate the color of a single
> + * pixel excluding any padding. This is different from the number of bits per
> + * pixel. For instance, XRGB has a bit depth of 24 but has 32 bits per
> + * pixel.
> + */
> #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3
> +/**
> + * DRM_CAP_DUMB_PREFER_SHADOW
> + *
> + * If set to 1, the driver prefers userspace to render to a shadow buffer
> + * instead of directly rendering to a dumb buffer. For best speed, userspace
> + * should do streaming ordered memory copies into the dumb buffer and never
> + * read from it.
> + */
> #define DRM_CAP_DUMB_PREFER_SHADOW 0x4
> +/**
> + * DRM_CAP_PRIME
> + *
> + * Bitfield of supported PRIME sharing capabilities. See
> _PRIME_CAP_IMPORT
> + * and _PRIME_CAP_EXPORT.
> + *
> + * PRIME buffers are exposed as dma-buf file descriptors. See
> + * Documentation/gpu/drm-mm.rst, section "PRIME Buffer Sharing".
> + */
> #define DRM_CAP_PRIME0x5
> +/**
> + * DRM_PRIME_CAP_IMPORT
> + *
> + * If this bit is set in _CAP_PRIME, the driver supports importing PRIME
> + * buffers via the _IOCTL_PRIME_FD_TO_HANDLE ioctl.
> + */
> #define DRM_PRIME_CAP_IMPORT0x1
> +/**
> + * DRM_PRIME_CAP_EXPORT
> + *
> + * If this bit is set in _CAP_PRIME, the driver supports exporting PRIME
> + * buffers via the _IOCTL_PRIME_HANDLE_TO_FD ioctl.
> + */
> #define DRM_PRIME_CAP_EXPORT0x2
> +/**
> + * DRM_CAP_TIMESTAMP_MONOTONIC
> + *
> + * If set to 0, the kernel will report timestamps with ``CLOCK_REALTIME`` in
> + * struct drm_event_vblank. If set to 1, the kernel will report timestamps
> with
> + * ``CLOCK_MONOTONIC``. See ``clock_gettime(2)`` for the definition of these
> + * clocks.
> + */
> #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> +/**
> + * DRM_CAP_ASYNC_PAGE_FLIP
> + *
> + * If set to 1, the driver supports _MODE_PAGE_FLIP_ASYNC.
> + */
> #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
> -/*
> - * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid
> widthxheight
> - * combination for the hardware cursor. The intention is that a hardware
> - * agnostic userspace can query a cursor plane size to use.
> +/**
> + * DRM_CAP_CURSOR_WIDTH
> + *
> + * The ``CURSOR_WIDTH`` and ``CURSOR_HEIGHT`` capabilities return a valid
> + * width x height combination for the hardware cursor. The intention is that
> a
> + * hardware agnostic userspace can query a cursor plane size to use.
> *
> * Note that the cross-driver contract is to merely return a valid size;
> * drivers are free to attach another meaning on top, eg. i915 returns the
> * maximum plane size.
> */
> #define DRM_CAP_CURSOR_WIDTH 0x8
> +/**
> + * DRM_CAP_CURSOR_HEIGHT
> + *
> + * See _CAP_CURSOR_WIDTH.
> + */
> #define DRM_CAP_CURSOR_HEIGHT0x9
> +/**
> + * DRM_CAP_ADDFB2_MODIFIERS
> + *
> + * If set to 1, the driver supports supplying modifiers in the
> + * _IOCTL_MODE_ADDFB2 ioctl.
> + */
> #define DRM_CAP_ADDFB2_MODIFIERS 0x10
> +/**
> + * DRM_CAP_PAGE_FLIP_TARGET
> + *
> + * If set to 1, the driver supports the _MODE_PAGE_FLIP_TARGET_ABSOLUTE
> and
> + * _MODE_PAGE_FLIP_TARGET_RELATIVE flags in
> + * _mode_crtc_page_flip_target.flags for the _IOCTL_MODE_PAGE_FLIP
> + * ioctl.
> + */
> #define DRM_CAP_PAGE_FLIP_TARGET 0x11
> +/**
> + * DRM_CAP_CRTC_IN_VBLANK_EVENT
> + *
> + * If set to 1, the kernel supports reporting the
Re: [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
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 12:41:32 -0800
> > > > Manasi Navare wrote:
> > > >
> > > > > In case of a modeset where a mode gets split across mutiple CRTCs
> > > > > in the driver specific implementation (bigjoiner in i915) we wrongly
> > > > > count
> > > > > the affected CRTCs based on the drm_crtc_mask and indicate the stolen
> > > > > CRTC as
> > > > > an affected CRTC in atomic_check_only().
> > > > > This triggers a warning since affected CRTCs doent match requested
> > > > > CRTC.
> > > > >
> > > > > To fix this in such bigjoiner configurations, we should only
> > > > > increment affected crtcs if that CRTC is enabled in UAPI not
> > > > > if it is just used internally in the driver to split the mode.
> > > >
> > > > Hi,
> > > >
> > > > I think that makes sense to me. Stealing CRTCs that are not currently
> > > > used by the userspace (display server) should be ok, as long as that
> > > > is completely invisible to userspace: meaning that it does not cause
> > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic
> > > > completion events.
> > >
> > > Yes since we are only doing atomic_check_only() here, the stolen
> >
> > But the real not-test-only commit will follow if this test-only commit
> > succeeds, and keeping the guarantees for the real commit are important.
>
> Hmm well after the actual real commit, since the second crtc is stolen
> even though it is not being used for the display output, it is
> used for joiner so the uapi.enable will be true after the real commit.
>
> so actually the assertion would fail in this case.
>
> @Ville @Danvet any suggestions here in that case?
Hi,
that is not what I was talking about, but sounds like you found a
different problem. It seems like the problem you are talking about
would be guaranteed to be hit if bigjoiner was used. Have you not
tested this?
However, I was talking about the real commit itself, not what happens
on commits after it, see below.
> > > crtc is completely invisible to the userspace and hence that is
> > > indicated by uapi.enable which is not true for this stolen
> > > crtc. However if allow modeset flag set, then it will do a full
> > > modeset and indicate the uapi.enable for this stolen crtc as well
> > > since that cannot be used for other modeset requested by userspace.
> > >
> > > >
> > > > Can that also be asserted somehow, or does this already do that?
> > >
> > > Not clear what you want the assertion for? Could you elaborate
> >
> > As assertion that when the real atomic commit happens and then
> > completion events are fired, they match exactly the affected crtcs mask.
This is my concern and a question, although like I say below, only
tangential to this patch.
However, as this patch aims to allow bigjoiner usage, naturally the
question will arise whether the completion events then match what
userspace expects or not. Userspace does not expect completion events
referring to the stolen CRTCs.
> > I understand this may be off-topic for this particular patch, but since
> > we are discussing the topic, such checks would be really nice. I'm
> > curious if such checks already exist.
Thanks,
pq
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic.c | 6 --
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 5b4547e0f775..d7acd6bbd97e 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1358,8 +1358,10 @@ int drm_atomic_check_only(struct
> > > > > drm_atomic_state *state)
> > > > > }
> > > > > }
> > > > >
> > > > > - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > > > > - affected_crtc |= drm_crtc_mask(crtc);
> > > > > + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> > > > > + if (new_crtc_state->enable)
> > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > + }
> > > > >
> > > > > /*
> > > > >* For commits that allow modesets drivers can add other CRTCs
> > > > > to the
pgpIIGcwLTd5j.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m
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: > > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_bind_process_to_device': > kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_unbind_process': > kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_suspend': > kfd_iommu.c:(.text+0x966): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to > `amd_iommu_free_device' > x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function > `kfd_iommu_resume': > kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' > x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to > `amd_iommu_bind_pasid' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to > `amd_iommu_set_invalidate_ctx_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to > `amd_iommu_set_invalid_ppr_cb' > x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to > `amd_iommu_free_device' > > Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols > are reachable by the amdkfd driver. Output a warning if they are not, > because that may not be what the user was expecting. This would fix the compile-time failure, but it still fails my CI because you introduce a compile-time warning. Can you change it into a runtime warning instead? Neither type of warning is likely to actually reach the person trying to debug the problem, so you still end up with machines that don't do what they should, but I can live with the runtime warning as long as the build doesn't break. 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 interfaces. I realize this is more work, but I wonder if you've tried that, and why it didn't work out. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] locking/rwsem: Add down_write_interruptible
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. > > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Will Deacon > Cc: linux-ker...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org No SoB! Assuning you actually wrote and and simply forgot to add it, the patch does look ok, so: Acked-by: Peter Zijlstra (Intel) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: meson_drv add shutdown function
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] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown domain 0:VPU...
> ...STUCK...
>
> Solution: add shutdown function to meson_drm driver
> // debug kernel log
> [5.231896] reboot: kernel restart prepare CMD:(null)
> [5.246135] [drm:meson_drv_shutdown]
> ...
> [5.259271] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown begin
> [5.274688] meson_ee_pwrc c883c000.system-controller:power-controller:
> shutdown domain 0:VPU...
> [5.338331] reboot: Restarting system
> [5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null)
> bl31 reboot reason: 0xd
> bl31 reboot reason: 0x0
> system cmd 1.
> ...REBOOT...
>
> Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots
> and Odroid boards, WeTek Play2 (GXBB)
>
> Tested-by: Christian Hewitt
> Signed-off-by: Artem Lapkin
>
> ---
> drivers/gpu/drm/meson/meson_drv.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 42c5d3246..693bb1293 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -482,6 +482,16 @@ static int meson_probe_remote(struct platform_device
> *pdev,
> return count;
> }
>
> +static void meson_drv_shutdown(struct platform_device *pdev)
> +{
> + struct meson_drm *priv = dev_get_drvdata(>dev);
> + struct drm_device *drm = priv->drm;
> +
> + DRM_DEBUG_DRIVER("\n");
> + drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> +}
> +
> static int meson_drv_probe(struct platform_device *pdev)
> {
> struct component_match *match = NULL;
> @@ -553,6 +563,7 @@ static const struct dev_pm_ops meson_drv_pm_ops = {
>
> static struct platform_driver meson_drm_platform_driver = {
> .probe = meson_drv_probe,
> + .shutdown = meson_drv_shutdown,
> .driver = {
> .name = "meson-drm",
> .of_match_table = dt_match,
>
Applied to drm-misc-fixes,
Thanks !
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Remove unnecessary conversion to bool
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(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c index 8dc3d1f..662ba74 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp_cm.c @@ -893,7 +893,7 @@ bool dpp20_program_shaper( else next_mode = LUT_RAM_A; - dpp20_configure_shaper_lut(dpp_base, next_mode == LUT_RAM_A ? true:false); + dpp20_configure_shaper_lut(dpp_base, next_mode == LUT_RAM_A); if (next_mode == LUT_RAM_A) dpp20_program_shaper_luta_settings(dpp_base, params); -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 1/2] dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP
>> >>> 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 supports both HDCP 2.2 and 1.4. So, this is a way >> >> to select the version of HDCP, system wish to support. >> > >> > Then I'm not sure this qualifies as a DT property, which should describe >> > the system, not configure it. A way for userspace to configure this >> > would be better. >> >> Since this is for source device, I am not sure how useful it is to allow >> user to change HDCP version supported. I think doing it in DTS >> gives more control over HDCP to system designer/integrator. > >But how would they do so ? What would be the rationale for selecting a >particular version in DT ? > >I'm not thinking about giving control of this parameter to the end-user, >but in the context of an embedded system, it may be useful to select >which HDCP versions to offer based on different constraints at runtime. >This really seems like a system configuration parameter to me, not a >system description. Ok, we can remove this parameter from DTS and let driver attempt both HDCP 2.2 and HDCP 1.4 in the same sequence so that HDCP version is selected based on sink capabilities. But then user space application will not have information about the HDCP version with which content will be protected. I suppose most UHD 4k content would need HDCP 2.2. So, forcing HDCP version in DTS was the easiest way. Regards, Parshuram Thombare ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
