Re: [PATCH v2 1/1] drm/panfrost: Add support for devcoredump
Hi "Adrián,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on linus/master v5.19-rc2 next-20220617]
[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/intel-lab-lkp/linux/commits/Adri-n-Larumbe/devcoredump-support-for-Panfrost-GPU-driver/20220621-103431
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arc-allyesconfig
(https://download.01.org/0day-ci/archive/20220621/202206211320.gpk3mfi3-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 11.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/intel-lab-lkp/linux/commit/297bd4948ab1f4eeb78389d57adc1edc819cb6f2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Adri-n-Larumbe/devcoredump-support-for-Panfrost-GPU-driver/20220621-103431
git checkout 297bd4948ab1f4eeb78389d57adc1edc819cb6f2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/panfrost/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/panfrost/panfrost_dump.c: In function 'panfrost_core_dump':
drivers/gpu/drm/panfrost/panfrost_dump.c:115:20: error: 'struct
panfrost_job' has no member named 'file_priv'
115 | as_nr = job->file_priv->mmu->as;
|^~
In file included from include/linux/byteorder/big_endian.h:5,
from arch/arc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/arc/include/asm/bitops.h:192,
from include/linux/bitops.h:33,
from include/linux/log2.h:12,
from include/asm-generic/div64.h:55,
from ./arch/arc/include/generated/asm/div64.h:1,
from include/linux/math.h:6,
from include/linux/math64.h:6,
from include/linux/time64.h:5,
from include/linux/restart_block.h:10,
from include/linux/thread_info.h:14,
from include/asm-generic/preempt.h:5,
from ./arch/arc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rculist.h:11,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/panfrost/panfrost_dump.c:5:
>> include/uapi/linux/byteorder/big_endian.h:32:26: warning: conversion from
>> 'long long unsigned int' to '__le32' {aka 'unsigned int'} changes value from
>> '72057594037927936' to '0' [-Woverflow]
32 | #define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
| ^
include/linux/byteorder/generic.h:86:21: note: in expansion of macro
'__cpu_to_le64'
86 | #define cpu_to_le64 __cpu_to_le64
| ^
drivers/gpu/drm/panfrost/panfrost_dump.c:225:41: note: in expansion of macro
'cpu_to_le64'
225 | iter.hdr->bomap.valid = cpu_to_le64(1);
| ^~~
vim +32 include/uapi/linux/byteorder/big_endian.h
5921e6f8809b16 David Howells 2012-10-13 15
5921e6f8809b16 David Howells 2012-10-13 16 #define __constant_htonl(x)
((__force __be32)(__u32)(x))
5921e6f8809b16 David Howells 2012-10-13 17 #define __constant_ntohl(x)
((__force __u32)(__be32)(x))
5921e6f8809b16 David Howells 2012-10-13 18 #define __constant_htons(x)
((__force __be16)(__u16)(x))
5921e6f8809b16 David Howells 2012-10-13 19 #define __constant_ntohs(x)
((__force __u16)(__be16)(x))
5921e6f8809b16 David Howells 2012-10-13 20 #define __constant_cpu_to_le64(x)
((__force __le64)___constant_swab64((x)))
5921e6f8809b16 David Howells 2012-10-13 21 #define __constant_le64_to_cpu(x)
___constant_swab64((__force __u64)(__le64)(x))
5921e6f8809b16 David Howells 2012-10-13 22 #define __constant_cpu_to_le32(x)
((__force __le32)___constant_swab32((x)))
5921e6f8809b16 David Howells 2012-10-13 23 #define __constant_le32_to_cpu(x)
___constant_swab32((__force __u32)(__le32)(x))
5921e6f8809b16 David Howells
Re: [PATCH v13 0/3] eDP/DP Phy vdda realted function
On 20-06-22, 13:43, Kuogee Hsieh wrote: > > On 6/20/2022 1:07 PM, Kuogee Hsieh wrote: > > > > On 6/16/2022 5:02 PM, Vinod Koul wrote: > > > On 25-05-22, 14:02, Kuogee Hsieh wrote: > > > > 1) add regulator_set_load() to eDP phy > > > > 2) add regulator_set_load() to DP phy > > > > 3) remove vdda related function out of eDP/DP controller > > > > > > > > Kuogee Hsieh (3): > > > > phy: qcom-edp: add regulator_set_load to edp phy > > > > phy: qcom-qmp: add regulator_set_load to dp phy > > > > drm/msm/dp: delete vdda regulator related functions from eDP/DP > > > > controller > > > > > > > > drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- > > > > drivers/gpu/drm/msm/dp/dp_parser.h | 8 > > > > drivers/gpu/drm/msm/dp/dp_power.c | 95 > > > > + > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 12 + > > > > drivers/phy/qualcomm/phy-qcom-qmp.c | 40 > > > Please rebase this to phy-next and apply to specific qmp phy driver... > > I will rebase to ==> > > https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git > > Hi Vinod, > > Would you please specify exactly procedures i have to do as to rebase this > patch series to phy=next tree. Yes pls rebase to above tree and next branch -- ~Vinod
Re: [PATCH] drm: Make drm_buddy a part of drm module
Hi Cai, I love your patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on linus/master v5.19-rc2 next-20220617] [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/intel-lab-lkp/linux/commits/Cai-Huoqing/drm-Make-drm_buddy-a-part-of-drm-module/20220621-095417 base: git://anongit.freedesktop.org/drm/drm drm-next config: microblaze-buildonly-randconfig-r003-20220620 (https://download.01.org/0day-ci/archive/20220621/202206211156.fjstejjc-...@intel.com/config) compiler: microblaze-linux-gcc (GCC) 11.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/intel-lab-lkp/linux/commit/517d5f44c861a5173eaa9a06efebe2ce2a6601a1 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Cai-Huoqing/drm-Make-drm_buddy-a-part-of-drm-module/20220621-095417 git checkout 517d5f44c861a5173eaa9a06efebe2ce2a6601a1 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 O=build_dir ARCH=microblaze SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable Reported-by: kernel test robot All errors (new ones prefixed by >>): microblaze-linux-ld: drivers/gpu/drm/drm_buddy.o: in function `drm_buddy_block_print': drivers/gpu/drm/drm_buddy.c:731: undefined reference to `drm_printf' microblaze-linux-ld: drivers/gpu/drm/drm_buddy.o: in function `drm_buddy_print': drivers/gpu/drm/drm_buddy.c:745: undefined reference to `drm_printf' >> microblaze-linux-ld: drivers/gpu/drm/drm_buddy.c:757: undefined reference to >> `drm_printf' microblaze-linux-ld: drivers/gpu/drm/drm_buddy.c:763: undefined reference to `drm_printf' microblaze-linux-ld: drivers/gpu/drm/drm_buddy.c:765: undefined reference to `drm_printf' microblaze-linux-ld: drivers/gpu/drm/drm_buddy.o:drivers/gpu/drm/drm_buddy.c:761: more undefined references to `drm_printf' follow -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [PATCH] drm: Make drm_buddy a part of drm module
Hi Cai,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on linus/master v5.19-rc2 next-20220617]
[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/intel-lab-lkp/linux/commits/Cai-Huoqing/drm-Make-drm_buddy-a-part-of-drm-module/20220621-095417
base: git://anongit.freedesktop.org/drm/drm drm-next
config: x86_64-rhel-8.3-kunit
(https://download.01.org/0day-ci/archive/20220621/202206211209.5h0eh2ff-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-3) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/517d5f44c861a5173eaa9a06efebe2ce2a6601a1
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Cai-Huoqing/drm-Make-drm_buddy-a-part-of-drm-module/20220621-095417
git checkout 517d5f44c861a5173eaa9a06efebe2ce2a6601a1
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/drm_buddy.o: in function `drm_buddy_print':
>> drivers/gpu/drm/drm_buddy.c:745: undefined reference to `drm_printf'
>> ld: drivers/gpu/drm/drm_buddy.c:757: undefined reference to `drm_printf'
ld: drivers/gpu/drm/drm_buddy.c:763: undefined reference to `drm_printf'
ld: drivers/gpu/drm/drm_buddy.c:765: undefined reference to `drm_printf'
ld: drivers/gpu/drm/drm_buddy.c:761: undefined reference to `drm_printf'
ld: drivers/gpu/drm/drm_buddy.o:drivers/gpu/drm/drm_buddy.c:757: more
undefined references to `drm_printf' follow
vim +745 drivers/gpu/drm/drm_buddy.c
6387a3c4b0c45a Arunpravin 2022-01-18 734
6387a3c4b0c45a Arunpravin 2022-01-18 735 /**
6387a3c4b0c45a Arunpravin 2022-01-18 736 * drm_buddy_print - print allocator
state
6387a3c4b0c45a Arunpravin 2022-01-18 737 *
6387a3c4b0c45a Arunpravin 2022-01-18 738 * @mm: DRM buddy manager
6387a3c4b0c45a Arunpravin 2022-01-18 739 * @p: DRM printer to use
6387a3c4b0c45a Arunpravin 2022-01-18 740 */
6387a3c4b0c45a Arunpravin 2022-01-18 741 void drm_buddy_print(struct
drm_buddy *mm, struct drm_printer *p)
6387a3c4b0c45a Arunpravin 2022-01-18 742 {
6387a3c4b0c45a Arunpravin 2022-01-18 743 int order;
6387a3c4b0c45a Arunpravin 2022-01-18 744
6387a3c4b0c45a Arunpravin 2022-01-18 @745 drm_printf(p, "chunk_size:
%lluKiB, total: %lluMiB, free: %lluMiB\n",
6387a3c4b0c45a Arunpravin 2022-01-18 746 mm->chunk_size >>
10, mm->size >> 20, mm->avail >> 20);
6387a3c4b0c45a Arunpravin 2022-01-18 747
6387a3c4b0c45a Arunpravin 2022-01-18 748 for (order = mm->max_order;
order >= 0; order--) {
6387a3c4b0c45a Arunpravin 2022-01-18 749 struct drm_buddy_block
*block;
6387a3c4b0c45a Arunpravin 2022-01-18 750 u64 count = 0, free;
6387a3c4b0c45a Arunpravin 2022-01-18 751
6387a3c4b0c45a Arunpravin 2022-01-18 752
list_for_each_entry(block, >free_list[order], link) {
6387a3c4b0c45a Arunpravin 2022-01-18 753
BUG_ON(!drm_buddy_block_is_free(block));
6387a3c4b0c45a Arunpravin 2022-01-18 754 count++;
6387a3c4b0c45a Arunpravin 2022-01-18 755 }
6387a3c4b0c45a Arunpravin 2022-01-18 756
6387a3c4b0c45a Arunpravin 2022-01-18 @757 drm_printf(p, "order-%d
", order);
6387a3c4b0c45a Arunpravin 2022-01-18 758
6387a3c4b0c45a Arunpravin 2022-01-18 759 free = count *
(mm->chunk_size << order);
6387a3c4b0c45a Arunpravin 2022-01-18 760 if (free < SZ_1M)
6387a3c4b0c45a Arunpravin 2022-01-18 761 drm_printf(p,
"free: %lluKiB", free >> 10);
6387a3c4b0c45a Arunpravin 2022-01-18 762 else
6387a3c4b0c45a Arunpravin 2022-01-18 763 drm_printf(p,
"free: %lluMiB", free >> 20);
6387a3c4b0c45a Arunpravin 2022-01-18 764
6387a3c4b0c45a Arunpravin 2022-01-18 765 drm_printf(p, ", pages:
%llu\n", count);
6387a3c4b0c45a Arunpravin 2022-01-18 766 }
6387a3c4b0c45a Arunpravin 2022-01-18 767 }
6387a3c4b0c45a Arunpravin 2022-01-18 768 EXPORT_SYMBOL(drm_buddy_print);
6387a3c4b0c45a Arunpravin 2022-01-18 769
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [PATCH v2 1/1] drm/panfrost: Add support for devcoredump
Hi "Adrián,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on linus/master v5.19-rc2 next-20220617]
[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/intel-lab-lkp/linux/commits/Adri-n-Larumbe/devcoredump-support-for-Panfrost-GPU-driver/20220621-103431
base: git://anongit.freedesktop.org/drm/drm drm-next
config: alpha-buildonly-randconfig-r003-20220619
(https://download.01.org/0day-ci/archive/20220621/20220624.pjcd2pjh-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 11.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/intel-lab-lkp/linux/commit/297bd4948ab1f4eeb78389d57adc1edc819cb6f2
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Adri-n-Larumbe/devcoredump-support-for-Panfrost-GPU-driver/20220621-103431
git checkout 297bd4948ab1f4eeb78389d57adc1edc819cb6f2
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=alpha SHELL=/bin/bash drivers/gpu/drm/panfrost/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/panfrost/panfrost_dump.c: In function 'panfrost_core_dump':
>> drivers/gpu/drm/panfrost/panfrost_dump.c:115:20: error: 'struct
>> panfrost_job' has no member named 'file_priv'
115 | as_nr = job->file_priv->mmu->as;
|^~
vim +115 drivers/gpu/drm/panfrost/panfrost_dump.c
102
103 void panfrost_core_dump(struct panfrost_job *job)
104 {
105 struct panfrost_device *pfdev = job->pfdev;
106 struct panfrost_dump_iterator iter;
107 struct drm_gem_object *dbo;
108 unsigned int n_obj, n_bomap_pages;
109 __le64 *bomap, *bomap_start;
110 size_t file_size;
111 u32 as_nr;
112 int slot;
113 int ret, i;
114
> 115 as_nr = job->file_priv->mmu->as;
116 slot = panfrost_job_get_slot(job);
117 slot = slot ? slot : 0;
118
119 /* Only catch the first event, or when manually re-armed */
120 if (!panfrost_dump_core)
121 return;
122 panfrost_dump_core = false;
123
124 /* At least, we dump registers and end marker */
125 n_obj = 2;
126 n_bomap_pages = 0;
127 file_size = ARRAY_SIZE(panfrost_dump_registers) *
128 sizeof(struct panfrost_dump_registers);
129
130 /* Add in the active buffer objects */
131 for (i = 0; i < job->bo_count; i++) {
132 dbo = job->bos[i];
133 file_size += dbo->size;
134 n_bomap_pages += dbo->size >> PAGE_SHIFT;
135 n_obj++;
136 }
137
138 /* If we have any buffer objects, add a bomap object */
139 if (n_bomap_pages) {
140 file_size += n_bomap_pages * sizeof(*bomap);
141 n_obj++;
142 }
143
144 /* Add the size of the headers */
145 file_size += sizeof(*iter.hdr) * n_obj;
146
147 /* Allocate the file in vmalloc memory, it's likely to be big */
148 iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
149 __GFP_NORETRY);
150 if (!iter.start) {
151 dev_warn(pfdev->dev, "failed to allocate devcoredump
file\n");
152 return;
153 }
154
155 /* Point the data member after the headers */
156 iter.hdr = iter.start;
157 iter.data = [n_obj];
158
159 memset(iter.hdr, 0, iter.data - iter.start);
160
161 /*
162 * For now, we write the job identifier in the register dump
header,
163 * so that we can decode the entire dump later with pandecode
164 */
165 iter.hdr->reghdr.jc = cpu_to_le64(job->jc);
166 iter.hdr->reghdr.version = cpu_to_le32(PANFROSTDUMP_VERSION_1);
167 iter.hdr->reghdr.gpu_id = cpu_to_le32(pfdev->features.id);
168 iter.hdr->reghdr.nbos = cpu_to_le64(job->bo_count);
169
170 panfrost_core_dump_registers(, pfdev, as_nr, slot);
171
172 /* Reserve space for the bomap */
173 if (job->bo_count) {
174
Re: [PATCH v2] drm/sun4i: Add DMA mask and segment size
On 6/20/22 1:13 PM, Jernej Skrabec wrote: > Kernel occasionally complains that there is mismatch in segment size > when trying to render HW decoded videos and rendering them directly with > sun4i DRM driver. Following message can be observed on H6 SoC: > > [ 184.298308] [ cut here ] > [ 184.298326] DMA-API: sun4i-drm display-engine: mapping sg segment longer > than device claims to support [len=6144000] [max=65536] > [ 184.298364] WARNING: CPU: 1 PID: 382 at kernel/dma/debug.c:1162 > debug_dma_map_sg+0x2b0/0x350 > [ 184.322997] CPU: 1 PID: 382 Comm: ffmpeg Not tainted 5.19.0-rc1+ #1331 > [ 184.329533] Hardware name: Tanix TX6 (DT) > [ 184.333544] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 184.340512] pc : debug_dma_map_sg+0x2b0/0x350 > [ 184.344882] lr : debug_dma_map_sg+0x2b0/0x350 > [ 184.349250] sp : 89f33a50 > [ 184.352567] x29: 89f33a50 x28: 0001 x27: > 01b86c00 > [ 184.359725] x26: x25: 05d8cc80 x24: > > [ 184.366879] x23: 8939ab18 x22: 0001 x21: > 0001 > [ 184.374031] x20: x19: 018a7410 x18: > > [ 184.381186] x17: x16: x15: > > [ 184.388338] x14: 0001 x13: 89534e86 x12: > 6f70707573206f74 > [ 184.395493] x11: 20736d69616c6320 x10: 000a x9 : > 0001 > [ 184.402647] x8 : 893b6d40 x7 : 89f33850 x6 : > 000c > [ 184.409800] x5 : bf997940 x4 : x3 : > 0027 > [ 184.416953] x2 : x1 : x0 : > 03960e80 > [ 184.424106] Call trace: > [ 184.426556] debug_dma_map_sg+0x2b0/0x350 > [ 184.430580] __dma_map_sg_attrs+0xa0/0x110 > [ 184.434687] dma_map_sgtable+0x28/0x4c > [ 184.438447] vb2_dc_dmabuf_ops_map+0x60/0xcc > [ 184.442729] __map_dma_buf+0x2c/0xd4 > [ 184.446321] dma_buf_map_attachment+0xa0/0x130 > [ 184.450777] drm_gem_prime_import_dev+0x7c/0x18c > [ 184.455410] drm_gem_prime_fd_to_handle+0x1b8/0x214 > [ 184.460300] drm_prime_fd_to_handle_ioctl+0x2c/0x40 > [ 184.465190] drm_ioctl_kernel+0xc4/0x174 > [ 184.469123] drm_ioctl+0x204/0x420 > [ 184.472534] __arm64_sys_ioctl+0xac/0xf0 > [ 184.476474] invoke_syscall+0x48/0x114 > [ 184.480240] el0_svc_common.constprop.0+0x44/0xec > [ 184.484956] do_el0_svc+0x2c/0xc0 > [ 184.488283] el0_svc+0x2c/0x84 > [ 184.491354] el0t_64_sync_handler+0x11c/0x150 > [ 184.495723] el0t_64_sync+0x18c/0x190 > [ 184.499397] ---[ end trace ]--- > > Fix that by setting DMA mask and segment size. > > Signed-off-by: Jernej Skrabec Reviewed-by: Samuel Holland
Re: [PATCH v2 07/15] Documentation: ABI: testing: mt6370: Add ADC sysfs guideline
Hi Jonathan, Thanks for your reply! Jonathan Cameron 於 2022年6月21日 週二 凌晨2:35寫道： > > On Mon, 20 Jun 2022 14:00:43 +0800 > ChiaEn Wu wrote: > > > Hi Jonathan, > > > > Thanks for your helpful comments, and I have some questions want to > > ask you below. > > > > Jonathan Cameron 於 2022年6月18日 週六 晚上11:39寫道： > > > > > > On Mon, 13 Jun 2022 19:11:38 +0800 > > > ChiaEn Wu wrote: > > > > > > > From: ChiaEn Wu > > > > > > > > Add ABI documentation for mt6370 non-standard ADC sysfs interfaces. > > > > > > > > Signed-off-by: ChiaEn Wu > > > > --- > > > > .../ABI/testing/sysfs-bus-iio-adc-mt6370 | 36 +++ > > > > 1 file changed, 36 insertions(+) > > > > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > > new file mode 100644 > > > > index ..039b3381176a > > > > --- /dev/null > > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > > @@ -0,0 +1,36 @@ > > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw > > > > > > Unfortunately the kernel documentation build scripts do no support > > > duplicating > > > standard ABI for particular devices so as to provide more information. > > > Hence you can't have anything in this file. > > > > > > > I want to confirm with you again, > > because my ABI file duplicates with standard sysfs-bus-iio (voltage, > > current, and temperature channels), > > Should I just remove this ABI file and modify the code of mt6370-adc > > to meet your expectations?? > > yes. OK! I got it! I will refine the code in the next patch! > > > > > > > > > > +KernelVersion: 5.18 > > > > +Contact: chiaen...@richtek.com > > > > +Description: > > > > + Indicated MT6370 VBUS ADC with lower accuracy(+-75mA) > > > Curious though, voltage with a mA accuracy range? > > > > Yes, this description is based on the data sheet. > > Weird :) First, I want to apologize to you because I rechecked the datasheet and asked the hardware engineer, the conclusion is I wrote the wrong unit... The correction is that the accuracy of vbusdiv5 is +-75"mV", not "mA", and another one, vbusdiv2, is +-30mV. I sincerely apologize for this mistake and for any inconvenience... > > > > > > This scale should be presented directly to userspace anyway so no need > > > for this doc. > > > > > > > + higher measure range(1~22V) > > > > + Calculating with scale returns voltage in uV > > > > > > No. All channels return in mV. That's the ABI requirement as > > > in sysfs-bus-iio and we cannot vary if for particular drivers. If we did > > > no generic tooling would work. > > > > Ok, I got it! > > > > > > > > > + > > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw > > > > +KernelVersion: 5.18 > > > > +Contact: chiaen...@richtek.com > > > > +Description: > > > > + Indicated MT6370 VBUS ADC with higher accuracy(+-30mA) > > > > + lower measure range(1~9.76V) > > > > + Calculating with scale offset returns voltage in uV > > > > + > > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage4_raw > > > > +KernelVersion: 5.18 > > > > +Contact: chiaen...@richtek.com > > > > +Description: > > > > + Indicated MT6370 TS_BAT ADC > > > > + Calculating with scale returns voltage in uV > > > > + > > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage7_raw > > > > +KernelVersion: 5.18 > > > > +Contact: chiaen...@richtek.com > > > > +Description: > > > > + Indicated MT6370 CHG_VDDP ADC > > > > + Calculating with scale returns voltage in mV > > > > + > > > > +What:/sys/bus/iio/devices/iio:deviceX/in_temp8_raw > > > > +KernelVersion: 5.18 > > > > +Contact: chiaen...@richtek.com > > > > +Description: > > > > + Indicated MT6370 IC junction temperature > > > > + Calculating with scale and offset returns temperature in > > > > degree > > > > Shall I modify the scale of temperature to milli degrees in > > mt6370-adc.c and remove this item?? > > yes. > > Thanks, > > Jonathan > > > > > > > > > > Best regards, > > ChiaEn Wu > Best regards, ChiaEn Wu
linux-next: build failure after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/xlnx/zynqmp_disp.c: In function 'zynqmp_disp_create_planes': drivers/gpu/drm/xlnx/zynqmp_disp.c:1260:17: error: implicit declaration of function 'drm_plane_create_zpos_immutable_property'; did you mean 'drm_plane_create_scaling_filter_property'? [-Werror=implicit-function-declaration] 1260 | drm_plane_create_zpos_immutable_property(>plane, i); | ^~~~ | drm_plane_create_scaling_filter_property drivers/gpu/drm/xlnx/zynqmp_disp.c:1262:25: error: implicit declaration of function 'drm_plane_create_alpha_property'; did you mean 'drm_plane_create_color_properties'? [-Werror=implicit-function-declaration] 1262 | drm_plane_create_alpha_property(>plane); | ^~~ | drm_plane_create_color_properties cc1: all warnings being treated as errors Presumably caused by one of the commits that dropped includes from drm-ctrc.h. I have used the drm-misc tree from next-20220620 for today. -- Cheers, Stephen Rothwell pgphDF419MeEb.pgp Description: OpenPGP digital signature
[PATCH v2 1/1] drm/panfrost: Add support for devcoredump
In the event of a job timeout, debug dump information will be written into
/sys/class/devcoredump.
Inspired by etnaviv's similar feature.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/Kconfig | 1 +
drivers/gpu/drm/panfrost/Makefile| 3 +-
drivers/gpu/drm/panfrost/panfrost_dump.c | 233 +++
drivers/gpu/drm/panfrost/panfrost_dump.h | 12 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 3 +
include/uapi/drm/panfrost_drm.h | 44 +
6 files changed, 295 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.h
diff --git a/drivers/gpu/drm/panfrost/Kconfig b/drivers/gpu/drm/panfrost/Kconfig
index 86cdc0ce79e6..079600328be1 100644
--- a/drivers/gpu/drm/panfrost/Kconfig
+++ b/drivers/gpu/drm/panfrost/Kconfig
@@ -11,6 +11,7 @@ config DRM_PANFROST
select DRM_GEM_SHMEM_HELPER
select PM_DEVFREQ
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select WANT_DEV_COREDUMP
help
DRM driver for ARM Mali Midgard (T6xx, T7xx, T8xx) and
Bifrost (G3x, G5x, G7x) GPUs.
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index b71935862417..7da2b3f02ed9 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -9,6 +9,7 @@ panfrost-y := \
panfrost_gpu.o \
panfrost_job.o \
panfrost_mmu.o \
- panfrost_perfcnt.o
+ panfrost_perfcnt.o \
+ panfrost_dump.o
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_dump.c
b/drivers/gpu/drm/panfrost/panfrost_dump.c
new file mode 100644
index ..53ecc9b43666
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_dump.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2021 Collabora ltd. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "panfrost_job.h"
+#include "panfrost_gem.h"
+#include "panfrost_regs.h"
+#include "panfrost_dump.h"
+#include "panfrost_device.h"
+
+static bool panfrost_dump_core = true;
+module_param_named(dump_core, panfrost_dump_core, bool, 0600);
+
+struct panfrost_dump_iterator {
+ void *start;
+ struct panfrost_dump_object_header *hdr;
+ void *data;
+};
+
+static const unsigned short panfrost_dump_registers[] = {
+ SHADER_READY_LO,
+ SHADER_READY_HI,
+ TILER_READY_LO,
+ TILER_READY_HI,
+ L2_READY_LO,
+ L2_READY_HI,
+ JOB_INT_MASK,
+ JOB_INT_STAT,
+ JS_HEAD_LO(0),
+ JS_HEAD_HI(0),
+ JS_TAIL_LO(0),
+ JS_TAIL_HI(0),
+ JS_AFFINITY_LO(0),
+ JS_AFFINITY_HI(0),
+ JS_CONFIG(0),
+ JS_STATUS(0),
+ JS_HEAD_NEXT_LO(0),
+ JS_HEAD_NEXT_HI(0),
+ JS_AFFINITY_NEXT_LO(0),
+ JS_AFFINITY_NEXT_HI(0),
+ JS_CONFIG_NEXT(0),
+ MMU_INT_MASK,
+ MMU_INT_STAT,
+ AS_TRANSTAB_LO(0),
+ AS_TRANSTAB_HI(0),
+ AS_MEMATTR_LO(0),
+ AS_MEMATTR_HI(0),
+ AS_FAULTSTATUS(0),
+ AS_FAULTADDRESS_LO(0),
+ AS_FAULTADDRESS_HI(0),
+ AS_STATUS(0),
+};
+
+static void panfrost_core_dump_header(struct panfrost_dump_iterator *iter,
+ u32 type, void *data_end)
+{
+ struct panfrost_dump_object_header *hdr = iter->hdr;
+
+ hdr->magic = cpu_to_le32(PANFROSTDUMP_MAGIC);
+ hdr->type = cpu_to_le32(type);
+ hdr->file_offset = cpu_to_le32(iter->data - iter->start);
+ hdr->file_size = cpu_to_le32(data_end - iter->data);
+
+ iter->hdr++;
+ iter->data += le32_to_cpu(hdr->file_size);
+}
+
+static void
+panfrost_core_dump_registers(struct panfrost_dump_iterator *iter,
+struct panfrost_device *pfdev,
+u32 as_nr, int slot)
+{
+ struct panfrost_dump_registers *dumpreg = iter->data;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(panfrost_dump_registers); i++, dumpreg++) {
+ unsigned int js_as_offset = 0;
+ unsigned int reg;
+
+ if (panfrost_dump_registers[i] >= JS_HEAD_LO(0) &&
+ panfrost_dump_registers[i] <= JS_CONFIG_NEXT(0))
+ js_as_offset = slot * 0x80;
+ else if (panfrost_dump_registers[i] >= AS_TRANSTAB_LO(0) &&
+panfrost_dump_registers[i] <= AS_STATUS(0))
+ js_as_offset = ((as_nr) << 6);
+
+ reg = panfrost_dump_registers[i] + js_as_offset;
+
+ dumpreg->reg = cpu_to_le32(reg);
+ dumpreg->value = cpu_to_le32(gpu_read(pfdev, reg));
+ }
+
+ panfrost_core_dump_header(iter, PANFROSTDUMP_BUF_REG, dumpreg);
+}
+
+void panfrost_core_dump(struct panfrost_job *job)
+{
+ struct panfrost_device *pfdev = job->pfdev;
+ struct panfrost_dump_iterator iter;
+ struct drm_gem_object *dbo;
+ unsigned
[PATCH v2 0/1] devcoredump support for Panfrost GPU driver
This is v2 for a previous patch series being discussed at https://lore.kernel.org/dri-devel/20220517174216.381287-1-adrian.laru...@collabora.com/. Mesa MR under review can be found at: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14034 Changes with respect to v1 of the same patch: - Change the list of dumped registers to those of greatest debugging value. - Fix bug where an invalid bomap header wouldn't be dumped - Changed the way that a decision is made whether to dump a BOMAP header so that no compiler warning supression has to be done. - Changed magic number for header fields to something more representative. - Changed the dump header format to a union whose members are the different header types. Adrián Larumbe (1): drm/panfrost: Add support for devcoredump drivers/gpu/drm/panfrost/Kconfig | 1 + drivers/gpu/drm/panfrost/Makefile| 3 +- drivers/gpu/drm/panfrost/panfrost_dump.c | 233 +++ drivers/gpu/drm/panfrost/panfrost_dump.h | 12 ++ drivers/gpu/drm/panfrost/panfrost_job.c | 3 + include/uapi/drm/panfrost_drm.h | 44 + 6 files changed, 295 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.h -- 2.36.1
Re: [PATCH 1/1] drm/panfrost: Add support for devcoredump
Hi Steven,
Thanks a lot for your feedback, it was quite useful.
Also I'm sorry about having taken so long to write a reply, but other things
held me
back from working on Panfrost for way too long already.
On 18.05.2022 12:03, Steven Price wrote:
>On 17/05/2022 18:42, Adrián Larumbe wrote:
>> In the event of a job timeout, debug dump information will be written into
>> /sys/class/devcoredump.
>>
>> Inspired by etnaviv's similar feature.
>>
>> Signed-off-by: Adrián Larumbe
>
>Nice! Some comments below.
>
>> ---
>> drivers/gpu/drm/panfrost/Kconfig | 1 +
>> drivers/gpu/drm/panfrost/Makefile| 3 +-
>> drivers/gpu/drm/panfrost/panfrost_dump.c | 198 +++
>> drivers/gpu/drm/panfrost/panfrost_dump.h | 12 ++
>> drivers/gpu/drm/panfrost/panfrost_job.c | 3 +
>> include/uapi/drm/panfrost_drm.h | 32
>> 6 files changed, 248 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.c
>> create mode 100644 drivers/gpu/drm/panfrost/panfrost_dump.h
>>
>> diff --git a/drivers/gpu/drm/panfrost/Kconfig
>> b/drivers/gpu/drm/panfrost/Kconfig
>> index 86cdc0ce79e6..079600328be1 100644
>> --- a/drivers/gpu/drm/panfrost/Kconfig
>> +++ b/drivers/gpu/drm/panfrost/Kconfig
>> @@ -11,6 +11,7 @@ config DRM_PANFROST
>> select DRM_GEM_SHMEM_HELPER
>> select PM_DEVFREQ
>> select DEVFREQ_GOV_SIMPLE_ONDEMAND
>> +select WANT_DEV_COREDUMP
>> help
>>DRM driver for ARM Mali Midgard (T6xx, T7xx, T8xx) and
>>Bifrost (G3x, G5x, G7x) GPUs.
>> diff --git a/drivers/gpu/drm/panfrost/Makefile
>> b/drivers/gpu/drm/panfrost/Makefile
>> index b71935862417..7da2b3f02ed9 100644
>> --- a/drivers/gpu/drm/panfrost/Makefile
>> +++ b/drivers/gpu/drm/panfrost/Makefile
>> @@ -9,6 +9,7 @@ panfrost-y := \
>> panfrost_gpu.o \
>> panfrost_job.o \
>> panfrost_mmu.o \
>> -panfrost_perfcnt.o
>> +panfrost_perfcnt.o \
>> +panfrost_dump.o
>>
>> obj-$(CONFIG_DRM_PANFROST) += panfrost.o
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_dump.c
>> b/drivers/gpu/drm/panfrost/panfrost_dump.c
>> new file mode 100644
>> index ..a76dcf4acf6f
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panfrost/panfrost_dump.c
>> @@ -0,0 +1,198 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright 2021 Collabora ltd. */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "panfrost_job.h"
>> +#include "panfrost_gem.h"
>> +#include "panfrost_regs.h"
>> +#include "panfrost_dump.h"
>> +#include "panfrost_device.h"
>> +
>> +static bool panfrost_dump_core = true;
>> +module_param_named(dump_core, panfrost_dump_core, bool, 0600);
>> +
>> +struct panfrost_dump_iterator {
>> +void *start;
>> +struct panfrost_dump_object_header *hdr;
>> +void *data;
>> +};
>> +
>> +static const unsigned short panfrost_dump_registers[] = {
>> +GPU_ID,
>> +GPU_L2_FEATURES,
>> +GPU_CORE_FEATURES,
>> +GPU_TILER_FEATURES,
>> +GPU_MEM_FEATURES,
>> +GPU_MMU_FEATURES,
>> +GPU_AS_PRESENT,
>> +GPU_JS_PRESENT,
>> +GPU_INT_RAWSTAT,
>> +GPU_INT_CLEAR,
>> +GPU_INT_MASK,
>> +GPU_INT_STAT,
>> +};
>
>It would be nice to also dump the contents of JS_HEAD/JS_TAIL and the
>exception status (i.e. what panfrost_job_handle_err() prints). Although
>I'm not sure how easy it is to plumb that in at the moment. The handling
>of job faults in the Panfrost driver isn't great. So maybe that can wait
>for a v2 and we can rely on dmesg for now.
>
>To be honest this list of registers is a little random, some (like
>JS_PRESENT) are almost entirely useless, but then we're missing some
>which userspace uses such as most of the GPU_THREAD_xxx registers,
>although usually when debugging such things you are well aware of the
>platform the dump comes from.
To be quite frank, the way I picked them was just selecting those of
lowest offset in the register file. I was hoping someone would tell me
which ones they might find interesting when debugging the driver, so this
information is quite useful.
>But I'm not an expert on debugging descriptors - my approach in the past
>with the similar kbase feature has been to simply replay the specific
>job on a software model of the GPU (hence the value of JS_HEAD/JS_TAIL).
>
>You may find the list of registers that kbase dumps[1] to be an
>interesting reference, the set is designed to spot kernel bugs (e.g.
>core power states being different from expected) and allow the job which
>failed to be replayed. In the blob this is combined with a debugfs file
>which allows dumping the complete GPU memory[2] and userspace code to
>trigger a dump after a job fault. These can then be combined to make a
>'dump file' which our tools allow replaying on the model, hardware or RTL.
>
>[1]
[PATCH] drm: Make drm_buddy a part of drm module
The drm_buddy is just a software allocator, so don't need to create
a module for this small part.
If drm_buddy is included in drm module, then only need to insmod drm.ko
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_buddy.c | 7 ++-
drivers/gpu/drm/drm_drv.c | 10 ++
include/drm/drm_buddy.h | 3 +++
5 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 22e7fa48d693..6c18b34f25d3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -180,7 +180,7 @@ config DRM_TTM
uses it.
config DRM_BUDDY
- tristate
+ bool
depends on DRM
help
A page based buddy allocator
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 13ef240b3d2b..75737ccb5fc0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -29,6 +29,7 @@ drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
drm_privacy_screen_x86.o
+drm-$(CONFIG_DRM_BUDDY) += drm_buddy.o
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_NOMODESET) += drm_nomodeset.o
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..9262811b39ac 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -767,12 +767,12 @@ void drm_buddy_print(struct drm_buddy *mm, struct
drm_printer *p)
}
EXPORT_SYMBOL(drm_buddy_print);
-static void drm_buddy_module_exit(void)
+void drm_buddy_slb_blk_put(void)
{
kmem_cache_destroy(slab_blocks);
}
-static int __init drm_buddy_module_init(void)
+int __init drm_buddy_slb_blk_get(void)
{
slab_blocks = KMEM_CACHE(drm_buddy_block, 0);
if (!slab_blocks)
@@ -781,8 +781,5 @@ static int __init drm_buddy_module_init(void)
return 0;
}
-module_init(drm_buddy_module_init);
-module_exit(drm_buddy_module_exit);
-
MODULE_DESCRIPTION("DRM Buddy Allocator");
MODULE_LICENSE("Dual MIT/GPL");
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8214a0b1ab7f..2b5d6a8b5572 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -1034,6 +1035,9 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
drm_privacy_screen_lookup_exit();
+#if IS_ENABLED(CONFIG_DRM_BUDDY)
+ drm_buddy_slb_blk_put();
+#endif
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1061,6 +1065,12 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+#if IS_ENABLED(CONFIG_DRM_BUDDY)
+ ret = drm_buddy_slb_blk_get();
+ if (!ret)
+ goto error;
+#endif
+
drm_privacy_screen_lookup_init();
drm_core_init_complete = true;
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index 572077ff8ae7..6f648175243c 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -156,4 +156,7 @@ void drm_buddy_block_print(struct drm_buddy *mm,
struct drm_buddy_block *block,
struct drm_printer *p);
+int __init drm_buddy_slb_blk_get(void);
+void drm_buddy_slb_blk_put(void);
+
#endif
--
2.25.1
[PATCH v3 3/4] drm/msm/dpu: Add MISR register support for interface
Add support for setting MISR registers within the interface
Changes since V1:
- Replaced dpu_hw_intf collect_misr and setup_misr implementations with
calls to dpu_hw_utils helper methods
Signed-off-by: Jessica Zhang
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 19 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 8 +++-
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 3f4d2c6e1b45..b37eeea36532 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#include "dpu_hwio.h"
@@ -67,6 +69,9 @@
#define INTF_CFG2_DATABUS_WIDENBIT(0)
#define INTF_CFG2_DATA_HCTL_EN BIT(4)
+#define INTF_MISR_CTRL 0x180
+#define INTF_MISR_SIGNATURE0x184
+
static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -319,6 +324,16 @@ static u32 dpu_hw_intf_get_line_count(struct dpu_hw_intf
*intf)
return DPU_REG_READ(c, INTF_LINE_COUNT);
}
+static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, u32
frame_count)
+{
+ dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count);
+}
+
+static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32 *misr_value)
+{
+ return dpu_hw_collect_misr(>hw, INTF_MISR_CTRL,
INTF_MISR_SIGNATURE, misr_value);
+}
+
static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
unsigned long cap)
{
@@ -329,6 +344,8 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->get_line_count = dpu_hw_intf_get_line_count;
if (cap & BIT(DPU_INTF_INPUT_CTRL))
ops->bind_pingpong_blk = dpu_hw_intf_bind_pingpong_blk;
+ ops->setup_misr = dpu_hw_intf_setup_misr;
+ ops->collect_misr = dpu_hw_intf_collect_misr;
}
struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 7b2d96ac61e8..8d0e7b509260 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -1,5 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#ifndef _DPU_HW_INTF_H
@@ -57,6 +59,8 @@ struct intf_status {
* @ get_line_count: reads current vertical line counter
* @bind_pingpong_blk: enable/disable the connection with pingpong which will
* feed pixels to this interface
+ * @setup_misr: enable/disable MISR
+ * @collect_misr: read MISR signature
*/
struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -77,6 +81,8 @@ struct dpu_hw_intf_ops {
void (*bind_pingpong_blk)(struct dpu_hw_intf *intf,
bool enable,
const enum dpu_pingpong pp);
+ void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32
frame_count);
+ int (*collect_misr)(struct dpu_hw_intf *intf, u32 *misr_value);
};
struct dpu_hw_intf {
--
2.35.1
[PATCH v3 4/4] drm/msm/dpu: Add interface support for CRC debugfs
Add support for writing CRC values for the interface block to
the debugfs by calling the necessary MISR setup/collect methods.
Changes since V1:
- Set values_cnt to only include phys with backing hw_intf
- Loop over all drm_encs connected to crtc
Changes since V2:
- Remove vblank.h inclusion
- Change `pos + i` to `pos + entries`
- Initialize values_cnt to 0 for encoder
- Change DPU_CRTC_CRC_SOURCE_INTF to DPU_CRTC_CRC_SOURCE_ENCODER (and
"intf" to "enc")
- Change dpu_encoder_get_num_phys to dpu_encoder_get_num_hw_intfs
- Add checks for setup_misr and collect_misr in
dpu_encoder_get_num_hw_intfs
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 50 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 64 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 22 +++
4 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 69a1257d3b6d..b4e8a4432796 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -79,6 +79,8 @@ static enum dpu_crtc_crc_source
dpu_crtc_parse_crc_source(const char *src_name)
if (!strcmp(src_name, "auto") ||
!strcmp(src_name, "lm"))
return DPU_CRTC_CRC_SOURCE_LAYER_MIXER;
+ if (!strcmp(src_name, "enc"))
+ return DPU_CRTC_CRC_SOURCE_ENCODER;
return DPU_CRTC_CRC_SOURCE_INVALID;
}
@@ -94,8 +96,16 @@ static int dpu_crtc_verify_crc_source(struct drm_crtc *crtc,
return -EINVAL;
}
- if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
+ if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER) {
*values_cnt = crtc_state->num_mixers;
+ } else if (source == DPU_CRTC_CRC_SOURCE_ENCODER) {
+ struct drm_encoder *drm_enc;
+
+ *values_cnt = 0;
+
+ drm_for_each_encoder_mask(drm_enc, crtc->dev,
crtc->state->encoder_mask)
+ *values_cnt += dpu_encoder_get_num_hw_intfs(drm_enc);
+ }
return 0;
}
@@ -116,6 +126,14 @@ static void dpu_crtc_setup_lm_misr(struct dpu_crtc_state
*crtc_state)
}
}
+static void dpu_crtc_setup_encoder_misr(struct drm_crtc *crtc)
+{
+ struct drm_encoder *drm_enc;
+
+ drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc->state->encoder_mask)
+ dpu_encoder_setup_misr(drm_enc);
+}
+
static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
enum dpu_crtc_crc_source source = dpu_crtc_parse_crc_source(src_name);
@@ -164,6 +182,8 @@ static int dpu_crtc_set_crc_source(struct drm_crtc *crtc,
const char *src_name)
if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
dpu_crtc_setup_lm_misr(crtc_state);
+ else if (source == DPU_CRTC_CRC_SOURCE_ENCODER)
+ dpu_crtc_setup_encoder_misr(crtc);
else
ret = -EINVAL;
@@ -212,6 +232,28 @@ static int dpu_crtc_get_lm_crc(struct drm_crtc *crtc,
drm_crtc_accurate_vblank_count(crtc), crcs);
}
+static int dpu_crtc_get_encoder_crc(struct drm_crtc *crtc, u32 *crcs)
+{
+ struct drm_encoder *drm_enc;
+ int rc, pos = 0;
+
+
+ drm_for_each_encoder_mask(drm_enc, crtc->dev,
crtc->state->encoder_mask) {
+ rc = dpu_encoder_get_crc(drm_enc, crcs, pos);
+ if (rc < 0) {
+ if (rc != -ENODATA)
+ DRM_DEBUG_DRIVER("MISR read failed\n");
+
+ return rc;
+ }
+
+ pos += rc;
+ }
+
+ return drm_crtc_add_crc_entry(crtc, true,
+ drm_crtc_accurate_vblank_count(crtc), crcs);
+}
+
static int dpu_crtc_get_crc(struct drm_crtc *crtc)
{
struct dpu_crtc_state *crtc_state = to_dpu_crtc_state(crtc->state);
@@ -226,6 +268,12 @@ static int dpu_crtc_get_crc(struct drm_crtc *crtc)
if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER) {
BUILD_BUG_ON(ARRAY_SIZE(crcs) < ARRAY_SIZE(crtc_state->mixers));
return dpu_crtc_get_lm_crc(crtc, crtc_state, crcs);
+ } else if (crtc_state->crc_source == DPU_CRTC_CRC_SOURCE_ENCODER) {
+ if (ARRAY_SIZE(crcs) < INTF_MAX)
+ DPU_ERROR("crcs array of size %ld less than %d\n",
+ ARRAY_SIZE(crcs), INTF_MAX);
+
+ return dpu_crtc_get_encoder_crc(crtc, crcs);
}
return 0;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index aa897ec28ad3..b49cf8ae126f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0-only */
/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc.
[PATCH v3 1/4] drm/msm/dpu: Move LM CRC code into separate method
Move layer mixer-specific section of dpu_crtc_get_crc() into a separate
helper method. This way, we can make it easier to get CRCs from other HW
blocks by adding other get_crc helper methods.
Changes since V1:
- Move common bitmasks to dpu_hw_util.h
- Move common CRC methods to dpu_hw_util.c
- Update copyrights
- Change crcs array to a dynamically allocated array and added it as a
member of crtc_state
Changes since V2:
- Put changes for hw_util into a separate commit
- Revert crcs array to a static array
- Add else case for set_crc_source to return EINVAL if no valid source
is selected
- Add DPU_CRTC_MAX_CRC_ENTRIES macro
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 79 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 8 +++
2 files changed, 56 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index b56f777dbd0e..69a1257d3b6d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) 2014-2021 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
@@ -99,17 +100,32 @@ static int dpu_crtc_verify_crc_source(struct drm_crtc
*crtc,
return 0;
}
+static void dpu_crtc_setup_lm_misr(struct dpu_crtc_state *crtc_state)
+{
+ struct dpu_crtc_mixer *m;
+ int i;
+
+ for (i = 0; i < crtc_state->num_mixers; ++i) {
+ m = _state->mixers[i];
+
+ if (!m->hw_lm || !m->hw_lm->ops.setup_misr)
+ continue;
+
+ /* Calculate MISR over 1 frame */
+ m->hw_lm->ops.setup_misr(m->hw_lm, true, 1);
+ }
+}
+
static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
enum dpu_crtc_crc_source source = dpu_crtc_parse_crc_source(src_name);
enum dpu_crtc_crc_source current_source;
struct dpu_crtc_state *crtc_state;
struct drm_device *drm_dev = crtc->dev;
- struct dpu_crtc_mixer *m;
bool was_enabled;
bool enable = false;
- int i, ret = 0;
+ int ret = 0;
if (source < 0) {
DRM_DEBUG_DRIVER("Invalid CRC source %s for CRTC%d\n",
src_name, crtc->index);
@@ -146,16 +162,10 @@ static int dpu_crtc_set_crc_source(struct drm_crtc *crtc,
const char *src_name)
crtc_state->crc_frame_skip_count = 0;
- for (i = 0; i < crtc_state->num_mixers; ++i) {
- m = _state->mixers[i];
-
- if (!m->hw_lm || !m->hw_lm->ops.setup_misr)
- continue;
-
- /* Calculate MISR over 1 frame */
- m->hw_lm->ops.setup_misr(m->hw_lm, true, 1);
- }
-
+ if (source == DPU_CRTC_CRC_SOURCE_LAYER_MIXER)
+ dpu_crtc_setup_lm_misr(crtc_state);
+ else
+ ret = -EINVAL;
cleanup:
drm_modeset_unlock(>mutex);
@@ -174,34 +184,22 @@ static u32 dpu_crtc_get_vblank_counter(struct drm_crtc
*crtc)
return dpu_encoder_get_vsync_count(encoder);
}
-
-static int dpu_crtc_get_crc(struct drm_crtc *crtc)
+static int dpu_crtc_get_lm_crc(struct drm_crtc *crtc,
+ struct dpu_crtc_state *crtc_state, u32 *crcs)
{
- struct dpu_crtc_state *crtc_state;
- struct dpu_crtc_mixer *m;
- u32 crcs[CRTC_DUAL_MIXERS];
+ struct dpu_crtc_mixer *lm;
- int i = 0;
int rc = 0;
-
- crtc_state = to_dpu_crtc_state(crtc->state);
-
- BUILD_BUG_ON(ARRAY_SIZE(crcs) != ARRAY_SIZE(crtc_state->mixers));
-
- /* Skip first 2 frames in case of "uncooked" CRCs */
- if (crtc_state->crc_frame_skip_count < 2) {
- crtc_state->crc_frame_skip_count++;
- return 0;
- }
+ int i;
for (i = 0; i < crtc_state->num_mixers; ++i) {
- m = _state->mixers[i];
+ lm = _state->mixers[i];
- if (!m->hw_lm || !m->hw_lm->ops.collect_misr)
+ if (!lm->hw_lm || !lm->hw_lm->ops.collect_misr)
continue;
- rc = m->hw_lm->ops.collect_misr(m->hw_lm, [i]);
+ rc = lm->hw_lm->ops.collect_misr(lm->hw_lm, [i]);
if (rc) {
if (rc != -ENODATA)
@@ -214,6 +212,25 @@ static int dpu_crtc_get_crc(struct drm_crtc *crtc)
drm_crtc_accurate_vblank_count(crtc), crcs);
}
+static int dpu_crtc_get_crc(struct drm_crtc *crtc)
+{
+ struct dpu_crtc_state *crtc_state = to_dpu_crtc_state(crtc->state);
+ u32 crcs[DPU_CRTC_MAX_CRC_ENTRIES];
+
+ /* Skip first 2 frames in case of "uncooked" CRCs */
+ if (crtc_state->crc_frame_skip_count < 2) {
+ crtc_state->crc_frame_skip_count++;
+ return 0;
+
[PATCH v3 2/4] drm/msm/dpu: Move MISR methods to dpu_hw_util
Move layer mixer specific MISR methods to generalized helper methods.
This will make it easier to add CRC support for other blocks in the
future.
Changes since V2:
- Reordered parameters so that offsets are after hw_blk_reg_map
- Fixed mismatched whitespace in bitmask definitions
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 42 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 49 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 16 +++
3 files changed, 67 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 462f5082099e..e370dcd76e17 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
* Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
*/
@@ -27,11 +28,6 @@
#define LM_MISR_CTRL 0x310
#define LM_MISR_SIGNATURE0x314
-#define LM_MISR_FRAME_COUNT_MASK 0xFF
-#define LM_MISR_CTRL_ENABLE BIT(8)
-#define LM_MISR_CTRL_STATUS BIT(9)
-#define LM_MISR_CTRL_STATUS_CLEARBIT(10)
-#define LM_MISR_CTRL_FREE_RUN_MASK BIT(31)
static const struct dpu_lm_cfg *_lm_offset(enum dpu_lm mixer,
@@ -108,44 +104,12 @@ static void dpu_hw_lm_setup_border_color(struct
dpu_hw_mixer *ctx,
static void dpu_hw_lm_setup_misr(struct dpu_hw_mixer *ctx, bool enable, u32
frame_count)
{
- struct dpu_hw_blk_reg_map *c = >hw;
- u32 config = 0;
-
- DPU_REG_WRITE(c, LM_MISR_CTRL, LM_MISR_CTRL_STATUS_CLEAR);
-
- /* Clear old MISR value (in case it's read before a new value is
calculated)*/
- wmb();
-
- if (enable) {
- config = (frame_count & LM_MISR_FRAME_COUNT_MASK) |
- LM_MISR_CTRL_ENABLE | LM_MISR_CTRL_FREE_RUN_MASK;
-
- DPU_REG_WRITE(c, LM_MISR_CTRL, config);
- } else {
- DPU_REG_WRITE(c, LM_MISR_CTRL, 0);
- }
-
+ dpu_hw_setup_misr(>hw, LM_MISR_CTRL, enable, frame_count);
}
static int dpu_hw_lm_collect_misr(struct dpu_hw_mixer *ctx, u32 *misr_value)
{
- struct dpu_hw_blk_reg_map *c = >hw;
- u32 ctrl = 0;
-
- if (!misr_value)
- return -EINVAL;
-
- ctrl = DPU_REG_READ(c, LM_MISR_CTRL);
-
- if (!(ctrl & LM_MISR_CTRL_ENABLE))
- return -ENODATA;
-
- if (!(ctrl & LM_MISR_CTRL_STATUS))
- return -EINVAL;
-
- *misr_value = DPU_REG_READ(c, LM_MISR_SIGNATURE);
-
- return 0;
+ return dpu_hw_collect_misr(>hw, LM_MISR_CTRL, LM_MISR_SIGNATURE,
misr_value);
}
static void dpu_hw_lm_setup_blend_config_sdm845(struct dpu_hw_mixer *ctx,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
index 512316f25a51..a679757159e9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
@@ -1,5 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/*
+ * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
@@ -447,3 +449,48 @@ u64 _dpu_hw_get_qos_lut(const struct dpu_qos_lut_tbl *tbl,
return 0;
}
+
+void dpu_hw_setup_misr(struct dpu_hw_blk_reg_map *c,
+ u32 misr_ctrl_offset,
+ bool enable, u32 frame_count)
+{
+ u32 config = 0;
+
+ DPU_REG_WRITE(c, misr_ctrl_offset, MISR_CTRL_STATUS_CLEAR);
+
+ /* Clear old MISR value (in case it's read before a new value is
calculated)*/
+ wmb();
+
+ if (enable) {
+ config = (frame_count & MISR_FRAME_COUNT_MASK) |
+ MISR_CTRL_ENABLE | MISR_CTRL_FREE_RUN_MASK;
+
+ DPU_REG_WRITE(c, misr_ctrl_offset, config);
+ } else {
+ DPU_REG_WRITE(c, misr_ctrl_offset, 0);
+ }
+
+}
+
+int dpu_hw_collect_misr(struct dpu_hw_blk_reg_map *c,
+ u32 misr_ctrl_offset,
+ u32 misr_signature_offset,
+ u32 *misr_value)
+{
+ u32 ctrl = 0;
+
+ if (!misr_value)
+ return -EINVAL;
+
+ ctrl = DPU_REG_READ(c, misr_ctrl_offset);
+
+ if (!(ctrl & MISR_CTRL_ENABLE))
+ return -ENODATA;
+
+ if (!(ctrl & MISR_CTRL_STATUS))
+ return -EINVAL;
+
+ *misr_value = DPU_REG_READ(c, misr_signature_offset);
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index e4a65eb4f769..98f1be0d2559 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++
[PATCH v3 0/4] Expand CRC to support interface blocks
Refactor existing CRC code for layer mixer and add CRC support for interface blocks Changes since V1: - Create helper methods for collect_misr and setup_misr in dpu_hw_util.c - Move common bitmasks into dpu_hw_util.h - Update copyrights - Create a dynamically allocated crcs array in dpu_crtc_state - Collect CRCs for all drm_encoders connected to the crtc Changes since V2: - Separate dpu_hw_util changes into a separate patch - Revert back to using a static array and define a macro for MAX_CRC_ENTRIES Jessica Zhang (4): drm/msm/dpu: Move LM CRC code into separate method drm/msm/dpu: Generalize MISR methods to hw_util drm/msm/dpu: Add MISR register support for interface drm/msm/dpu: Add interface support for CRC debugfs drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 130 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 11 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 64 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 22 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 19 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 42 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 49 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 16 +++ 9 files changed, 287 insertions(+), 74 deletions(-) -- 2.35.1
Re: [PATCH v1 4/4] drm/msm/dpu: move struct dpu_hw_blk definition to dpu_hw_utils.h
On 6/1/2022 9:13 AM, Dmitry Baryshkov wrote:
There is little point in having a separate header just for a single
opaque struct definition. Drop it now and move the struct to the
dpu_hw_util.h header.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 -
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h| 25 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 1 -
.../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h| 1 -
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h| 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 7 ++
12 files changed, 7 insertions(+), 36 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index b8785c394fcc..da64b0f639a9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -12,7 +12,6 @@
#include
#include "dpu_kms.h"
#include "dpu_core_perf.h"
-#include "dpu_hw_blk.h"
#define DPU_CRTC_NAME_SIZE 12
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index 53bb4639c8e9..1db6b75cd1f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -12,7 +12,6 @@
#include "dpu_hw_top.h"
#include "dpu_hw_wb.h"
#include "dpu_hw_lm.h"
-#include "dpu_hw_blk.h"
#include "dpu_hw_merge3d.h"
#include "dpu_hw_interrupts.h"
#include "dpu_core_irq.h"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
deleted file mode 100644
index 52e92f37eda4..
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
- */
-
-#ifndef _DPU_HW_BLK_H
-#define _DPU_HW_BLK_H
-
-#include
-#include
-
-struct dpu_hw_blk;
-
-
-/**
- * struct dpu_hw_blk - definition of hardware block object
- * @list: list of hardware blocks
- * @type: hardware block type
- * @id: instance id
- * @refcount: reference/usage count
- */
-struct dpu_hw_blk {
- /* opaque */
-};
-
-#endif /*_DPU_HW_BLK_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index 5755307089b5..7d9ad6a3f9f6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -10,7 +10,6 @@
#include "dpu_hw_util.h"
#include "dpu_hw_catalog.h"
#include "dpu_hw_sspp.h"
-#include "dpu_hw_blk.h"
/**
* dpu_ctl_mode_sel: Interface mode selection
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
index 7fa189cfcb06..05ecfdfac93b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
@@ -5,8 +5,6 @@
#ifndef _DPU_HW_DSPP_H
#define _DPU_HW_DSPP_H
-#include "dpu_hw_blk.h"
-
struct dpu_hw_dspp;
/**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 7b2d96ac61e8..c262430e4dbd 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -8,7 +8,6 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
-#include "dpu_hw_blk.h"
struct dpu_hw_intf;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
index d8052fb2d5da..652ddfdedec3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h
@@ -8,7 +8,6 @@
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
-#include "dpu_hw_blk.h"
struct dpu_hw_mixer;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h
index 870bdb14613e..81fd1d5f718e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h
@@ -8,7 +8,6 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
-#include "dpu_hw_blk.h"
struct dpu_hw_merge_3d;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 12758468d9ca..c00223441d99 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -8,7 +8,6 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
Re: [PATCH v2 2/2] vfio/pci: Remove console drivers
Hello Alex, On 6/16/22 22:38, Alex Williamson wrote: > Console drivers can create conflicts with PCI resources resulting in > userspace getting mmap failures to memory BARs. This is especially > evident when trying to re-use the system primary console for userspace > drivers. Use the aperture helpers to remove these conflicts. > > Reported-by: Laszlo Ersek > Suggested-by: Gerd Hoffmann > Signed-off-by: Alex Williamson > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v1 3/4] drm/msm/dpu: merge base_off with blk_off in struct dpu_hw_blk_reg_map
On 6/1/2022 9:13 AM, Dmitry Baryshkov wrote:
There is little point in keeping a separate MDP address and block offset
in this struct. Merge them to form a new blk_addr field used for all
register access.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c| 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 5 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 6 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
15 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 1120ff408dae..e12b7fa48a7b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -58,8 +58,7 @@ static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
for (i = 0; i < m->ctl_count; i++) {
if (ctl == m->ctl[i].id) {
- b->base_off = addr;
- b->blk_off = m->ctl[i].base;
+ b->blk_addr = addr + m->ctl[i].base;
b->log_mask = DPU_DBG_MASK_CTL;
return >ctl[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index dfe6e4c11917..411689ae6382 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -166,8 +166,7 @@ static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
for (i = 0; i < m->dsc_count; i++) {
if (dsc == m->dsc[i].id) {
- b->base_off = addr;
- b->blk_off = m->dsc[i].base;
+ b->blk_addr = addr + m->dsc[i].base;
b->log_mask = DPU_DBG_MASK_DSC;
return >dsc[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 8196ae47dea8..8ab5ace34a2d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -80,8 +80,7 @@ static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp
dspp,
for (i = 0; i < m->dspp_count; i++) {
if (dspp == m->dspp[i].id) {
- b->base_off = addr;
- b->blk_off = m->dspp[i].base;
+ b->blk_addr = addr + m->dspp[i].base;
b->log_mask = DPU_DBG_MASK_DSPP;
return >dspp[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index d83503ea2419..cf1b6d84c18a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -401,8 +401,7 @@ u32 dpu_core_irq_read(struct dpu_kms *dpu_kms, int irq_idx)
static void __intr_offset(const struct dpu_mdss_cfg *m,
void __iomem *addr, struct dpu_hw_blk_reg_map *hw)
{
- hw->base_off = addr;
- hw->blk_off = m->mdp[0].base;
+ hw->blk_addr = addr + m->mdp[0].base;
}
struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index c7eb314f1d7a..d8aff0f459f8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -77,8 +77,7 @@ static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf
intf,
for (i = 0; i < m->intf_count; i++) {
if ((intf == m->intf[i].id) &&
(m->intf[i].type != INTF_NONE)) {
- b->base_off = addr;
- b->blk_off = m->intf[i].base;
+ b->blk_addr = addr + m->intf[i].base;
b->log_mask = DPU_DBG_MASK_INTF;
return >intf[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 87a4a5869b9b..75d55fd65f19 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -43,8 +43,7 @@ static const struct dpu_lm_cfg
Re: [PATCH v2 1/2] drm: Implement DRM aperture helpers under video/
On 6/16/22 22:38, Alex Williamson wrote:
> From: Thomas Zimmermann
>
> Implement DRM's aperture helpers under video/ for sharing with other
> sub-systems. Remove DRM-isms from the interface. The helpers track
> the ownership of framebuffer apertures and provide hand-over from
> firmware, such as EFI and VESA, to native graphics drivers.
>
> Other subsystems, such as fbdev and vfio, also have to maintain ownership
> of framebuffer apertures. Moving DRM's aperture helpers to a more public
> location allows all subsystems to interact with each other and share a
> common implementation.
>
> The aperture helpers are selected by the various firmware drivers within
> DRM and fbdev, and the VGA text-console driver.
>
Thanks a lot for working on this.
> The original DRM interface is kept in place for use by DRM drivers.
>
> Signed-off-by: Thomas Zimmermann
> Signed-off-by: Alex Williamson
> ---
[...]
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 427a993c7f57..c69b45f8c427 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -5,6 +5,12 @@
>
> menu "Graphics support"
>
> +config APERTURE_HELPERS
> + bool
> + help
> + Support tracking and hand-over of aperture ownership. Required
> + for firmware graphics drivers.
> +
Maybe "graphics drivers using a firmware-provided framebuffer" is more clear?
[...]
> +++ b/drivers/video/aperture.c
> @@ -0,0 +1,340 @@
> +// SPDX-License-Identifier: MIT
> +
> +#include
> +#include
> +#include /* for old fbdev helpers */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * DOC: overview
> + *
> + * A graphics device might be supported by different drivers, but only one
> + * driver can be active at any given time. Many systems load a generic
> + * graphics drivers, such as EFI-GOP or VESA, early during the boot process.
> + * During later boot stages, they replace the generic driver with a
> dedicated,
> + * hardware-specific driver. To take over the device the dedicated driver
> + * first has to remove the generic driver. Aperture functions manage
> + * ownership of framebuffer memory and hand-over between drivers.
> + *
> + * Graphics drivers should call remove_conflicting_devices()
> + * at the top of their probe function. The function removes any generic
> + * driver that is currently associated with the given framebuffer memory.
> + * If the framebuffer is located at PCI BAR 0, the rsp code looks as in the
s/rsp/respective
> + * example given below. The cod assumes a DRM driver.
> + *
s/cod/code
> + * .. code-block:: c
> + *
> + * static const struct drm_driver example_driver = {
> + * .name = "exampledrm",
> + * ...
> + * };
> + *
> + * static int remove_conflicting_framebuffers(struct pci_dev *pdev)
> + * {
> + * bool primary = false;
> + * resource_size_t base, size;
> + * int ret;
> + *
> + * base = pci_resource_start(pdev, 0);
> + * size = pci_resource_len(pdev, 0);
> + * #ifdef CONFIG_X86
> + * primary = pdev->resource[PCI_ROM_RESOURCE].flags &
> IORESOURCE_ROM_SHADOW;
> + * #endif
This example seems to be copied from drivers/gpu/drm/ast/ast_drv.c and I
don't see any other driver that has its framebuffer located in PCI BAR 0
or at least having a similar code.
So I wonder if we really want to have this example for such a corner case ?
Also, remove_conflicting_pci_framebuffers() seems to already at least check
for the IORESOURCE_ROM_SHADOW flag so it would be better to grow that and
support this special case of PCI BAR 0 (maybe adding another param that is
passed through remove_conflicting_pci_devices() ?
In any case, it seems to me that it is something that ast shouldn't really
have to open code it and instead the helpers should be fixed to cover that
case for drivers not to care. I would really not add the snippet in the doc.
Since we are talking about remove_conflicting_devices() here, a better code
example could be for a platform device instead of a PCI device, like this:
* static const struct platform_driver example_driver = {
* .name = "example",
* ...
* };
*
* static int probe(struct platform_device *pdev)
* {
* struct resource *mem;
* resource_size_t base, size;
*
* mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
* if (!mem)
* return -EINVAL;
* base = mem->start;
* size = resource_size(mem);
*
* ret = remove_conflicting_devices(base, size, false,
_driver->name);
* if (ret)
* return ret;
*
* // ... and initialize the hardware.
* ...
*
* return 0;
* }
> + * static int probe(struct pci_dev *pdev)
> + * {
> + * int ret;
> + *
> + * // Remove any
Re: [PATCH v1 2/4] drm/msm/dpu: drop length from struct dpu_hw_blk_reg_map
On 6/1/2022 9:13 AM, Dmitry Baryshkov wrote:
We (nearly) do not use the length field from struct dpu_hw_blk_reg_map,
so we can drop it safely.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
13 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 7d416bf4ae91..1120ff408dae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -60,7 +60,6 @@ static const struct dpu_ctl_cfg *_ctl_offset(enum dpu_ctl ctl,
if (ctl == m->ctl[i].id) {
b->base_off = addr;
b->blk_off = m->ctl[i].base;
- b->length = m->ctl[i].len;
b->log_mask = DPU_DBG_MASK_CTL;
return >ctl[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
index 184a1b27b13d..dfe6e4c11917 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c
@@ -168,7 +168,6 @@ static struct dpu_dsc_cfg *_dsc_offset(enum dpu_dsc dsc,
if (dsc == m->dsc[i].id) {
b->base_off = addr;
b->blk_off = m->dsc[i].base;
- b->length = m->dsc[i].len;
b->log_mask = DPU_DBG_MASK_DSC;
return >dsc[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 3e63bf4fa64e..8196ae47dea8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -82,7 +82,6 @@ static const struct dpu_dspp_cfg *_dspp_offset(enum dpu_dspp
dspp,
if (dspp == m->dspp[i].id) {
b->base_off = addr;
b->blk_off = m->dspp[i].base;
- b->length = m->dspp[i].len;
b->log_mask = DPU_DBG_MASK_DSPP;
return >dspp[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index b2ca8d19fdd7..c7eb314f1d7a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -79,7 +79,6 @@ static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf
intf,
(m->intf[i].type != INTF_NONE)) {
b->base_off = addr;
b->blk_off = m->intf[i].base;
- b->length = m->intf[i].len;
b->log_mask = DPU_DBG_MASK_INTF;
return >intf[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index b41993269d09..87a4a5869b9b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -45,7 +45,6 @@ static const struct dpu_lm_cfg *_lm_offset(enum dpu_lm mixer,
if (mixer == m->mixer[i].id) {
b->base_off = addr;
b->blk_off = m->mixer[i].base;
- b->length = m->mixer[i].len;
b->log_mask = DPU_DBG_MASK_LM;
return >mixer[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
index b053d68d38da..538691f7bf66 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
@@ -25,7 +25,6 @@ static const struct dpu_merge_3d_cfg *_merge_3d_offset(enum
dpu_merge_3d idx,
if (idx == m->merge_3d[i].id) {
b->base_off = addr;
b->blk_off = m->merge_3d[i].base;
- b->length = m->merge_3d[i].len;
b->log_mask = DPU_DBG_MASK_PINGPONG;
return >merge_3d[i];
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 6538e195cfe9..0aa63636bc9a 100644
Re: [PATCH v1 1/4] drm/msm/dpu: drop xin_id from struct dpu_hw_blk_reg_map
On 6/1/2022 9:13 AM, Dmitry Baryshkov wrote:
Drop the unused field xin_id.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index 550b2e2b3e34..e8adb118fa85 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -20,13 +20,11 @@
* @base_off: mdp register mapped offset
* @blk_off: pipe offset relative to mdss offset
* @lengthlength of register block offset
- * @xin_idxin id
*/
struct dpu_hw_blk_reg_map {
void __iomem *base_off;
u32 blk_off;
u32 length;
- u32 xin_id;
u32 log_mask;
};
Re: [PATCH 2/2] drm/radeon: Drop CONFIG_BACKLIGHT_CLASS_DEVICE ifdefs
Applied the series. Thanks,
Alex
On Mon, Jun 20, 2022 at 5:44 AM Hans de Goede wrote:
>
> The DRM_RADEON Kconfig code contains:
>
> select BACKLIGHT_CLASS_DEVICE
>
> So the condition these ifdefs test for is always true, drop them.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 14 --
> drivers/gpu/drm/radeon/radeon_acpi.c| 2 --
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 15 ---
> drivers/gpu/drm/radeon/radeon_mode.h| 4
> 4 files changed, 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index f82577dc25e8..160a309e1048 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -143,8 +143,6 @@ atombios_set_backlight_level(struct radeon_encoder
> *radeon_encoder, u8 level)
> }
> }
>
> -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
> -
> static u8 radeon_atom_bl_level(struct backlight_device *bd)
> {
> u8 level;
> @@ -293,18 +291,6 @@ static void radeon_atom_backlight_exit(struct
> radeon_encoder *radeon_encoder)
> }
> }
>
> -#else /* !CONFIG_BACKLIGHT_CLASS_DEVICE */
> -
> -void radeon_atom_backlight_init(struct radeon_encoder *encoder)
> -{
> -}
> -
> -static void radeon_atom_backlight_exit(struct radeon_encoder *encoder)
> -{
> -}
> -
> -#endif
> -
> static bool radeon_atom_mode_fixup(struct drm_encoder *encoder,
>const struct drm_display_mode *mode,
>struct drm_display_mode *adjusted_mode)
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 1baef7b493de..b603c0b77075 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -391,7 +391,6 @@ static int radeon_atif_handler(struct radeon_device *rdev,
>
> radeon_set_backlight_level(rdev, enc,
> req.backlight_level);
>
> -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
> if (rdev->is_atom_bios) {
> struct radeon_encoder_atom_dig *dig =
> enc->enc_priv;
> backlight_force_update(dig->bl_dev,
> @@ -401,7 +400,6 @@ static int radeon_atif_handler(struct radeon_device *rdev,
> backlight_force_update(dig->bl_dev,
>
> BACKLIGHT_UPDATE_HOTKEY);
> }
> -#endif
> }
> }
> if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index d2180f5c80fa..1d207c76f53e 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -320,8 +320,6 @@ radeon_legacy_set_backlight_level(struct radeon_encoder
> *radeon_encoder, u8 leve
> radeon_legacy_lvds_update(_encoder->base, dpms_mode);
> }
>
> -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
> -
> static uint8_t radeon_legacy_lvds_level(struct backlight_device *bd)
> {
> struct radeon_backlight_privdata *pdata = bl_get_data(bd);
> @@ -495,19 +493,6 @@ static void radeon_legacy_backlight_exit(struct
> radeon_encoder *radeon_encoder)
> }
> }
>
> -#else /* !CONFIG_BACKLIGHT_CLASS_DEVICE */
> -
> -void radeon_legacy_backlight_init(struct radeon_encoder *encoder)
> -{
> -}
> -
> -static void radeon_legacy_backlight_exit(struct radeon_encoder *encoder)
> -{
> -}
> -
> -#endif
> -
> -
> static void radeon_lvds_enc_destroy(struct drm_encoder *encoder)
> {
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index 3485e7f142e9..b34cffc162e2 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -281,15 +281,11 @@ struct radeon_mode_info {
>
> #define RADEON_MAX_BL_LEVEL 0xFF
>
> -#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) ||
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE)
> -
> struct radeon_backlight_privdata {
> struct radeon_encoder *encoder;
> uint8_t negative;
> };
>
> -#endif
> -
> #define MAX_H_CODE_TIMING_LEN 32
> #define MAX_V_CODE_TIMING_LEN 32
>
> --
> 2.36.0
>
Re: [PATCH] drm/amd/display: Remove unused variable 'abo'
I sent out the same patch last week. I just pushed it to drm-misc-next. Thanks! Alex On Sat, Jun 18, 2022 at 1:38 AM Simon Ser wrote: > > Reviewed-by: Simon Ser
[PATCH 5/5] drm/amdgpu: Follow up change to previous drm scheduler change.
Align refcount behaviour for amdgpu_job embedded HW fence with
classic pointer style HW fences by increasing refcount each
time emit is called so amdgpu code doesn't need to make workarounds
using amdgpu_job.job_run_counter to keep the HW fence refcount balanced.
Also since in the previous patch we resumed setting s_fence->parent to NULL
in drm_sched_stop switch to directly checking if job->hw_fence is
signaled to short circuit reset if already signed.
Signed-off-by: Andrey Grodzovsky
Tested-by: Yiqing Yao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 23 --
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 4
4 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index 513c57f839d8..447bd92c4856 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -684,6 +684,8 @@ int amdgpu_amdkfd_submit_ib(struct amdgpu_device *adev,
goto err_ib_sched;
}
+ /* Drop the initial kref_init count (see drm_sched_main as example) */
+ dma_fence_put(f);
ret = dma_fence_wait(f, false);
err_ib_sched:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index c99541685804..f9718119834f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -5009,16 +5009,28 @@ static void amdgpu_device_recheck_guilty_jobs(
/* clear job's guilty and depend the folowing step to decide
the real one */
drm_sched_reset_karma(s_job);
- /* for the real bad job, it will be resubmitted twice, adding a
dma_fence_get
-* to make sure fence is balanced */
- dma_fence_get(s_job->s_fence->parent);
drm_sched_resubmit_jobs_ext(>sched, 1);
+ if (!s_job->s_fence->parent) {
+ DRM_WARN("Failed to get a HW fence for job!");
+ continue;
+ }
+
ret = dma_fence_wait_timeout(s_job->s_fence->parent, false,
ring->sched.timeout);
if (ret == 0) { /* timeout */
DRM_ERROR("Found the real bad job! ring:%s,
job_id:%llx\n",
ring->sched.name, s_job->id);
+
+ /* Clear this failed job from fence array */
+ amdgpu_fence_driver_clear_job_fences(ring);
+
+ /* Since the job won't signal and we go for
+* another resubmit drop this parent pointer
+*/
+ dma_fence_put(s_job->s_fence->parent);
+ s_job->s_fence->parent = NULL;
+
/* set guilty */
drm_sched_increase_karma(s_job);
retry:
@@ -5047,7 +5059,6 @@ static void amdgpu_device_recheck_guilty_jobs(
/* got the hw fence, signal finished fence */
atomic_dec(ring->sched.score);
- dma_fence_put(s_job->s_fence->parent);
dma_fence_get(_job->s_fence->finished);
dma_fence_signal(_job->s_fence->finished);
dma_fence_put(_job->s_fence->finished);
@@ -5220,8 +5231,8 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
*
* job->base holds a reference to parent fence
*/
- if (job && job->base.s_fence->parent &&
- dma_fence_is_signaled(job->base.s_fence->parent)) {
+ if (job && (job->hw_fence.ops != NULL) &&
+ dma_fence_is_signaled(>hw_fence)) {
job_signaled = true;
dev_info(adev->dev, "Guilty job already signaled, skipping HW
reset");
goto skip_hw_reset;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index d6d54ba4c185..9bd4e18212fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -164,11 +164,16 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, struct
dma_fence **f, struct amd
if (job && job->job_run_counter) {
/* reinit seq for resubmitted jobs */
fence->seqno = seq;
+ /* TO be inline with external fence creation and other drivers
*/
+ dma_fence_get(fence);
} else {
- if (job)
+ if (job) {
dma_fence_init(fence, _job_fence_ops,
>fence_drv.lock,
adev->fence_context + ring->idx, seq);
+ /* Against remove in amdgpu_job_{free, free_cb} */
+ dma_fence_get(fence);
+ }
[PATCH 3/5] drm/amdgpu: Prevent race between late signaled fences and GPU reset.
Problem:
After we start handling timed out jobs we assume there fences won't be
signaled but we cannot be sure and sometimes they fire late. We need
to prevent concurrent accesses to fence array from
amdgpu_fence_driver_clear_job_fences during GPU reset and amdgpu_fence_process
from a late EOP interrupt.
Fix:
Before accessing fence array in GPU disable EOP interrupt and flush
all pending interrupt handlers for amdgpu device's interrupt line.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 26 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2b92281dd0c1..c99541685804 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4605,6 +4605,8 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
*adev,
amdgpu_virt_fini_data_exchange(adev);
}
+ amdgpu_fence_driver_isr_toggle(adev, true);
+
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -4620,6 +4622,8 @@ int amdgpu_device_pre_asic_reset(struct amdgpu_device
*adev,
amdgpu_fence_driver_force_completion(ring);
}
+ amdgpu_fence_driver_isr_toggle(adev, false);
+
if (job && job->vm)
drm_sched_increase_karma(>base);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index a9ae3beaa1d3..d6d54ba4c185 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -532,6 +532,32 @@ void amdgpu_fence_driver_hw_fini(struct amdgpu_device
*adev)
}
}
+void amdgpu_fence_driver_isr_toggle(struct amdgpu_device *adev, bool stop)
+{
+ int i;
+
+ for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
+ struct amdgpu_ring *ring = adev->rings[i];
+
+ if (!ring || !ring->fence_drv.initialized ||
!ring->fence_drv.irq_src)
+ continue;
+
+ if (stop)
+ amdgpu_irq_put(adev, ring->fence_drv.irq_src,
+ ring->fence_drv.irq_type);
+ else
+ amdgpu_irq_get(adev, ring->fence_drv.irq_src,
+ ring->fence_drv.irq_type);
+ }
+
+ /* TODO Only waits for irq handlers on other CPUs, maybe local_irq_save
+* local_irq_local_irq_restore are needed here for local interrupts ?
+*
+*/
+ if (stop)
+ synchronize_irq(adev->irq.irq);
+}
+
void amdgpu_fence_driver_sw_fini(struct amdgpu_device *adev)
{
unsigned int i, j;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 7d89a52091c0..82c178a9033a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -143,6 +143,7 @@ signed long amdgpu_fence_wait_polling(struct amdgpu_ring
*ring,
uint32_t wait_seq,
signed long timeout);
unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring);
+void amdgpu_fence_driver_isr_toggle(struct amdgpu_device *adev, bool stop);
/*
* Rings.
--
2.25.1
[PATCH 4/5] drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer'
Problem:
This patch caused negative refcount as described in [1] because
for that case parent fence did not signal by the time of drm_sched_stop and
hence
kept in pending list the assumption was they will not signal and
so fence was put to account for the s_fence->parent refcount but for
amdgpu which has embedded HW fence (always same parent fence)
drm_sched_fence_release_scheduled was always called and would
still drop the count for parent fence once more. For jobs that
never signaled this imbalance was masked by refcount bug in
amdgpu_fence_driver_clear_job_fences that would not drop
refcount on the fences that were removed from fence drive
fences array (against prevois insertion into the array in
get in amdgpu_fence_emit).
Fix:
Revert this patch and by setting s_job->s_fence->parent to NULL
as before prevent the extra refcount drop in amdgpu when
drm_sched_fence_release_scheduled is called on job release.
Also - align behaviour in drm_sched_resubmit_jobs_ext with that of
drm_sched_main when submitting jobs - take a refcount for the
new parent fence pointer and drop refcount for original kref_init
for new HW fence creation (or fake new HW fence in amdgpu - see next patch).
[1] -
https://lore.kernel.org/all/731b7ff1-3cc9-e314-df2a-7c51b76d4...@amd.com/t/#r00c728fcc069b1276642c325bfa9d82bf8fa21a3
Signed-off-by: Andrey Grodzovsky
Tested-by: Yiqing Yao
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index b81fceb0b8a2..b38394f5694f 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -419,6 +419,11 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
_job->cb)) {
+ /* Revert drm/sched: Keep s_fence->parent pointer, no
+* need anymore for amdgpu and creates only troubles
+*/
+ dma_fence_put(s_job->s_fence->parent);
+ s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
} else {
/*
@@ -548,7 +553,6 @@ void drm_sched_resubmit_jobs_ext(struct drm_gpu_scheduler
*sched, int max)
if (found_guilty && s_job->s_fence->scheduled.context ==
guilty_context)
dma_fence_set_error(_fence->finished, -ECANCELED);
- dma_fence_put(s_job->s_fence->parent);
fence = sched->ops->run_job(s_job);
i++;
@@ -558,7 +562,11 @@ void drm_sched_resubmit_jobs_ext(struct drm_gpu_scheduler
*sched, int max)
s_job->s_fence->parent = NULL;
} else {
- s_job->s_fence->parent = fence;
+
+ s_job->s_fence->parent = dma_fence_get(fence);
+
+ /* Drop for orignal kref_init */
+ dma_fence_put(fence);
}
}
}
@@ -952,6 +960,9 @@ static int drm_sched_main(void *param)
if (!IS_ERR_OR_NULL(fence)) {
s_fence->parent = dma_fence_get(fence);
+ /* Drop for original kref_init of the fence */
+ dma_fence_put(fence);
+
r = dma_fence_add_callback(fence, _job->cb,
drm_sched_job_done_cb);
if (r == -ENOENT)
@@ -959,7 +970,6 @@ static int drm_sched_main(void *param)
else if (r)
DRM_DEV_ERROR(sched->dev, "fence add callback
failed (%d)\n",
r);
- dma_fence_put(fence);
} else {
if (IS_ERR(fence))
dma_fence_set_error(_fence->finished,
PTR_ERR(fence));
--
2.25.1
[PATCH 2/5] drm/amdgpu: Add put fence in amdgpu_fence_driver_clear_job_fences
This function should drop the fence refcount when it extracts the
fence from the fence array, just as it's done in amdgpu_fence_process.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 957437a5558c..a9ae3beaa1d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -595,8 +595,10 @@ void amdgpu_fence_driver_clear_job_fences(struct
amdgpu_ring *ring)
for (i = 0; i <= ring->fence_drv.num_fences_mask; i++) {
ptr = >fence_drv.fences[i];
old = rcu_dereference_protected(*ptr, 1);
- if (old && old->ops == _job_fence_ops)
+ if (old && old->ops == _job_fence_ops) {
RCU_INIT_POINTER(*ptr, NULL);
+ dma_fence_put(old);
+ }
}
}
--
2.25.1
[PATCH 1/5] drm/amdgpu: Fix possible refcount leak for release of external_hw_fence
Problem:
In amdgpu_job_submit_direct - The refcount should drop by 2
but it drops only by 1.
amdgpu_ib_sched->emit -> refcount 1 from first fence init
dma_fence_get -> refcount 2
dme_fence_put -> refcount 1
Fix:
Add put for external_hw_fence in amdgpu_job_free/free_cb
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 10aa073600d4..58568fdde2d0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -152,8 +152,10 @@ static void amdgpu_job_free_cb(struct drm_sched_job *s_job)
/* only put the hw fence if has embedded fence */
if (job->hw_fence.ops != NULL)
dma_fence_put(>hw_fence);
- else
+ else {
+ dma_fence_put(job->external_hw_fence);
kfree(job);
+ }
}
void amdgpu_job_free(struct amdgpu_job *job)
@@ -165,8 +167,10 @@ void amdgpu_job_free(struct amdgpu_job *job)
/* only put the hw fence if has embedded fence */
if (job->hw_fence.ops != NULL)
dma_fence_put(>hw_fence);
- else
+ else {
+ dma_fence_put(job->external_hw_fence);
kfree(job);
+ }
}
int amdgpu_job_submit(struct amdgpu_job *job, struct drm_sched_entity *entity,
--
2.25.1
[PATCH 0/5] Rework amdgpu HW fence refocunt and update scheduler parent fence refcount.
Yiqing raised a problem of negative fence refcount for resubmitted jobs in amdgpu and suggested a workaround in [1]. I took a look myself and discovered some deeper problems both in amdgpu and scheduler code. Yiqing helped with testing the new code and also drew a detailed refcount and flow tracing diagram for parent (HW) fence life cycle and refcount under various cases for the proposed patchset at [2]. [1] - https://lore.kernel.org/all/731b7ff1-3cc9-e314-df2a-7c51b76d4...@amd.com/t/#r00c728fcc069b1276642c325bfa9d82bf8fa21a3 [2] - https://drive.google.com/file/d/1yEoeW6OQC9WnwmzFW6NBLhFP_jD0xcHm/view?usp=sharing Andrey Grodzovsky (5): drm/amdgpu: Fix possible refcount leak for release of external_hw_fence drm/amdgpu: Add put fence in amdgpu_fence_driver_clear_job_fences drm/amdgpu: Prevent race between late signaled fences and GPU reset. drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer' drm/amdgpu: Follow up change to previous drm scheduler change. drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 27 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 37 -- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 12 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 + drivers/gpu/drm/scheduler/sched_main.c | 16 -- 6 files changed, 78 insertions(+), 17 deletions(-) -- 2.25.1
Using generic fbdev helpers breaks hibernation
Maybe someone more familiar with the generic drm fbdev helpers can help me understand why they don't work with hibernation, at least with AMD GPUs. We converted amdgpu to use the generic helpers instead of rolling our own in this patch[1], but it seems to have broken hibernation[2]. amdgpu has always set mode_config.prefer_shadow = 1, but that seems to be the cause of the hibernation breakage with the generic helpers. I've been staring at the code for a while now but I can't see why this fails. Any pointers? Thanks, Alex [1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=087451f372bf76d971184caa258807b7c35aac8f [2] - https://bugzilla.kernel.org/show_bug.cgi?id=216119
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On Sat, Jun 18, 2022 at 7:27 PM Guenter Roeck wrote:
>
> ppc:allmodconfig builds fail with the following error.
>
> powerpc64-linux-ld:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> uses hard float,
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> uses soft float
> powerpc64-linux-ld:
> failed to merge target specific data of file
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> powerpc64-linux-ld:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> uses hard float,
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> uses soft float
> powerpc64-linux-ld:
> failed to merge target specific data of
> file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> powerpc64-linux-ld:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> uses hard float,
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> uses soft float
> powerpc64-linux-ld:
> failed to merge target specific data of file
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
>
> The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> 64-bit outline-only KASAN support") which adds support for KASAN. This
> commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> compiled which lack the selection of hard-float.
>
> Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
> Cc: Michael Ellerman
> Cc: Daniel Axtens
> Signed-off-by: Guenter Roeck
> ---
> drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
> drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
> drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
> 3 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> index ec041e3cda30..74be02114ae4 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> @@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
> dcn31_init.o dcn31_hubp.o
> dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o
> \
> dcn31_afmt.o dcn31_vpg.o
>
> +ifdef CONFIG_PPC64
> +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
> +endif
This stuff was all moved as part of the FP rework in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26f4712aedbdf4b9f5e3888a50a2a4b130ee4a9b
@Siqueira, Rodrigo
, @Melissa Wen, @Dhillon, Jasdeep can you take a look to understand
why this is necessary? If we add back the PPC flags, I think we need
to add back the x86 ones as well.
Alex
> +
> AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
>
> AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> index 59381d24800b..1395c1ced8c5 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> @@ -25,6 +25,10 @@
>
> DCN315 = dcn315_resource.o
>
> +ifdef CONFIG_PPC64
> +CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
> +endif
> +
> AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
>
> AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> index 819d44a9439b..c3d2dd78f1e2 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> @@ -25,6 +25,10 @@
>
> DCN316 = dcn316_resource.o
>
> +ifdef CONFIG_PPC64
> +CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
> +endif
> +
> AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
>
> AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
> --
> 2.35.1
>
[PATCH v7 10/10] drm/i915: stolen memory use ttm backend
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +-
drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/intel_region_ttm.c | 42 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 8 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 12 +-
13 files changed, 303 insertions(+), 342 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8b807284cde1..6f3afac5e8c9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
* forcibly disable it to allow proper screen updates.
*/
+#include "gem/i915_gem_stolen.h"
#include
#include
@@ -51,6 +52,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
#define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS;
(__fbc_id)++) \
@@ -92,8 +94,8 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
- struct drm_mm_node compressed_fb;
- struct drm_mm_node compressed_llb;
+ struct ttm_resource *compressed_fb;
+ struct ttm_resource *compressed_llb;
enum intel_fbc_id id;
@@ -331,16 +333,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+ u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
intel_de_write(i915, FBC_CFB_BASE,
- i915->dsm.start + fbc->compressed_fb.start);
+ i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
- i915->dsm.start + fbc->compressed_llb.start);
+ i915->dsm.start + llb_offset);
}
static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -448,8 +454,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, DPFC_CB_BASE, fb_offset);
}
static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -499,8 +507,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
}
static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -744,21 +754,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
{
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
- int ret, limit = min_limit;
+ int limit = min_limit;
+ struct ttm_resource *res;
size /= limit;
/* Try to over-allocate to reduce reallocations and fragmentation. */
- ret = i915_gem_stolen_insert_node_in_range(i915, >compressed_fb,
- size <<= 1, 4096, 0, end);
- if (ret == 0)
+ res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+ if (!IS_ERR(res)) {
+ fbc->compressed_fb = res;
return limit;
+ }
for (; limit <=
[PATCH v7 05/10] drm/i915: instantiate ttm ranger manager for stolen memory
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++-
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 40249fa28a7a..675e9ab30396 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -60,11 +60,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
/* There's some room for optimization here... */
- GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
- ttm_mem_type < I915_PL_LMEM0);
+ GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
0);
+ if (ttm_mem_type == I915_PL_STOLEN)
+ return i915->mm.stolen_region;
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index fd2ecfdd8fa1..694e9acb69e2 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -54,7 +54,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private
*dev_priv)
/*
* Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
* memory and TTM_PL_TT for GGTT use if decided to implement this.
*/
int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -63,11 +63,17 @@ int intel_region_to_ttm_type(const struct
intel_memory_region *mem)
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
mem->type != INTEL_MEMORY_MOCK &&
- mem->type != INTEL_MEMORY_SYSTEM);
+ mem->type != INTEL_MEMORY_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_LOCAL);
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
+ if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+ return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
@@ -91,10 +97,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
- ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(>region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+ if (mem_type == I915_PL_STOLEN) {
+ ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(>region) >>
PAGE_SHIFT);
+ mem->is_range_manager = true;
+ } else {
+ ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(>region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+ }
if (ret)
return ret;
@@ -114,6 +126,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int intel_region_ttm_fini(struct intel_memory_region *mem)
{
struct ttm_resource_manager *man = mem->region_private;
+ int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
@@ -144,8 +157,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
- ret = i915_ttm_buddy_man_fini(>i915->bdev,
- intel_region_to_ttm_type(mem));
+ if (mem_type == I915_PL_STOLEN)
+ ret = ttm_range_man_fini(>i915->bdev, mem_type);
+ else
+ ret = i915_ttm_buddy_man_fini(>i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
--
2.25.1
[PATCH v7 07/10] drm/i915: ttm move/clear logic fix
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 81c67ca9edda..a3f8fc056dbc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/
+#include "drm/ttm/ttm_tt.h"
#include
#include "i915_deps.h"
@@ -476,6 +477,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
}
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct
ttm_resource *dst_mem)
+{
+ /* never clear stolen */
+ if (dst_mem->mem_type == I915_PL_STOLEN)
+ return false;
+ /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+ if (obj->flags & I915_BO_ALLOC_USER)
+ return true;
+
+ if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+ return true;
+
+ return false;
+}
+
/**
* i915_ttm_move - The TTM move callback used by i915.
* @bo: The buffer object.
@@ -526,7 +546,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm ||
!ttm_tt_is_populated(ttm));
- if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+ if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
i915_deps_init(, GFP_KERNEL | __GFP_NORETRY |
__GFP_NOWARN);
--
2.25.1
[PATCH v7 09/10] drm/i915/ttm: add buffer pin on alloc flag
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback options for stolen backend allocation like
create_ring_vma to work as expected.
Signed-off-by: Robert Beckett
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 13 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 25 ++-
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 6632ed52e919..07bc11247a3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -325,17 +325,20 @@ struct drm_i915_gem_object {
* dealing with userspace objects the CPU fault handler is free to ignore this.
*/
#define I915_BO_ALLOC_GPU_ONLY BIT(6)
+/* object should be pinned in destination region from allocation */
+#define I915_BO_ALLOC_PINNED BIT(7)
#define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
I915_BO_ALLOC_VOLATILE | \
I915_BO_ALLOC_CPU_CLEAR | \
I915_BO_ALLOC_USER | \
I915_BO_ALLOC_PM_VOLATILE | \
I915_BO_ALLOC_PM_EARLY | \
-I915_BO_ALLOC_GPU_ONLY)
-#define I915_BO_READONLY BIT(7)
-#define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED BIT(9)
-#define I915_BO_WAS_BOUND_BIT 10
+I915_BO_ALLOC_GPU_ONLY | \
+I915_BO_ALLOC_PINNED)
+#define I915_BO_READONLY BIT(8)
+#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED BIT(10)
+#define I915_BO_WAS_BOUND_BIT 11
/**
* @mem_flags - Mutable placement-related flags
*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27d59639177f..bb988608296d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -998,6 +998,13 @@ static void i915_ttm_delayed_free(struct
drm_i915_gem_object *obj)
{
GEM_BUG_ON(!obj->ttm.created);
+ /* stolen objects are pinned for lifetime. Unpin before putting */
+ if (obj->flags & I915_BO_ALLOC_PINNED) {
+ ttm_bo_reserve(i915_gem_to_ttm(obj), true, false, NULL);
+ ttm_bo_unpin(i915_gem_to_ttm(obj));
+ ttm_bo_unreserve(i915_gem_to_ttm(obj));
+ }
+
ttm_bo_put(i915_gem_to_ttm(obj));
}
@@ -1193,6 +1200,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+ struct ttm_place _place;
+ struct ttm_placement _placement;
+ struct ttm_placement *placement;
int ret;
drm_gem_private_object_init(>drm, >base, size);
@@ -1222,6 +1232,17 @@ int __i915_gem_ttm_object_init(struct
intel_memory_region *mem,
*/
i915_gem_object_make_unshrinkable(obj);
+ if (obj->flags & I915_BO_ALLOC_PINNED) {
+ i915_ttm_place_from_region(mem, &_place, obj->bo_offset,
+ obj->base.size, obj->flags);
+ _placement.num_placement = 1;
+ _placement.placement = &_place;
+ _placement.num_busy_placement = 0;
+ _placement.busy_placement = NULL;
+ placement = &_placement;
+ } else {
+ placement = _sys_placement;
+ }
/*
* If this function fails, it will call the destructor, but
* our caller still owns the object. So no freeing in the
@@ -1230,7 +1251,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
* until successful initialization.
*/
ret = ttm_bo_init_reserved(>bdev, i915_gem_to_ttm(obj), size,
- bo_type, _sys_placement,
+ bo_type, placement,
page_size >> PAGE_SHIFT,
, NULL, NULL, i915_ttm_bo_destroy);
if (ret)
@@ -1242,6 +1263,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
obj->ttm.cache_level_override = false;
+ if (obj->flags & I915_BO_ALLOC_PINNED)
+ ttm_bo_pin(i915_gem_to_ttm(obj));
i915_gem_object_unlock(obj);
return 0;
--
2.25.1
[PATCH v7 04/10] drm/i915/gem: selftest should not attempt mmap of private regions
During testing make can_mmap consider whether the region is private. Signed-off-by: Robert Beckett --- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index 5bc93a1ce3e3..76181e28c75e 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type type) struct drm_i915_private *i915 = to_i915(obj->base.dev); bool no_map; + if (obj->mm.region && obj->mm.region->private) + return false; + if (obj->ops->mmap_offset) return type == I915_MMAP_TYPE_FIXED; else if (type == I915_MMAP_TYPE_FIXED) -- 2.25.1
[PATCH v7 08/10] drm/i915: allow memory region creators to alloc and free the region
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index e38d2db1c3e3..3da07a712f90 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -231,7 +231,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
struct intel_memory_region *mem;
int err;
- mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (ops->alloc)
+ mem = ops->alloc();
+ else
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return ERR_PTR(-ENOMEM);
@@ -265,7 +268,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
if (mem->ops->release)
mem->ops->release(mem);
err_free:
- kfree(mem);
+ if (mem->ops->free)
+ mem->ops->free(mem);
+ else
+ kfree(mem);
return ERR_PTR(err);
}
@@ -288,7 +294,11 @@ void intel_memory_region_destroy(struct
intel_memory_region *mem)
GEM_WARN_ON(!list_empty_careful(>objects.list));
mutex_destroy(>objects.lock);
- if (!ret)
+ if (ret)
+ return;
+ if (mem->ops->free)
+ mem->ops->free(mem);
+ else
kfree(mem);
}
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 3d8378c1b447..048955b5429f 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -61,6 +61,8 @@ struct intel_memory_region_ops {
resource_size_t size,
resource_size_t page_size,
unsigned int flags);
+ struct intel_memory_region *(*alloc)(void);
+ void (*free)(struct intel_memory_region *mem);
};
struct intel_memory_region {
--
2.25.1
[PATCH v7 06/10] drm/i915: sanitize mem_flags for stolen buffers
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.
See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 675e9ab30396..81c67ca9edda 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -14,6 +14,7 @@
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_ttm.h"
#include "gem/i915_gem_ttm_move.h"
+#include "gem/i915_gem_stolen.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
@@ -124,8 +125,9 @@ void i915_ttm_adjust_gem_after_move(struct
drm_i915_gem_object *obj)
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
- obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ?
I915_BO_FLAG_IOMEM :
- I915_BO_FLAG_STRUCT_PAGE;
+ if (!i915_gem_object_is_stolen(obj))
+ obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ?
I915_BO_FLAG_IOMEM :
+ I915_BO_FLAG_STRUCT_PAGE;
if (!obj->ttm.cache_level_override) {
cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
--
2.25.1
[PATCH v7 02/10] drm/i915: limit ttm to dma32 for i965G[M]
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..fd2ecfdd8fa1 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
{
struct drm_device *drm = _priv->drm;
+ bool use_dma32 = false;
+
+ /* i965g[m] cannot relocate objects above 4GiB. */
+ if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+ use_dma32 = true;
return ttm_device_init(_priv->bdev, i915_ttm_driver(),
drm->dev, drm->anon_inode->i_mapping,
- drm->vma_offset_manager, false, false);
+ drm->vma_offset_manager, false, use_dma32);
}
/**
--
2.25.1
[PATCH v7 03/10] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
struct ttm_tt *ttm)
{
- return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+ bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+ return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
--
2.25.1
[PATCH v7 01/10] drm/i915/ttm: dont trample cache_level overrides during ttm move
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.
Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..519887769c08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
obj->cache_level = cache_level;
+ obj->ttm.cache_level_override = true;
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2c88bdb8ff7c..6632ed52e919 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -605,6 +605,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+ bool cache_level_override:1;
} ttm;
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..27d59639177f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1241,6 +1241,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+ obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..4c1de0b4a10f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -123,9 +123,12 @@ void i915_ttm_adjust_gem_after_move(struct
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ?
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
- cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
- bo->ttm);
- i915_gem_object_set_cache_coherency(obj, cache_level);
+ if (!obj->ttm.cache_level_override) {
+ cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+ bo->resource, bo->ttm);
+ i915_gem_object_set_cache_coherency(obj, cache_level);
+ obj->ttm.cache_level_override = false;
+ }
}
/**
--
2.25.1
[PATCH v7 00/10] drm/i915: ttm for stolen
This series refactors i915's stolen memory region to use ttm. v2: handle disabled stolen similar to legacy version. relying on ttm to fail allocs works fine, but is dmesg noisy and causes testing dmesg warning regressions. v3: rebase to latest drm-tip. fix v2 code refactor which could leave a buffer pinned. locally passes fftl again now. v4: - Allow memory regions creators to do allocation. Allows stolen region to track it's own reservations. - Pre-reserve first page of stolen mem (add back WaSkipStolenMemoryFirstPage:bdw+) - Improve commit descritpion for "drm/i915: sanitize mem_flags for stolen buffers" - replace i915_gem_object_pin_pages_unlocked() call with manual locking and pinning. this avoids ww ctx class reuse during context creation -> ring vma obj alloc. v5: - detect both types of stolen as stolen buffers in "drm/i915: sanitize mem_flags for stolen buffers" - in stolen_object_init limit page size to mem region minimum. The range allocator expects the page_size to define the alignment v6: - Share first 4 patches from ttm for internal series as generic i915 ttm fixes - Drop patch 4 from v5. We don't need separate object ops just to satisfy test interfaces. The tests have now been fixed via checking whether the memory region is private to decide whether to mmap - Add new buffer pin alloc flag to allow creation of buffers in their final ttm placement instead of deferring until get_pages. This fixes legacy fallback paths for buffer allocations during stolen memory pressure. v7: - fix mock_region_get_pages() to correctly handle I915_BO_INVALID_OFFSET Robert Beckett (10): drm/i915/ttm: dont trample cache_level overrides during ttm move drm/i915: limit ttm to dma32 for i965G[M] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level drm/i915/gem: selftest should not attempt mmap of private regions drm/i915: instantiate ttm ranger manager for stolen memory drm/i915: sanitize mem_flags for stolen buffers drm/i915: ttm move/clear logic fix drm/i915: allow memory region creators to alloc and free the region drm/i915/ttm: add buffer pin on alloc flag drm/i915: stolen memory use ttm backend drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++-- drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 16 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++--- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 29 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 47 +- .../drm/i915/gem/selftests/i915_gem_mman.c| 3 + drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +- drivers/gpu/drm/i915/i915_debugfs.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_memory_region.c| 16 +- drivers/gpu/drm/i915/intel_memory_region.h| 2 + drivers/gpu/drm/i915/intel_region_ttm.c | 80 +++- drivers/gpu/drm/i915/intel_region_ttm.h | 8 +- drivers/gpu/drm/i915/selftests/mock_region.c | 12 +- 18 files changed, 423 insertions(+), 369 deletions(-) -- 2.25.1
[PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
1 file changed, 51 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 41dc60784847..6499713eccf6 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
pm_runtime_disable(dev);
mdp_kms_destroy(_kms->base);
-
- kfree(mdp4_kms);
}
static const struct mdp_kms_funcs kms_funcs = {
@@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
{
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
- struct mdp4_kms *mdp4_kms;
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
struct msm_kms *kms = NULL;
struct iommu_domain *iommu;
struct msm_gem_address_space *aspace;
- int irq, ret;
+ int ret;
u32 major, minor;
unsigned long max_clk;
/* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */
max_clk = 27000;
- mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
- if (!mdp4_kms) {
- DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
- return -ENOMEM;
- }
-
ret = mdp_kms_init(_kms->base, _funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
goto fail;
}
- priv->kms = _kms->base.base;
kms = priv->kms;
mdp4_kms->dev = dev;
- mdp4_kms->mmio = msm_ioremap(pdev, NULL);
- if (IS_ERR(mdp4_kms->mmio)) {
- ret = PTR_ERR(mdp4_kms->mmio);
- goto fail;
- }
-
- irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
- goto fail;
- }
-
- kms->irq = irq;
-
- /* NOTE: driver for this regulator still missing upstream.. use
-* _get_exclusive() and ignore the error if it does not exist
-* (and hope that the bootloader left it on for us)
-*/
- mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
- if (IS_ERR(mdp4_kms->vdd))
- mdp4_kms->vdd = NULL;
-
if (mdp4_kms->vdd) {
ret = regulator_enable(mdp4_kms->vdd);
if (ret) {
@@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
}
}
- mdp4_kms->clk = devm_clk_get(>dev, "core_clk");
- if (IS_ERR(mdp4_kms->clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
- ret = PTR_ERR(mdp4_kms->clk);
- goto fail;
- }
-
- mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
- if (IS_ERR(mdp4_kms->pclk))
- mdp4_kms->pclk = NULL;
-
- mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
- if (IS_ERR(mdp4_kms->axi_clk)) {
- DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
- ret = PTR_ERR(mdp4_kms->axi_clk);
- goto fail;
- }
-
clk_set_rate(mdp4_kms->clk, max_clk);
read_mdp_hw_revision(mdp4_kms, , );
@@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
mdp4_kms->rev = minor;
if (mdp4_kms->rev >= 2) {
- mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
- if (IS_ERR(mdp4_kms->lut_clk)) {
+ if (!mdp4_kms->lut_clk) {
DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
- ret = PTR_ERR(mdp4_kms->lut_clk);
+ ret = -ENODEV;
goto fail;
}
clk_set_rate(mdp4_kms->lut_clk, max_clk);
@@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
static int mdp4_probe(struct platform_device *pdev)
{
- return msm_drv_probe(>dev, mdp4_kms_init, NULL);
+ struct device *dev = >dev;
+ struct mdp4_kms *mdp4_kms;
+ int irq;
+
+ mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
+ if (!mdp4_kms)
+ return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
+
+ mdp4_kms->mmio = msm_ioremap(pdev, NULL);
+ if (IS_ERR(mdp4_kms->mmio))
+ return PTR_ERR(mdp4_kms->mmio);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return dev_err_probe(dev, irq, "failed to get irq\n");
+
+ mdp4_kms->base.base.irq = irq;
+
+ /* NOTE: driver for
[PATCH v1 2/4] drm/msm/dpu: move resource allocation to the _probe function
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62 +
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae13a3a5d8a5..756be04d804b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1206,31 +1206,13 @@ static int dpu_kms_init(struct drm_device *ddev)
struct device *dev = ddev->dev;
struct platform_device *pdev = to_platform_device(dev);
struct dpu_kms *dpu_kms;
- int irq;
struct dev_pm_opp *opp;
int ret = 0;
unsigned long max_freq = ULONG_MAX;
- dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), GFP_KERNEL);
+ dpu_kms = to_dpu_kms(priv->kms);
if (!dpu_kms)
- return -ENOMEM;
-
- ret = devm_pm_opp_set_clkname(dev, "core");
- if (ret)
- return ret;
- /* OPP table is optional */
- ret = devm_pm_opp_of_add_table(dev);
- if (ret && ret != -ENODEV) {
- dev_err(dev, "invalid OPP table in device tree\n");
- return ret;
- }
-
- ret = devm_clk_bulk_get_all(>dev, _kms->clocks);
- if (ret < 0) {
- DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
- return ret;
- }
- dpu_kms->num_clocks = ret;
+ return -EINVAL;
opp = dev_pm_opp_find_freq_floor(dev, _freq);
if (!IS_ERR(opp))
@@ -1249,21 +1231,41 @@ static int dpu_kms_init(struct drm_device *ddev)
pm_runtime_enable(>dev);
dpu_kms->rpm_enabled = true;
- priv->kms = _kms->base;
-
- irq = irq_of_parse_and_map(dpu_kms->pdev->dev.of_node, 0);
- if (!irq) {
- DPU_ERROR("failed to get irq\n");
- return -EINVAL;
- }
- dpu_kms->base.irq = irq;
-
return 0;
}
static int dpu_dev_probe(struct platform_device *pdev)
{
- return msm_drv_probe(>dev, dpu_kms_init, NULL);
+ struct device *dev = >dev;
+ struct dpu_kms *dpu_kms;
+ int irq;
+ int ret = 0;
+
+ dpu_kms = devm_kzalloc(dev, sizeof(*dpu_kms), GFP_KERNEL);
+ if (!dpu_kms)
+ return -ENOMEM;
+
+ ret = devm_pm_opp_set_clkname(dev, "core");
+ if (ret)
+ return ret;
+ /* OPP table is optional */
+ ret = devm_pm_opp_of_add_table(dev);
+ if (ret && ret != -ENODEV)
+ return dev_err_probe(dev, ret, "invalid OPP table in device
tree\n");
+
+ ret = devm_clk_bulk_get_all(>dev, _kms->clocks);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to parse clocks\n");
+
+ dpu_kms->num_clocks = ret;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return dev_err_probe(dev, irq, "failed to get irq\n");
+
+ dpu_kms->base.irq = irq;
+
+ return msm_drv_probe(>dev, dpu_kms_init, _kms->base);
}
static int dpu_dev_remove(struct platform_device *pdev)
--
2.35.1
[PATCH v1 4/4] drm/msm/mdp5: move resource allocation to the _probe function
To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 97 +++-
1 file changed, 45 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index daf5b5ca7233..015388f262f4 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -556,17 +556,18 @@ static int mdp5_kms_init(struct drm_device *dev)
struct mdp5_cfg *config;
struct msm_kms *kms;
struct msm_gem_address_space *aspace;
- int irq, i, ret;
+ int i, ret;
struct device *iommu_dev;
- ret = mdp5_init(to_platform_device(dev->dev), dev);
-
/* priv->kms would have been populated by the MDP5 driver */
kms = priv->kms;
if (!kms)
return -ENOMEM;
mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+
+ ret = mdp5_init(to_platform_device(dev->dev), dev);
+
pdev = mdp5_kms->pdev;
ret = mdp_kms_init(_kms->base, _funcs);
@@ -575,15 +576,6 @@ static int mdp5_kms_init(struct drm_device *dev)
goto fail;
}
- irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- if (!irq) {
- ret = -EINVAL;
- DRM_DEV_ERROR(>dev, "failed to get irq\n");
- goto fail;
- }
-
- kms->irq = irq;
-
config = mdp5_cfg_get_config(mdp5_kms->cfg);
/* make sure things are off before attaching iommu (bootloader could
@@ -804,51 +796,17 @@ static int interface_init(struct mdp5_kms *mdp5_kms)
static int mdp5_init(struct platform_device *pdev, struct drm_device *dev)
{
struct msm_drm_private *priv = dev->dev_private;
- struct mdp5_kms *mdp5_kms;
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
struct mdp5_cfg *config;
u32 major, minor;
int ret;
- mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
- if (!mdp5_kms) {
- ret = -ENOMEM;
- goto fail;
- }
-
- spin_lock_init(_kms->resource_lock);
-
mdp5_kms->dev = dev;
- mdp5_kms->pdev = pdev;
ret = mdp5_global_obj_init(mdp5_kms);
if (ret)
goto fail;
- mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");
- if (IS_ERR(mdp5_kms->mmio)) {
- ret = PTR_ERR(mdp5_kms->mmio);
- goto fail;
- }
-
- /* mandatory clocks: */
- ret = get_clk(pdev, _kms->axi_clk, "bus", true);
- if (ret)
- goto fail;
- ret = get_clk(pdev, _kms->ahb_clk, "iface", true);
- if (ret)
- goto fail;
- ret = get_clk(pdev, _kms->core_clk, "core", true);
- if (ret)
- goto fail;
- ret = get_clk(pdev, _kms->vsync_clk, "vsync", true);
- if (ret)
- goto fail;
-
- /* optional clocks: */
- get_clk(pdev, _kms->lut_clk, "lut", false);
- get_clk(pdev, _kms->tbu_clk, "tbu", false);
- get_clk(pdev, _kms->tbu_rt_clk, "tbu_rt", false);
-
/* we need to set a default rate before enabling. Set a safe
* rate first, then figure out hw revision, and then set a
* more optimal rate:
@@ -906,9 +864,6 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
if (ret)
goto fail;
- /* set uninit-ed kms */
- priv->kms = _kms->base.base;
-
return 0;
fail:
if (mdp5_kms)
@@ -951,15 +906,53 @@ static int mdp5_setup_interconnect(struct platform_device
*pdev)
static int mdp5_dev_probe(struct platform_device *pdev)
{
- int ret;
+ struct mdp5_kms *mdp5_kms;
+ int ret, irq;
DBG("");
+ mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
+ if (!mdp5_kms)
+ return -ENOMEM;
+
ret = mdp5_setup_interconnect(pdev);
if (ret)
return ret;
- return msm_drv_probe(>dev, mdp5_kms_init, NULL);
+ mdp5_kms->pdev = pdev;
+
+ spin_lock_init(_kms->resource_lock);
+
+ mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");
+ if (IS_ERR(mdp5_kms->mmio))
+ return PTR_ERR(mdp5_kms->mmio);
+
+ /* mandatory clocks: */
+ ret = get_clk(pdev, _kms->axi_clk, "bus", true);
+ if (ret)
+ return ret;
+ ret = get_clk(pdev, _kms->ahb_clk, "iface", true);
+ if (ret)
+ return ret;
+ ret = get_clk(pdev, _kms->core_clk, "core", true);
+ if (ret)
+ return ret;
+ ret = get_clk(pdev, _kms->vsync_clk, "vsync", true);
+ if (ret)
+ return ret;
+
+ /* optional clocks: */
+ get_clk(pdev, _kms->lut_clk, "lut", false);
+ get_clk(pdev,
[PATCH v1 1/4] drm/msm/mdp5: stop overriding drvdata
The rest of the code expects that master's device drvdata is the
struct msm_drm_private instance. Do not override the mdp5's drvdata.
Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index c668a4b27cc6..daf5b5ca7233 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -203,7 +203,7 @@ static int mdp5_set_split_display(struct msm_kms *kms,
slave_encoder);
}
-static void mdp5_destroy(struct platform_device *pdev);
+static void mdp5_destroy(struct mdp5_kms *mdp5_kms);
static void mdp5_kms_destroy(struct msm_kms *kms)
{
@@ -223,7 +223,7 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
}
mdp_kms_destroy(_kms->base);
- mdp5_destroy(mdp5_kms->pdev);
+ mdp5_destroy(mdp5_kms);
}
#ifdef CONFIG_DEBUG_FS
@@ -651,9 +651,8 @@ static int mdp5_kms_init(struct drm_device *dev)
return ret;
}
-static void mdp5_destroy(struct platform_device *pdev)
+static void mdp5_destroy(struct mdp5_kms *mdp5_kms)
{
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
int i;
if (mdp5_kms->ctlm)
@@ -667,7 +666,7 @@ static void mdp5_destroy(struct platform_device *pdev)
kfree(mdp5_kms->intfs[i]);
if (mdp5_kms->rpm_enabled)
- pm_runtime_disable(>dev);
+ pm_runtime_disable(_kms->pdev->dev);
drm_atomic_private_obj_fini(_kms->glob_state);
drm_modeset_lock_fini(_kms->glob_state_lock);
@@ -816,8 +815,6 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
goto fail;
}
- platform_set_drvdata(pdev, mdp5_kms);
-
spin_lock_init(_kms->resource_lock);
mdp5_kms->dev = dev;
@@ -915,7 +912,7 @@ static int mdp5_init(struct platform_device *pdev, struct
drm_device *dev)
return 0;
fail:
if (mdp5_kms)
- mdp5_destroy(pdev);
+ mdp5_destroy(mdp5_kms);
return ret;
}
@@ -975,7 +972,8 @@ static int mdp5_dev_remove(struct platform_device *pdev)
static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
DBG("");
@@ -985,7 +983,8 @@ static __maybe_unused int mdp5_runtime_suspend(struct
device *dev)
static __maybe_unused int mdp5_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
- struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+ struct msm_drm_private *priv = platform_get_drvdata(pdev);
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
DBG("");
--
2.35.1
[PATCH v1 0/4] drm/msm: move resource allocation to the _probe function
As discussed several times on IRC, move display subdriver resource allocation from kms_init to probe time to let it bail early. The first patch fixes an issue with drvdata and is probably a -fixes material, but it is still included as a base for the rest of mdp5 changes. Dmitry Baryshkov (4): drm/msm/mdp5: stop overriding drvdata drm/msm/dpu: move resource allocation to the _probe function drm/msm/mdp4: move resource allocation to the _probe function drm/msm/mdp5: move resource allocation to the _probe function drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62 ++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 ++--- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 116 +++ 3 files changed, 137 insertions(+), 148 deletions(-) -- 2.35.1
Re: [PATCH v13 0/3] eDP/DP Phy vdda realted function
On 6/20/2022 1:07 PM, Kuogee Hsieh wrote: On 6/16/2022 5:02 PM, Vinod Koul wrote: On 25-05-22, 14:02, Kuogee Hsieh wrote: 1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy: qcom-edp: add regulator_set_load to edp phy phy: qcom-qmp: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 8 drivers/gpu/drm/msm/dp/dp_power.c | 95 + drivers/phy/qualcomm/phy-qcom-edp.c | 12 + drivers/phy/qualcomm/phy-qcom-qmp.c | 40 Please rebase this to phy-next and apply to specific qmp phy driver... I will rebase to ==> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git Hi Vinod, Would you please specify exactly procedures i have to do as to rebase this patch series to phy=next tree.
Re: [PATCH v14 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
On 20/06/2022 23:22, Kuogee Hsieh wrote: On 6/20/2022 1:15 PM, Dmitry Baryshkov wrote: On 20/06/2022 23:12, Kuogee Hsieh wrote: This patch add regulator_set_load() before enable regulator at DP phy driver. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson --- drivers/phy/qualcomm/phy-qcom-qmp.c | 40 - This was not rebased. There is no phy-qcom-qmp.c in phy-next. is https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git phy-next tree? Yes. The 'next' branch. The file in question was removed in the commit a50280ead1b6a56f3b4738808a8c2be7c2c63666 -- With best wishes Dmitry
Re: [PATCH v14 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
On 6/20/2022 1:15 PM, Dmitry Baryshkov wrote: On 20/06/2022 23:12, Kuogee Hsieh wrote: This patch add regulator_set_load() before enable regulator at DP phy driver. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson --- drivers/phy/qualcomm/phy-qcom-qmp.c | 40 - This was not rebased. There is no phy-qcom-qmp.c in phy-next. is https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git phy-next tree? What exactly procedures I have to do base on Vinod's comment? Thanks,
Re: [PATCH v14 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
On 20/06/2022 23:12, Kuogee Hsieh wrote: This patch add regulator_set_load() before enable regulator at DP phy driver. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Douglas Anderson --- drivers/phy/qualcomm/phy-qcom-qmp.c | 40 - This was not rebased. There is no phy-qcom-qmp.c in phy-next. -- With best wishes Dmitry
Re: [PATCH v14 1/3] phy: qcom-edp: add regulator_set_load to edp phy
On 20/06/2022 23:12, Kuogee Hsieh wrote: This patch add regulator_set_load() before enable regulator at eDP phy driver. Signed-off-by: Kuogee Hsieh Reviewed-by: Douglas Anderson Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH v14 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller
Vdda regulators are related to both eDP and DP phy so that it should be
managed at eDP and DP phy driver instead of controller. This patch removes
vdda regulators related functions out of eDP/DP controller.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/msm/dp/dp_parser.c | 14 --
drivers/gpu/drm/msm/dp/dp_parser.h | 8
drivers/gpu/drm/msm/dp/dp_power.c | 95 +-
3 files changed, 2 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c
b/drivers/gpu/drm/msm/dp/dp_parser.c
index 8f9fed9..4ef2130 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -22,14 +22,6 @@
#define DP_DEFAULT_P0_OFFSET 0x1000
#define DP_DEFAULT_P0_SIZE 0x0400
-static const struct dp_regulator_cfg sdm845_dp_reg_cfg = {
- .num = 2,
- .regs = {
- {"vdda-1p2", 21800, 4 },/* 1.2 V */
- {"vdda-0p9", 36000, 32 }, /* 0.9 V */
- },
-};
-
static void __iomem *dp_ioremap(struct platform_device *pdev, int idx, size_t
*len)
{
struct resource *res;
@@ -298,12 +290,6 @@ static int dp_parser_parse(struct dp_parser *parser)
if (rc)
return rc;
- /* Map the corresponding regulator information according to
-* version. Currently, since we only have one supported platform,
-* mapping the regulator directly.
-*/
- parser->regulator_cfg = _dp_reg_cfg;
-
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 3a4d797..47430e3 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -92,8 +92,6 @@ struct dp_pinctrl {
struct pinctrl_state *state_suspend;
};
-#define DP_DEV_REGULATOR_MAX 4
-
/* Regulators for DP devices */
struct dp_reg_entry {
char name[32];
@@ -101,11 +99,6 @@ struct dp_reg_entry {
int disable_load;
};
-struct dp_regulator_cfg {
- int num;
- struct dp_reg_entry regs[DP_DEV_REGULATOR_MAX];
-};
-
/**
* struct dp_parser - DP parser's data exposed to clients
*
@@ -121,7 +114,6 @@ struct dp_parser {
struct dp_pinctrl pinctrl;
struct dp_io io;
struct dp_display_data disp_data;
- const struct dp_regulator_cfg *regulator_cfg;
u32 max_dp_lanes;
struct drm_bridge *next_bridge;
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index d9e0117..b52ac1d 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -20,82 +20,10 @@ struct dp_power_private {
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
- struct regulator_bulk_data supplies[DP_DEV_REGULATOR_MAX];
struct dp_power dp_power;
};
-static void dp_power_regulator_disable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int i;
-
- DBG("");
- for (i = num - 1; i >= 0; i--)
- if (regs[i].disable_load >= 0)
- regulator_set_load(s[i].consumer,
- regs[i].disable_load);
-
- regulator_bulk_disable(num, s);
-}
-
-static int dp_power_regulator_enable(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- int num = power->parser->regulator_cfg->num;
- int ret, i;
-
- DBG("");
- for (i = 0; i < num; i++) {
- if (regs[i].enable_load >= 0) {
- ret = regulator_set_load(s[i].consumer,
-regs[i].enable_load);
- if (ret < 0) {
- pr_err("regulator %d set op mode failed, %d\n",
- i, ret);
- goto fail;
- }
- }
- }
-
- ret = regulator_bulk_enable(num, s);
- if (ret < 0) {
- pr_err("regulator enable failed, %d\n", ret);
- goto fail;
- }
-
- return 0;
-
-fail:
- for (i--; i >= 0; i--)
- regulator_set_load(s[i].consumer, regs[i].disable_load);
- return ret;
-}
-
-static int dp_power_regulator_init(struct dp_power_private *power)
-{
- struct regulator_bulk_data *s = power->supplies;
- const struct dp_reg_entry *regs = power->parser->regulator_cfg->regs;
- struct platform_device *pdev = power->pdev;
- int num = power->parser->regulator_cfg->num;
- int i, ret;
-
- for (i = 0; i < num; i++)
-
[PATCH v14 2/3] phy: qcom-qmp: add regulator_set_load to dp phy
This patch add regulator_set_load() before enable regulator at
DP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 40 -
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index c7309e981..e5836ea 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -3119,6 +3119,17 @@ static const struct qmp_phy_init_tbl
sm8450_qmp_gen4x2_pcie_pcs_misc_tbl[] = {
QMP_PHY_INIT_CFG(QPHY_V5_20_PCS_PCIE_G4_PRE_GAIN, 0x2e),
};
+/* list of regulators */
+struct qmp_regulator_data {
+ const char *name;
+ unsigned int enable_load;
+};
+
+struct qmp_regulator_data qmp_phy_vreg_l[] = {
+ { .name = "vdda-phy", .enable_load = 21800 },
+ { .name = "vdda-pll", .enable_load = 36000 },
+};
+
struct qmp_phy;
/* struct qmp_phy_cfg - per-PHY initialization config */
@@ -3173,7 +3184,7 @@ struct qmp_phy_cfg {
const char * const *reset_list;
int num_resets;
/* regulators to be requested */
- const char * const *vreg_list;
+ const struct qmp_regulator_data *vreg_list;
int num_vregs;
/* array of registers with different offsets */
@@ -3385,11 +3396,6 @@ static const char * const sdm845_pciephy_reset_l[] = {
"phy",
};
-/* list of regulators */
-static const char * const qmp_phy_vreg_l[] = {
- "vdda-phy", "vdda-pll",
-};
-
static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
.type = PHY_TYPE_USB3,
.nlanes = 1,
@@ -5561,16 +5567,32 @@ static int qcom_qmp_phy_vreg_init(struct device *dev,
const struct qmp_phy_cfg *
{
struct qcom_qmp *qmp = dev_get_drvdata(dev);
int num = cfg->num_vregs;
- int i;
+ int ret, i;
qmp->vregs = devm_kcalloc(dev, num, sizeof(*qmp->vregs), GFP_KERNEL);
if (!qmp->vregs)
return -ENOMEM;
for (i = 0; i < num; i++)
- qmp->vregs[i].supply = cfg->vreg_list[i];
+ qmp->vregs[i].supply = cfg->vreg_list[i].name;
- return devm_regulator_bulk_get(dev, num, qmp->vregs);
+ ret = devm_regulator_bulk_get(dev, num, qmp->vregs);
+ if (ret) {
+ dev_err(dev, "failed at devm_regulator_bulk_get\n");
+ return ret;
+ }
+
+ for (i = 0; i < num; i++) {
+ ret = regulator_set_load(qmp->vregs[i].consumer,
+cfg->vreg_list[i].enable_load);
+ if (ret) {
+ dev_err(dev, "failed to set load at %s\n",
+ qmp->vregs[i].supply);
+ return ret;
+ }
+ }
+
+ return 0;
}
static int qcom_qmp_phy_reset_init(struct device *dev, const struct
qmp_phy_cfg *cfg)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v14 1/3] phy: qcom-edp: add regulator_set_load to edp phy
This patch add regulator_set_load() before enable regulator at
eDP phy driver.
Signed-off-by: Kuogee Hsieh
Reviewed-by: Douglas Anderson
---
drivers/phy/qualcomm/phy-qcom-edp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
b/drivers/phy/qualcomm/phy-qcom-edp.c
index cacd32f..7e357078 100644
--- a/drivers/phy/qualcomm/phy-qcom-edp.c
+++ b/drivers/phy/qualcomm/phy-qcom-edp.c
@@ -639,6 +639,18 @@ static int qcom_edp_phy_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = regulator_set_load(edp->supplies[0].consumer, 21800); /* 1.2 V
vdda-phy */
+ if (ret) {
+ dev_err(dev, "failed to set load at %s\n",
edp->supplies[0].supply);
+ return ret;
+ }
+
+ ret = regulator_set_load(edp->supplies[1].consumer, 36000); /* 0.9 V
vdda-pll */
+ if (ret) {
+ dev_err(dev, "failed to set load at %s\n",
edp->supplies[1].supply);
+ return ret;
+ }
+
ret = qcom_edp_clks_register(edp, pdev->dev.of_node);
if (ret)
return ret;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v14 0/3] eDP/DP Phy vdda realted function
0) rebase on https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tree 1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy: qcom-edp: add regulator_set_load to edp phy phy: qcom-qmp: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 8 drivers/gpu/drm/msm/dp/dp_power.c | 95 + drivers/phy/qualcomm/phy-qcom-edp.c | 12 + drivers/phy/qualcomm/phy-qcom-qmp.c | 40 5 files changed, 45 insertions(+), 124 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] drm/bridge: ti-sn65dsi83: add more dev_err_probe
On Tue, 14 Jun 2022 at 11:58, Alexander Stein wrote: > > Add more warning/debug messages during probe. E.g. a single -EPROBE_DEFER > might have several causes, these messages help finding the origin. > > Signed-off-by: Alexander Stein > --- > * New in v2 > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > index b27c0d7c451a..a306150a8027 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c > @@ -677,7 +677,7 @@ static int sn65dsi83_probe(struct i2c_client *client, > ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable", >GPIOD_OUT_LOW); > if (IS_ERR(ctx->enable_gpio)) > - return PTR_ERR(ctx->enable_gpio); > + return dev_err_probe(dev, PTR_ERR(ctx->enable_gpio), "failed > to get enable GPIO\n"); > > usleep_range(1, 11000); > > @@ -687,7 +687,7 @@ static int sn65dsi83_probe(struct i2c_client *client, > > ctx->regmap = devm_regmap_init_i2c(client, _regmap_config); > if (IS_ERR(ctx->regmap)) > - return PTR_ERR(ctx->regmap); > + return dev_err_probe(dev, PTR_ERR(ctx->regmap), "failed to > get regmap\n"); > > dev_set_drvdata(dev, ctx); > i2c_set_clientdata(client, ctx); > -- > 2.25.1 > Reviewed & applied series to drm-misc-next. Reviewed-by: Robert Foss
Re: [PATCH v13 0/3] eDP/DP Phy vdda realted function
On 6/16/2022 5:02 PM, Vinod Koul wrote: On 25-05-22, 14:02, Kuogee Hsieh wrote: 1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy: qcom-edp: add regulator_set_load to edp phy phy: qcom-qmp: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 8 drivers/gpu/drm/msm/dp/dp_power.c | 95 + drivers/phy/qualcomm/phy-qcom-edp.c | 12 + drivers/phy/qualcomm/phy-qcom-qmp.c | 40 Please rebase this to phy-next and apply to specific qmp phy driver... I will rebase to ==> https://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git
Re: [PATCH 0/2] Fixes for TC358775 DSI to LVDS bridge
On Thu, 16 Jun 2022 at 00:25, Jiri Vanek wrote: > > This patchset fixes two bugs in the driver for TC358775 DSI to LVDS bridge. > > Jiri Vanek (2): > drm/bridge/tc358775: Return before displaying inappropriate error > message > drm/bridge/tc358775: Fix DSI clock division for vsync delay > calculation > > drivers/gpu/drm/bridge/tc358775.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Applied to drm-misc-next.
Re: (subset) [PATCH 1/2] dt-bindings: leds: qcom-wled: fix number of addresses
On Thu, 5 May 2022 17:47:01 +0200, Krzysztof Kozlowski wrote: > On PM660L, PMI8994 and PMI8998, the WLED has two address spaces. This > also fixes dtbs_check warnings like: > > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dtb: leds@d800: reg: > [[55296], [2]] is too long > > Applied, thanks! [1/2] dt-bindings: leds: qcom-wled: fix number of addresses https://git.kernel.org/krzk/linux-dt/c/ba52039325826b3f2bddd00972f3f61fbe7d9f0e Best regards, -- Krzysztof Kozlowski
Re: [PATCH v9 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs
On Thu, 16 Jun 2022 at 13:18, Sakari Ailus wrote: > > On Sat, Jun 11, 2022 at 10:14:07PM +0800, Liu Ying wrote: > > Patch 1/14 and 2/14 add bus formats used by pixel combiner. > > Thanks! > > For these: > > Acked-by: Sakari Ailus Applied to drm-misc-next.
Re: [PATCH v2 4/4] drm/bridge: anx7625: Use DPI bus type
On Fri, 17 Jun 2022 at 12:32, Chen-Yu Tsai wrote:
>
> Hi,
>
> On Mon, May 23, 2022 at 4:37 PM Robert Foss wrote:
> >
> > On Mon, 23 May 2022 at 09:18, Chen-Yu Tsai wrote:
> > >
> > > On Mon, May 23, 2022 at 11:13 AM Xin Ji wrote:
> > > >
> > > > On Sat, May 21, 2022 at 06:28:42PM +0200, Daniel Vetter wrote:
> > > > > On Sat, 21 May 2022 at 18:07, Daniel Vetter wrote:
> > > > > >
> > > > > > On Tue, 17 May 2022 at 18:09, Robert Foss
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, 25 Apr 2022 at 11:14, Xin Ji
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, Apr 25, 2022 at 04:24:50PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On Fri, Apr 22, 2022 at 10:13 PM Robert Foss
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, 22 Apr 2022 at 16:01, Robert Foss
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 22 Apr 2022 at 10:49, Xin Ji
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > As V4L2_FWNODE_BUS_TYPE_PARALLEL not properly descript
> > > > > > > > > > > > for DPI
> > > > > > > > > > > > interface, this patch use new defined
> > > > > > > > > > > > V4L2_FWNODE_BUS_TYPE_DPI for it.
> > > > > > > > > > > >
> > > > > > > > > > > > Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI
> > > > > > > > > > > > input feature")
> > > > > > > > > > > > Signed-off-by: Xin Ji
> > > > > > > > > > > > ---
> > > > > > > > > > > > drivers/gpu/drm/bridge/analogix/anx7625.c | 8
> > > > > > > > > > > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > > index 376da01243a3..71df977e8f53 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > > @@ -1623,14 +1623,14 @@ static int
> > > > > > > > > > > > anx7625_parse_dt(struct device *dev,
> > > > > > > > > > > >
> > > > > > > > > > > > anx7625_get_swing_setting(dev, pdata);
> > > > > > > > > > > >
> > > > > > > > > > > > - pdata->is_dpi = 1; /* default dpi mode */
> > > > > > > > > > > > + pdata->is_dpi = 0; /* default dsi mode */
> > > > > > > > > > > > pdata->mipi_host_node =
> > > > > > > > > > > > of_graph_get_remote_node(np, 0, 0);
> > > > > > > > > > > > if (!pdata->mipi_host_node) {
> > > > > > > > > > > > DRM_DEV_ERROR(dev, "fail to get
> > > > > > > > > > > > internal panel.\n");
> > > > > > > > > > > > return -ENODEV;
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > - bus_type = V4L2_FWNODE_BUS_TYPE_PARALLEL;
> > > > > > > > > > > > + bus_type = 0;
> > > > > > > > > > > > mipi_lanes = MAX_LANES_SUPPORT;
> > > > > > > > > > > > ep0 = of_graph_get_endpoint_by_regs(np, 0, 0);
> > > > > > > > > > > > if (ep0) {
> > > > > > > > > > > > @@ -1640,8 +1640,8 @@ static int
> > > > > > > > > > > > anx7625_parse_dt(struct device *dev,
> > > > > > > > > > > > mipi_lanes =
> > > > > > > > > > > > of_property_count_u32_elems(ep0, "data-lanes");
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > - if (bus_type == V4L2_FWNODE_BUS_TYPE_PARALLEL)
> > > > > > > > > > > > /* bus type is Parallel(DSI) */
> > > > > > > > > > > > - pdata->is_dpi = 0;
> > > > > > > > > > > > + if (bus_type == V4L2_FWNODE_BUS_TYPE_DPI) /*
> > > > > > > > > > > > bus type is DPI */
> > > > > > > > > > > > + pdata->is_dpi = 1;
> > > > > > > > > > > >
> > > > > > > > > > > > pdata->mipi_lanes = mipi_lanes;
> > > > > > > > > > > > if (pdata->mipi_lanes > MAX_LANES_SUPPORT ||
> > > > > > > > > > > > pdata->mipi_lanes <= 0)
> > > > > > > > > > >
> > > > > > > > > > > Reviewed-by: Robert Foss
> > > > > > > > > >
> > > > > > > > > > Acked-by: Robert Foss
> > > > > > > > >
> > > > > > > > > Tested-by: Chen-Yu Tsai
> > > > > > > > >
> > > > > > > > > Confirmed this fixes the display on Juniper (Acer Chromebook
> > > > > > > > > Spin 311) on
> > > > > > > > > mainline (next-20220422).
> > > > > > > > >
> > > > > > > > > Xin, in the future, please send the whole series to all
> > > > > > > > > recipients of
> > > > > > > > > all patches listed by get_maintainers.pl, not just the
> > > > > > > > > recipients of
> > > > > > > > > each patch. In the case of this series, they should have been
> > > > > > > > > sent
> > > > > > > > > to all of the mailing lists (media, devicetree, dri-devel) so
> > > > > > > > > that
> > > > > > > > > everyone has the same, full view of the patches.
> > > > > > > > Hi ChenYu, OK, I'll send to all media, devicetree, dri-devel
> > > > > > > > next time.
> > > > > > > > Thanks,
> > > > > > > > Xin
> > > > > > >
Re: [PATCH 09/64] drm/simple: Introduce drmm_simple_encoder_init
Hi Am 20.06.22 um 16:45 schrieb Thomas Zimmermann: Hi Am 20.06.22 um 16:39 schrieb Maxime Ripard: On Mon, Jun 20, 2022 at 04:25:38PM +0200, Thomas Zimmermann wrote: Hi Am 20.06.22 um 15:48 schrieb Maxime Ripard: Hi, On Mon, Jun 20, 2022 at 12:44:24PM +0200, Thomas Zimmermann wrote: Am 10.06.22 um 11:28 schrieb Maxime Ripard: The DRM-managed function to register an encoder is drmm_simple_encoder_alloc() and its variants, which will allocate the underlying structure and initialisation the encoder. However, we might want to separate the structure creation and the encoder initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise an encoder that would be passed as an argument. There's nothing wrong with this patch, but I have to admit that adding drm_simple_encoder_init() et al was a mistake. Why do you think it was a mistake? The simple-encoder stuff is an interface that no one really needs. Compared to open-coding the function, it's barely an improvement in LOCs, but nothing else. Back when I added drm_simple_encoder_init(), I wanted to simplify the many drivers that initialized the encoder with a cleanup callback and nothing else. IIRC it was an improvement back then. But now we already have a related drmm_ helper and a drmm_alloc_ helper. If I had only added the macro back then, we could use the regular encoder helpers. It would have been better to add an initializer macro like #define DRM_STATIC_ENCODER_DEFAULT_FUNCS \ .destroy = drm_encoder_cleanup It's way more flexible and similarly easy to use. Anyway... We can still have this. It would simplify this series so I could definitely squeeze that patch in and add a TODO item / deprecation notice for simple encoders if you think it's needed Not necessary. It's not super important. The corollary is though :) If I understand you right, it means that you'd rather have a destroy callback everywhere instead of calling the _cleanup function through a drm-managed callback, and let drm_dev_unregister do its job? If so, it means that we shouldn't be following the drmm_.*_alloc functions and should drop all the new ones from this series. No, no. What I'm saying is that simple-encoder is a pointless mid-layer. There's nothing that couldn't easily be achieved with the regular encoder functions. I guess that if you want to change something here, you could add drmm_encoder_init() instead and convert vc4. That function might be more useful for other drivers in the long run. Best regards Thomas Best regards Thomas Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH v2 2/2] arm64: dts: qcom: sm8250: Enable per-process page tables.
This is an SMMU for the adreno gpu, and adding this compatible lets
the driver use per-fd page tables, which are required for security
between GPU clients.
Signed-off-by: Emma Anholt
Reviewed-by: Dmitry Baryshkov
---
v2: moved qcom,adreno-smmu earlier
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index a92230bec1dd..aae7b841b81a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -2513,7 +2513,7 @@ gpucc: clock-controller@3d9 {
};
adreno_smmu: iommu@3da {
- compatible = "qcom,sm8250-smmu-500", "arm,mmu-500";
+ compatible = "qcom,sm8250-smmu-500",
"qcom,adreno-smmu", "arm,mmu-500";
reg = <0 0x03da 0 0x1>;
#iommu-cells = <2>;
#global-interrupts = <2>;
--
2.36.1
[PATCH v2 1/2] iommu: arm-smmu-impl: Add 8250 display compatible to the client list.
Required for turning on per-process page tables for the GPU.
Signed-off-by: Emma Anholt
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d8e1ef83c01b..bb9220937068 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -233,6 +233,7 @@ static const struct of_device_id
qcom_smmu_client_of_match[] __maybe_unused = {
{ .compatible = "qcom,sc7280-mdss" },
{ .compatible = "qcom,sc7280-mss-pil" },
{ .compatible = "qcom,sc8180x-mdss" },
+ { .compatible = "qcom,sm8250-mdss" },
{ .compatible = "qcom,sdm845-mdss" },
{ .compatible = "qcom,sdm845-mss-pil" },
{ }
--
2.36.1
[PATCH v2 0/2] per-process page tables for qcom 8250
This enable per-process page tables on the Qualcomm RB5 boards I'm setting up for Mesa CI. Has survived a full deqp-vk run. v2: moved qcom,adreno-smmu compatible earlier Emma Anholt (2): iommu: arm-smmu-impl: Add 8250 display compatible to the client list. arm64: dts: qcom: sm8250: Enable per-process page tables. arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.36.1
Re: [PATCH v2 07/15] Documentation: ABI: testing: mt6370: Add ADC sysfs guideline
On Mon, 20 Jun 2022 14:00:43 +0800 ChiaEn Wu wrote: > Hi Jonathan, > > Thanks for your helpful comments, and I have some questions want to > ask you below. > > Jonathan Cameron 於 2022年6月18日 週六 晚上11:39寫道： > > > > On Mon, 13 Jun 2022 19:11:38 +0800 > > ChiaEn Wu wrote: > > > > > From: ChiaEn Wu > > > > > > Add ABI documentation for mt6370 non-standard ADC sysfs interfaces. > > > > > > Signed-off-by: ChiaEn Wu > > > --- > > > .../ABI/testing/sysfs-bus-iio-adc-mt6370 | 36 +++ > > > 1 file changed, 36 insertions(+) > > > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > new file mode 100644 > > > index ..039b3381176a > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 > > > @@ -0,0 +1,36 @@ > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw > > > > Unfortunately the kernel documentation build scripts do no support > > duplicating > > standard ABI for particular devices so as to provide more information. > > Hence you can't have anything in this file. > > > > I want to confirm with you again, > because my ABI file duplicates with standard sysfs-bus-iio (voltage, > current, and temperature channels), > Should I just remove this ABI file and modify the code of mt6370-adc > to meet your expectations?? yes. > > > > > > +KernelVersion: 5.18 > > > +Contact: chiaen...@richtek.com > > > +Description: > > > + Indicated MT6370 VBUS ADC with lower accuracy(+-75mA) > > Curious though, voltage with a mA accuracy range? > > Yes, this description is based on the data sheet. Weird :) > > > This scale should be presented directly to userspace anyway so no need > > for this doc. > > > > > + higher measure range(1~22V) > > > + Calculating with scale returns voltage in uV > > > > No. All channels return in mV. That's the ABI requirement as > > in sysfs-bus-iio and we cannot vary if for particular drivers. If we did > > no generic tooling would work. > > Ok, I got it! > > > > > > + > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw > > > +KernelVersion: 5.18 > > > +Contact: chiaen...@richtek.com > > > +Description: > > > + Indicated MT6370 VBUS ADC with higher accuracy(+-30mA) > > > + lower measure range(1~9.76V) > > > + Calculating with scale offset returns voltage in uV > > > + > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage4_raw > > > +KernelVersion: 5.18 > > > +Contact: chiaen...@richtek.com > > > +Description: > > > + Indicated MT6370 TS_BAT ADC > > > + Calculating with scale returns voltage in uV > > > + > > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage7_raw > > > +KernelVersion: 5.18 > > > +Contact: chiaen...@richtek.com > > > +Description: > > > + Indicated MT6370 CHG_VDDP ADC > > > + Calculating with scale returns voltage in mV > > > + > > > +What:/sys/bus/iio/devices/iio:deviceX/in_temp8_raw > > > +KernelVersion: 5.18 > > > +Contact: chiaen...@richtek.com > > > +Description: > > > + Indicated MT6370 IC junction temperature > > > + Calculating with scale and offset returns temperature in > > > degree > > Shall I modify the scale of temperature to milli degrees in > mt6370-adc.c and remove this item?? yes. Thanks, Jonathan > > > > > Best regards, > ChiaEn Wu
Re: [PATCH] fbdev: simplefb: Check before clk_put() not needed
On 6/2/22 12:50, Hans de Goede wrote:
> Hi,
>
> On 6/2/22 11:42, Yihao Han wrote:
>> clk_put() already checks the clk ptr using !clk and IS_ERR()
>> so there is no need to check it again before calling it.
>>
>> Signed-off-by: Yihao Han
>> ---
>> drivers/video/fbdev/simplefb.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
>> index 2c198561c338..f96ce8801be4 100644
>> --- a/drivers/video/fbdev/simplefb.c
>> +++ b/drivers/video/fbdev/simplefb.c
>> @@ -237,8 +237,7 @@ static int simplefb_clocks_get(struct simplefb_par *par,
>> if (IS_ERR(clock)) {
>> if (PTR_ERR(clock) == -EPROBE_DEFER) {
>> while (--i >= 0) {
>> -if (par->clks[i])
>> -clk_put(par->clks[i]);
>> +clk_put(par->clks[i]);
>> }
>> kfree(par->clks);
>> return -EPROBE_DEFER;
>
> Thanks, patch looks good to me:
>
> Reviewed-by: Hans de Goede
applied to fbdev tree.
Thanks!
Helge
Re: [PATCH] video: fbdev: au1100fb: Check before some function not needed
On 6/8/22 13:43, Yihao Han wrote: > clk_disable() already checks the clk ptr using IS_ERR_OR_NULL(clk) > and clk_enable() checks the clk ptr using !clk, so there is no > need to check clk ptr again before calling them. > > Signed-off-by: Yihao Han applied to fbdev tree. Thanks! Helge > --- > drivers/video/fbdev/au1100fb.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/video/fbdev/au1100fb.c b/drivers/video/fbdev/au1100fb.c > index 52f731a61482..519313b8bb00 100644 > --- a/drivers/video/fbdev/au1100fb.c > +++ b/drivers/video/fbdev/au1100fb.c > @@ -560,8 +560,7 @@ int au1100fb_drv_suspend(struct platform_device *dev, > pm_message_t state) > /* Blank the LCD */ > au1100fb_fb_blank(VESA_POWERDOWN, >info); > > - if (fbdev->lcdclk) > - clk_disable(fbdev->lcdclk); > + clk_disable(fbdev->lcdclk); > > memcpy(, fbdev->regs, sizeof(struct au1100fb_regs)); > > @@ -577,8 +576,7 @@ int au1100fb_drv_resume(struct platform_device *dev) > > memcpy(fbdev->regs, , sizeof(struct au1100fb_regs)); > > - if (fbdev->lcdclk) > - clk_enable(fbdev->lcdclk); > + clk_enable(fbdev->lcdclk); > > /* Unblank the LCD */ > au1100fb_fb_blank(VESA_NO_BLANKING, >info);
Re: [PATCH 1/4] video: fbdev: offb: Include missing linux/platform_device.h
On 6/11/22 18:50, Christophe Leroy wrote:
> A lot of drivers were getting platform and of headers
> indirectly via headers like asm/pci.h or asm/prom.h
>
> Most of them were fixed during 5.19 cycle but a newissue was
> introduced by commit 52b1b46c39ae ("of: Create platform devices
> for OF framebuffers")
>
> Include missing platform_device.h to allow cleaning asm/pci.h
>
> Cc: Thomas Zimmermann
> Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers")
> Signed-off-by: Christophe Leroy
Acked-by: Helge Deller
I assume you take this through the linuxppc git tree?
Helge
> ---
> drivers/video/fbdev/offb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
> index b1acb1ebebe9..91001990e351 100644
> --- a/drivers/video/fbdev/offb.c
> +++ b/drivers/video/fbdev/offb.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #ifdef CONFIG_PPC32
[PATCH v2] drm/sun4i: Add DMA mask and segment size
Kernel occasionally complains that there is mismatch in segment size
when trying to render HW decoded videos and rendering them directly with
sun4i DRM driver. Following message can be observed on H6 SoC:
[ 184.298308] [ cut here ]
[ 184.298326] DMA-API: sun4i-drm display-engine: mapping sg segment longer
than device claims to support [len=6144000] [max=65536]
[ 184.298364] WARNING: CPU: 1 PID: 382 at kernel/dma/debug.c:1162
debug_dma_map_sg+0x2b0/0x350
[ 184.322997] CPU: 1 PID: 382 Comm: ffmpeg Not tainted 5.19.0-rc1+ #1331
[ 184.329533] Hardware name: Tanix TX6 (DT)
[ 184.333544] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 184.340512] pc : debug_dma_map_sg+0x2b0/0x350
[ 184.344882] lr : debug_dma_map_sg+0x2b0/0x350
[ 184.349250] sp : 89f33a50
[ 184.352567] x29: 89f33a50 x28: 0001 x27: 01b86c00
[ 184.359725] x26: x25: 05d8cc80 x24:
[ 184.366879] x23: 8939ab18 x22: 0001 x21: 0001
[ 184.374031] x20: x19: 018a7410 x18:
[ 184.381186] x17: x16: x15:
[ 184.388338] x14: 0001 x13: 89534e86 x12: 6f70707573206f74
[ 184.395493] x11: 20736d69616c6320 x10: 000a x9 : 0001
[ 184.402647] x8 : 893b6d40 x7 : 89f33850 x6 : 000c
[ 184.409800] x5 : bf997940 x4 : x3 : 0027
[ 184.416953] x2 : x1 : x0 : 03960e80
[ 184.424106] Call trace:
[ 184.426556] debug_dma_map_sg+0x2b0/0x350
[ 184.430580] __dma_map_sg_attrs+0xa0/0x110
[ 184.434687] dma_map_sgtable+0x28/0x4c
[ 184.438447] vb2_dc_dmabuf_ops_map+0x60/0xcc
[ 184.442729] __map_dma_buf+0x2c/0xd4
[ 184.446321] dma_buf_map_attachment+0xa0/0x130
[ 184.450777] drm_gem_prime_import_dev+0x7c/0x18c
[ 184.455410] drm_gem_prime_fd_to_handle+0x1b8/0x214
[ 184.460300] drm_prime_fd_to_handle_ioctl+0x2c/0x40
[ 184.465190] drm_ioctl_kernel+0xc4/0x174
[ 184.469123] drm_ioctl+0x204/0x420
[ 184.472534] __arm64_sys_ioctl+0xac/0xf0
[ 184.476474] invoke_syscall+0x48/0x114
[ 184.480240] el0_svc_common.constprop.0+0x44/0xec
[ 184.484956] do_el0_svc+0x2c/0xc0
[ 184.488283] el0_svc+0x2c/0x84
[ 184.491354] el0t_64_sync_handler+0x11c/0x150
[ 184.495723] el0t_64_sync+0x18c/0x190
[ 184.499397] ---[ end trace ]---
Fix that by setting DMA mask and segment size.
Signed-off-by: Jernej Skrabec
---
Changes from v1:
- added comment
- updated commit message with kernel report
drivers/gpu/drm/sun4i/sun4i_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 275f7e4a03ae..f135a6b3cadb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -367,6 +368,13 @@ static int sun4i_drv_probe(struct platform_device *pdev)
INIT_KFIFO(list.fifo);
+ /*
+* DE2 and DE3 cores actually supports 40-bit addresses, but
+* driver does not.
+*/
+ dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
+ dma_set_max_seg_size(>dev, DMA_BIT_MASK(32));
+
for (i = 0;; i++) {
struct device_node *pipeline = of_parse_phandle(np,
"allwinner,pipelines",
--
2.36.1
[pull] drm/msm: drm-msm-fixes-2022-06-20 for v5.19-rc4
Hi Dave, Here are fixes for v5.19, summary below (and in tag msg) The following changes since commit 24df12013853ac59c52cc726e9cbe51e38d09eda: MAINTAINERS: Add Dmitry as MSM DRM driver co-maintainer (2022-05-07 12:02:29 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2022-06-20 for you to fetch changes up to a6e2af64a79afa7f1b29375b5231e840a84bb845: drm/msm/dp: force link training for display resolution change (2022-06-18 09:14:06 -0700) Fixes for v5.19-rc4 - Workaround for parade DSI bridge power sequencing - Fix for multi-planar YUV format offsets - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was being hit frequently in CI. - Fix to add minimum ICC vote in the msm_mdss pm_resume path to address bootup splats - Fix to avoid dereferencing without checking in WB encoder - Fix to avoid crash during suspend in DP driver by ensuring interrupt mask bits are updated - Remove unused code from dpu_encoder_virt_atomic_check() - Fix to remove redundant init of dsc variable - Fix to ensure mmap offset is initialized to avoid memory corruption from unpin/evict - Fix double runpm disable in probe-defer path - VMA fenced-unpin fixes - Fix for WB max-width - Fix for rare dp resolution change issue Abhinav Kumar (4): drm/msm/dpu: limit writeback modes according to max_linewidth drm/msm/dpu: add DRM_MODE_ROTATE_180 back to supported rotations drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path drm/msm/dpu: limit wb modes based on max_mixer_width Dmitry Baryshkov (1): drm/msm: don't free the IRQ if it was not requested Douglas Anderson (2): drm/msm/dsi: don't powerup at modeset time for parade-ps8640 drm/msm/dpu: Move min BW request and full BW disable back to mdss Hangyu Hua (1): drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() Haowen Bai (1): drm/msm/dpu: Fix pointer dereferenced before checking Jiapeng Chong (1): drm/msm/dpu: Remove unused code Jonathan Marek (1): drm/msm: use for_each_sgtable_sg to iterate over scatterlist Kuogee Hsieh (3): drm/msm/dp: Always clear mask bits to disable interrupts at dp_ctrl_reset_irq_ctrl() drm/msm/dp: check core_initialized before disable interrupts at dp_display_unbind() drm/msm/dp: force link training for display resolution change Maximilian Luz (1): drm/msm: Fix double pm_runtime_disable() call Miaoqian Lin (2): drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf Rob Clark (9): drm/msm: Fix fb plane offset calculation Merge tag 'msm-next-5.19-fixes' of https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging Merge tag 'msm-next-5.19-fixes-06-01' of https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging drm/msm: Ensure mmap offset is initialized drm/msm: Switch ordering of runpm put vs devfreq_idle drm/msm/gem: Separate object and vma unpin drm/msm/gem: Drop early returns in close/purge vma drm/msm: Drop update_fences() drm/msm: Don't overwrite hw fence in hw_init Vinod Koul (1): drm/msm/disp/dpu1: remove superfluous init drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 1 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 14 -- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 3 -- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 12 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 13 - drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 42 drivers/gpu/drm/msm/dp/dp_ctrl.h | 2 +- drivers/gpu/drm/msm/dp/dp_display.c| 16 +++--- drivers/gpu/drm/msm/dsi/dsi_manager.c | 32 +++- drivers/gpu/drm/msm/msm_drv.c | 9 +++- drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_fb.c | 2 +- drivers/gpu/drm/msm/msm_fence.c| 8 +-- drivers/gpu/drm/msm/msm_gem.c | 7 ++- drivers/gpu/drm/msm/msm_gem.h | 11 +++-- drivers/gpu/drm/msm/msm_gem_prime.c| 15 ++ drivers/gpu/drm/msm/msm_gem_submit.c | 18 --- drivers/gpu/drm/msm/msm_gem_vma.c | 6 +-- drivers/gpu/drm/msm/msm_gpu.c
Re: [Intel-gfx] [PATCH v2 1/3] drm/doc/rfc: VM_BIND feature design document
On Mon, Jun 20, 2022 at 11:43:10AM +0100, Tvrtko Ursulin wrote: Hi, On 17/06/2022 06:14, Niranjana Vishwanathapura wrote: VM_BIND design document with description of intended use cases. v2: Reduce the scope to simple Mesa use case. since I expressed interest please add me to cc when sending out. Hi Tvrtko, I did include you in the cc list with git send-email, but looks like some patches in this series has the full cc list, but some don't (you are on cc list of this patch though). I am not sure why. How come the direction changed to simplify all of a sudden? I did not spot any discussion to that effect. Was it internal talks? Yah, some of us had offline discussion involving the Mesa team. I did update the thread (previous version of this patch series) about that. Plan was to align our roadmap to focus on the deliverables at this point without further complicating the uapi. Signed-off-by: Niranjana Vishwanathapura --- Documentation/gpu/rfc/i915_vm_bind.rst | 238 + Documentation/gpu/rfc/index.rst| 4 + 2 files changed, 242 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..4ab590ef11fd --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,238 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuf calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuf mode). + +The VM_BIND/UNBIND calls allow UMDs to request a timeline fence for signaling +the completion of bind/unbind operation. + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +Normally, vm_bind/unbind operations will get completed synchronously, To me synchronously, at this point in the text, reads as ioctl will return only when the operation is done. Rest of the paragraph however disagrees (plus existence of out fence). It is not clear to me what is the actual behaviour. Will it be clear to userspace developers reading uapi kerneldoc? If it is async, what are the ordering rules in this version? Yah, here I am simply stating the i915_vma_pin_ww() behavior which mostly does the binding synchronously unless there is a moving fence associated with the object in which case, binding will complete later once that fence is signaled (hence the out fence). +but if the object is being moved, the binding will happen once that the +moving is complete and out fence will be signaled after binding is complete. +The bind/unbind operation can get completed out of submission order. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuf ioctl in VM_BIND mode +--- +A VM in VM_BIND mode will not support older execbuf mode of binding. +The execbuf ioctl handling in VM_BIND mode differs significantly from the +older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2). +Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See +struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any +execlist. Hence, no support for implicit sync. It is expected that the below +work will be able to support requirements of object dependency setting in all +use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) What does this mean? If execbuf3 does not know about target objects how can we add a meaningful fence? Execbuf3 does know about the target objects. It is all the objects bound to that VM via vm_bind call. + +The execbuf3 ioctl directly specifies the batch addresses instead of as +object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not +support many of the older features like in/out/submit fences, fence array, +default gem context and many more (See struct drm_i915_gem_execbuffer3). + +In VM_BIND mode, VA allocation is completely managed by the user instead of +the
Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate
On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote: > Hi Jani, > > On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote: >> On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote: >> > Hi Jani, >> > >> > Do you plan to merge this revert? >> >> Yes, I've done that now, thanks for the bisection and the patch. > > Thanks! > > I see that this went into `drm-intel-next`, but shouldn't it go into > `drm-intel-fixes`, so that it makes it into 5.19-rc4? All of our commits go to drm-intel-next first. I'll pick it up for fixes later. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate
Hi Jani, On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote: > On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote: > > Hi Jani, > > > > Do you plan to merge this revert? > > Yes, I've done that now, thanks for the bisection and the patch. Thanks! I see that this went into `drm-intel-next`, but shouldn't it go into `drm-intel-fixes`, so that it makes it into 5.19-rc4? Jason
Re: [Intel-gfx] [PATCH] drm/i915/display: Re-add check for low voltage sku for max dp source rate
On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote: > Hi Jani, > > Do you plan to merge this revert? Yes, I've done that now, thanks for the bisection and the patch. Ankit, Imre, we need to figure out what to do with [1] now. BR, Jani. [1] https://gitlab.freedesktop.org/drm/intel/-/issues/5272 -- Jani Nikula, Intel Open Source Graphics Center
[PATCH v4 3/3] drm/doc: Add KUnit documentation
Explain how to run the KUnit tests present in the DRM subsystem and clarify why the UML-only options were not added to the configuration file present in drivers/gpu/drm/.kunitconfig [1] [2]. [1] https://lore.kernel.org/dri-devel/CABVgOSn8i=lo5p7830h2xu1jgg0krn0qtnxkomhf1otgxja...@mail.gmail.com/ [2] https://lore.kernel.org/dri-devel/CAGS_qxqpiCim_sy1LDK7PLwVgWf-LKW+uNFTGM=t7ydk-dy...@mail.gmail.com/ Reviewed-by: Maxime Ripard Reviewed-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Signed-off-by: José Expósito --- Documentation/gpu/drm-internals.rst | 32 + 1 file changed, 32 insertions(+) diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 38afed24a75c..5fd20a306718 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -207,6 +207,38 @@ Utilities :internal: +Unit testing + + +KUnit +- + +KUnit (Kernel unit testing framework) provides a common framework for unit tests +within the Linux kernel. + +This section covers the specifics for the DRM subsystem. For general information +about KUnit, please refer to Documentation/dev-tools/kunit/start.rst. + +How to run the tests? +~ + +In order to facilitate running the test suite, a configuration file is present +in ``drivers/gpu/drm/tests/.kunitconfig``. It can be used by ``kunit.py`` as +follows: + +.. code-block:: bash + + $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \ + --kconfig_add CONFIG_VIRTIO_UML=y \ + --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y + +.. note:: + The configuration included in ``.kunitconfig`` should be as generic as + possible. + ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not + included in it because they are only required for User Mode Linux. + + Legacy Support Code === -- 2.25.1
[PATCH v4 2/3] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Test the conversion from XRGB to RGB332.
What is tested?
- Different values for the X in XRGB to make sure it is ignored
- Different clip values: Single pixel and full and partial buffer
- Well known colors: White, black, red, green, blue, magenta, yellow
and cyan
- Other colors: Randomly picked
- Destination pitch
How to run the tests?
$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \
--kconfig_add CONFIG_VIRTIO_UML=y \
--kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
Suggested-by: Javier Martinez Canillas
Reviewed-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Signed-off-by: José Expósito
---
drivers/gpu/drm/Kconfig | 16 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/tests/.kunitconfig| 3 +
drivers/gpu/drm/tests/Makefile| 3 +
.../gpu/drm/tests/drm_format_helper_test.c| 161 ++
5 files changed, 184 insertions(+)
create mode 100644 drivers/gpu/drm/tests/.kunitconfig
create mode 100644 drivers/gpu/drm/tests/Makefile
create mode 100644 drivers/gpu/drm/tests/drm_format_helper_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 22e7fa48d693..6c2256e8474b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -70,6 +70,22 @@ config DRM_DEBUG_SELFTEST
If in doubt, say "N".
+config DRM_KUNIT_TEST
+ tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS
+ depends on DRM && KUNIT=y
+ select DRM_KMS_HELPER
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for DRM. This option is not useful for
+ distributions or general kernels, but only for kernel
+ developers working on DRM and associated drivers.
+
+ For more information on KUnit and unit tests in general,
+ please refer to the KUnit documentation in
+ Documentation/dev-tools/kunit/.
+
+ If in doubt, say "N".
+
config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 13ef240b3d2b..db8ffcf4e048 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
#
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
+obj-$(CONFIG_DRM_KUNIT_TEST) += tests/
obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
diff --git a/drivers/gpu/drm/tests/.kunitconfig
b/drivers/gpu/drm/tests/.kunitconfig
new file mode 100644
index ..6ec04b4c979d
--- /dev/null
+++ b/drivers/gpu/drm/tests/.kunitconfig
@@ -0,0 +1,3 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_KUNIT_TEST=y
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
new file mode 100644
index ..2c8273796d9d
--- /dev/null
+++ b/drivers/gpu/drm/tests/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
new file mode 100644
index ..98583bf56044
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../drm_crtc_internal.h"
+
+#define TEST_BUF_SIZE 50
+
+struct xrgb_to_rgb332_case {
+ const char *name;
+ unsigned int pitch;
+ unsigned int dst_pitch;
+ struct drm_rect clip;
+ const u32 xrgb[TEST_BUF_SIZE];
+ const u8 expected[4 * TEST_BUF_SIZE];
+};
+
+static struct xrgb_to_rgb332_case xrgb_to_rgb332_cases[] = {
+ {
+ .name = "single_pixel_source_buffer",
+ .pitch = 1 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(0, 0, 1, 1),
+ .xrgb = { 0x01FF },
+ .expected = { 0xE0 },
+ },
+ {
+ .name = "single_pixel_clip_rectangle",
+ .pitch = 2 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(1, 1, 1, 1),
+ .xrgb = {
+ 0x, 0x,
+ 0x, 0x10FF,
+ },
+ .expected = { 0xE0 },
+ },
+ {
+ /* Well known colors: White, black, red, green, blue, magenta,
+* yellow and cyan. Different values for the X in XRGB to
+* make sure it is ignored. Partial clip area.
+*/
+ .name = "well_known_colors",
+ .pitch = 4 * 4,
+ .dst_pitch = 0,
+ .clip = DRM_RECT_INIT(1, 1, 2, 4),
+ .xrgb = {
+ 0x, 0x, 0x, 0x,
+
[PATCH v4 1/3] drm/rect: Add DRM_RECT_INIT() macro
Add a helper macro to initialize a rectangle from x, y, width and
height information.
Reviewed-by: Jani Nikula
Acked-by: Thomas Zimmermann
Signed-off-by: José Expósito
---
include/drm/drm_rect.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6f6e19bd4dac..e8d94fca2703 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -47,6 +47,22 @@ struct drm_rect {
int x1, y1, x2, y2;
};
+/**
+ * DRM_RECT_INIT - initialize a rectangle from x/y/w/h
+ * @x: x coordinate
+ * @y: y coordinate
+ * @w: width
+ * @h: height
+ *
+ * RETURNS:
+ * A new rectangle of the specified size.
+ */
+#define DRM_RECT_INIT(x, y, w, h) ((struct drm_rect){ \
+ .x1 = (x), \
+ .y1 = (y), \
+ .x2 = (x) + (w), \
+ .y2 = (y) + (h) })
+
/**
* DRM_RECT_FMT - printf string for drm_rect
*/
--
2.25.1
[PATCH v4 0/3] KUnit tests for drm_format_helper
Hello everyone, Following the style used in the selftest to KUnit series [1] and the AMD series [2], the tests were moved to the "tests" folder. In addition, to be consistent naming functions, I renamed the kunit_suite and the test cases to use underscores as suggested in [3]. It is not clear yet whether we want to have one or multiple Kconfig symbols and select which test should be built. However, refactoring from one approach to the other is quite simple, so I think we should be fine choosing the simpler option now and refactoring if required. Thanks a lot, José Expósito [1] https://lore.kernel.org/dri-devel/20220615135824.15522-1-maira.ca...@usp.br/T/ [2] https://lore.kernel.org/dri-devel/20220608010709.272962-1-maira.ca...@usp.br/ [3] https://www.kernel.org/doc/html/latest/dev-tools/kunit/style.html RFC -> v1: https://lore.kernel.org/dri-devel/20220530102017.471865-1-jose.exposit...@gmail.com/T/ - Add .kunitconfig (Maxime Ripard) - Fix memory leak (Daniel Latypov) - Make config option generic (Javier Martinez Canillas): DRM_FORMAR_HELPER_TEST -> DRM_KUNIT_TEST - Remove DISABLE_STRUCTLEAK_PLUGIN (Daniel Latypov) v1 -> v2: https://lore.kernel.org/dri-devel/20220606095516.938934-1-jose.exposit...@gmail.com/T/ Thomas Zimmermann: - Add DRM_RECT_INIT() macro - Move tests to drivers/gpu/drm/kunit - Improve test documentation v2 -> v3: https://lore.kernel.org/dri-devel/20220612161248.271590-1-jose.exposit...@gmail.com/T/ - Use designated initializer in DRM_RECT_INIT (Jani Nikula) - Simplify the "conversion_buf_size" helper v3 -> v4: https://lore.kernel.org/dri-devel/20220616183852.GA12343@elementary/T/ - Move the source to the "tests" folder - Use "_" in kunit_suite and cases: https://www.kernel.org/doc/html/latest/dev-tools/kunit/style.html - Reviewed-by and Acked-by tags José Expósito (3): drm/rect: Add DRM_RECT_INIT() macro drm/format-helper: Add KUnit tests for drm_fb_xrgb_to_rgb332() drm/doc: Add KUnit documentation Documentation/gpu/drm-internals.rst | 32 drivers/gpu/drm/Kconfig | 16 ++ drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/tests/.kunitconfig| 3 + drivers/gpu/drm/tests/Makefile| 3 + .../gpu/drm/tests/drm_format_helper_test.c| 161 ++ include/drm/drm_rect.h| 16 ++ 7 files changed, 232 insertions(+) create mode 100644 drivers/gpu/drm/tests/.kunitconfig create mode 100644 drivers/gpu/drm/tests/Makefile create mode 100644 drivers/gpu/drm/tests/drm_format_helper_test.c -- 2.25.1
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction
On 20.06.2022 14:36, Thomas Hellström wrote:
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
mutex_unlock(vma->vm->mutex);
__i915_vm_release();
release_references();
And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.
However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().
v2: Fix a typo in the commit message (Andi Shyti)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")
Cc: Niranjana Vishwanathapura
Cc: Matthew Auld
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)
+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+ bool vm_ddestroy)
{
struct drm_i915_gem_object *obj = vma->obj;
- struct intel_gt *gt = vma->vm->gt;
GEM_BUG_ON(i915_vma_is_active(vma));
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
force_unbind(vma);
list_del_init(>vm_link);
- release_references(vma, false);
+ release_references(vma, vma->vm->gt, false);
}
void i915_vma_destroy(struct i915_vma *vma)
{
+ struct intel_gt *gt;
bool vm_ddestroy;
mutex_lock(>vm->mutex);
@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(>vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
mutex_unlock(>vm->mutex);
- release_references(vma, vm_ddestroy);
+ release_references(vma, gt, vm_ddestroy);
Reviewed-by: Andrzej Hajda
Regards
Andrzej
}
void i915_vma_parked(struct intel_gt *gt)
Re: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
On Mon, Jun 20, 2022 at 07:42:25AM -0700, Zeng, Oak wrote:
Thanks,
Oak
-Original Message-
From: Vishwanathapura, Niranjana
Sent: June 17, 2022 1:15 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Vetter,
Daniel
Cc: Hellstrom, Thomas ; Wilson, Chris P
; ja...@jlekstrand.net;
christian.koe...@amd.com; Brost, Matthew ;
Ursulin, Tvrtko ; Auld, Matthew
; Landwerlin, Lionel G
; Zanoni, Paulo R
; Zeng, Oak
Subject: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 226
+++
1 file changed, 226 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..b7540ddb526d
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,226 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * The older execbuf2 ioctl will not support VM_BIND mode of operation.
+ * For VM_BIND mode, we have new execbuf3 ioctl which will not accept
any
+ * execlist (See struct drm_i915_gem_execbuffer3 for more details).
+ *
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_EXECBUFFER3 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND,
struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_EXECBUFFER3
DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+
+/**
+ * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
+ *
+ * A timeline out fence for vm_bind/unbind completion notification.
+ */
+struct drm_i915_gem_vm_bind_fence {
+ /** @handle: User's handle for a drm_syncobj to signal. */
+ __u32 handle;
+
+ /** @rsvd: Reserved, MBZ */
+ __u32 rsvd;
+
+ /**
+ * @value: A point in the timeline.
+ * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
+ * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+ * binary one.
+ */
+ __u64 value;
+};
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of
GPU
+ * virtual address (VA) range to the section of an object that should be
bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ *
+ * The @start, @offset and @length should be 4K page aligned. However
the DG2
+ * and XEHPSDV has 64K page size for device local-memory and has compact
page
+ * table. On those platforms, for binding device local-memory objects, the
+ * @start should be 2M aligned, @offset and @length should be 64K aligned.
+ * Also, on those platforms, it is not allowed to bind an device local-memory
+ * object and a system memory object in a single 2M section of VA range.
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+ * @flags: Supported flags are:
+ *
+ * I915_GEM_VM_BIND_READONLY:
+ * Mapping is read-only.
+ *
+ * I915_GEM_VM_BIND_CAPTURE:
+ * Capture this mapping in the dump upon GPU error.
+ */
+ __u64 flags;
+#define I915_GEM_VM_BIND_READONLY(1 << 0)
Should we define another flag for DEVICE_ATOMIC? Without this flag, do you
imply all the mapping support device atomic operation?
HW platform also has an implication to device atomic, i.e., some platform don't
support device atomics to system memory.
Thanks Oak, we can always add required flags later when we want to add the
support.
Niranjana
Regards,
Oak
+#define I915_GEM_VM_BIND_CAPTURE (1 << 1)
+
+ /** @fence:
Re: [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy
On Sun, Jun 19, 2022 at 11:32:07PM -0700, Christoph Hellwig wrote: > > This helps because we now block io memory from ever getting into these > > call paths. I'm pretty sure this is a serious security bug, but would > > let the IBM folks remark as I don't know it all that well.. > > Prevent as in crash when trying to convert it to a page? That or when calling memcpy() on an IO memory PFN that the guest passed into the dma s/g list the ccw driver is processing. Jason
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker drivers should:
>
> 1. Implement new evict() shmem object callback.
> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
>activate shrinking of shmem GEMs.
>
> This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem_shmem_helper.h| 87 ++-
> 5 files changed, 594 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 555fe212bd98..4cd0b5913492 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -126,6 +126,42 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + return (shmem->madv >= 0) && shmem->evict &&
> + shmem->eviction_enabled && shmem->pages_use_count &&
> + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> + !shmem->base.import_attach && shmem->sgt && !shmem->evicted;
> +}
> +
> +static void
> +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = >base;
> + struct drm_gem_shmem_shrinker *gem_shrinker =
> obj->dev->shmem_shrinker;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + if (!gem_shrinker || obj->import_attach)
> + return;
> +
> + mutex_lock(_shrinker->lock);
> +
> + if (drm_gem_shmem_is_evictable(shmem) ||
> + drm_gem_shmem_is_purgeable(shmem))
> + list_move_tail(>madv_list,
> _shrinker->lru_evictable);
> + else if (shmem->madv < 0)
> + list_del_init(>madv_list);
> + else if (shmem->evicted)
> + list_move_tail(>madv_list, _shrinker->lru_evicted);
> + else if (!shmem->pages)
> + list_del_init(>madv_list);
> + else
> + list_move_tail(>madv_list, _shrinker->lru_pinned);
> +
> + mutex_unlock(_shrinker->lock);
> +}
> +
> /**
> * drm_gem_shmem_free - Free resources associated with a shmem GEM object
> * @shmem: shmem GEM object to free
> @@ -142,6 +178,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> } else {
> dma_resv_lock(shmem->base.resv, NULL);
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, -1);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (shmem->sgt) {
> @@ -150,7 +189,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> - if (shmem->pages)
> + if (shmem->pages_use_count)
> drm_gem_shmem_put_pages(shmem);
>
> WARN_ON(shmem->pages_use_count);
> @@ -163,18 +202,82 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> -static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +/**
> + * drm_gem_shmem_set_evictable() - Make GEM evictable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be evicted. Initially eviction is
> + * disabled for all GEMs. If GEM was purged, then -ENOMEM is returned.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + dma_resv_lock(shmem->base.resv, NULL);
> +
> + if (shmem->madv < 0)
> + return -ENOMEM;
> +
> + shmem->eviction_enabled = true;
> +
> + dma_resv_unlock(shmem->base.resv);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_set_evictable);
> +
> +/**
> + * drm_gem_shmem_set_purgeable() - Make GEM purgeable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be purged. Initially purging is
> + * disabled for all GEMs. If GEM was purged, then -ENOMEM is returned.
> + *
>
Re: [RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for vfio_pin_pages()
On Sun, Jun 19, 2022 at 11:37:47PM -0700, Christoph Hellwig wrote: > On Sun, Jun 19, 2022 at 10:51:47PM -0700, Christoph Hellwig wrote: > > On Mon, Jun 20, 2022 at 12:00:46AM -0300, Jason Gunthorpe wrote: > > > On Fri, Jun 17, 2022 at 01:54:05AM -0700, Christoph Hellwig wrote: > > > > There is a bunch of code an comments in the iommu type1 code that > > > > suggest we can pin memory that is not page backed. > > > > > > AFAIK you can.. The whole follow_pte() mechanism allows raw PFNs to be > > > loaded into the type1 maps and the pin API will happily return > > > them. This happens in almost every qemu scenario because PCI MMIO BAR > > > memory ends up routed down this path. > > > > Indeed, my read wasn't deep enough. Which means that we can't change > > the ->pin_pages interface to return a struct pages array, as we don't > > have one for those. > > Actually. gvt requires a struct page, and both s390 seem to require > normal non-I/O, non-remapped kernel pointers. So I think for the > vfio_pin_pages we can assume that we only want page backed memory and > remove the follow_fault_pfn case entirely. But we'll probably have > to keep it for the vfio_iommu_replay case that is not tied to > emulated IOMMU drivers. Right, that is my thinking - since all drivers actually need a struct page we should have the API return a working struct page and have the VFIO layer isolate the non-struct page stuff so it never leaks out of this API. This nicely fixes the various problems in all the drivers if io memory comes down this path. It is also why doing too much surgery deeper into type 1 probably isn't too worthwhile as it still needs raw pfns in its data structures for iommu modes. Thanks, Jason
Re: [PATCH 1/3] drm/msm/dp: Reorganize code to avoid forward declaration
On 6/17/2022 3:50 PM, Dmitry Baryshkov wrote:
On 17/06/2022 23:47, Stephen Boyd wrote:
Let's move these functions around to avoid having to forward declare
dp_ctrl_on_stream_phy_test_report(). Also remove
dp_ctrl_reinitialize_mainlink() forward declaration because we're doing
that sort of task.
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 104 +++
1 file changed, 50 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 703249384e7c..bd445e683cfc 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1238,8 +1238,6 @@ static int dp_ctrl_link_train_2(struct
dp_ctrl_private *ctrl,
return -ETIMEDOUT;
}
-static int dp_ctrl_reinitialize_mainlink(struct dp_ctrl_private
*ctrl);
-
static int dp_ctrl_link_train(struct dp_ctrl_private *ctrl,
int *training_step)
{
@@ -1534,38 +1532,6 @@ static int dp_ctrl_link_maintenance(struct
dp_ctrl_private *ctrl)
return ret;
}
-static int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl
*dp_ctrl);
-
-static int dp_ctrl_process_phy_test_request(struct dp_ctrl_private
*ctrl)
-{
- int ret = 0;
-
- if (!ctrl->link->phy_params.phy_test_pattern_sel) {
- drm_dbg_dp(ctrl->drm_dev,
- "no test pattern selected by sink\n");
- return ret;
- }
-
- /*
- * The global reset will need DP link related clocks to be
- * running. Add the global reset just before disabling the
- * link clocks and core clocks.
- */
- ret = dp_ctrl_off(>dp_ctrl);
- if (ret) {
- DRM_ERROR("failed to disable DP controller\n");
- return ret;
- }
-
- ret = dp_ctrl_on_link(>dp_ctrl);
- if (!ret)
- ret = dp_ctrl_on_stream_phy_test_report(>dp_ctrl);
- else
- DRM_ERROR("failed to enable DP link controller\n");
-
- return ret;
-}
-
static bool dp_ctrl_send_phy_test_pattern(struct dp_ctrl_private
*ctrl)
{
bool success = false;
@@ -1618,6 +1584,56 @@ static bool
dp_ctrl_send_phy_test_pattern(struct dp_ctrl_private *ctrl)
return success;
}
+static int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
+{
+ int ret;
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ ctrl->dp_ctrl.pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
+
+ ret = dp_ctrl_enable_stream_clocks(ctrl);
+ if (ret) {
+ DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
+ return ret;
+ }
+
+ dp_ctrl_send_phy_test_pattern(ctrl);
+
+ return 0;
+}
+
+static int dp_ctrl_process_phy_test_request(struct dp_ctrl_private
*ctrl)
+{
+ int ret = 0;
+
+ if (!ctrl->link->phy_params.phy_test_pattern_sel) {
+ drm_dbg_dp(ctrl->drm_dev,
+ "no test pattern selected by sink\n");
+ return ret;
+ }
+
+ /*
+ * The global reset will need DP link related clocks to be
+ * running. Add the global reset just before disabling the
+ * link clocks and core clocks.
+ */
+ ret = dp_ctrl_off(>dp_ctrl);
+ if (ret) {
+ DRM_ERROR("failed to disable DP controller\n");
+ return ret;
+ }
+
+ ret = dp_ctrl_on_link(>dp_ctrl);
+ if (!ret)
+ ret = dp_ctrl_on_stream_phy_test_report(>dp_ctrl);
+ else
+ DRM_ERROR("failed to enable DP link controller\n");
+
+ return ret;
+}
+
void dp_ctrl_handle_sink_request(struct dp_ctrl *dp_ctrl)
{
struct dp_ctrl_private *ctrl;
@@ -1815,26 +1831,6 @@ static int dp_ctrl_link_retrain(struct
dp_ctrl_private *ctrl)
return dp_ctrl_setup_main_link(ctrl, _step);
}
-static int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
-{
- int ret;
- struct dp_ctrl_private *ctrl;
-
- ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
-
- ctrl->dp_ctrl.pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
-
- ret = dp_ctrl_enable_stream_clocks(ctrl);
- if (ret) {
- DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
- return ret;
- }
-
- dp_ctrl_send_phy_test_pattern(ctrl);
-
- return 0;
-}
-
int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool force_link_train)
{
int ret = 0;
Re: [PATCH 3/3] drm/msm/dp: Get rid of dp_ctrl_on_stream_phy_test_report()
On 6/17/2022 1:47 PM, Stephen Boyd wrote:
This API isn't really more than a couple lines now that we don't store
the pixel_rate to the struct member. Inline it into the caller.
Cc: Kuogee Hsieh
Signed-off-by: Stephen Boyd
Reviewed-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 40
1 file changed, 15 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index e114521af2e9..d04fddb29fdf 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1582,34 +1582,15 @@ static bool dp_ctrl_send_phy_test_pattern(struct
dp_ctrl_private *ctrl)
return success;
}
-static int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
+static int dp_ctrl_process_phy_test_request(struct dp_ctrl_private *ctrl)
{
int ret;
- struct dp_ctrl_private *ctrl;
unsigned long pixel_rate;
- ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
-
- pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
- ret = dp_ctrl_enable_stream_clocks(ctrl, pixel_rate);
- if (ret) {
- DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
- return ret;
- }
-
- dp_ctrl_send_phy_test_pattern(ctrl);
-
- return 0;
-}
-
-static int dp_ctrl_process_phy_test_request(struct dp_ctrl_private *ctrl)
-{
- int ret = 0;
-
if (!ctrl->link->phy_params.phy_test_pattern_sel) {
drm_dbg_dp(ctrl->drm_dev,
"no test pattern selected by sink\n");
- return ret;
+ return 0;
}
/*
@@ -1624,12 +1605,21 @@ static int dp_ctrl_process_phy_test_request(struct
dp_ctrl_private *ctrl)
}
ret = dp_ctrl_on_link(>dp_ctrl);
- if (!ret)
- ret = dp_ctrl_on_stream_phy_test_report(>dp_ctrl);
- else
+ if (ret) {
DRM_ERROR("failed to enable DP link controller\n");
+ return ret;
+ }
- return ret;
+ pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
+ ret = dp_ctrl_enable_stream_clocks(ctrl, pixel_rate);
+ if (ret) {
+ DRM_ERROR("Failed to start pixel clocks. ret=%d\n", ret);
+ return ret;
+ }
+
+ dp_ctrl_send_phy_test_pattern(ctrl);
+
+ return 0;
}
void dp_ctrl_handle_sink_request(struct dp_ctrl *dp_ctrl)
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_control *sc)
> >> +{
> >> + struct drm_gem_shmem_shrinker *gem_shrinker =
> >> to_drm_shrinker(shrinker);
> >> + struct drm_gem_shmem_object *shmem;
> >> + unsigned long count = 0;
> >> +
> >> + if (!mutex_trylock(_shrinker->lock))
> >> + return 0;
> >> +
> >> + list_for_each_entry(shmem, _shrinker->lru_evictable,
> >> madv_list) {
> >> + count += shmem->base.size;
> >> +
> >> + if (count >= SHRINK_EMPTY)
> >> + break;
> >> + }
> >> +
> >> + mutex_unlock(_shrinker->lock);
> >
> > As I mentioned on other thread, count_objects, being approximate but
> > lockless and fast is the important thing. Otherwise when you start
> > hitting the shrinker on many threads, you end up serializing them all,
> > even if you have no pages to return to the system at that point.
>
> Daniel's point for dropping the lockless variant was that we're already
> in trouble if we're hitting shrinker too often and extra optimizations
> won't bring much benefits to us.
At least with zram swap (which I highly recommend using even if you
are not using a physical swap file/partition), swapin/out is actually
quite fast. And if you are leaning on zram swap to fit 8GB of chrome
browser on a 4GB device, the shrinker gets hit quite a lot. Lower
spec (4GB RAM) chromebooks can be under constant memory pressure and
can quite easily get into a situation where you are hitting the
shrinker on many threads simultaneously. So it is pretty important
for all shrinkers in the system (not just drm driver) to be as
concurrent as possible. As long as you avoid serializing reclaim on
all the threads, performance can still be quite good, but if you don't
performance will fall off a cliff.
jfwiw, we are seeing pretty good results (iirc 40-70% increase in open
tab counts) with the combination of eviction + multigen LRU[1] +
sizing zram swap to be 2x physical RAM
[1] https://lwn.net/Articles/856931/
> Alright, I'll add back the lockless variant (or will use yours
> drm_gem_lru) in the next revision. The code difference is very small
> after all.
>
> ...
> >> + /* prevent racing with the dma-buf importing/exporting */
> >> + if (!mutex_trylock(_shrinker->dev->object_name_lock)) {
> >> + *lock_contention |= true;
> >> + goto resv_unlock;
> >> + }
> >
> > I'm not sure this is a good idea to serialize on object_name_lock.
> > Purgeable buffers should never be shared (imported or exported). So
> > at best you are avoiding evicting and immediately swapping back in, in
> > a rare case, at the cost of serializing multiple threads trying to
> > reclaim pages in parallel.
>
> The object_name_lock shouldn't cause contention in practice. But objects
> are also pinned on attachment, hence maybe this lock is indeed
> unnecessary.. I'll re-check it.
I'm not worried about contention with export/import/etc, but
contention between multiple threads hitting the shrinker in parallel.
I guess since you are using trylock, it won't *block* the other
threads hitting shrinker, but they'll just end up looping in
do_shrink_slab() because they are hitting contention.
I'd have to do some experiments to see how it works out in practice,
but my gut feel is that it isn't a good idea
BR,
-R
> --
> Best regards,
> Dmitry
Re: [PATCH 09/64] drm/simple: Introduce drmm_simple_encoder_init
Hi Am 20.06.22 um 16:39 schrieb Maxime Ripard: On Mon, Jun 20, 2022 at 04:25:38PM +0200, Thomas Zimmermann wrote: Hi Am 20.06.22 um 15:48 schrieb Maxime Ripard: Hi, On Mon, Jun 20, 2022 at 12:44:24PM +0200, Thomas Zimmermann wrote: Am 10.06.22 um 11:28 schrieb Maxime Ripard: The DRM-managed function to register an encoder is drmm_simple_encoder_alloc() and its variants, which will allocate the underlying structure and initialisation the encoder. However, we might want to separate the structure creation and the encoder initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise an encoder that would be passed as an argument. There's nothing wrong with this patch, but I have to admit that adding drm_simple_encoder_init() et al was a mistake. Why do you think it was a mistake? The simple-encoder stuff is an interface that no one really needs. Compared to open-coding the function, it's barely an improvement in LOCs, but nothing else. Back when I added drm_simple_encoder_init(), I wanted to simplify the many drivers that initialized the encoder with a cleanup callback and nothing else. IIRC it was an improvement back then. But now we already have a related drmm_ helper and a drmm_alloc_ helper. If I had only added the macro back then, we could use the regular encoder helpers. It would have been better to add an initializer macro like #define DRM_STATIC_ENCODER_DEFAULT_FUNCS \ .destroy = drm_encoder_cleanup It's way more flexible and similarly easy to use. Anyway... We can still have this. It would simplify this series so I could definitely squeeze that patch in and add a TODO item / deprecation notice for simple encoders if you think it's needed Not necessary. It's not super important. The corollary is though :) If I understand you right, it means that you'd rather have a destroy callback everywhere instead of calling the _cleanup function through a drm-managed callback, and let drm_dev_unregister do its job? If so, it means that we shouldn't be following the drmm_.*_alloc functions and should drop all the new ones from this series. No, no. What I'm saying is that simple-encoder is a pointless mid-layer. There's nothing that couldn't easily be achieved with the regular encoder functions. Best regards Thomas Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 05/64] drm/connector: Mention the cleanup after drm_connector_init
Hi Am 20.06.22 um 16:40 schrieb Maxime Ripard: On Mon, Jun 20, 2022 at 04:19:43PM +0200, Thomas Zimmermann wrote: Hi Am 20.06.22 um 14:18 schrieb Maxime Ripard: + * At driver unload time the driver's _connector_funcs.destroy hook + * should call drm_connector_unregister(), drm_connector_cleanup() and + * kfree() the connector structure. This sentence sounds odd. Yeah, I was using kfree as a verb which is probably where the weirdness comes from. Would that be better: At driver unload time the driver's _connector_funcs.destroy hook should call drm_connector_unregister() and free the connector structure. Yes. That's better. Best regards Thomas Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
RE: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
Thanks,
Oak
> -Original Message-
> From: Vishwanathapura, Niranjana
> Sent: June 17, 2022 1:15 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Vetter,
> Daniel
> Cc: Hellstrom, Thomas ; Wilson, Chris P
> ; ja...@jlekstrand.net;
> christian.koe...@amd.com; Brost, Matthew ;
> Ursulin, Tvrtko ; Auld, Matthew
> ; Landwerlin, Lionel G
> ; Zanoni, Paulo R
> ; Zeng, Oak
> Subject: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
>
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
>
> Signed-off-by: Niranjana Vishwanathapura
>
> ---
> Documentation/gpu/rfc/i915_vm_bind.h | 226
> +++
> 1 file changed, 226 insertions(+)
> create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
>
> diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
> b/Documentation/gpu/rfc/i915_vm_bind.h
> new file mode 100644
> index ..b7540ddb526d
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_vm_bind.h
> @@ -0,0 +1,226 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +/**
> + * DOC: I915_PARAM_HAS_VM_BIND
> + *
> + * VM_BIND feature availability.
> + * See typedef drm_i915_getparam_t param.
> + */
> +#define I915_PARAM_HAS_VM_BIND 57
> +
> +/**
> + * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
> + *
> + * Flag to opt-in for VM_BIND mode of binding during VM creation.
> + * See struct drm_i915_gem_vm_control flags.
> + *
> + * The older execbuf2 ioctl will not support VM_BIND mode of operation.
> + * For VM_BIND mode, we have new execbuf3 ioctl which will not accept
> any
> + * execlist (See struct drm_i915_gem_execbuffer3 for more details).
> + *
> + */
> +#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
> +
> +/* VM_BIND related ioctls */
> +#define DRM_I915_GEM_VM_BIND 0x3d
> +#define DRM_I915_GEM_VM_UNBIND 0x3e
> +#define DRM_I915_GEM_EXECBUFFER3 0x3f
> +
> +#define DRM_IOCTL_I915_GEM_VM_BIND
> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND,
> struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_VM_UNBIND
> DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
> +#define DRM_IOCTL_I915_GEM_EXECBUFFER3
> DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
> +
> +/**
> + * struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
> notification.
> + *
> + * A timeline out fence for vm_bind/unbind completion notification.
> + */
> +struct drm_i915_gem_vm_bind_fence {
> + /** @handle: User's handle for a drm_syncobj to signal. */
> + __u32 handle;
> +
> + /** @rsvd: Reserved, MBZ */
> + __u32 rsvd;
> +
> + /**
> + * @value: A point in the timeline.
> + * Value must be 0 for a binary drm_syncobj. A Value of 0 for a
> + * timeline drm_syncobj is invalid as it turns a drm_syncobj into a
> + * binary one.
> + */
> + __u64 value;
> +};
> +
> +/**
> + * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
> + *
> + * This structure is passed to VM_BIND ioctl and specifies the mapping of
> GPU
> + * virtual address (VA) range to the section of an object that should be
> bound
> + * in the device page table of the specified address space (VM).
> + * The VA range specified must be unique (ie., not currently bound) and can
> + * be mapped to whole object or a section of the object (partial binding).
> + * Multiple VA mappings can be created to the same section of the object
> + * (aliasing).
> + *
> + * The @start, @offset and @length should be 4K page aligned. However
> the DG2
> + * and XEHPSDV has 64K page size for device local-memory and has compact
> page
> + * table. On those platforms, for binding device local-memory objects, the
> + * @start should be 2M aligned, @offset and @length should be 64K aligned.
> + * Also, on those platforms, it is not allowed to bind an device local-memory
> + * object and a system memory object in a single 2M section of VA range.
> + */
> +struct drm_i915_gem_vm_bind {
> + /** @vm_id: VM (address space) id to bind */
> + __u32 vm_id;
> +
> + /** @handle: Object handle */
> + __u32 handle;
> +
> + /** @start: Virtual Address start to bind */
> + __u64 start;
> +
> + /** @offset: Offset in object to bind */
> + __u64 offset;
> +
> + /** @length: Length of mapping to bind */
> + __u64 length;
> +
> + /**
> + * @flags: Supported flags are:
> + *
> + * I915_GEM_VM_BIND_READONLY:
> + * Mapping is read-only.
> + *
> + * I915_GEM_VM_BIND_CAPTURE:
> + * Capture this mapping in the dump upon GPU error.
> + */
> + __u64 flags;
> +#define I915_GEM_VM_BIND_READONLY(1 << 0)
Should we define another flag for DEVICE_ATOMIC? Without this flag, do you
imply all the mapping support device atomic operation?
HW platform also has an implication to device atomic, i.e., some platform
Re: [PATCH 05/64] drm/connector: Mention the cleanup after drm_connector_init
On Mon, Jun 20, 2022 at 04:19:43PM +0200, Thomas Zimmermann wrote: > Hi > > Am 20.06.22 um 14:18 schrieb Maxime Ripard: > > + * At driver unload time the driver's _connector_funcs.destroy hook > > + * should call drm_connector_unregister(), drm_connector_cleanup() and > > + * kfree() the connector structure. > > This sentence sounds odd. Yeah, I was using kfree as a verb which is probably where the weirdness comes from. Would that be better: At driver unload time the driver's _connector_funcs.destroy hook should call drm_connector_unregister() and free the connector structure. Maxime signature.asc Description: PGP signature
Re: [PATCH 09/64] drm/simple: Introduce drmm_simple_encoder_init
On Mon, Jun 20, 2022 at 04:25:38PM +0200, Thomas Zimmermann wrote: > Hi > > Am 20.06.22 um 15:48 schrieb Maxime Ripard: > > Hi, > > > > On Mon, Jun 20, 2022 at 12:44:24PM +0200, Thomas Zimmermann wrote: > > > Am 10.06.22 um 11:28 schrieb Maxime Ripard: > > > > The DRM-managed function to register an encoder is > > > > drmm_simple_encoder_alloc() and its variants, which will allocate the > > > > underlying structure and initialisation the encoder. > > > > > > > > However, we might want to separate the structure creation and the > > > > encoder > > > > initialisation, for example if the structure is shared across multiple > > > > DRM > > > > entities, for example an encoder and a connector. > > > > > > > > Let's create an helper to only initialise an encoder that would be > > > > passed > > > > as an argument. > > > > > > > > > > There's nothing wrong with this patch, but I have to admit that adding > > > drm_simple_encoder_init() et al was a mistake. > > > > Why do you think it was a mistake? > > The simple-encoder stuff is an interface that no one really needs. Compared > to open-coding the function, it's barely an improvement in LOCs, but nothing > else. > > Back when I added drm_simple_encoder_init(), I wanted to simplify the many > drivers that initialized the encoder with a cleanup callback and nothing > else. IIRC it was an improvement back then. But now we already have a > related drmm_ helper and a drmm_alloc_ helper. If I had only added the macro > back then, we could use the regular encoder helpers. > > > > > > It would have been better to add an initializer macro like > > > > > > #define DRM_STATIC_ENCODER_DEFAULT_FUNCS \ > > >.destroy = drm_encoder_cleanup > > > > > > It's way more flexible and similarly easy to use. Anyway... > > > > We can still have this. It would simplify this series so I could > > definitely squeeze that patch in and add a TODO item / deprecation > > notice for simple encoders if you think it's needed > > Not necessary. It's not super important. The corollary is though :) If I understand you right, it means that you'd rather have a destroy callback everywhere instead of calling the _cleanup function through a drm-managed callback, and let drm_dev_unregister do its job? If so, it means that we shouldn't be following the drmm_.*_alloc functions and should drop all the new ones from this series. Maxime signature.asc Description: PGP signature
Re: [PATCH 09/64] drm/simple: Introduce drmm_simple_encoder_init
Hi Am 20.06.22 um 15:48 schrieb Maxime Ripard: Hi, On Mon, Jun 20, 2022 at 12:44:24PM +0200, Thomas Zimmermann wrote: Am 10.06.22 um 11:28 schrieb Maxime Ripard: The DRM-managed function to register an encoder is drmm_simple_encoder_alloc() and its variants, which will allocate the underlying structure and initialisation the encoder. However, we might want to separate the structure creation and the encoder initialisation, for example if the structure is shared across multiple DRM entities, for example an encoder and a connector. Let's create an helper to only initialise an encoder that would be passed as an argument. There's nothing wrong with this patch, but I have to admit that adding drm_simple_encoder_init() et al was a mistake. Why do you think it was a mistake? The simple-encoder stuff is an interface that no one really needs. Compared to open-coding the function, it's barely an improvement in LOCs, but nothing else. Back when I added drm_simple_encoder_init(), I wanted to simplify the many drivers that initialized the encoder with a cleanup callback and nothing else. IIRC it was an improvement back then. But now we already have a related drmm_ helper and a drmm_alloc_ helper. If I had only added the macro back then, we could use the regular encoder helpers. It would have been better to add an initializer macro like #define DRM_STATIC_ENCODER_DEFAULT_FUNCS \ .destroy = drm_encoder_cleanup It's way more flexible and similarly easy to use. Anyway... We can still have this. It would simplify this series so I could definitely squeeze that patch in and add a TODO item / deprecation notice for simple encoders if you think it's needed Not necessary. It's not super important. Best regards Thomas Maxime -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 05/64] drm/connector: Mention the cleanup after drm_connector_init
Hi Am 20.06.22 um 14:18 schrieb Maxime Ripard: + * At driver unload time the driver's _connector_funcs.destroy hook + * should call drm_connector_unregister(), drm_connector_cleanup() and + * kfree() the connector structure. This sentence sounds odd. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On 6/19/22 20:53, Rob Clark wrote:
...
>> +static unsigned long
>> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
>> +struct shrink_control *sc)
>> +{
>> + struct drm_gem_shmem_shrinker *gem_shrinker =
>> to_drm_shrinker(shrinker);
>> + struct drm_gem_shmem_object *shmem;
>> + unsigned long count = 0;
>> +
>> + if (!mutex_trylock(_shrinker->lock))
>> + return 0;
>> +
>> + list_for_each_entry(shmem, _shrinker->lru_evictable, madv_list) {
>> + count += shmem->base.size;
>> +
>> + if (count >= SHRINK_EMPTY)
>> + break;
>> + }
>> +
>> + mutex_unlock(_shrinker->lock);
>
> As I mentioned on other thread, count_objects, being approximate but
> lockless and fast is the important thing. Otherwise when you start
> hitting the shrinker on many threads, you end up serializing them all,
> even if you have no pages to return to the system at that point.
Daniel's point for dropping the lockless variant was that we're already
in trouble if we're hitting shrinker too often and extra optimizations
won't bring much benefits to us.
Alright, I'll add back the lockless variant (or will use yours
drm_gem_lru) in the next revision. The code difference is very small
after all.
...
>> + /* prevent racing with the dma-buf importing/exporting */
>> + if (!mutex_trylock(_shrinker->dev->object_name_lock)) {
>> + *lock_contention |= true;
>> + goto resv_unlock;
>> + }
>
> I'm not sure this is a good idea to serialize on object_name_lock.
> Purgeable buffers should never be shared (imported or exported). So
> at best you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.
The object_name_lock shouldn't cause contention in practice. But objects
are also pinned on attachment, hence maybe this lock is indeed
unnecessary.. I'll re-check it.
--
Best regards,
Dmitry
Re: [PATCH 09/64] drm/simple: Introduce drmm_simple_encoder_init
Hi, On Mon, Jun 20, 2022 at 12:44:24PM +0200, Thomas Zimmermann wrote: > Am 10.06.22 um 11:28 schrieb Maxime Ripard: > > The DRM-managed function to register an encoder is > > drmm_simple_encoder_alloc() and its variants, which will allocate the > > underlying structure and initialisation the encoder. > > > > However, we might want to separate the structure creation and the encoder > > initialisation, for example if the structure is shared across multiple DRM > > entities, for example an encoder and a connector. > > > > Let's create an helper to only initialise an encoder that would be passed > > as an argument. > > > > There's nothing wrong with this patch, but I have to admit that adding > drm_simple_encoder_init() et al was a mistake. Why do you think it was a mistake? > It would have been better to add an initializer macro like > > #define DRM_STATIC_ENCODER_DEFAULT_FUNCS \ > .destroy = drm_encoder_cleanup > > It's way more flexible and similarly easy to use. Anyway... We can still have this. It would simplify this series so I could definitely squeeze that patch in and add a TODO item / deprecation notice for simple encoders if you think it's needed Maxime signature.asc Description: PGP signature
Re: [PATCH v2] drm/i915: Fix vm use-after-free in vma destruction
Acked-by: Nirmoy Das
On 6/20/2022 2:36 PM, Thomas Hellström wrote:
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
mutex_unlock(vma->vm->mutex);
__i915_vm_release();
release_references();
And in release_reference() we dereference vma->vm to get to the
vm gt pointer, leading to a use-after free.
However, __i915_vm_release() grabs the vm->mutex so the vm won't be
destroyed before vma->vm->mutex is released, so extract the gt pointer
under the vm->mutex to avoid the vma->vm dereference in
release_references().
v2: Fix a typo in the commit message (Andi Shyti)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5944
Fixes: e1a7ab4fca ("drm/i915: Remove the vm open count")
Cc: Niranjana Vishwanathapura
Cc: Matthew Auld
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_vma.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0bffb70b3c5f..04d12f278f57 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1637,10 +1637,10 @@ static void force_unbind(struct i915_vma *vma)
GEM_BUG_ON(drm_mm_node_allocated(>node));
}
-static void release_references(struct i915_vma *vma, bool vm_ddestroy)
+static void release_references(struct i915_vma *vma, struct intel_gt *gt,
+ bool vm_ddestroy)
{
struct drm_i915_gem_object *obj = vma->obj;
- struct intel_gt *gt = vma->vm->gt;
GEM_BUG_ON(i915_vma_is_active(vma));
@@ -1695,11 +1695,12 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
force_unbind(vma);
list_del_init(>vm_link);
- release_references(vma, false);
+ release_references(vma, vma->vm->gt, false);
}
void i915_vma_destroy(struct i915_vma *vma)
{
+ struct intel_gt *gt;
bool vm_ddestroy;
mutex_lock(>vm->mutex);
@@ -1707,8 +1708,11 @@ void i915_vma_destroy(struct i915_vma *vma)
list_del_init(>vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
mutex_unlock(>vm->mutex);
- release_references(vma, vm_ddestroy);
+ release_references(vma, gt, vm_ddestroy);
}
void i915_vma_parked(struct intel_gt *gt)
