[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #20 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286834 https://gitlab.com/gitlab-org/gitlab/-/issues/286835 https://gitlab.com/gitlab-org/gitlab/-/issues/286835 https://gitlab.com/gitlab-org/gitlab/-/issues/286837 https://gitlab.com/gitlab-org/gitlab/-/issues/286838 https://gitlab.com/gitlab-org/gitlab/-/issues/286839 https://gitlab.com/gitlab-org/gitlab/-/issues/286840 https://gitlab.com/gitlab-org/gitlab/-/issues/286841 https://gitlab.com/gitlab-org/gitlab/-/issues/286842 https://gitlab.com/gitlab-org/gitlab/-/issues/286843 https://gitlab.com/gitlab-org/gitlab/-/issues/286844 https://gitlab.com/gitlab-org/gitlab/-/issues/286845 https://gitlab.com/gitlab-org/gitlab/-/issues/286846 https://gitlab.com/gitlab-org/gitlab/-/issues/286847 https://gitlab.com/gitlab-org/gitlab/-/issues/286848 https://gitlab.com/gitlab-org/gitlab/-/issues/286849 https://gitlab.com/gitlab-org/gitlab/-/issues/286850 https://gitlab.com/gitlab-org/gitlab/-/issues/286851 https://gitlab.com/gitlab-org/gitlab/-/issues/286852 https://gitlab.com/gitlab-org/gitlab/-/issues/286853 https://gitlab.com/gitlab-org/gitlab/-/issues/286854 https://gitlab.com/gitlab-org/gitlab/-/issues/286855 https://gitlab.com/gitlab-org/gitlab/-/issues/286856 https://gitlab.com/gitlab-org/gitlab/-/issues/286857 https://gitlab.com/gitlab-org/gitlab/-/issues/286858 https://gitlab.com/gitlab-org/gitlab/-/issues/286859 https://gitlab.com/gitlab-org/gitlab/-/issues/286860 https://gitlab.com/gitlab-org/gitlab/-/issues/286861 https://gitlab.com/gitlab-org/gitlab/-/issues/286862 https://gitlab.com/gitlab-org/gitlab/-/issues/286863 https://gitlab.com/gitlab-org/gitlab/-/issues/286864 https://gitlab.com/gitlab-org/gitlab/-/issues/286865 https://gitlab.com/gitlab-org/gitlab/-/issues/286866 https://gitlab.com/gitlab-org/gitlab/-/issues/286867 https://gitlab.com/gitlab-org/gitlab/-/issues/286868 https://gitlab.com/gitlab-org/gitlab/-/issues/286869 https://gitlab.com/gitlab-org/gitlab/-/issues/286870 https://paiza.io/projects/xfPIrGGTy0o9u5bFGK90vA?language=php https://blog.goo.ne.jp/seresrnetyrt/e/e0927028685e5b6fc6f708dbed69c76c https://note.com/wsrbwanretrytuy/n/nd3d4fd769086 https://www.postads.ph/ad/officialfree-ufc-255-live-stream-free-to-watch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #19 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286778 https://gitlab.com/gitlab-org/gitlab/-/issues/286779 https://gitlab.com/gitlab-org/gitlab/-/issues/286780 https://gitlab.com/gitlab-org/gitlab/-/issues/286781 https://gitlab.com/gitlab-org/gitlab/-/issues/286782 https://gitlab.com/gitlab-org/gitlab/-/issues/286784 https://gitlab.com/gitlab-org/gitlab/-/issues/286785 https://gitlab.com/gitlab-org/gitlab/-/issues/286787 https://gitlab.com/gitlab-org/gitlab/-/issues/286789 https://gitlab.com/gitlab-org/gitlab/-/issues/286792 https://gitlab.com/gitlab-org/gitlab/-/issues/286793 https://gitlab.com/gitlab-org/gitlab/-/issues/286795 https://gitlab.com/gitlab-org/gitlab/-/issues/286797 https://gitlab.com/gitlab-org/gitlab/-/issues/286799 https://gitlab.com/gitlab-org/gitlab/-/issues/286800 https://gitlab.com/gitlab-org/gitlab/-/issues/286803 https://gitlab.com/gitlab-org/gitlab/-/issues/286804 https://gitlab.com/gitlab-org/gitlab/-/issues/286805 https://gitlab.com/gitlab-org/gitlab/-/issues/286806 https://gitlab.com/gitlab-org/gitlab/-/issues/286807 https://gitlab.com/gitlab-org/gitlab/-/issues/286809 https://gitlab.com/gitlab-org/gitlab/-/issues/286810 https://gitlab.com/gitlab-org/gitlab/-/issues/286812 https://gitlab.com/gitlab-org/gitlab/-/issues/286813 https://gitlab.com/gitlab-org/gitlab/-/issues/286815 https://gitlab.com/gitlab-org/gitlab/-/issues/286816 https://gitlab.com/gitlab-org/gitlab/-/issues/286817 https://gitlab.com/gitlab-org/gitlab/-/issues/286819 https://gitlab.com/gitlab-org/gitlab/-/issues/286820 https://gitlab.com/gitlab-org/gitlab/-/issues/286822 https://gitlab.com/gitlab-org/gitlab/-/issues/286823 https://gitlab.com/gitlab-org/gitlab/-/issues/286824 https://gitlab.com/gitlab-org/gitlab/-/issues/286826 https://paiza.io/projects/Ci_bkGbc4qMJBBpvrjibTg?language=php https://blog.goo.ne.jp/seresrnetyrt/e/d0a624c5e266c8b4090fe3ee6566127d https://note.com/wsrbwanretrytuy/n/n4a06eda47b11 https://caribbeanfever.com/photo/albums/deiveson-figueiredo-vs-alex-perez-fight-free-live-stream https://www.postads.ph/ad/watch-ufc-255-full-fight-live-free https://jersen-ruari.medium.com/as-people-get-older-they-tend-to-think-that-they-can-do-less-and-less-when-in-reality-they-b86bdefc088 https://niltofipsi.medium.com/whether-they-approve-of-what-you-do-or-not-at-some-point-no-longer-matters-633b4c97da1f https://niltofipsi.medium.com/ask-anyone-you-know-the-last-good-book-they-read-and-ill-bet-most-of-them-respond-with-wow-i-5f9535e53498 https://niltofipsi.medium.com/when-was-the-last-time-you-sat-on-a-sidewalk-and-looked-closely-at-the-cracks-the-rocks-the-dirt-e9d1cfbb0d2b -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #18 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286778 https://gitlab.com/gitlab-org/gitlab/-/issues/286779 https://gitlab.com/gitlab-org/gitlab/-/issues/286780 https://gitlab.com/gitlab-org/gitlab/-/issues/286781 https://gitlab.com/gitlab-org/gitlab/-/issues/286782 https://gitlab.com/gitlab-org/gitlab/-/issues/286784 https://gitlab.com/gitlab-org/gitlab/-/issues/286785 https://gitlab.com/gitlab-org/gitlab/-/issues/286787 https://gitlab.com/gitlab-org/gitlab/-/issues/286789 https://gitlab.com/gitlab-org/gitlab/-/issues/286792 https://gitlab.com/gitlab-org/gitlab/-/issues/286793 https://gitlab.com/gitlab-org/gitlab/-/issues/286795 https://gitlab.com/gitlab-org/gitlab/-/issues/286797 https://gitlab.com/gitlab-org/gitlab/-/issues/286799 https://gitlab.com/gitlab-org/gitlab/-/issues/286800 https://gitlab.com/gitlab-org/gitlab/-/issues/286803 https://gitlab.com/gitlab-org/gitlab/-/issues/286804 https://gitlab.com/gitlab-org/gitlab/-/issues/286805 https://gitlab.com/gitlab-org/gitlab/-/issues/286806 https://gitlab.com/gitlab-org/gitlab/-/issues/286807 https://gitlab.com/gitlab-org/gitlab/-/issues/286809 https://gitlab.com/gitlab-org/gitlab/-/issues/286810 https://gitlab.com/gitlab-org/gitlab/-/issues/286812 https://gitlab.com/gitlab-org/gitlab/-/issues/286813 https://gitlab.com/gitlab-org/gitlab/-/issues/286815 https://gitlab.com/gitlab-org/gitlab/-/issues/286816 https://gitlab.com/gitlab-org/gitlab/-/issues/286817 https://gitlab.com/gitlab-org/gitlab/-/issues/286819 https://gitlab.com/gitlab-org/gitlab/-/issues/286820 https://gitlab.com/gitlab-org/gitlab/-/issues/286822 https://gitlab.com/gitlab-org/gitlab/-/issues/286823 https://gitlab.com/gitlab-org/gitlab/-/issues/286824 https://gitlab.com/gitlab-org/gitlab/-/issues/286826 https://paiza.io/projects/Ci_bkGbc4qMJBBpvrjibTg?language=php https://blog.goo.ne.jp/seresrnetyrt/e/d0a624c5e266c8b4090fe3ee6566127d https://note.com/wsrbwanretrytuy/n/n4a06eda47b11 https://caribbeanfever.com/photo/albums/deiveson-figueiredo-vs-alex-perez-fight-free-live-stream https://www.postads.ph/ad/watch-ufc-255-full-fight-live-free -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #17 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286743 https://gitlab.com/gitlab-org/gitlab/-/issues/286745 https://etienne-yahriel.medium.com/usually-in-reference-to-your-current-interest-1e6769bc6424 https://etienne-yahriel.medium.com/some-people-might-take-interest-c6cf3038dff4 https://etienne-yahriel.medium.com/no-amount-of-money-or-achievement-or-external-validation-will-ever-take-the-place-of-what-you-do-e2615104e9d1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #16 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286709 https://gitlab.com/gitlab-org/gitlab/-/issues/286710 https://gitlab.com/gitlab-org/gitlab/-/issues/286711 https://gitlab.com/gitlab-org/gitlab/-/issues/286712 https://gitlab.com/gitlab-org/gitlab/-/issues/286713 https://gitlab.com/gitlab-org/gitlab/-/issues/286714 https://gitlab.com/gitlab-org/gitlab/-/issues/286715 https://gitlab.com/gitlab-org/gitlab/-/issues/286716 https://gitlab.com/gitlab-org/gitlab/-/issues/286717 https://gitlab.com/gitlab-org/gitlab/-/issues/286718 https://gitlab.com/gitlab-org/gitlab/-/issues/286719 https://gitlab.com/gitlab-org/gitlab/-/issues/286720 https://gitlab.com/gitlab-org/gitlab/-/issues/286721 https://gitlab.com/gitlab-org/gitlab/-/issues/286722 https://gitlab.com/gitlab-org/gitlab/-/issues/286723 https://gitlab.com/gitlab-org/gitlab/-/issues/286724 https://gitlab.com/gitlab-org/gitlab/-/issues/286725 https://gitlab.com/gitlab-org/gitlab/-/issues/286727 https://gitlab.com/gitlab-org/gitlab/-/issues/286728 https://gitlab.com/gitlab-org/gitlab/-/issues/286726 https://paiza.io/projects/HWQrvAylu4vE5x2EVgxvmg?language=php https://blog.goo.ne.jp/seresrnetyrt/e/2580c769ce64b0fd24e5ec95b2f94d03 https://note.com/wsrbwanretrytuy/n/n10d6d5d2b0d6 https://www.postads.ph/ad/ufc-255-live-figueiredo-vs-perez-live-stream-free -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-20.45 2115/2417] drivers/gpu/drm/amd/amdgpu/../display/dc/core/../dcn30/dcn30_resource.h:83:57: warning: 'struct clk_bw_params' declared inside parameter list will not be visible outs
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 2731dbcd0d317dd03d7552e0356ce0ea08b0b838 [2115/2417] drm/amd/display:
Adjust static-ness of resource functions
config: i386-randconfig-a003-20201120 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-20.45
git checkout 2731dbcd0d317dd03d7552e0356ce0ea08b0b838
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:63:
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/../dcn30/dcn30_resource.h:83:57:
>> warning: 'struct clk_bw_params' declared inside parameter list will not be
>> visible outside of this definition or declaration
83 | void dcn30_update_bw_bounding_box(struct dc *dc, struct
clk_bw_params *bw_params);
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c::5: warning:
no previous prototype for 'shift_border_left_to_dst' [-Wmissing-prototypes]
| int shift_border_left_to_dst(struct pipe_ctx *pipe_ctx)
| ^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1122:6: warning:
no previous prototype for 'restore_border_left_from_dst' [-Wmissing-prototypes]
1122 | void restore_border_left_from_dst(struct pipe_ctx *pipe_ctx,
| ^~~~
In file included from drivers/gpu/drm/amd/display/dc/inc/core_types.h:88,
from drivers/gpu/drm/amd/display/dc/inc/resource.h:28,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:30:
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h:54:42: warning:
'dpp_input_csc_matrix' defined but not used [-Wunused-const-variable=]
54 | static const struct dpp_input_csc_matrix dpp_input_csc_matrix[] = {
| ^~~~
In file included from drivers/gpu/drm/amd/display/dc/inc/core_types.h:32,
from drivers/gpu/drm/amd/display/dc/inc/resource.h:28,
from
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:30:
drivers/gpu/drm/amd/display/include/ddc_service_types.h:124:22: warning:
'DP_DVI_CONVERTER_ID_4' defined but not used [-Wunused-const-variable=]
124 | static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
| ^
drivers/gpu/drm/amd/display/include/ddc_service_types.h:122:22: warning:
'DP_VGA_LVDS_CONVERTER_ID_3' defined but not used [-Wunused-const-variable=]
122 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
| ^~
drivers/gpu/drm/amd/display/include/ddc_service_types.h:120:22: warning:
'DP_VGA_LVDS_CONVERTER_ID_2' defined but not used [-Wunused-const-variable=]
120 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
| ^~
In file included from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/amdgpu/amdgpu.h:198:19: warning: 'no_system_mem_limit'
defined but not used [-Wunused-const-variable=]
198 | static const bool no_system_mem_limit;
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:197:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
197 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:196:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
196 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/display/dc/dc_types.h:33,
from drivers/gpu/drm/amd/display/dc/dm_services_types.h:30,
from drivers/gpu/drm/amd/include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:64,
from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #15 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286634 https://gitlab.com/gitlab-org/gitlab/-/issues/286635 https://gitlab.com/gitlab-org/gitlab/-/issues/286636 https://gitlab.com/gitlab-org/gitlab/-/issues/286637 https://gitlab.com/gitlab-org/gitlab/-/issues/286638 https://gitlab.com/gitlab-org/gitlab/-/issues/286639 https://gitlab.com/gitlab-org/gitlab/-/issues/286640 https://gitlab.com/gitlab-org/gitlab/-/issues/286641 https://gitlab.com/gitlab-org/gitlab/-/issues/286642 https://gitlab.com/gitlab-org/gitlab/-/issues/286643 https://gitlab.com/gitlab-org/gitlab/-/issues/286644 https://gitlab.com/gitlab-org/gitlab/-/issues/286645 https://gitlab.com/gitlab-org/gitlab/-/issues/286646 https://gitlab.com/gitlab-org/gitlab/-/issues/286648 https://gitlab.com/gitlab-org/gitlab/-/issues/286649 https://gitlab.com/gitlab-org/gitlab/-/issues/286650 https://gitlab.com/gitlab-org/gitlab/-/issues/286652 https://paiza.io/projects/FAKh0CzpgjeUt1tWpd77Ag?language=php https://blog.goo.ne.jp/seresrnetyrt/e/3710e37c7986e499c98c7611b6e5687a https://note.com/wsrbwanretrytuy/n/nae843a959761 https://www.postads.ph/ad/ufc-255-live-stream-free-watch https://townsend-poe.medium.com/nobody-creates-themselves-by-themselves-we-are-all-mirror-images-sculpted-through-the-2b54a88df876 https://townsend-poe.medium.com/some-people-might-take-interest-27b0bc90ebc2 https://townsend-poe.medium.com/life-is-a-journey-of-twists-and-turns-peaks-and-valleys-mountains-to-climb-and-oceans-to-explore-25f40a665d64 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #14 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286634 https://gitlab.com/gitlab-org/gitlab/-/issues/286635 https://gitlab.com/gitlab-org/gitlab/-/issues/286636 https://gitlab.com/gitlab-org/gitlab/-/issues/286637 https://gitlab.com/gitlab-org/gitlab/-/issues/286638 https://gitlab.com/gitlab-org/gitlab/-/issues/286639 https://gitlab.com/gitlab-org/gitlab/-/issues/286640 https://gitlab.com/gitlab-org/gitlab/-/issues/286641 https://gitlab.com/gitlab-org/gitlab/-/issues/286642 https://gitlab.com/gitlab-org/gitlab/-/issues/286643 https://gitlab.com/gitlab-org/gitlab/-/issues/286644 https://gitlab.com/gitlab-org/gitlab/-/issues/286645 https://gitlab.com/gitlab-org/gitlab/-/issues/286646 https://gitlab.com/gitlab-org/gitlab/-/issues/286648 https://gitlab.com/gitlab-org/gitlab/-/issues/286649 https://gitlab.com/gitlab-org/gitlab/-/issues/286650 https://gitlab.com/gitlab-org/gitlab/-/issues/286652 https://paiza.io/projects/FAKh0CzpgjeUt1tWpd77Ag?language=php https://blog.goo.ne.jp/seresrnetyrt/e/3710e37c7986e499c98c7611b6e5687a https://note.com/wsrbwanretrytuy/n/nae843a959761 https://www.postads.ph/ad/ufc-255-live-stream-free-watch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-20.45 2113/2417] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2448:28: warning: initialized field overwritten
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 24a52b0a25c5c311e471b0552284d8c359ca7047 [2113/2417] drm/amd/display:
Add dsc_to_stream_resource for dcn3
config: i386-randconfig-a003-20201120 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-20.45
git checkout 24a52b0a25c5c311e471b0552284d8c359ca7047
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2147:56:
error: 'struct clk_mgr' has no member named 'bw_params'
2147 | context->bw_ctx.dml.soc.sr_exit_time_us =
dc->clk_mgr->bw_params->wm_table.nv_entries[WM_B].dml_input.sr_exit_time_us;
|^~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2154:37:
error: 'struct dcn_watermarks' has no member named 'frac_urg_bw_nom'
2154 | context->bw_ctx.bw.dcn.watermarks.b.frac_urg_bw_nom =
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2155:37:
error: 'struct dcn_watermarks' has no member named 'frac_urg_bw_flip'
2155 | context->bw_ctx.bw.dcn.watermarks.b.frac_urg_bw_flip =
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes,
pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2156:37:
error: 'struct dcn_watermarks' has no member named 'urgent_latency_ns'
2156 | context->bw_ctx.bw.dcn.watermarks.b.urgent_latency_ns =
get_urgent_latency(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2166:17:
error: 'struct clk_mgr' has no member named 'bw_params'
2166 | if (dc->clk_mgr->bw_params->wm_table.nv_entries[WM_C].valid) {
| ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2166:50:
error: 'WM_C' undeclared (first use in this function)
2166 | if (dc->clk_mgr->bw_params->wm_table.nv_entries[WM_C].valid) {
| ^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2167:69:
error: 'struct clk_mgr' has no member named 'bw_params'
2167 | context->bw_ctx.dml.soc.dram_clock_change_latency_us =
dc->clk_mgr->bw_params->wm_table.nv_entries[WM_C].dml_input.pstate_latency_us;
|
^~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2168:67:
error: 'struct clk_mgr' has no member named 'bw_params'
2168 | context->bw_ctx.dml.soc.sr_enter_plus_exit_time_us =
dc->clk_mgr->bw_params->wm_table.nv_entries[WM_C].dml_input.sr_enter_plus_exit_time_us;
| ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2169:56:
error: 'struct clk_mgr' has no member named 'bw_params'
2169 | context->bw_ctx.dml.soc.sr_exit_time_us =
dc->clk_mgr->bw_params->wm_table.nv_entries[WM_C].dml_input.sr_exit_time_us;
|^~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2176:37:
error: 'struct dcn_watermarks' has no member named 'frac_urg_bw_nom'
2176 | context->bw_ctx.bw.dcn.watermarks.c.frac_urg_bw_nom =
get_fraction_of_urgent_bandwidth(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2177:37:
error: 'struct dcn_watermarks' has no member named 'frac_urg_bw_flip'
2177 | context->bw_ctx.bw.dcn.watermarks.c.frac_urg_bw_flip =
get_fraction_of_urgent_bandwidth_imm_flip(>bw_ctx.dml, pipes,
pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2178:37:
error: 'struct dcn_watermarks' has no member named 'urgent_latency_ns'
2178 | context->bw_ctx.bw.dcn.watermarks.c.urgent_latency_ns =
get_urgent_latency(>bw_ctx.dml, pipes, pipe_cnt) * 1000;
| ^
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:2185:17:
error: 'struct clk_mgr' has no member named 'bw_params'
2185 | if (dc->clk_mgr->bw_params->wm_table.nv_entries[WM_D].valid) {
| ^~
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #13 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286588 https://gitlab.com/gitlab-org/gitlab/-/issues/286589 https://gitlab.com/gitlab-org/gitlab/-/issues/286590 https://gitlab.com/gitlab-org/gitlab/-/issues/286591 https://gitlab.com/gitlab-org/gitlab/-/issues/286592 https://gitlab.com/gitlab-org/gitlab/-/issues/286593 https://gitlab.com/gitlab-org/gitlab/-/issues/286594 https://gitlab.com/gitlab-org/gitlab/-/issues/286595 https://gitlab.com/gitlab-org/gitlab/-/issues/286596 https://gitlab.com/gitlab-org/gitlab/-/issues/286597 https://gitlab.com/gitlab-org/gitlab/-/issues/286598 https://gitlab.com/gitlab-org/gitlab/-/issues/286599 https://gitlab.com/gitlab-org/gitlab/-/issues/286600 https://gitlab.com/gitlab-org/gitlab/-/issues/286601 https://gitlab.com/gitlab-org/gitlab/-/issues/286602 https://gitlab.com/gitlab-org/gitlab/-/issues/286603 https://gitlab.com/gitlab-org/gitlab/-/issues/286604 https://gitlab.com/gitlab-org/gitlab/-/issues/286605 https://gitlab.com/gitlab-org/gitlab/-/issues/286606 https://gitlab.com/gitlab-org/gitlab/-/issues/286607 https://gitlab.com/gitlab-org/gitlab/-/issues/286608 https://gitlab.com/gitlab-org/gitlab/-/issues/286609 https://paiza.io/projects/p8xBA-vMOqai9X8dE880Tw?language=php https://blog.goo.ne.jp/seresrnetyrt/e/4944ef76a9178fa97615721fa5ae13f9 https://note.com/wsrbwanretrytuy/n/n1f71923d5a1c https://www.postads.ph/ad/swaeaqnwaetrydtwaebewanwarestrydtuyu -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/5] dma-buf: heaps: Skip sync if not mapped
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Before v5.0 (commit 55897af63091 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.
In v5.0 this was incidentally fixed by commit 55897af63091 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.
But, this issue is re-introduced in v5.3 with
commit 449fa54d6815 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.
dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.
Logic and commit message originally by: Ørjan Eide
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 10 ++
drivers/dma-buf/heaps/system_heap.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 05aaa4f29397..5e7c3436310c 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -43,6 +43,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table table;
struct list_head list;
+ bool mapped;
};
static int cma_heap_attach(struct dma_buf *dmabuf,
@@ -67,6 +68,7 @@ static int cma_heap_attach(struct dma_buf *dmabuf,
a->dev = attachment->dev;
INIT_LIST_HEAD(>list);
+ a->mapped = false;
attachment->priv = a;
@@ -101,6 +103,7 @@ static struct sg_table *cma_heap_map_dma_buf(struct
dma_buf_attachment *attachme
ret = dma_map_sgtable(attachment->dev, table, direction, 0);
if (ret)
return ERR_PTR(-ENOMEM);
+ a->mapped = true;
return table;
}
@@ -108,6 +111,9 @@ static void cma_heap_unmap_dma_buf(struct
dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ struct dma_heap_attachment *a = attachment->priv;
+
+ a->mapped = false;
dma_unmap_sgtable(attachment->dev, table, direction, 0);
}
@@ -122,6 +128,8 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_cpu(a->dev, >table, direction);
}
mutex_unlock(>lock);
@@ -140,6 +148,8 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf
*dmabuf,
mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
+ if (!a->mapped)
+ continue;
dma_sync_sgtable_for_device(a->dev, >table, direction);
}
mutex_unlock(>lock);
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index b2d02f50f9ed..32b17a5c8079 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -37,6 +37,7 @@ struct dma_heap_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+ bool mapped;
};
static struct sg_table *dup_sg_table(struct sg_table *table)
@@ -84,6 +85,7 @@ static int system_heap_attach(struct dma_buf *dmabuf,
a->table = table;
[PATCH v7 3/5] dma-buf: heaps: Remove heap-helpers code
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v6: Rebased onto drm-misc-next
---
drivers/dma-buf/heaps/Makefile | 1 -
drivers/dma-buf/heaps/heap-helpers.c | 274 ---
drivers/dma-buf/heaps/heap-helpers.h | 53 --
3 files changed, 328 deletions(-)
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c
delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 6e54cdec3da0..974467791032 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,4 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
-obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
deleted file mode 100644
index fcf4ce3e2cbb..
--- a/drivers/dma-buf/heaps/heap-helpers.c
+++ /dev/null
@@ -1,274 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "heap-helpers.h"
-
-void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
-void (*free)(struct heap_helper_buffer *))
-{
- buffer->priv_virt = NULL;
- mutex_init(>lock);
- buffer->vmap_cnt = 0;
- buffer->vaddr = NULL;
- buffer->pagecount = 0;
- buffer->pages = NULL;
- INIT_LIST_HEAD(>attachments);
- buffer->free = free;
-}
-
-struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
- int fd_flags)
-{
- DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-
- exp_info.ops = _helper_ops;
- exp_info.size = buffer->size;
- exp_info.flags = fd_flags;
- exp_info.priv = buffer;
-
- return dma_buf_export(_info);
-}
-
-static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- vaddr = vmap(buffer->pages, buffer->pagecount, VM_MAP, PAGE_KERNEL);
- if (!vaddr)
- return ERR_PTR(-ENOMEM);
-
- return vaddr;
-}
-
-static void dma_heap_buffer_destroy(struct heap_helper_buffer *buffer)
-{
- if (buffer->vmap_cnt > 0) {
- WARN(1, "%s: buffer still mapped in the kernel\n", __func__);
- vunmap(buffer->vaddr);
- }
-
- buffer->free(buffer);
-}
-
-static void *dma_heap_buffer_vmap_get(struct heap_helper_buffer *buffer)
-{
- void *vaddr;
-
- if (buffer->vmap_cnt) {
- buffer->vmap_cnt++;
- return buffer->vaddr;
- }
- vaddr = dma_heap_map_kernel(buffer);
- if (IS_ERR(vaddr))
- return vaddr;
- buffer->vaddr = vaddr;
- buffer->vmap_cnt++;
- return vaddr;
-}
-
-static void dma_heap_buffer_vmap_put(struct heap_helper_buffer *buffer)
-{
- if (!--buffer->vmap_cnt) {
- vunmap(buffer->vaddr);
- buffer->vaddr = NULL;
- }
-}
-
-struct dma_heaps_attachment {
- struct device *dev;
- struct sg_table table;
- struct list_head list;
-};
-
-static int dma_heap_attach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a;
- struct heap_helper_buffer *buffer = dmabuf->priv;
- int ret;
-
- a = kzalloc(sizeof(*a), GFP_KERNEL);
- if (!a)
- return -ENOMEM;
-
- ret = sg_alloc_table_from_pages(>table, buffer->pages,
- buffer->pagecount, 0,
- buffer->pagecount << PAGE_SHIFT,
- GFP_KERNEL);
- if (ret) {
- kfree(a);
- return ret;
- }
-
- a->dev = attachment->dev;
- INIT_LIST_HEAD(>list);
-
- attachment->priv = a;
-
- mutex_lock(>lock);
- list_add(>list, >attachments);
- mutex_unlock(>lock);
-
- return 0;
-}
-
-static void dma_heap_detach(struct dma_buf *dmabuf,
- struct dma_buf_attachment *attachment)
-{
- struct dma_heaps_attachment *a = attachment->priv;
- struct heap_helper_buffer *buffer = dmabuf->priv;
-
- mutex_lock(>lock);
- list_del(>list);
- mutex_unlock(>lock);
-
- sg_free_table(>table);
- kfree(a);
-}
-
-static
-struct
[PATCH v7 5/5] dma-buf: system_heap: Allocate higher order pages if available
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v3:
* Use page_size() rather then opencoding it
v5:
* Add comment explaining order size rational
---
drivers/dma-buf/heaps/system_heap.c | 89 +++--
1 file changed, 71 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 32b17a5c8079..17e0e9a68baf 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -40,6 +40,20 @@ struct dma_heap_attachment {
bool mapped;
};
+#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
+ | __GFP_NORETRY) & ~__GFP_RECLAIM) \
+ | __GFP_COMP)
+#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
+static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP};
+/*
+ * The selection of the orders used for allocation (1MB, 64K, 4K) is designed
+ * to match with the sizes often found in IOMMUs. Using order 4 pages instead
+ * of order 0 pages can significantly improve the performance of many IOMMUs
+ * by reducing TLB pressure and time spent updating page tables.
+ */
+static const unsigned int orders[] = {8, 4, 0};
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
static struct sg_table *dup_sg_table(struct sg_table *table)
{
struct sg_table *new_table;
@@ -275,8 +289,11 @@ static void system_heap_dma_buf_release(struct dma_buf
*dmabuf)
int i;
table = >sg_table;
- for_each_sgtable_sg(table, sg, i)
- __free_page(sg_page(sg));
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ struct page *page = sg_page(sg);
+
+ __free_pages(page, compound_order(page));
+ }
sg_free_table(table);
kfree(buffer);
}
@@ -294,6 +311,26 @@ static const struct dma_buf_ops system_heap_buf_ops = {
.release = system_heap_dma_buf_release,
};
+static struct page *alloc_largest_available(unsigned long size,
+ unsigned int max_order)
+{
+ struct page *page;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ if (size < (PAGE_SIZE << orders[i]))
+ continue;
+ if (max_order < orders[i])
+ continue;
+
+ page = alloc_pages(order_flags[i], orders[i]);
+ if (!page)
+ continue;
+ return page;
+ }
+ return NULL;
+}
+
static int system_heap_allocate(struct dma_heap *heap,
unsigned long len,
unsigned long fd_flags,
@@ -301,11 +338,13 @@ static int system_heap_allocate(struct dma_heap *heap,
{
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+ unsigned long size_remaining = len;
+ unsigned int max_order = orders[0];
struct dma_buf *dmabuf;
struct sg_table *table;
struct scatterlist *sg;
- pgoff_t pagecount;
- pgoff_t pg;
+ struct list_head pages;
+ struct page *page, *tmp_page;
int i, ret = -ENOMEM;
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
@@ -317,25 +356,35 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer->heap = heap;
buffer->len = len;
- table = >sg_table;
- pagecount = len / PAGE_SIZE;
- if (sg_alloc_table(table, pagecount, GFP_KERNEL))
- goto free_buffer;
-
- sg = table->sgl;
- for (pg = 0; pg < pagecount; pg++) {
- struct page *page;
+ INIT_LIST_HEAD();
+ i = 0;
+ while (size_remaining > 0) {
/*
* Avoid trying to allocate memory if the process
* has been killed by SIGKILL
*/
if (fatal_signal_pending(current))
- goto free_pages;
- page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ goto free_buffer;
+
+ page = alloc_largest_available(size_remaining, max_order);
if (!page)
- goto free_pages;
+ goto free_buffer;
+
+ list_add_tail(>lru, );
+ size_remaining -= page_size(page);
+ max_order = compound_order(page);
+ i++;
+ }
+
+ table =
[PATCH v7 2/5] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix unused return value and locking issue Reported-by:
kernel test robot
Julia Lawall
* Make cma_heap_buf_ops static suggested by
kernel test robot
* Fix uninitialized return in cma Reported-by:
kernel test robot
* Minor cleanups
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Spelling fix suggested by BrianS
v6:
* Fixups against drm-misc-next
v7:
* Redo the incorrect dma-buf-map adaptation in the last revision
---
drivers/dma-buf/heaps/cma_heap.c | 319 ++-
1 file changed, 270 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index e55384dc115b..05aaa4f29397 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -2,76 +2,295 @@
/*
* DMABUF CMA heap exporter
*
- * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Copyright (C) 2012, 2019, 2020 Linaro Ltd.
* Author: for ST-Ericsson.
+ *
+ * Also utilizing parts of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
-
#include
-#include
#include
#include
#include
#include
-#include
#include
+#include
+#include
#include
-#include
#include
-#include
+#include
-#include "heap-helpers.h"
struct cma_heap {
struct dma_heap *heap;
struct cma *cma;
};
-static void cma_heap_free(struct heap_helper_buffer *buffer)
+struct cma_heap_buffer {
+ struct cma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct page *cma_pages;
+ struct page **pages;
+ pgoff_t pagecount;
+ int vmap_cnt;
+ void *vaddr;
+};
+
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table table;
+ struct list_head list;
+};
+
+static int cma_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
{
- struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
- unsigned long nr_pages = buffer->pagecount;
- struct page *cma_pages = buffer->priv_virt;
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ int ret;
- /* free page list */
- kfree(buffer->pages);
- /* release memory */
- cma_release(cma_heap->cma, cma_pages, nr_pages);
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ ret = sg_alloc_table_from_pages(>table, buffer->pages,
+ buffer->pagecount, 0,
+ buffer->pagecount << PAGE_SHIFT,
+ GFP_KERNEL);
+ if (ret) {
+ kfree(a);
+ return ret;
+ }
+
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(>list);
+
+ attachment->priv = a;
+
+ mutex_lock(>lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
+static void cma_heap_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct cma_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(>lock);
+ list_del(>list);
+ mutex_unlock(>lock);
+
+ sg_free_table(>table);
+ kfree(a);
+}
+
+static struct sg_table *cma_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+enum dma_data_direction direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = >table;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return ERR_PTR(-ENOMEM);
+ return table;
+}
+
+static void cma_heap_unmap_dma_buf(struct dma_buf_attachment *attachment,
+ struct sg_table *table,
+ enum dma_data_direction direction)
+{
+ dma_unmap_sgtable(attachment->dev, table, direction, 0);
+}
+
+static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
+enum dma_data_direction direction)
+{
+ struct cma_heap_buffer
[PATCH v7 1/5] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops using the heap-helpers logic
which sadly is not quite as generic as I was hoping it to be, so
this patch adds heap specific implementations of the dma_buf_ops
function handlers.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey
Signed-off-by: John Stultz
---
v2:
* Fix locking issue and an unused return value Reported-by:
kernel test robot
Julia Lawall
* Make system_heap_buf_ops static Reported-by:
kernel test robot
v3:
* Use the new sgtable mapping functions, as Suggested-by:
Daniel Mentz
v4:
* Make sys_heap static (indirectly) Reported-by:
kernel test robot
* Spelling fix suggested by BrianS
v6:
* Fixups against drm-misc-next, from Sumit
v7:
* Redo the incorrect dma-buf-map adaptation in the last revision
---
drivers/dma-buf/heaps/system_heap.c | 349
1 file changed, 303 insertions(+), 46 deletions(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 0bf688e3c023..b2d02f50f9ed 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -3,7 +3,11 @@
* DMABUF System heap exporter
*
* Copyright (C) 2011 Google, Inc.
- * Copyright (C) 2019 Linaro Ltd.
+ * Copyright (C) 2019, 2020 Linaro Ltd.
+ *
+ * Portions based off of Andrew Davis' SRAM heap:
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis
*/
#include
@@ -15,72 +19,326 @@
#include
#include
#include
-#include
-#include
+#include
+
+static struct dma_heap *sys_heap;
-#include "heap-helpers.h"
+struct system_heap_buffer {
+ struct dma_heap *heap;
+ struct list_head attachments;
+ struct mutex lock;
+ unsigned long len;
+ struct sg_table sg_table;
+ int vmap_cnt;
+ void *vaddr;
+};
-struct dma_heap *sys_heap;
+struct dma_heap_attachment {
+ struct device *dev;
+ struct sg_table *table;
+ struct list_head list;
+};
-static void system_heap_free(struct heap_helper_buffer *buffer)
+static struct sg_table *dup_sg_table(struct sg_table *table)
{
- pgoff_t pg;
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->orig_nents, GFP_KERNEL);
+ if (ret) {
+ kfree(new_table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sgtable_sg(table, sg, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, sg->offset);
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
+static int system_heap_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a;
+ struct sg_table *table;
+
+ a = kzalloc(sizeof(*a), GFP_KERNEL);
+ if (!a)
+ return -ENOMEM;
+
+ table = dup_sg_table(>sg_table);
+ if (IS_ERR(table)) {
+ kfree(a);
+ return -ENOMEM;
+ }
+
+ a->table = table;
+ a->dev = attachment->dev;
+ INIT_LIST_HEAD(>list);
+
+ attachment->priv = a;
+
+ mutex_lock(>lock);
+ list_add(>list, >attachments);
+ mutex_unlock(>lock);
+
+ return 0;
+}
+
+static void system_heap_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attachment)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+ struct dma_heap_attachment *a = attachment->priv;
+
+ mutex_lock(>lock);
+ list_del(>list);
+ mutex_unlock(>lock);
+
+ sg_free_table(a->table);
+ kfree(a->table);
+ kfree(a);
+}
+
+static struct sg_table *system_heap_map_dma_buf(struct dma_buf_attachment
*attachment,
+ enum dma_data_direction
direction)
+{
+ struct dma_heap_attachment *a = attachment->priv;
+ struct sg_table *table = a->table;
+ int ret;
+
+ ret = dma_map_sgtable(attachment->dev, table, direction, 0);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return table;
+}
+
+static void
[PATCH v7 0/5] dma-buf: Code rework and performance improvements for system heap
Hey All, So Sumit noted a flub I made in adapting the last series to the new dma-buf-map code that is in drm-misc-next. Thus I wanted to send this (hopefully) last revision of my patch series of performance optimizations to the dma-buf system heap, once again against drm-misc-next. This series reworks the system heap to use sgtables, and then consolidates the pagelist method from the heap-helpers into the CMA heap. After which the heap-helpers logic is removed (as it is unused). I'd still like to find a better way to avoid some of the logic duplication in implementing the entire dma_buf_ops handlers per heap. But unfortunately that code is tied somewhat to how the buffer's memory is tracked. As more heaps show up I think we'll have a better idea how to best share code, so for now I think this is ok. After this, the series introduces an optimization that Ørjan Eide implemented for ION that avoids calling sync on attachments that don't have a mapping. Finally, an optimization to use larger order pages for the system heap. This change brings us closer to the current performance of the ION allocation code (though there still is a gap due to ION using a mix of deferred-freeing and page pools, I'll be looking at integrating those eventually). This version of the series does not include the system-uncached heap as Daniel wanted further demonstration that it is useful with devices that use the mesa stack. I'm working on such a justification but I don't want to hold up these rework patches in the meantime. thanks -john New in v7: * Fixed the incorrect adaptation to the dma-buf-map usage Cc: Sumit Semwal Cc: Liam Mark Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Chris Goldsworthy Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: linux-me...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org John Stultz (5): dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists dma-buf: heaps: Move heap-helper logic into the cma_heap implementation dma-buf: heaps: Remove heap-helpers code dma-buf: heaps: Skip sync if not mapped dma-buf: system_heap: Allocate higher order pages if available drivers/dma-buf/heaps/Makefile | 1 - drivers/dma-buf/heaps/cma_heap.c | 329 + drivers/dma-buf/heaps/heap-helpers.c | 274 -- drivers/dma-buf/heaps/heap-helpers.h | 53 drivers/dma-buf/heaps/system_heap.c | 414 --- 5 files changed, 647 insertions(+), 424 deletions(-) delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #12 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286503 https://gitlab.com/gitlab-org/gitlab/-/issues/286504 https://gitlab.com/gitlab-org/gitlab/-/issues/286505 https://gitlab.com/gitlab-org/gitlab/-/issues/286506 https://gitlab.com/gitlab-org/gitlab/-/issues/286507 https://gitlab.com/gitlab-org/gitlab/-/issues/286508 https://gitlab.com/gitlab-org/gitlab/-/issues/286509 https://gitlab.com/gitlab-org/gitlab/-/issues/286510 https://gitlab.com/gitlab-org/gitlab/-/issues/286512 https://gitlab.com/gitlab-org/gitlab/-/issues/286513 https://gitlab.com/gitlab-org/gitlab/-/issues/286514 https://gitlab.com/gitlab-org/gitlab/-/issues/286515 https://gitlab.com/gitlab-org/gitlab/-/issues/286516 https://gitlab.com/gitlab-org/gitlab/-/issues/286528 https://gitlab.com/gitlab-org/gitlab/-/issues/286529 https://gitlab.com/gitlab-org/gitlab/-/issues/286531 https://gitlab.com/gitlab-org/gitlab/-/issues/286532 https://gitlab.com/gitlab-org/gitlab/-/issues/286533 https://gitlab.com/gitlab-org/gitlab/-/issues/286535 https://gitlab.com/gitlab-org/gitlab/-/issues/286536 https://gitlab.com/gitlab-org/gitlab/-/issues/286537 https://gitlab.com/gitlab-org/gitlab/-/issues/286538 https://gitlab.com/gitlab-org/gitlab/-/issues/286539 https://gitlab.com/gitlab-org/gitlab/-/issues/286540 https://gitlab.com/gitlab-org/gitlab/-/issues/286542 https://gitlab.com/gitlab-org/gitlab/-/issues/286543 https://gitlab.com/gitlab-org/gitlab/-/issues/286545 https://paiza.io/projects/mxrHB8xb0yNMwNx-sDDCrQ?language=php https://blog.goo.ne.jp/seresrnetyrt/e/b6e71226d428398644a395cec3105c0a https://note.com/wsrbwanretrytuy/n/n2a2bb4176eb4 https://www.postads.ph/ad/live-college-football-stream-watch-ncaaf-stream-online-free -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210301] New: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u
https://bugzilla.kernel.org/show_bug.cgi?id=210301 Bug ID: 210301 Summary: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u Product: Drivers Version: 2.5 Kernel Version: 5.9.8 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: ar_registrat...@mailbox.org Regression: No Boting in a new Thinkpad T14 AMD (4750u), I get *sometimes* the following errors: 2020-11-21T16:45:15.53245 kern.err: [5.934142] amdgpu :07:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). 2020-11-21T16:45:15.53247 kern.err: [5.935598] [drm:process_one_work] *ERROR* ib ring test failed (-110). When this happens (typically 9/10 times) the machine eventually hangs. Sometimes with a page fault, sometimes with a general protection fault, but *always* in what appears to be the zfs calls. When the machine boots without the "*ERROR* IB test failed on gfx ", the machines *never* produces segmentation faults/general protection faults, even under very heavy i/o load. I have reproduced this problem: - In kernels 5.8.18, 5.9.6, 5.9.7, 5.9.8 - With two different SSD - With the firmware versions 20201118, 20201022, 20200918 - I have updated te BIOS two times (versions 1.09, 1.25, 1.27) I boot with the kernel command line options amd_iommu=on iommu=soft in order to avoid *another* error (AMD-Vi: Unable to read/write to IOMMU perf counter.) For example: 2020-10-24T22:00:29.88940 kern.warn: [ 1021.160344] general protection fault, probably for non-canonical address 0x3ff80004000: [#1] SMP NOPTI 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89021 kern.warn: [ 1021.160385] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:b3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:b3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89041 kern.warn: [ 1021.160389] RAX: 03ff80004000 RBX: 000587ce RCX: 1fd4 2020-10-24T22:00:29.89044 kern.warn: [ 1021.160389] RDX: 98bc4b6dbe00 RSI: 000587ce RDI: c11be4d0 2020-10-24T22:00:29.89046 kern.warn: [ 1021.160390] RBP: 98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89049 kern.warn: [ 1021.160391] R10: R11: 98bcca928000 R12: 00030fc0 2020-10-24T22:00:29.89061 kern.warn: [ 1021.160391] R13: R14: 98bc4b6dbe00 R15: c11be4d0 2020-10-24T22:00:29.89065 kern.warn: [ 1021.160392] FS: 7f739cf48740() GS:98bccf08() knlGS: 2020-10-24T22:00:29.89070 kern.warn: [ 1021.160393] CS: 0010 DS: ES: CR0: 80050033 2020-10-24T22:00:29.89077 kern.warn: [ 1021.160393] CR2: 7f790e77d280 CR3: 000757346000 CR4: 00340ee0 2020-10-24T22:00:29.89081 kern.warn: [ 1021.160394] Call Trace: 2020-10-24T22:00:29.89084 kern.warn: [ 1021.160400] ? _cond_resched+0x15/0x30 2020-10-24T22:00:29.89088 kern.warn: [ 1021.160410] dbuf_hold_impl_arg+0x41/0x610 [zfs] 2020-10-24T22:00:29.89091 kern.warn: [ 1021.160413] ? spl_kmem_alloc+0xbf/0x100 [spl] 2020-10-24T22:00:29.89095 kern.warn: [ 1021.160424] dbuf_hold_impl+0x94/0xc0 [zfs] 2020-10-24T22:00:29.89098 kern.warn: [ 1021.160434] dbuf_hold_level+0x2b/0x60 [zfs] 2020-10-24T22:00:29.89102 kern.warn: [ 1021.160446] dmu_tx_check_ioerr+0x35/0xd0 [zfs] 2020-10-24T22:00:29.89105 kern.warn: [ 1021.160457] dmu_tx_count_write+0xe5/0x1a0 [zfs] 2020-10-24T22:00:29.89109 kern.warn: [ 1021.160468] dmu_tx_hold_write_by_dnode+0x35/0x50 [zfs] 2020-10-24T22:00:29.89112 kern.warn: [ 1021.160481] zfs_write+0x410/0xe00 [zfs] 2020-10-24T22:00:29.89116 kern.warn: [ 1021.160485] ? enqueue_entity+0xf1/0x580 2020-10-24T22:00:29.89121
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #11 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286386 https://gitlab.com/gitlab-org/gitlab/-/issues/286387 https://gitlab.com/gitlab-org/gitlab/-/issues/286389 https://gitlab.com/gitlab-org/gitlab/-/issues/286390 https://gitlab.com/gitlab-org/gitlab/-/issues/286391 https://gitlab.com/gitlab-org/gitlab/-/issues/286392 https://gitlab.com/gitlab-org/gitlab/-/issues/286393 https://gitlab.com/gitlab-org/gitlab/-/issues/286394 https://gitlab.com/gitlab-org/gitlab/-/issues/286395 https://gitlab.com/gitlab-org/gitlab/-/issues/286397 https://gitlab.com/gitlab-org/gitlab/-/issues/286398 https://gitlab.com/gitlab-org/gitlab/-/issues/286399 https://gitlab.com/gitlab-org/gitlab/-/issues/286401 https://gitlab.com/gitlab-org/gitlab/-/issues/286402 https://gitlab.com/gitlab-org/gitlab/-/issues/286403 https://gitlab.com/gitlab-org/gitlab/-/issues/286405 https://gitlab.com/gitlab-org/gitlab/-/issues/286407 https://gitlab.com/gitlab-org/gitlab/-/issues/286408 https://paiza.io/projects/3Z8MphOIPYTJHvgBJmY7kw?language=php https://blog.goo.ne.jp/seresrnetyrt/e/e067af785fc9c076856ff83c5aa565bf https://note.com/wsrbwanretrytuy/n/nea2c0a7e08e3 https://www.postads.ph/ad/streaming-live-nadal-vs-medvedev-live-free-21th -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-20.45 1379/2417] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:164:2: error: expected specifier-qualifier-list before 'DCN21_HUBP_REG_COMMON_VARIABLE_LIST'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45 head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1 commit: 470f4be73099cc46478d2c708411fecde8197ca3 [1379/2417] drm/amdkcl: update DRM_AMD_DC_DCN3_0 to depends on legacy display config config: i386-randconfig-a003-20201120 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git git fetch --no-tags radeon-alex amd-20.45 git checkout 470f4be73099cc46478d2c708411fecde8197ca3 # save the attached .config to linux build tree make W=1 ARCH=i386 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All error/warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:42: >> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:164:2: error: >> expected specifier-qualifier-list before >> 'DCN21_HUBP_REG_COMMON_VARIABLE_LIST' 164 | DCN21_HUBP_REG_COMMON_VARIABLE_LIST;\ | ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:164:2: note: in definition of macro 'DCN30_HUBP_REG_COMMON_VARIABLE_LIST' 164 | DCN21_HUBP_REG_COMMON_VARIABLE_LIST;\ | ^~~ >> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:207:2: error: >> expected specifier-qualifier-list before 'DCN21_HUBP_REG_FIELD_VARIABLE_LIST' 207 | DCN21_HUBP_REG_FIELD_VARIABLE_LIST(type);\ | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:207:2: note: in definition of macro 'DCN30_HUBP_REG_FIELD_VARIABLE_LIST' 207 | DCN21_HUBP_REG_FIELD_VARIABLE_LIST(type);\ | ^~ >> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:207:2: error: >> expected specifier-qualifier-list before 'DCN21_HUBP_REG_FIELD_VARIABLE_LIST' 207 | DCN21_HUBP_REG_FIELD_VARIABLE_LIST(type);\ | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.h:207:2: note: in definition of macro 'DCN30_HUBP_REG_FIELD_VARIABLE_LIST' 207 | DCN21_HUBP_REG_FIELD_VARIABLE_LIST(type);\ | ^~ In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:68: drivers/gpu/drm/amd/include/navi10_ip_offset.h:269:52: warning: initialized field overwritten [-Woverride-init] 269 | #define DCN_BASE__INST0_SEG2 0x34C0 |^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:494:25: note: in expansion of macro 'DCN_BASE__INST0_SEG2' 494 | #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg | ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:496:19: note: in expansion of macro 'BASE_INNER' 496 | #define BASE(seg) BASE_INNER(seg) | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:503:14: note: in expansion of macro 'BASE' 503 | .reg_name = BASE(mm ## block ## id ## _ ## reg_name ## _BASE_IDX) + \ | ^~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_link_encoder.h:202:2: note: in expansion of macro 'SRI' 202 | SRI(TMDS_CTL_BITS, DIG, id), \ | ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_link_encoder.h:235:2: note: in expansion of macro 'DPCS_DCN2_CMN_REG_LIST' 235 | DPCS_DCN2_CMN_REG_LIST(id), \ | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:678:2: note: in expansion of macro 'DPCS_DCN2_REG_LIST' 678 | DPCS_DCN2_REG_LIST(id), \ | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:683:2: note: in expansion of macro 'link_regs' 683 | link_regs(0, A), | ^ drivers/gpu/drm/amd/include/navi10_ip_offset.h:269:52: note: (near initialization for 'link_enc_regs[0].TMDS_CTL_BITS') 269 | #define DCN_BASE__INST0_SEG2 0x34C0 |^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:494:25: note: in expansion of macro 'DCN_BASE__INST0_SEG2' 494 | #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg | ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:496:19: note: in expansion of macro 'BASE_INNER' 496 | #define BASE(seg) BASE_INNER(seg) | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:503:14: note: in expansion of macro 'BASE' 503 |
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #10 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286267 https://gitlab.com/gitlab-org/gitlab/-/issues/286268 https://gitlab.com/gitlab-org/gitlab/-/issues/286269 https://gitlab.com/gitlab-org/gitlab/-/issues/286270 https://gitlab.com/gitlab-org/gitlab/-/issues/286271 https://gitlab.com/gitlab-org/gitlab/-/issues/286272 https://gitlab.com/gitlab-org/gitlab/-/issues/286273 https://gitlab.com/gitlab-org/gitlab/-/issues/286274 https://gitlab.com/gitlab-org/gitlab/-/issues/286275 https://gitlab.com/gitlab-org/gitlab/-/issues/286276 https://gitlab.com/gitlab-org/gitlab/-/issues/286277 https://gitlab.com/gitlab-org/gitlab/-/issues/286278 https://gitlab.com/gitlab-org/gitlab/-/issues/286279 https://gitlab.com/gitlab-org/gitlab/-/issues/286280 https://gitlab.com/gitlab-org/gitlab/-/issues/286283 https://gitlab.com/gitlab-org/gitlab/-/issues/286284 https://gitlab.com/gitlab-org/gitlab/-/issues/286285 https://gitlab.com/gitlab-org/gitlab/-/issues/286286 https://gitlab.com/gitlab-org/gitlab/-/issues/286288 https://gitlab.com/gitlab-org/gitlab/-/issues/286289 https://gitlab.com/gitlab-org/gitlab/-/issues/286290 https://gitlab.com/gitlab-org/gitlab/-/issues/286291 https://gitlab.com/gitlab-org/gitlab/-/issues/286296 https://gitlab.com/gitlab-org/gitlab/-/issues/286292 https://gitlab.com/gitlab-org/gitlab/-/issues/286293 https://gitlab.com/gitlab-org/gitlab/-/issues/286294 https://gitlab.com/gitlab-org/gitlab/-/issues/286295 https://paiza.io/projects/9_kyoItxsCNoNsdo_o4QSg?language=php https://blog.goo.ne.jp/seresrnetyrt/e/75e77e394be21b909002812d3791d5d0 https://pastebin.com/46dkqGk8 https://note.com/wsrbwanretrytuy/n/nc84c128061e7 https://www.postads.ph/ad/ncaaf-football-live-stream-online-free https://vidiwo9044.medium.com/you-are-your-own-evolving-masterpiece-growing-2d031a2b55e1 https://vidiwo9044.medium.com/our-potential-is-directly-correlated-to-how-well-you-know-yourself-8162dc6898d2 https://vidiwo9044.medium.com/life-is-a-journey-of-twists-and-turns-peaks-and-valleys-mountains-to-climb-and-oceans-to-explore-67488d53e2a7 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #9 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286267 https://gitlab.com/gitlab-org/gitlab/-/issues/286268 https://gitlab.com/gitlab-org/gitlab/-/issues/286269 https://gitlab.com/gitlab-org/gitlab/-/issues/286270 https://gitlab.com/gitlab-org/gitlab/-/issues/286271 https://gitlab.com/gitlab-org/gitlab/-/issues/286272 https://gitlab.com/gitlab-org/gitlab/-/issues/286273 https://gitlab.com/gitlab-org/gitlab/-/issues/286274 https://gitlab.com/gitlab-org/gitlab/-/issues/286275 https://gitlab.com/gitlab-org/gitlab/-/issues/286276 https://gitlab.com/gitlab-org/gitlab/-/issues/286277 https://gitlab.com/gitlab-org/gitlab/-/issues/286278 https://gitlab.com/gitlab-org/gitlab/-/issues/286279 https://gitlab.com/gitlab-org/gitlab/-/issues/286280 https://gitlab.com/gitlab-org/gitlab/-/issues/286283 https://gitlab.com/gitlab-org/gitlab/-/issues/286284 https://gitlab.com/gitlab-org/gitlab/-/issues/286285 https://gitlab.com/gitlab-org/gitlab/-/issues/286286 https://gitlab.com/gitlab-org/gitlab/-/issues/286288 https://gitlab.com/gitlab-org/gitlab/-/issues/286289 https://gitlab.com/gitlab-org/gitlab/-/issues/286290 https://gitlab.com/gitlab-org/gitlab/-/issues/286291 https://gitlab.com/gitlab-org/gitlab/-/issues/286296 https://gitlab.com/gitlab-org/gitlab/-/issues/286292 https://gitlab.com/gitlab-org/gitlab/-/issues/286293 https://gitlab.com/gitlab-org/gitlab/-/issues/286294 https://gitlab.com/gitlab-org/gitlab/-/issues/286295 https://paiza.io/projects/9_kyoItxsCNoNsdo_o4QSg?language=php https://blog.goo.ne.jp/seresrnetyrt/e/75e77e394be21b909002812d3791d5d0 https://pastebin.com/46dkqGk8 https://note.com/wsrbwanretrytuy/n/nc84c128061e7 https://www.postads.ph/ad/ncaaf-football-live-stream-online-free -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #8 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286240 https://gitlab.com/gitlab-org/gitlab/-/issues/286241 https://gitlab.com/gitlab-org/gitlab/-/issues/286242 https://gitlab.com/gitlab-org/gitlab/-/issues/286243 https://gitlab.com/gitlab-org/gitlab/-/issues/286244 https://gitlab.com/gitlab-org/gitlab/-/issues/286245 https://gitlab.com/gitlab-org/gitlab/-/issues/286246 https://gitlab.com/gitlab-org/gitlab/-/issues/286247 https://gitlab.com/gitlab-org/gitlab/-/issues/286248 https://gitlab.com/gitlab-org/gitlab/-/issues/286249 https://gitlab.com/gitlab-org/gitlab/-/issues/286250 https://gitlab.com/gitlab-org/gitlab/-/issues/286251 https://gitlab.com/gitlab-org/gitlab/-/issues/286252 https://gitlab.com/gitlab-org/gitlab/-/issues/286253 https://gitlab.com/gitlab-org/gitlab/-/issues/286254 https://gitlab.com/gitlab-org/gitlab/-/issues/286255 https://gitlab.com/gitlab-org/gitlab/-/issues/286256 https://paiza.io/projects/9t2Xx-W2SBAgj_rN2FRRgQ?language=php https://blog.goo.ne.jp/seresrnetyrt/e/987ab172ddb60cd1dfa76e6e89ea7478 https://pastebin.com/AxWE36bL https://note.com/wsrbwanretrytuy/n/ne79a7f718241 https://www.postads.ph/ad/daniil-medvedev-vs-rafael-nadal-live-atp-finals-2020 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #7 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286167 https://gitlab.com/gitlab-org/gitlab/-/issues/286168 https://gitlab.com/gitlab-org/gitlab/-/issues/286169 https://gitlab.com/gitlab-org/gitlab/-/issues/286170 https://gitlab.com/gitlab-org/gitlab/-/issues/286171 https://gitlab.com/gitlab-org/gitlab/-/issues/286172 https://gitlab.com/gitlab-org/gitlab/-/issues/286173 https://gitlab.com/gitlab-org/gitlab/-/issues/286174 https://gitlab.com/gitlab-org/gitlab/-/issues/286175 https://gitlab.com/gitlab-org/gitlab/-/issues/286176 https://gitlab.com/gitlab-org/gitlab/-/issues/286177 https://gitlab.com/gitlab-org/gitlab/-/issues/286178 https://gitlab.com/gitlab-org/gitlab/-/issues/286179 https://gitlab.com/gitlab-org/gitlab/-/issues/286180 https://gitlab.com/gitlab-org/gitlab/-/issues/286181 https://gitlab.com/gitlab-org/gitlab/-/issues/286182 https://gitlab.com/gitlab-org/gitlab/-/issues/286183 https://gitlab.com/gitlab-org/gitlab/-/issues/286184 https://paiza.io/projects/5D3ktOKdrf4Z1YHFAapxbA?language=php https://blog.goo.ne.jp/seresrnetyrt/e/7240a3317332aa012fdc434c385855e8 https://pastebin.com/JS8t0Jkx https://note.com/wsrbwanretrytuy/n/n26eed81c2110 https://www.postads.ph/ad/man-united-vs-west-brom-live-live-streamsfree https://cidefov994.medium.com/some-people-might-take-interest-edab3d603952 https://cidefov994.medium.com/what-does-that-really-mean-success-to-one-person-could-mean-the-opposite-for-someone-else-37b8221ffc24 https://cidefov994.medium.com/life-is-a-journey-of-twists-and-turns-peaks-and-valleys-mountains-to-climb-and-oceans-to-explore-99afb23ec98 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 --- Comment #6 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286167 https://gitlab.com/gitlab-org/gitlab/-/issues/286168 https://gitlab.com/gitlab-org/gitlab/-/issues/286169 https://gitlab.com/gitlab-org/gitlab/-/issues/286170 https://gitlab.com/gitlab-org/gitlab/-/issues/286171 https://gitlab.com/gitlab-org/gitlab/-/issues/286172 https://gitlab.com/gitlab-org/gitlab/-/issues/286173 https://gitlab.com/gitlab-org/gitlab/-/issues/286174 https://gitlab.com/gitlab-org/gitlab/-/issues/286175 https://gitlab.com/gitlab-org/gitlab/-/issues/286176 https://gitlab.com/gitlab-org/gitlab/-/issues/286177 https://gitlab.com/gitlab-org/gitlab/-/issues/286178 https://gitlab.com/gitlab-org/gitlab/-/issues/286179 https://gitlab.com/gitlab-org/gitlab/-/issues/286180 https://gitlab.com/gitlab-org/gitlab/-/issues/286181 https://gitlab.com/gitlab-org/gitlab/-/issues/286182 https://gitlab.com/gitlab-org/gitlab/-/issues/286183 https://gitlab.com/gitlab-org/gitlab/-/issues/286184 https://paiza.io/projects/5D3ktOKdrf4Z1YHFAapxbA?language=php https://blog.goo.ne.jp/seresrnetyrt/e/7240a3317332aa012fdc434c385855e8 https://pastebin.com/JS8t0Jkx https://note.com/wsrbwanretrytuy/n/n26eed81c2110 https://www.postads.ph/ad/man-united-vs-west-brom-live-live-streamsfree -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205675] Display locks up. AMDGPU timeout
https://bugzilla.kernel.org/show_bug.cgi?id=205675 swebwaer (gosesen...@tjuln.com) changed: What|Removed |Added CC||gosesen...@tjuln.com --- Comment #5 from swebwaer (gosesen...@tjuln.com) --- https://gitlab.com/gitlab-org/gitlab/-/issues/286123 https://gitlab.com/gitlab-org/gitlab/-/issues/286124 https://gitlab.com/gitlab-org/gitlab/-/issues/286125 https://gitlab.com/gitlab-org/gitlab/-/issues/286126 https://gitlab.com/gitlab-org/gitlab/-/issues/286127 https://gitlab.com/gitlab-org/gitlab/-/issues/286128 https://gitlab.com/gitlab-org/gitlab/-/issues/286129 https://gitlab.com/gitlab-org/gitlab/-/issues/286130 https://gitlab.com/gitlab-org/gitlab/-/issues/286131 https://gitlab.com/gitlab-org/gitlab/-/issues/286132 https://gitlab.com/gitlab-org/gitlab/-/issues/286133 https://gitlab.com/gitlab-org/gitlab/-/issues/286134 https://gitlab.com/gitlab-org/gitlab/-/issues/286135 https://gitlab.com/gitlab-org/gitlab/-/issues/286136 https://gitlab.com/gitlab-org/gitlab/-/issues/286137 https://gitlab.com/gitlab-org/gitlab/-/issues/286138 https://gitlab.com/gitlab-org/gitlab/-/issues/286139 https://gitlab.com/gitlab-org/gitlab/-/issues/286140 https://gitlab.com/gitlab-org/gitlab/-/issues/286141 https://gitlab.com/gitlab-org/gitlab/-/issues/286142 https://paiza.io/projects/IIgp4_PBF019w0QzJsAvmw?language=php https://blog.goo.ne.jp/seresrnetyrt/e/d3529dc2c010507019a112ae7cb55881 https://pastebin.com/eTurKnYS https://note.com/wsrbwanretrytuy/n/n9f218cabe9df https://www.postads.ph/ad/man-utd-vs-west-brom-live-streaming -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] MAINTAINERS tag for cleanup robot
On Sat, 2020-11-21 at 09:18 -0800, James Bottomley wrote: > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: > > A difficult part of automating commits is composing the subsystem > > preamble in the commit log. For the ongoing effort of a fixer > > producing one or two fixes a release the use of 'treewide:' does > > not seem appropriate. > > > > It would be better if the normal prefix was used. Unfortunately > > normal is not consistent across the tree. > > > > D: Commit subsystem prefix > > > > ex/ for FPGA DFL DRIVERS > > > > D: fpga: dfl: > > I've got to bet this is going to cause more issues than it solves. > SCSI uses scsi: : for drivers but not every driver has a > MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer > things, but we're not consistent. Block uses blk-: for all > of it's stuff but almost no s have a MAINTAINERS entry. So > the next thing you're going to cause is an explosion of suggested > MAINTAINERs entries. As well as some changes require simultaneous changes across multiple subsystems. > Has anyone actually complained about treewide:? It depends on what you mean by treewide: If a treewide: patch is applied by some "higher level" maintainer, then generally, no. If the treewide patch is also cc'd to many individual maintainers, then yes, many many times. Mostly because patches cause what is in their view churn or that changes are not specific to their subsystem grounds. The treewide patch is sometimes dropped, sometimes broken up and generally not completely applied. What would be useful in many cases like this is for a pre and post application of the treewide patch to be compiled and the object code verified for lack of any logic change. Unfortunately, gcc does not guarantee deterministic compilation so this isn't feasible with at least gcc. Does clang guarantee this? I'm not sure it's possible: https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] MAINTAINERS tag for cleanup robot
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote: > A difficult part of automating commits is composing the subsystem > preamble in the commit log. For the ongoing effort of a fixer > producing > one or two fixes a release the use of 'treewide:' does not seem > appropriate. > > It would be better if the normal prefix was used. Unfortunately > normal is > not consistent across the tree. > > > D: Commit subsystem prefix > > ex/ for FPGA DFL DRIVERS > > D: fpga: dfl: > I've got to bet this is going to cause more issues than it solves. SCSI uses scsi: : for drivers but not every driver has a MAINTAINERS entry. We use either scsi: or scsi: core: for mid layer things, but we're not consistent. Block uses blk-: for all of it's stuff but almost no s have a MAINTAINERS entry. So the next thing you're going to cause is an explosion of suggested MAINTAINERs entries. Has anyone actually complained about treewide:? James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] MAINTAINERS tag for cleanup robot
On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> A difficult part of automating commits is composing the subsystem
> preamble in the commit log. For the ongoing effort of a fixer producing
> one or two fixes a release the use of 'treewide:' does not seem appropriate.
>
> It would be better if the normal prefix was used. Unfortunately normal is
> not consistent across the tree.
>
> So I am looking for comments for adding a new tag to the MAINTAINERS file
>
> D: Commit subsystem prefix
>
> ex/ for FPGA DFL DRIVERS
>
> D: fpga: dfl:
I'm all for it. Good luck with the effort. It's not completely trivial.
>From a decade ago:
https://lore.kernel.org/lkml/1289919077.28741.50.camel@Joe-Laptop/
(and that thread started with extra semicolon patches too)
> Continuing with cleaning up clang's -Wextra-semi-stmt
> diff --git a/Makefile b/Makefile
[]
> @@ -1567,20 +1567,21 @@ help:
> echo ''
> @echo 'Static analysers:'
> @echo ' checkstack - Generate a list of stack hogs'
> @echo ' versioncheck- Sanity check on version.h usage'
> @echo ' includecheck- Check for duplicate included header files'
> @echo ' export_report - List the usages of all exported symbols'
> @echo ' headerdep - Detect inclusion cycles in headers'
> @echo ' coccicheck - Check with Coccinelle'
> @echo ' clang-analyzer - Check with clang static analyzer'
> @echo ' clang-tidy - Check with clang-tidy'
> + @echo ' clang-tidy-fix - Check and fix with clang-tidy'
A pity the ordering of the code below isn't the same as the above.
> -PHONY += clang-tidy clang-analyzer
> +PHONY += clang-tidy-fix clang-tidy clang-analyzer
[]
> -clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json
> +clang-tidy-fix clang-tidy clang-analyzer:
> $(extmod-prefix)compile_commands.json
> $(call cmd,clang_tools)
> else
> -clang-tidy clang-analyzer:
> +clang-tidy-fix clang-tidy clang-analyzer:
[]
> diff --git a/scripts/clang-tools/run-clang-tools.py
> b/scripts/clang-tools/run-clang-tools.py
[]
> @@ -22,43 +22,57 @@ def parse_arguments():
[]
> parser.add_argument("type",
> -choices=["clang-tidy", "clang-analyzer"],
> +choices=["clang-tidy-fix", "clang-tidy",
> "clang-analyzer"],
etc...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] MAINTAINERS tag for cleanup robot
A difficult part of automating commits is composing the subsystem
preamble in the commit log. For the ongoing effort of a fixer producing
one or two fixes a release the use of 'treewide:' does not seem appropriate.
It would be better if the normal prefix was used. Unfortunately normal is
not consistent across the tree.
So I am looking for comments for adding a new tag to the MAINTAINERS file
D: Commit subsystem prefix
ex/ for FPGA DFL DRIVERS
D: fpga: dfl:
Continuing with cleaning up clang's -Wextra-semi-stmt
A significant number of warnings are caused by function like macros with
a trailing semicolon. For example.
#define FOO(a) a++; <-- extra, unneeded semicolon
void bar() {
int v = 0;
FOO(a);
}
Clang will warn at the FOO(a); expansion location. Instead of removing
the semicolon there, the fixer removes semicolon from the macro
definition. After the fixer, the code will be:
#define FOO(a) a++
void bar() {
int v = 0;
FOO(a);
}
The fixer review is
https://reviews.llvm.org/D91789
A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives.
The false positives are caused by macros passed to other macros and by
some macro expansions that did not have an extra semicolon.
This cleans up about 1,000 of the current 10,000 -Wextra-semi-stmt
warnings in linux-next.
An update to [RFC] clang tooling cleanup
This change adds the clang-tidy-fix as a top level target and
uses it to do the cleaning. The next iteration will do a loop of
cleaners. This will mean breaking clang-tidy-fix out into its own
processing function 'run_fixers'.
Makefile: Add toplevel target clang-tidy-fix to makefile
Calls clang-tidy with -fix option for a set of checkers that
programatically fixes the kernel source in place, treewide.
Signed-off-by: Tom Rix
---
Makefile | 7 ---
scripts/clang-tools/run-clang-tools.py | 20 +---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 47a8add4dd28..57756dbb767b 100644
--- a/Makefile
+++ b/Makefile
@@ -1567,20 +1567,21 @@ help:
echo ''
@echo 'Static analysers:'
@echo ' checkstack - Generate a list of stack hogs'
@echo ' versioncheck- Sanity check on version.h usage'
@echo ' includecheck- Check for duplicate included header files'
@echo ' export_report - List the usages of all exported symbols'
@echo ' headerdep - Detect inclusion cycles in headers'
@echo ' coccicheck - Check with Coccinelle'
@echo ' clang-analyzer - Check with clang static analyzer'
@echo ' clang-tidy - Check with clang-tidy'
+ @echo ' clang-tidy-fix - Check and fix with clang-tidy'
@echo ''
@echo 'Tools:'
@echo ' nsdeps - Generate missing symbol namespace
dependencies'
@echo ''
@echo 'Kernel selftest:'
@echo ' kselftest - Build and run kernel selftest'
@echo ' Build, install, and boot kernel before'
@echo ' running kselftest on it'
@echo ' Run as root for full coverage'
@echo ' kselftest-all - Build kernel selftest'
@@ -1842,30 +1843,30 @@ nsdeps: modules
quiet_cmd_gen_compile_commands = GEN $@
cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<,
$(real-prereqs))
$(extmod-prefix)compile_commands.json:
scripts/clang-tools/gen_compile_commands.py \
$(if $(KBUILD_EXTMOD),,$(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)) \
$(if $(CONFIG_MODULES), $(MODORDER)) FORCE
$(call if_changed,gen_compile_commands)
targets += $(extmod-prefix)compile_commands.json
-PHONY += clang-tidy clang-analyzer
+PHONY += clang-tidy-fix clang-tidy clang-analyzer
ifdef CONFIG_CC_IS_CLANG
quiet_cmd_clang_tools = CHECK $<
cmd_clang_tools = $(PYTHON3)
$(srctree)/scripts/clang-tools/run-clang-tools.py $@ $<
-clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json
+clang-tidy-fix clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json
$(call cmd,clang_tools)
else
-clang-tidy clang-analyzer:
+clang-tidy-fix clang-tidy clang-analyzer:
@echo "$@ requires CC=clang" >&2
@false
endif
# Scripts to check various things for consistency
# ---
PHONY += includecheck versioncheck coccicheck export_report
includecheck:
diff --git a/scripts/clang-tools/run-clang-tools.py
b/scripts/clang-tools/run-clang-tools.py
index fa7655c7cec0..c177ca822c56 100755
--- a/scripts/clang-tools/run-clang-tools.py
+++ b/scripts/clang-tools/run-clang-tools.py
@@ -22,43 +22,57 @@ def parse_arguments():
Returns:
args: Dict of parsed args
Has keys: [path, type]
"""
usage = """Run
[radeon-alex:amd-20.45 1835/2417] drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:788:5: error: redefinition of 'amdgpu_mn_register'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45
head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1
commit: 90e75e02fc4f30c8139b7321f8bbd635ec9d75ce [1835/2417] drm/amdkcl: dkms
support for hmm
config: sparc-randconfig-c004-20201120 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-20.45
git checkout 90e75e02fc4f30c8139b7321f8bbd635ec9d75ce
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:788:5: error: redefinition of
>> 'amdgpu_mn_register'
788 | int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned long addr)
| ^~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:85,
from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h:70:19: note: previous definition of
'amdgpu_mn_register' was here
70 | static inline int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned
long addr)
| ^~
>> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:806:6: error: redefinition of
>> 'amdgpu_mn_unregister'
806 | void amdgpu_mn_unregister(struct amdgpu_bo *bo)
| ^~~~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu.h:85,
from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h:76:20: note: previous definition of
'amdgpu_mn_unregister' was here
76 | static inline void amdgpu_mn_unregister(struct amdgpu_bo *bo) {}
|^~~~
In file included from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/amdgpu/amdgpu.h:195:19: warning: 'debug_evictions'
defined but not used [-Wunused-const-variable=]
195 | static const bool debug_evictions; /* = false */
| ^~~
drivers/gpu/drm/amd/amdgpu/amdgpu.h:194:18: warning: 'sched_policy' defined
but not used [-Wunused-const-variable=]
194 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
| ^~~~
In file included from drivers/gpu/drm/amd/display/dc/dc_types.h:33,
from drivers/gpu/drm/amd/display/dc/dm_services_types.h:30,
from drivers/gpu/drm/amd/include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:64,
from
drivers/gpu/drm/amd/backport/include/kcl/kcl_amdgpu.h:6,
from drivers/gpu/drm/amd/backport/backport.h:18,
from :
drivers/gpu/drm/amd/display/include/fixed31_32.h:76:32: warning:
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
|^~
drivers/gpu/drm/amd/display/include/fixed31_32.h:75:32: warning:
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
|^~~~
drivers/gpu/drm/amd/display/include/fixed31_32.h:74:32: warning:
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
|^~
drivers/gpu/drm/amd/display/include/fixed31_32.h:73:32: warning:
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
|^~~
drivers/gpu/drm/amd/display/include/fixed31_32.h:72:32: warning:
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
|^~~
drivers/gpu/drm/amd/display/include/fixed31_32.h:67:32: warning:
'dc_fixpt_zero' defined but not used [-Wunused-const-variable=]
67 | static const struct fixed31_32 dc_fixpt_zero = { 0 };
|
Re: [PATCH v5 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Fri 2020-11-13 12:54:41, Sakari Ailus wrote: > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM > pixel formats denoted by fourccs. The fourcc encoding is the same for both > so the same implementation can be used. > > Suggested-by: Mauro Carvalho Chehab > Signed-off-by: Sakari Ailus The last version looks fine to me. Reviewed-by: Petr Mladek Best Regards, Petr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: hyperv_fb: Directly use the MMIO VRAM
Late in 2019, 2 commits (see the 2 Fixes tags) were introduced to
mitigate the slow framebuffer issue. Now that we have fixed the
slowness issue by correctly mapping the MMIO VRAM (see
commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping
the VRAM")), we can remove most of the code introduced by the 2 commits,
i.e. we no longer need to allocate physical memory and use it to back up
the VRAM in Generation-1 VM, and we also no longer need to allocate
physical memory to back up the framebuffer in a Generation-2 VM and copy
the framebuffer to the real VRAM.
synthvid_deferred_io() is kept, because it's still desirable to send the
SYNTHVID_DIRT message only for the exact dirty rectangle, and only when
needed.
Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V
frame buffer driver")
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on
HyperV Gen 1 VMs.")
Cc: Wei Hu
Cc: Boqun Feng
Signed-off-by: Dexuan Cui
---
This patch changes drivers/video/fbdev/Kconfig, but I hope this can
still go through the Hyper-V tree
https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-next
because it's unlikely to cause any build issue to other fbdev drivers
(that line was introduced by 3a6fb6c4255c only for hyperv_fb.c)
Note: this patch is based on the Hyper-V tree's hyperv-fixes branch, but
it should also apply cleanly to the branch hyperv-next if the commit
5f1251a48c17 is applied first. This patch is for v5.11 rather than
v5.10.
drivers/video/fbdev/Kconfig | 1 -
drivers/video/fbdev/hyperv_fb.c | 170 ++--
2 files changed, 9 insertions(+), 162 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 402e85450bb5..05b37fb3c6d6 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2205,7 +2205,6 @@ config FB_HYPERV
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_DEFERRED_IO
- select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
help
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 58c74d2356ba..8131f4e66f98 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -31,16 +31,6 @@
* "set-vmvideo" command. For example
* set-vmvideo -vmname name -horizontalresolution:1920 \
* -verticalresolution:1200 -resolutiontype single
- *
- * Gen 1 VMs also support direct using VM's physical memory for framebuffer.
- * It could improve the efficiency and performance for framebuffer and VM.
- * This requires to allocate contiguous physical memory from Linux kernel's
- * CMA memory allocator. To enable this, supply a kernel parameter to give
- * enough memory space to CMA allocator for framebuffer. For example:
- *cma=130m
- * This gives 130MB memory to CMA allocator that can be allocated to
- * framebuffer. For reference, 8K resolution (7680x4320) takes about
- * 127MB memory.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -267,16 +257,8 @@ struct hvfb_par {
/* If true, the VSC notifies the VSP on every framebuffer change */
bool synchronous_fb;
- /* If true, need to copy from deferred IO mem to framebuffer mem */
- bool need_docopy;
-
struct notifier_block hvfb_panic_nb;
- /* Memory for deferred IO and frame buffer itself */
- unsigned char *dio_vp;
- unsigned char *mmio_vp;
- phys_addr_t mmio_pp;
-
/* Dirty rectangle, protected by delayed_refresh_lock */
int x1, y1, x2, y2;
bool delayed_refresh;
@@ -405,21 +387,6 @@ synthvid_update(struct fb_info *info, int x1, int y1, int
x2, int y2)
return 0;
}
-static void hvfb_docopy(struct hvfb_par *par,
- unsigned long offset,
- unsigned long size)
-{
- if (!par || !par->mmio_vp || !par->dio_vp || !par->fb_ready ||
- size == 0 || offset >= dio_fb_size)
- return;
-
- if (offset + size > dio_fb_size)
- size = dio_fb_size - offset;
-
- memcpy(par->mmio_vp + offset, par->dio_vp + offset, size);
-}
-
-/* Deferred IO callback */
static void synthvid_deferred_io(struct fb_info *p,
struct list_head *pagelist)
{
@@ -444,10 +411,6 @@ static void synthvid_deferred_io(struct fb_info *p,
y2 = end / p->fix.line_length;
miny = min_t(int, miny, y1);
maxy = max_t(int, maxy, y2);
-
- /* Copy from dio space to mmio address */
- if (par->fb_ready && par->need_docopy)
- hvfb_docopy(par, start, PAGE_SIZE);
}
if (par->fb_ready && par->update)
@@ -704,7 +667,7 @@ static int synthvid_send_config(struct hv_device *hdev)
msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
Re: [PATCH] video: hyperv_fb: Directly use the MMIO VRAM
Hi Dexuan,
On Fri, Nov 20, 2020 at 05:45:47PM -0800, Dexuan Cui wrote:
> Late in 2019, 2 commits (see the 2 Fixes tags) were introduced to
> mitigate the slow framebuffer issue. Now that we have fixed the
> slowness issue by correctly mapping the MMIO VRAM (see
> commit 5f1251a48c17 ("video: hyperv_fb: Fix the cache type when mapping
> the VRAM")), we can remove most of the code introduced by the 2 commits,
> i.e. we no longer need to allocate physical memory and use it to back up
> the VRAM in Generation-1 VM, and we also no longer need to allocate
> physical memory to back up the framebuffer in a Generation-2 VM and copy
> the framebuffer to the real VRAM.
>
> synthvid_deferred_io() is kept, because it's still desirable to send the
> SYNTHVID_DIRT message only for the exact dirty rectangle, and only when
> needed.
>
> Fixes: d21987d709e8 ("video: hyperv: hyperv_fb: Support deferred IO for
> Hyper-V frame buffer driver")
> Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on
> HyperV Gen 1 VMs.")
> Cc: Wei Hu
> Cc: Boqun Feng
> Signed-off-by: Dexuan Cui
After I applied this patch and patch ("video: hyperv_fb: Fix the cache
type when mapping the VRAM") on my development branch (with Michael's
patchset for ARM64 core support on Hyper-V), and everything worked fine.
So feel free to add:
Tested-by: Boqun Feng
Regards,
Bqoun
> ---
>
> This patch changes drivers/video/fbdev/Kconfig, but I hope this can
> still go through the Hyper-V tree
> https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-next
> because it's unlikely to cause any build issue to other fbdev drivers
> (that line was introduced by 3a6fb6c4255c only for hyperv_fb.c)
>
> Note: this patch is based on the Hyper-V tree's hyperv-fixes branch, but
> it should also apply cleanly to the branch hyperv-next if the commit
> 5f1251a48c17 is applied first. This patch is for v5.11 rather than
> v5.10.
>
> drivers/video/fbdev/Kconfig | 1 -
> drivers/video/fbdev/hyperv_fb.c | 170 ++--
> 2 files changed, 9 insertions(+), 162 deletions(-)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 402e85450bb5..05b37fb3c6d6 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2205,7 +2205,6 @@ config FB_HYPERV
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> select FB_DEFERRED_IO
> - select DMA_CMA if HAVE_DMA_CONTIGUOUS && CMA
> help
> This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index 58c74d2356ba..8131f4e66f98 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -31,16 +31,6 @@
> * "set-vmvideo" command. For example
> * set-vmvideo -vmname name -horizontalresolution:1920 \
> * -verticalresolution:1200 -resolutiontype single
> - *
> - * Gen 1 VMs also support direct using VM's physical memory for framebuffer.
> - * It could improve the efficiency and performance for framebuffer and VM.
> - * This requires to allocate contiguous physical memory from Linux kernel's
> - * CMA memory allocator. To enable this, supply a kernel parameter to give
> - * enough memory space to CMA allocator for framebuffer. For example:
> - *cma=130m
> - * This gives 130MB memory to CMA allocator that can be allocated to
> - * framebuffer. For reference, 8K resolution (7680x4320) takes about
> - * 127MB memory.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -267,16 +257,8 @@ struct hvfb_par {
> /* If true, the VSC notifies the VSP on every framebuffer change */
> bool synchronous_fb;
>
> - /* If true, need to copy from deferred IO mem to framebuffer mem */
> - bool need_docopy;
> -
> struct notifier_block hvfb_panic_nb;
>
> - /* Memory for deferred IO and frame buffer itself */
> - unsigned char *dio_vp;
> - unsigned char *mmio_vp;
> - phys_addr_t mmio_pp;
> -
> /* Dirty rectangle, protected by delayed_refresh_lock */
> int x1, y1, x2, y2;
> bool delayed_refresh;
> @@ -405,21 +387,6 @@ synthvid_update(struct fb_info *info, int x1, int y1,
> int x2, int y2)
> return 0;
> }
>
> -static void hvfb_docopy(struct hvfb_par *par,
> - unsigned long offset,
> - unsigned long size)
> -{
> - if (!par || !par->mmio_vp || !par->dio_vp || !par->fb_ready ||
> - size == 0 || offset >= dio_fb_size)
> - return;
> -
> - if (offset + size > dio_fb_size)
> - size = dio_fb_size - offset;
> -
> - memcpy(par->mmio_vp + offset, par->dio_vp + offset, size);
> -}
> -
> -/* Deferred IO callback */
> static void synthvid_deferred_io(struct fb_info *p,
>struct list_head *pagelist)
> {
> @@ -444,10 +411,6 @@ static void synthvid_deferred_io(struct fb_info
Re: [PATCH v3 02/12] drm: Unamp the entire device address space on device unplug
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Invalidate all BOs CPU mappings once device is removed. v3: Move the code from TTM into drm_dev_unplug Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König --- drivers/gpu/drm/drm_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 13068fd..d550fd5 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -479,6 +479,9 @@ void drm_dev_unplug(struct drm_device *dev) synchronize_srcu(_unplug_srcu); drm_dev_unregister(dev); + + /* Clear all CPU mappings pointing to this device */ + unmap_mapping_range(dev->anon_inode->i_mapping, 0, 0, 1); } EXPORT_SYMBOL(drm_dev_unplug); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link them together so they
are freed when the device is finally reaped?
Regards,
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..ff3d39f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
+ file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!file->dummy_page) {
+ ret = -ENOMEM;
+ goto out_prime_destroy;
+ }
+
return file;
out_prime_destroy:
@@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
+ __free_page(file->dummy_page);
+
drm_prime_destroy_file_private(>prime);
WARN_ON(!list_empty(>event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7..987b45c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
ret = drm_prime_add_buf_handle(_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!obj->dummy_page)
+ ret = -ENOMEM;
+ }
+
mutex_unlock(_priv->prime.lock);
if (ret)
goto fail;
@@ -1020,6 +1027,9 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj,
struct sg_table *sg)
dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
+
+ __free_page(obj->dummy_page);
+
/* remove the reference */
dma_buf_put(dma_buf);
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 716990b..2a011fc 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -346,6 +346,8 @@ struct drm_file {
*/
struct drm_prime_file_private prime;
+ struct page *dummy_page;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 337a483..76a97a3 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -311,6 +311,8 @@ struct drm_gem_object {
*
*/
const struct drm_gem_object_funcs *funcs;
+
+ struct page *dummy_page;
};
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/12] drm/ttm: Set dma addr to null after freee
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: Fixes oops. That file doesn't even exist any more. What oops should this fix? Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index b40a467..b0df328 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -1160,6 +1160,8 @@ void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt) dma_unmap_page(dev, tt->dma_address[i], num_pages * PAGE_SIZE, DMA_BIDIRECTIONAL); + tt->dma_address[i] = 0; + i += num_pages; } ttm_pool_unpopulate(>ttm); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: fsl-imx-drm: fix example compatible string
On Fri, 13 Nov 2020 18:06:19 +0300, Cengiz Can wrote: > Example `display-subsystem` has an incorrect compatible string. > > Required properties section tells that developers should use > "fsl,imx-display-subsystem" as "compatible" string but the example > misses 'imx-' prefix. > > Change example to have correct "compatible" string. > > Signed-off-by: Cengiz Can > --- > Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
On Thu, Nov 12, 2020 at 04:37:03PM +0800, Hsin-Yi Wang wrote:
> anx7625 requires 3 power supply regulators.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> .../display/bridge/analogix,anx7625.yaml | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> index 60585a4fc22b..1aa08f10d894 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> @@ -34,6 +34,18 @@ properties:
> description: used for reset chip control, RESET_N pin B7.
> maxItems: 1
>
> + vdd10-supply:
> +description: Regulator that provides the supply 1.0V power.
> +maxItems: 1
> +
> + vdd18-supply:
> +description: Regulator that provides the supply 1.8V power.
> +maxItems: 1
> +
> + vdd33-supply:
> +description: Regulator that provides the supply 3.3V power.
> +maxItems: 1
Supplies are always a single item, so you can drop maxItems.
> +
>ports:
> type: object
>
> @@ -55,6 +67,9 @@ properties:
> required:
>- compatible
>- reg
> + - vdd10-supply
> + - vdd18-supply
> + - vdd33-supply
>- ports
>
> additionalProperties: false
> @@ -72,6 +87,9 @@ examples:
> reg = <0x58>;
> enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> +vdd10-supply = <_mipibrdg>;
> +vdd18-supply = <_mipibrdg>;
> +vdd33-supply = <_mipibrdg>;
>
> ports {
> #address-cells = <1>;
> --
> 2.29.2.222.g5d2a92d10f8-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 03/17] misc/habana: Stop using frame_vector helpers
On Thu, Nov 19, 2020 at 4:41 PM Daniel Vetter wrote:
>
> All we need are a pages array, pin_user_pages_fast can give us that
> directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
>
> Note that pin_user_pages_fast is a safe replacement despite the
> seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
> ptes are marked with pte_mkspecial (which pup_fast rejects in the
> fastpath), and only architectures supporting that support the
> pin_user_pages_fast fastpath.
>
> Reviewed-by: John Hubbard
> Signed-off-by: Daniel Vetter
> Cc: Christoph Hellwig
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Oded Gabbay
> Cc: Omer Shpigelman
> Cc: Ofir Bitton
> Cc: Tomer Tayar
> Cc: Moti Haimovski
> Cc: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: Pawel Piskorski
> Signed-off-by: Daniel Vetter
> --
> v2: Use unpin_user_pages_dirty_lock (John)
> v3: Update kerneldoc (Oded)
> v6: Explain why pup_fast is safe, after discussions with John and
> Christoph.
> ---
> drivers/misc/habanalabs/Kconfig | 1 -
> drivers/misc/habanalabs/common/habanalabs.h | 6 ++-
> drivers/misc/habanalabs/common/memory.c | 49 -
> 3 files changed, 22 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/Kconfig b/drivers/misc/habanalabs/Kconfig
> index 1640340d3e62..293d79811372 100644
> --- a/drivers/misc/habanalabs/Kconfig
> +++ b/drivers/misc/habanalabs/Kconfig
> @@ -6,7 +6,6 @@
> config HABANA_AI
> tristate "HabanaAI accelerators (habanalabs)"
> depends on PCI && HAS_IOMEM
> - select FRAME_VECTOR
> select GENERIC_ALLOCATOR
> select HWMON
> help
> diff --git a/drivers/misc/habanalabs/common/habanalabs.h
> b/drivers/misc/habanalabs/common/habanalabs.h
> index 80d4d7385ffe..272aa3f29200 100644
> --- a/drivers/misc/habanalabs/common/habanalabs.h
> +++ b/drivers/misc/habanalabs/common/habanalabs.h
> @@ -921,7 +921,8 @@ struct hl_ctx_mgr {
> * struct hl_userptr - memory mapping chunk information
> * @vm_type: type of the VM.
> * @job_node: linked-list node for hanging the object on the Job's list.
> - * @vec: pointer to the frame vector.
> + * @pages: pointer to struct page array
> + * @npages: size of @pages array
> * @sgt: pointer to the scatter-gather table that holds the pages.
> * @dir: for DMA unmapping, the direction must be supplied, so save it.
> * @debugfs_list: node in debugfs list of command submissions.
> @@ -932,7 +933,8 @@ struct hl_ctx_mgr {
> struct hl_userptr {
> enum vm_type_t vm_type; /* must be first */
> struct list_headjob_node;
> - struct frame_vector *vec;
> + struct page **pages;
> + unsigned intnpages;
> struct sg_table *sgt;
> enum dma_data_direction dir;
> struct list_headdebugfs_list;
> diff --git a/drivers/misc/habanalabs/common/memory.c
> b/drivers/misc/habanalabs/common/memory.c
> index 84227819e4d1..0b220221873d 100644
> --- a/drivers/misc/habanalabs/common/memory.c
> +++ b/drivers/misc/habanalabs/common/memory.c
> @@ -1291,45 +1291,41 @@ static int get_user_memory(struct hl_device *hdev,
> u64 addr, u64 size,
> return -EFAULT;
> }
>
> - userptr->vec = frame_vector_create(npages);
> - if (!userptr->vec) {
> + userptr->pages = kvmalloc_array(npages, sizeof(*userptr->pages),
> + GFP_KERNEL);
> + if (!userptr->pages) {
> dev_err(hdev->dev, "Failed to create frame vector\n");
> return -ENOMEM;
> }
Hi Daniel, sorry but missed this in my initial review.
The error message no longer fits the code, and actually it isn't
needed as we don't print error messages on malloc failures.
With that fixed, this patch is:
Reviewed-by: Oded Gabbay
>
> - rc = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
> - userptr->vec);
> + rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
> +userptr->pages);
>
> if (rc != npages) {
> dev_err(hdev->dev,
> "Failed to map host memory, user ptr probably
> wrong\n");
> if (rc < 0)
> - goto destroy_framevec;
> + goto destroy_pages;
> + npages = rc;
> rc = -EFAULT;
> - goto put_framevec;
> - }
> -
> - if (frame_vector_to_pages(userptr->vec) < 0) {
> - dev_err(hdev->dev,
> - "Failed to translate frame vector to pages\n");
> - rc = -EFAULT;
> - goto put_framevec;
[radeon-alex:amd-20.45 198/2417] ./usr/include/drm/amdgpu_drm.h:314:2: error: unknown type name 'int32_t'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45 head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1 commit: 641803ba0aabf8d823eb6cf6667dda3fdca58872 [198/2417] drm/amdgpu: [hybrid] add semaphore object support config: x86_64-randconfig-a011-20201120 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 3ded927cf80ac519f9f9c4664fef08787f7c537d) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git git fetch --no-tags radeon-alex amd-20.45 git checkout 641803ba0aabf8d823eb6cf6667dda3fdca58872 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from :1: ./usr/include/drm/amdgpu_drm.h:304:2: error: unknown type name 'uint32_t' uint32_top; ^ ./usr/include/drm/amdgpu_drm.h:305:2: error: unknown type name 'uint32_t' uint32_thandle; ^ ./usr/include/drm/amdgpu_drm.h:306:2: error: unknown type name 'uint32_t' uint32_tctx_id; ^ ./usr/include/drm/amdgpu_drm.h:307:2: error: unknown type name 'uint32_t' uint32_tip_type; ^ ./usr/include/drm/amdgpu_drm.h:308:2: error: unknown type name 'uint32_t' uint32_tip_instance; ^ ./usr/include/drm/amdgpu_drm.h:309:2: error: unknown type name 'uint32_t' uint32_tring; ^ ./usr/include/drm/amdgpu_drm.h:310:2: error: unknown type name 'uint64_t' uint64_tseq; ^ >> ./usr/include/drm/amdgpu_drm.h:314:2: error: unknown type name 'int32_t' int32_t fd; ^ ./usr/include/drm/amdgpu_drm.h:315:2: error: unknown type name 'uint32_t' uint32_thandle; ^ ./usr/include/drm/amdgpu_drm.h:939:4: error: unknown type name 'uint32_t' uint32_t aperture; ^ ./usr/include/drm/amdgpu_drm.h:940:4: error: unknown type name 'uint32_t' uint32_t _pad; ^ ./usr/include/drm/amdgpu_drm.h:1167:2: error: unknown type name 'uint64_t' uint64_t start; ^ ./usr/include/drm/amdgpu_drm.h:1168:2: error: unknown type name 'uint64_t' uint64_t end; ^ 13 errors generated. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mm: Extract might_alloc() debug check
On Fri, Nov 20, 2020 at 10:54:43AM +0100, Daniel Vetter wrote:
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index d5ece7a9a403..f94405d43fd1 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) { }
> static inline void fs_reclaim_release(gfp_t gfp_mask) { }
> #endif
>
> +/**
> + * might_alloc - Marks possible allocation sites
> + * @gfp_mask: gfp_t flags that would be use to allocate
> + *
> + * Similar to might_sleep() and other annotations this can be used in
> functions
> + * that might allocate, but often dont. Compiles to nothing without
> + * CONFIG_LOCKDEP. Includes a conditional might_sleep() if @gfp allows
> blocking.
> + */
> +static inline void might_alloc(gfp_t gfp_mask)
> +{
> + fs_reclaim_acquire(gfp_mask);
> + fs_reclaim_release(gfp_mask);
> +
> + might_sleep_if(gfpflags_allow_blocking(gfp_mask));
> +}
Reviewed-by: Jason Gunthorpe
Oh, I just had a another thread with Matt about xarray, this would be
perfect to add before xas_nomem():
diff --git a/lib/idr.c b/lib/idr.c
index f4ab4f4aa3c7f5..722d9ddff53221 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -391,6 +391,8 @@ int ida_alloc_range(struct ida *ida, unsigned int min,
unsigned int max,
if ((int)max < 0)
max = INT_MAX;
+ might_alloc(gfp);
+
retry:
xas_lock_irqsave(, flags);
next:
diff --git a/lib/xarray.c b/lib/xarray.c
index 5fa51614802ada..dd260ee7dcae9a 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -1534,6 +1534,8 @@ void *__xa_store(struct xarray *xa, unsigned long index,
void *entry, gfp_t gfp)
XA_STATE(xas, xa, index);
void *curr;
+ might_alloc(gfp);
+
if (WARN_ON_ONCE(xa_is_advanced(entry)))
return XA_ERROR(-EINVAL);
if (xa_track_free(xa) && !entry)
@@ -1600,6 +1602,8 @@ void *__xa_cmpxchg(struct xarray *xa, unsigned long index,
XA_STATE(xas, xa, index);
void *curr;
+ might_alloc(gfp);
+
if (WARN_ON_ONCE(xa_is_advanced(entry)))
return XA_ERROR(-EINVAL);
@@ -1637,6 +1641,8 @@ int __xa_insert(struct xarray *xa, unsigned long index,
void *entry, gfp_t gfp)
XA_STATE(xas, xa, index);
void *curr;
+ might_alloc(gfp);
+
if (WARN_ON_ONCE(xa_is_advanced(entry)))
return -EINVAL;
if (!entry)
@@ -1806,6 +1812,8 @@ int __xa_alloc(struct xarray *xa, u32 *id, void *entry,
{
XA_STATE(xas, xa, 0);
+ might_alloc(gfp);
+
if (WARN_ON_ONCE(xa_is_advanced(entry)))
return -EINVAL;
if (WARN_ON_ONCE(!xa_track_free(xa)))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG] drm/vkms: Failure when using drmGetConnectorCurrent()
Hello, We have a patch in Weston to replace drmGetConnector() calls with drmGetConnectorCurrent(): https://gitlab.freedesktop.org/wayland/weston/-/issues/437 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518 Unfortunately this is not working when we use VKMS (upstream version tested). Please see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518#note_700345 for more information, and feel free to jump into the discussion. If there's more helpful information that I can share, please let me know. Thank you, Leandro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/vc4: kms: Don't disable the muxing of an active CRTC
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.
However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new state.
Fix this by setting a flag on the CRTC state when the muxing has been
changed, and only change the muxing configuration when that flag is there.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 3 ++
drivers/gpu/drm/vc4/vc4_kms.c | 81 +++
2 files changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index fcfeef0949af..c5f2944d5bc6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -532,6 +532,9 @@ struct vc4_crtc_state {
unsigned int top;
unsigned int bottom;
} margins;
+
+ /* Transitional state below, only valid during atomic commits */
+ bool update_muxing;
};
#define VC4_HVS_CHANNEL_DISABLED ((unsigned int)-1)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 0bbd7b554275..ba310c0ab5f6 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -239,10 +239,7 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
{
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
- unsigned char dsp2_mux = 0;
- unsigned char dsp3_mux = 3;
- unsigned char dsp4_mux = 3;
- unsigned char dsp5_mux = 3;
+ unsigned char mux;
unsigned int i;
u32 reg;
@@ -250,50 +247,59 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
struct vc4_crtc_state *vc4_state =
to_vc4_crtc_state(crtc_state);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
- if (!crtc_state->active)
+ if (!vc4_state->update_muxing)
continue;
switch (vc4_crtc->data->hvs_output) {
case 2:
- dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
+ mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
+ reg = HVS_READ(SCALER_DISPECTRL);
+ HVS_WRITE(SCALER_DISPECTRL,
+ (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
+ VC4_SET_FIELD(mux,
SCALER_DISPECTRL_DSP2_MUX));
break;
case 3:
- dsp3_mux = vc4_state->assigned_channel;
+ if (vc4_state->assigned_channel ==
VC4_HVS_CHANNEL_DISABLED)
+ mux = 3;
+ else
+ mux = vc4_state->assigned_channel;
+
+ reg = HVS_READ(SCALER_DISPCTRL);
+ HVS_WRITE(SCALER_DISPCTRL,
+ (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
+ VC4_SET_FIELD(mux, SCALER_DISPCTRL_DSP3_MUX));
break;
case 4:
- dsp4_mux = vc4_state->assigned_channel;
+ if (vc4_state->assigned_channel ==
VC4_HVS_CHANNEL_DISABLED)
+ mux = 3;
+ else
+ mux = vc4_state->assigned_channel;
+
+ reg = HVS_READ(SCALER_DISPEOLN);
+ HVS_WRITE(SCALER_DISPEOLN,
+ (reg & ~SCALER_DISPEOLN_DSP4_MUX_MASK) |
+ VC4_SET_FIELD(mux, SCALER_DISPEOLN_DSP4_MUX));
+
break;
case 5:
- dsp5_mux = vc4_state->assigned_channel;
+ if (vc4_state->assigned_channel ==
VC4_HVS_CHANNEL_DISABLED)
+ mux = 3;
+ else
+ mux = vc4_state->assigned_channel;
+
+ reg = HVS_READ(SCALER_DISPDITHER);
+ HVS_WRITE(SCALER_DISPDITHER,
+ (reg & ~SCALER_DISPDITHER_DSP5_MUX_MASK) |
+ VC4_SET_FIELD(mux,
SCALER_DISPDITHER_DSP5_MUX));
break;
default:
break;
}
}
-
- reg = HVS_READ(SCALER_DISPECTRL);
- HVS_WRITE(SCALER_DISPECTRL,
- (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
- VC4_SET_FIELD(dsp2_mux, SCALER_DISPECTRL_DSP2_MUX));
-
- reg = HVS_READ(SCALER_DISPCTRL);
- HVS_WRITE(SCALER_DISPCTRL,
- (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
-
Re: [PATCH v3 6/7] drm/vc4: kms: Store the unassigned channel list in the state
Hi!
On Thu, Nov 19, 2020 at 09:59:15AM +0100, Thomas Zimmermann wrote:
> Am 05.11.20 um 14:56 schrieb Maxime Ripard:
> > If a CRTC is enabled but not active, and that we're then doing a page
> > flip on another CRTC, drm_atomic_get_crtc_state will bring the first
> > CRTC state into the global state, and will make us wait for its vblank
> > as well, even though that might never occur.
> >
> > Instead of creating the list of the free channels each time atomic_check
> > is called, and calling drm_atomic_get_crtc_state to retrieve the
> > allocated channels, let's create a private state object in the main
> > atomic state, and use it to store the available channels.
> >
> > Since vc4 has a semaphore (with a value of 1, so a lock) in its commit
> > implementation to serialize all the commits, even the nonblocking ones, we
> > are free from the use-after-free race if two subsequent commits are not ran
> > in their submission order.
> >
> > Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel
> > automatically")
> > Reviewed-by: Hoegeun Kwon
> > Tested-by: Hoegeun Kwon
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> > drivers/gpu/drm/vc4/vc4_kms.c | 124 +++---
> > 2 files changed, 100 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> > index bdbb9540d47d..014113823647 100644
> > --- a/drivers/gpu/drm/vc4/vc4_drv.h
> > +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> > @@ -219,6 +219,7 @@ struct vc4_dev {
> > struct drm_modeset_lock ctm_state_lock;
> > struct drm_private_obj ctm_manager;
> > + struct drm_private_obj hvs_channels;
> > struct drm_private_obj load_tracker;
> > /* List of vc4_debugfs_info_entry for adding to debugfs once
> > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> > index 499c6914fce4..0a231ae500e5 100644
> > --- a/drivers/gpu/drm/vc4/vc4_kms.c
> > +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> > @@ -37,6 +37,17 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
> > drm_private_state *priv)
> > return container_of(priv, struct vc4_ctm_state, base);
> > }
> > +struct vc4_hvs_state {
> > + struct drm_private_state base;
> > + unsigned int unassigned_channels;
> > +};
> > +
> > +static struct vc4_hvs_state *
> > +to_vc4_hvs_state(struct drm_private_state *priv)
> > +{
> > + return container_of(priv, struct vc4_hvs_state, base);
> > +}
> > +
> > struct vc4_load_tracker_state {
> > struct drm_private_state base;
> > u64 hvs_load;
> > @@ -662,6 +673,70 @@ static int vc4_load_tracker_obj_init(struct vc4_dev
> > *vc4)
> > return drmm_add_action_or_reset(>base, vc4_load_tracker_obj_fini,
> > NULL);
> > }
> > +static struct drm_private_state *
> > +vc4_hvs_channels_duplicate_state(struct drm_private_obj *obj)
> > +{
> > + struct vc4_hvs_state *state;
> > +
> > + state = kmemdup(obj->state, sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return NULL;
> > +
> > + __drm_atomic_helper_private_obj_duplicate_state(obj, >base);
> > +
> > + return >base;
> > +}
> > +
> > +static void vc4_hvs_channels_destroy_state(struct drm_private_obj *obj,
> > + struct drm_private_state *state)
> > +{
> > + struct vc4_hvs_state *hvs_state;
> > +
> > + hvs_state = to_vc4_hvs_state(state);
> > + kfree(hvs_state);
> > +}
> > +
> > +static const struct drm_private_state_funcs vc4_hvs_state_funcs = {
> > + .atomic_duplicate_state = vc4_hvs_channels_duplicate_state,
> > + .atomic_destroy_state = vc4_hvs_channels_destroy_state,
> > +};
> > +
> > +static void vc4_hvs_channels_obj_fini(struct drm_device *dev, void *unused)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(dev);
> > +
> > + drm_atomic_private_obj_fini(>hvs_channels);
> > +}
> > +
> > +static int vc4_hvs_channels_obj_init(struct vc4_dev *vc4)
> > +{
> > + struct vc4_hvs_state *state;
> > +
> > + state = kzalloc(sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return -ENOMEM;
> > +
> > + state->unassigned_channels = GENMASK(HVS_NUM_CHANNELS - 1, 0);
> > + drm_atomic_private_obj_init(>base, >hvs_channels,
> > + >base,
> > + _hvs_state_funcs);
> > +
> > + return drmm_add_action_or_reset(>base, vc4_hvs_channels_obj_fini,
> > NULL);
> > +}
> > +
> > +static struct vc4_hvs_state *
> > +vc4_hvs_get_global_state(struct drm_atomic_state *state)
> > +{
> > + struct vc4_dev *vc4 = to_vc4_dev(state->dev);
> > + struct drm_private_state *priv_state;
> > +
> > + priv_state = drm_atomic_get_private_obj_state(state,
> > >hvs_channels);
> > + if (IS_ERR(priv_state))
> > + return ERR_CAST(priv_state);
> > +
> > + return to_vc4_hvs_state(priv_state);
> > +}
> > +
> > /*
> >* The BCM2711 HVS has up to 7 output connected to the pixelvalves and
> >* the TXP (and therefore all the CRTCs
[PATCH v4 0/2] drm/vc4: Rework the HVS muxing code
Hi, Here's a second attempt at fixing the current issues we have with the muxing code that results in a PV muxing its HVS muxing when only another CRTC is modified by a state, or vblank timeouts when trying to wait for a vblank on a single CRTC while another one is inactive but enabled. Let me know what you think, Maxime Changes from v3: - Pulled some patches from the atomic_helper_commit series that reorder / cleanup some code added here - s/needs_muxing/update_muxing/, and some cleanups suggested by Thomas - Removed the patches already applied Changes from v1: - Dropped the code trying to access all the CRTCs (whether in the state or not) state - Added Hoegeun Kwon's tags - Fixed a build bisection error - Cleaned up the private state using drmm_add_action_or_reset - Rebased on current linux next Maxime Ripard (2): drm/vc4: kms: Store the unassigned channel list in the state drm/vc4: kms: Don't disable the muxing of an active CRTC drivers/gpu/drm/vc4/vc4_drv.h | 4 + drivers/gpu/drm/vc4/vc4_kms.c | 199 -- 2 files changed, 146 insertions(+), 57 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 17/17] RFC: mm: add mmu_notifier argument to follow_pfn
On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> * Return: zero and the pfn at @pfn on success, -ve otherwise.
> */
> int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> - unsigned long *pfn)
> + unsigned long *pfn, struct mmu_notifier *subscription)
> {
> - int ret = -EINVAL;
> - spinlock_t *ptl;
> - pte_t *ptep;
> + if (WARN_ON(!subscription->mm))
> + return -EINVAL;
>
> + if (WARN_ON(subscription->mm != vma->vm_mm))
> + return -EINVAL;
These two things are redundant right? vma->vm_mm != NULL?
BTW, why do we even have this for nommu? If the only caller is kvm,
can you even compile kvm on nommu??
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event
The explicit out-fences in crtc are signaled as part of vblank event,
indicating all framebuffers present on the Atomic Commit request are
scanned out on the screen. Though the fence signal and the vblank event
notification happens at the same time, triggered by the same hardware
vsync event, the timestamp set in both are different. With drivers
supporting precise vblank timestamp the difference between the two
timestamps would be even higher. This might have an impact on use-mode
frameworks using these fence timestamps for purposes other than simple
buffer usage. For instance, the Android framework [1] uses the
retire-fences as an alternative to vblank when frame-updates are in
progress. Set the fence timestamp during send vblank event using a new
drm_send_event_timestamp_locked variant to avoid discrepancies.
[1] https://android.googlesource.com/platform/frameworks/native/+/master/
services/surfaceflinger/Scheduler/Scheduler.cpp#397
Changes in v2:
- Use drm_send_event_timestamp_locked to update fence timestamp
- add more information to commit text
Signed-off-by: Veera Sundaram Sankaran
---
drivers/gpu/drm/drm_file.c | 43 +++
drivers/gpu/drm/drm_vblank.c | 9 -
include/drm/drm_file.h | 3 +++
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..5944bb9 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -775,6 +775,49 @@ void drm_event_cancel_free(struct drm_device *dev,
EXPORT_SYMBOL(drm_event_cancel_free);
/**
+ * drm_send_event_timestamp_locked - send DRM event to file descriptor
+ * @dev: DRM device
+ * @e: DRM event to deliver
+ * @timestamp: timestamp to set for the fence event
+ *
+ * This function sends the event @e, initialized with drm_event_reserve_init(),
+ * to its associated userspace DRM file. Callers must already hold
+ * _device.event_lock, see drm_send_event() for the unlocked version.
+ *
+ * Note that the core will take care of unlinking and disarming events when the
+ * corresponding DRM file is closed. Drivers need not worry about whether the
+ * DRM file for this event still exists and can call this function upon
+ * completion of the asynchronous work unconditionally.
+ */
+void drm_send_event_timestamp_locked(struct drm_device *dev,
+ struct drm_pending_event *e, ktime_t timestamp)
+{
+ assert_spin_locked(>event_lock);
+
+ if (e->completion) {
+ complete_all(e->completion);
+ e->completion_release(e->completion);
+ e->completion = NULL;
+ }
+
+ if (e->fence) {
+ dma_fence_signal_timestamp(e->fence, timestamp);
+ dma_fence_put(e->fence);
+ }
+
+ if (!e->file_priv) {
+ kfree(e);
+ return;
+ }
+
+ list_del(>pending_link);
+ list_add_tail(>link,
+ >file_priv->event_list);
+ wake_up_interruptible(>file_priv->event_wait);
+}
+EXPORT_SYMBOL(drm_send_event_timestamp_locked);
+
+/**
* drm_send_event_locked - send DRM event to file descriptor
* @dev: DRM device
* @e: DRM event to deliver
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index b18e1ef..9899187 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1000,7 +1000,14 @@ static void send_vblank_event(struct drm_device *dev,
break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
- drm_send_event_locked(dev, >base);
+ /*
+* Use the same timestamp for any associated fence signal to avoid
+* mismatch in timestamps for vsync & fence events triggered by the
+* same HW event. Frameworks like SurfaceFlinger in Android expects the
+* retire-fence timestamp to match exactly with HW vsync as it uses it
+* for its software vsync modeling.
+*/
+ drm_send_event_timestamp_locked(dev, >base, now);
}
/**
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 716990b..b81b3bf 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -399,6 +399,9 @@ void drm_event_cancel_free(struct drm_device *dev,
struct drm_pending_event *p);
void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event
*e);
void drm_send_event(struct drm_device *dev, struct drm_pending_event *e);
+void drm_send_event_timestamp_locked(struct drm_device *dev,
+struct drm_pending_event *e,
+ktime_t timestamp);
struct file *mock_drm_getfile(struct drm_minor *minor, unsigned int flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mm: Extract might_alloc() debug check
Hi,
On 11/20/20 1:54 AM, Daniel Vetter wrote:
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index d5ece7a9a403..f94405d43fd1 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) { }
> static inline void fs_reclaim_release(gfp_t gfp_mask) { }
> #endif
>
> +/**
> + * might_alloc - Marks possible allocation sites
Mark
> + * @gfp_mask: gfp_t flags that would be use to allocate
used
> + *
> + * Similar to might_sleep() and other annotations this can be used in
> functions
annotations,
> + * that might allocate, but often dont. Compiles to nothing without
don't.
> + * CONFIG_LOCKDEP. Includes a conditional might_sleep() if @gfp allows
> blocking.
?might_sleep_if() if
> + */
> +static inline void might_alloc(gfp_t gfp_mask)
> +{
> + fs_reclaim_acquire(gfp_mask);
> + fs_reclaim_release(gfp_mask);
> +
> + might_sleep_if(gfpflags_allow_blocking(gfp_mask));
> +}
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] mm: Track mmu notifiers in fs_reclaim_acquire/release
On Fri, Nov 20, 2020 at 10:54:42AM +0100, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep annotations since 23b68395c7c7
> ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
>
> But these only fire if a path actually results in some pte
> invalidation - for most small allocations that's very rarely the case.
> The other trouble is that pte invalidation can happen any time when
> __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> recursion.
>
> I was pondering whether we should just do the general annotation, but
> there's always the risk for false positives. Plus I'm assuming that
> the core fs and io code is a lot better reviewed and tested than
> random mmu notifier code in drivers. Hence why I decide to only
> annotate for that specific case.
>
> Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> still need to explicit pull in the mmu notifier map - there's a lot
> more places that do pte invalidation than just direct reclaim, these
> two contexts arent the same.
>
> Note that the mmu notifiers needing their own independent lockdep map
> is also the reason we can't hold them from fs_reclaim_acquire to
> fs_reclaim_release - it would nest with the acquistion in the pte
> invalidation code, causing a lockdep splat. And we can't remove the
> annotations from pte invalidation and all the other places since
> they're called from many other places than page reclaim. Hence we can
> only do the equivalent of might_lock, but on the raw lockdep map.
>
> With this we can also remove the lockdep priming added in 66204f1d2d1b
> ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> strictly more powerful.
>
> v2: Review from Thomas Hellstrom:
> - unbotch the fs_reclaim context check, I accidentally inverted it,
> but it didn't blow up because I inverted it immediately
> - fix compiling for !CONFIG_MMU_NOTIFIER
>
> v3: Unbreak the PF_MEMALLOC_ context flags. Thanks to Qian for the
> report and Dave for explaining what I failed to see.
>
> Cc: linux-fsde...@vger.kernel.org
> Cc: Dave Chinner
> Cc: Qian Cai
> Cc: linux-...@vger.kernel.org
> Cc: Thomas Hellström (Intel)
> Cc: Andrew Morton
> Cc: Jason Gunthorpe
> Cc: linux...@kvack.org
> Cc: linux-r...@vger.kernel.org
> Cc: Maarten Lankhorst
> Cc: Christian König
> Cc: "Matthew Wilcox (Oracle)"
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 7 ---
> mm/page_alloc.c | 31 ---
> 2 files changed, 20 insertions(+), 18 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: fix relocations applying logic and a double-free
Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
a logic-bug which results in the relocations not actually getting
applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is
never reached. This causes a regression with graphical corruption,
triggered when relocations need to be done (for example after a
suspend/resume cycle.)
Fix by setting *apply_relocs value only if there were more than 0
relocations.
Additionally, the never reached code had a leftover u_free() call,
which, after fixing the logic, now got called and resulted in a
double-free. Fix by removing one u_free(), moving the other
and adding check for errors.
Cc: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Matti Hamalainen
Fixes: 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl")
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 549bc67feabb..c2051380d18c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -558,8 +558,10 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
NV_PRINTK(err, cli, "validating bo list\n");
validate_fini(op, chan, NULL, NULL);
return ret;
+ } else if (ret > 0) {
+ *apply_relocs = true;
}
- *apply_relocs = ret;
+
return 0;
}
@@ -662,7 +664,6 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
nouveau_bo_wr32(nvbo, r->reloc_bo_offset >> 2, data);
}
- u_free(reloc);
return ret;
}
@@ -872,9 +873,10 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
break;
}
}
- u_free(reloc);
}
out_prevalid:
+ if (!IS_ERR(reloc))
+ u_free(reloc);
u_free(bo);
u_free(push);
base-commit: 3494d58865ad4a47611dbb427b214cc5227fa5eb
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: Linux 5.10-rc4; graphics alignment
From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
>
>8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")
Ok, that one fixes the screen colours (etc).
So 8e3784dfef8a was good and then HEAD^ was bad.
I might try to bisect the breakage.
The stack splat is entirely different.
I'll try to bisect that on Linus's tree.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: Linux 5.10-rc4; graphics alignment
From: Thomas Zimmermann > Sent: 20 November 2020 10:14 ... > > Is there any way to bisect through the parts of the > > drm merge patch into v5.10-rc1 ? > > > > That ought to be quicker (and less error prone) than > > the bisect builds I was doing. > > > > Note that the stack 'splat' is due to a later change. > > It is separate from the broken pixel alignment. > > > > I actually saw the vga text go 'funny' while the boot > > was outputting all the [OK] messages (from systemd?) > > before the graphic login stole tty1 (bloody stupid > > to use tty1). > > > > I don't need to use the failing system today, I'll > > have another go at isolating the failure. > > You can use drm-tip for testing, where many of the DRM patches go through. > >https://cgit.freedesktop.org/drm/drm-tip/ > > It's fairly up-to-date. Any idea of tags either side of the 5.10 merge? > I have two systems with AST chips and neither shows any of the symptoms > you describe; nor do we have such reports about drivers that use a > similar stack (hibmc, bochs). Could you provide the output of > >dmesg | grep drm [2.112303] fb0: switching to astdrmfb from EFI VGA [2.120222] ast :02:00.0: [drm] Using P2A bridge for configuration [2.120233] ast :02:00.0: [drm] AST 2400 detected [2.120247] ast :02:00.0: [drm] Analog VGA only [2.120257] ast :02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16 [2.121121] [drm] Initialized ast 0.1.0 20120228 for :02:00.0 on minor 0 [2.125838] fbcon: astdrmfb (fb0) is primary device [2.152179] ast :02:00.0: [drm] fb0: astdrmfb frame buffer device [6.061034] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped. The output is the same for both good and bad kernels. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: Linux 5.10-rc4; graphics alignment
From: Thomas Zimmermann
> Sent: 20 November 2020 11:27
...
> >> You can use drm-tip for testing, where many of the DRM patches go through.
> >>
> >> https://cgit.freedesktop.org/drm/drm-tip/
> >>
> >> It's fairly up-to-date.
> >
> > Any idea of tags either side of the 5.10 merge?
>
> The final commit before v5.9 appears to be
>
>Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
>
> I'd try this as a good commit. For the bad commit, just try HEAD.
HEAD off that tree works.
Colours ok and no stack backtrace.
Ideas??
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 000/141] Fix fall-through warnings for Clang
Hi Gustavo, On Fri, Nov 20, 2020 at 7:21 PM Gustavo A. R. Silva wrote: > > Hi all, > > This series aims to fix almost all remaining fall-through warnings in > order to enable -Wimplicit-fallthrough for Clang. Thanks for this. Since this warning is reliable in both/all compilers and we are eventually getting rid of all the cases, what about going even further and making it an error right after? Cheers, Miguel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/vc4: kms: Store the unassigned channel list in the state
If a CRTC is enabled but not active, and that we're then doing a page
flip on another CRTC, drm_atomic_get_crtc_state will bring the first
CRTC state into the global state, and will make us wait for its vblank
as well, even though that might never occur.
Instead of creating the list of the free channels each time atomic_check
is called, and calling drm_atomic_get_crtc_state to retrieve the
allocated channels, let's create a private state object in the main
atomic state, and use it to store the available channels.
Since vc4 has a semaphore (with a value of 1, so a lock) in its commit
implementation to serialize all the commits, even the nonblocking ones, we
are free from the use-after-free race if two subsequent commits are not ran
in their submission order.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Reviewed-by: Hoegeun Kwon
Reviewed-by: Thomas Zimmermann
Tested-by: Hoegeun Kwon
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_kms.c | 126 +++---
2 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 19b75bebd35f..fcfeef0949af 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -219,6 +219,7 @@ struct vc4_dev {
struct drm_modeset_lock ctm_state_lock;
struct drm_private_obj ctm_manager;
+ struct drm_private_obj hvs_channels;
struct drm_private_obj load_tracker;
/* List of vc4_debugfs_info_entry for adding to debugfs once
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 0f44fc526fd2..0bbd7b554275 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -37,6 +37,17 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct
drm_private_state *priv)
return container_of(priv, struct vc4_ctm_state, base);
}
+struct vc4_hvs_state {
+ struct drm_private_state base;
+ unsigned int unassigned_channels;
+};
+
+static struct vc4_hvs_state *
+to_vc4_hvs_state(struct drm_private_state *priv)
+{
+ return container_of(priv, struct vc4_hvs_state, base);
+}
+
struct vc4_load_tracker_state {
struct drm_private_state base;
u64 hvs_load;
@@ -171,6 +182,19 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct
drm_atomic_state *state)
VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
}
+static struct vc4_hvs_state *
+vc4_hvs_get_global_state(struct drm_atomic_state *state)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state,
>hvs_channels);
+ if (IS_ERR(priv_state))
+ return ERR_CAST(priv_state);
+
+ return to_vc4_hvs_state(priv_state);
+}
+
static void vc4_hvs_pv_muxing_commit(struct vc4_dev *vc4,
struct drm_atomic_state *state)
{
@@ -662,6 +686,59 @@ static int vc4_load_tracker_obj_init(struct vc4_dev *vc4)
return drmm_add_action_or_reset(>base, vc4_load_tracker_obj_fini,
NULL);
}
+static struct drm_private_state *
+vc4_hvs_channels_duplicate_state(struct drm_private_obj *obj)
+{
+ struct vc4_hvs_state *old_state = to_vc4_hvs_state(obj->state);
+ struct vc4_hvs_state *state;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ __drm_atomic_helper_private_obj_duplicate_state(obj, >base);
+
+ state->unassigned_channels = old_state->unassigned_channels;
+
+ return >base;
+}
+
+static void vc4_hvs_channels_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ struct vc4_hvs_state *hvs_state = to_vc4_hvs_state(state);
+
+ kfree(hvs_state);
+}
+
+static const struct drm_private_state_funcs vc4_hvs_state_funcs = {
+ .atomic_duplicate_state = vc4_hvs_channels_duplicate_state,
+ .atomic_destroy_state = vc4_hvs_channels_destroy_state,
+};
+
+static void vc4_hvs_channels_obj_fini(struct drm_device *dev, void *unused)
+{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+ drm_atomic_private_obj_fini(>hvs_channels);
+}
+
+static int vc4_hvs_channels_obj_init(struct vc4_dev *vc4)
+{
+ struct vc4_hvs_state *state;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ state->unassigned_channels = GENMASK(HVS_NUM_CHANNELS - 1, 0);
+ drm_atomic_private_obj_init(>base, >hvs_channels,
+ >base,
+ _hvs_state_funcs);
+
+ return drmm_add_action_or_reset(>base, vc4_hvs_channels_obj_fini,
NULL);
+}
+
/*
* The BCM2711 HVS has up to 7 outputs connected to the pixelvalves and
* the TXP (and therefore all the CRTCs found on that platform).
@@ -678,6
Re: [PATCH 1/8] drm: Introduce an atomic_commit_setup function
Hi Daniel, Thanks for your review On Fri, Nov 13, 2020 at 10:02:40PM +0100, Daniel Vetter wrote: > > +* is not used by the atomic helpers. > > +* > > +* This function is called at the end of > > +* drm_atomic_helper_setup_commit(), so once the commit has been > > +* properly setup across the generic DRM object states. It allows > > +* drivers to do some additional commit tracking that isn't related to a > > +* CRTC, plane or connector, typically a private object. > > +* > > +* This hook is optional. > > +*/ > > + int (*atomic_commit_setup)(struct drm_atomic_state *state); > > I think the kerneldoc for drm_private_obj should also explain when it is > necessary to use this, and when not: > > - when the private state is a tied to an existing drm object (drm_crtc, > drm_plane or drm_crtc) and never moves, then sufficient synchronization > is already guaranteed by that superior object. This could even hold > when the private object can be e.g. reassigned between planes, but > always stays on the same crtc. > > - if the private state object can be globally reassigned, then > drm_crtc_commit synchronization points need to be set up in > ->atomic_commit_setup and waited on as the first step in > ->atomic_commit_tail Does the comment added on patch 2 sufficient for you, or would you extend it / make it clearer? Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ARM: dts: rpi-4: disable wifi frequencies
On Thu, 2020-10-29 at 14:40 +0100, Maxime Ripard wrote: > The RPi4 WiFi chip and HDMI outputs have some frequency overlap with > crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive > maneuvers. > > Signed-off-by: Maxime Ripard > > --- > > Changes from v1: > - Changed the property name Applied for next. Thanks! signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: Linux 5.10-rc4; graphics alignment
> Hi David > > Am 18.11.20 um 23:01 schrieb David Laight: ... > Did you try Daniel's suggestion of testing with the direct parent commit? (I was on holiday yesterday and didn't want to spend a sunny afternoon doing bisects.) I've just done that and it is bad. Is there any way to bisect through the parts of the drm merge patch into v5.10-rc1 ? That ought to be quicker (and less error prone) than the bisect builds I was doing. Note that the stack 'splat' is due to a later change. It is separate from the broken pixel alignment. I actually saw the vga text go 'funny' while the boot was outputting all the [OK] messages (from systemd?) before the graphic login stole tty1 (bloody stupid to use tty1). I don't need to use the failing system today, I'll have another go at isolating the failure. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dma-fence: allow signaling drivers to set fence timestamp
Some drivers have hardware capability to get the precise timestamp of
certain events based on which the fences are triggered. This allows it to
set accurate timestamp factoring out any software and IRQ latencies. Add
a timestamp variant of fence signal function, dma_fence_signal_timestamp
to allow drivers to update the precise timestamp for fences.
Changes in v2:
- Add a new fence signal variant instead of modifying fence struct
Signed-off-by: Veera Sundaram Sankaran
---
drivers/dma-buf/dma-fence.c | 70 -
include/linux/dma-fence.h | 3 ++
2 files changed, 66 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 43624b4..ef9902d 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -311,22 +311,25 @@ void __dma_fence_might_wait(void)
/**
- * dma_fence_signal_locked - signal completion of a fence
+ * dma_fence_signal_timestamp_locked - signal completion of a fence
* @fence: the fence to signal
+ * @timestamp: fence signal timestamp
*
* Signal completion for software callbacks on a fence, this will unblock
* dma_fence_wait() calls and run all the callbacks added with
* dma_fence_add_callback(). Can be called multiple times, but since a fence
* can only go from the unsignaled to the signaled state and not back, it will
- * only be effective the first time.
+ * only be effective the first time. Set the timestamp provided as the fence
+ * signal timestamp.
*
- * Unlike dma_fence_signal(), this function must be called with _fence.lock
- * held.
+ * Unlike dma_fence_signal_timestamp(), this function must be called with
+ * _fence.lock held.
*
* Returns 0 on success and a negative error value when @fence has been
* signalled already.
*/
-int dma_fence_signal_locked(struct dma_fence *fence)
+int dma_fence_signal_timestamp_locked(struct dma_fence *fence,
+ ktime_t timestamp)
{
struct dma_fence_cb *cur, *tmp;
struct list_head cb_list;
@@ -340,7 +343,7 @@ int dma_fence_signal_locked(struct dma_fence *fence)
/* Stash the cb_list before replacing it with the timestamp */
list_replace(>cb_list, _list);
- fence->timestamp = ktime_get();
+ fence->timestamp = timestamp;
set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags);
trace_dma_fence_signaled(fence);
@@ -351,6 +354,59 @@ int dma_fence_signal_locked(struct dma_fence *fence)
return 0;
}
+EXPORT_SYMBOL(dma_fence_signal_timestamp_locked);
+
+/**
+ * dma_fence_signal_timestamp - signal completion of a fence
+ * @fence: the fence to signal
+ * @timestamp: fence signal timestamp
+ *
+ * Signal completion for software callbacks on a fence, this will unblock
+ * dma_fence_wait() calls and run all the callbacks added with
+ * dma_fence_add_callback(). Can be called multiple times, but since a fence
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time. Set the timestamp provided as the fence
+ * signal timestamp.
+ *
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
+ */
+int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp)
+{
+ unsigned long flags;
+ int ret;
+
+ if (!fence)
+ return -EINVAL;
+
+ spin_lock_irqsave(fence->lock, flags);
+ ret = dma_fence_signal_timestamp_locked(fence, timestamp);
+ spin_unlock_irqrestore(fence->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(dma_fence_signal_timestamp);
+
+/**
+ * dma_fence_signal_locked - signal completion of a fence
+ * @fence: the fence to signal
+ *
+ * Signal completion for software callbacks on a fence, this will unblock
+ * dma_fence_wait() calls and run all the callbacks added with
+ * dma_fence_add_callback(). Can be called multiple times, but since a fence
+ * can only go from the unsignaled to the signaled state and not back, it will
+ * only be effective the first time.
+ *
+ * Unlike dma_fence_signal(), this function must be called with _fence.lock
+ * held.
+ *
+ * Returns 0 on success and a negative error value when @fence has been
+ * signalled already.
+ */
+int dma_fence_signal_locked(struct dma_fence *fence)
+{
+ return dma_fence_signal_timestamp_locked(fence, ktime_get());
+}
EXPORT_SYMBOL(dma_fence_signal_locked);
/**
@@ -378,7 +434,7 @@ int dma_fence_signal(struct dma_fence *fence)
tmp = dma_fence_begin_signalling();
spin_lock_irqsave(fence->lock, flags);
- ret = dma_fence_signal_locked(fence);
+ ret = dma_fence_signal_timestamp_locked(fence, ktime_get());
spin_unlock_irqrestore(fence->lock, flags);
dma_fence_end_signalling(tmp);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 09e23ad..9f12efa 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -372,6 +372,9 @@ static inline
Re: [PATCH v2] drm: Pass the full state to connectors atomic functions
Hi,
On Thu, Nov 19, 2020 at 05:21:48PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2020 at 10:47:58AM +0100, Maxime Ripard wrote:
> > The current atomic helpers have either their object state being passed as
> > an argument or the full atomic state.
> >
> > The former is the pattern that was done at first, before switching to the
> > latter for new hooks or when it was needed.
> >
> > Now that the CRTCs have been converted, let's move forward with the
> > connectors to provide a consistent interface.
> >
> > The conversion was done using the coccinelle script below, and built tested
> > on all the drivers.
> >
> > @@
> > identifier connector, connector_state;
> > @@
> >
> > struct drm_connector_helper_funcs {
> > ...
> > struct drm_encoder* (*atomic_best_encoder)(struct drm_connector
> > *connector,
> > - struct drm_connector_state
> > *connector_state);
> > + struct drm_atomic_state
> > *state);
> > ...
> > }
> >
> > @@
> > identifier connector, connector_state;
> > @@
> >
> > struct drm_connector_helper_funcs {
> > ...
> > void (*atomic_commit)(struct drm_connector *connector,
> > - struct drm_connector_state *connector_state);
> > + struct drm_atomic_state *state);
> > ...
> > }
> >
> > @@
> > struct drm_connector_helper_funcs *FUNCS;
> > identifier state;
> > identifier connector, connector_state;
> > identifier f;
> > @@
> >
> > f(..., struct drm_atomic_state *state, ...)
> > {
> > <+...
> > - FUNCS->atomic_commit(connector, connector_state);
> > + FUNCS->atomic_commit(connector, state);
> > ...+>
> > }
> >
> > @@
> > struct drm_connector_helper_funcs *FUNCS;
> > identifier state;
> > identifier connector, connector_state;
> > identifier var, f;
> > @@
> >
> > f(struct drm_atomic_state *state, ...)
>
> I think there was some way to deal with these variants using a single
> rule, but maybe that required the use of the parameter list stuff
> which IIRC was a bit ugly. Probably not worth the hassle here.
Do you have any recollection of some patch that used it? I couldn't find
a cleaner way to deal with it, but I'd really like to use it if
available.
> > {
> > <+...
> > - var = FUNCS->atomic_best_encoder(connector, connector_state);
> > + var = FUNCS->atomic_best_encoder(connector, state);
> > ...+>
> > }
> >
> > @ connector_atomic_func @
> > identifier helpers;
> > identifier func;
> > @@
> >
> > (
> > static struct drm_connector_helper_funcs helpers = {
> > ...,
> > .atomic_best_encoder = func,
> > ...,
> > };
> > |
> > static struct drm_connector_helper_funcs helpers = {
> > ...,
> > .atomic_commit = func,
> > ...,
> > };
> > )
> >
> > @@
> > identifier connector_atomic_func.func;
> > identifier connector;
> > symbol state;
> > @@
> >
> > func(struct drm_connector *connector,
> > - struct drm_connector_state *state
> > + struct drm_connector_state *connector_state
> > )
> > {
> > ...
> > - state
> > + connector_state
> > ...
> > }
> >
> > @ ignores_state @
> > identifier connector_atomic_func.func;
> > identifier connector, connector_state;
> > @@
> >
> > func(struct drm_connector *connector,
> > struct drm_connector_state *connector_state)
> > {
> > ... when != connector_state
> > }
> >
> > @ adds_state depends on connector_atomic_func && !ignores_state @
> > identifier connector_atomic_func.func;
> > identifier connector, connector_state;
> > @@
> >
> > func(struct drm_connector *connector, struct drm_connector_state
> > *connector_state)
> > {
> > + struct drm_connector_state *connector_state =
> > drm_atomic_get_new_connector_state(state, connector);
> > ...
> > }
> >
> > @ depends on connector_atomic_func @
> > identifier connector_atomic_func.func;
> > identifier connector_state;
> > identifier connector;
> > @@
> >
> > func(struct drm_connector *connector,
> > - struct drm_connector_state *connector_state
> > + struct drm_atomic_state *state
> >)
> > { ... }
> >
> > @ include depends on adds_state @
> > @@
> >
> > #include
> >
> > @ no_include depends on !include && adds_state @
> > @@
> >
> > + #include
> > #include
>
> Nicely done with the depends. Also never used that stuff myself
> so thanks for the tutorial :)
You're welcome :)
> Reviewed-by: Ville Syrjälä
Thanks! I've applied it
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: Linux 5.10-rc4; graphics alignment
From: Thomas Zimmermann
> Sent: 20 November 2020 12:30
>
> Am 20.11.20 um 12:45 schrieb David Laight:
> > From: Thomas Zimmermann
> >> Sent: 20 November 2020 11:27
> > ...
> You can use drm-tip for testing, where many of the DRM patches go
> through.
>
> https://cgit.freedesktop.org/drm/drm-tip/
>
> It's fairly up-to-date.
> >>>
> >>> Any idea of tags either side of the 5.10 merge?
> >>
> >> The final commit before v5.9 appears to be
> >>
> >> Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init
> >> interface")
> >>
> >> I'd try this as a good commit. For the bad commit, just try HEAD.
> >
> > HEAD off that tree works.
> > Colours ok and no stack backtrace.
> >
> > Ideas??
>
> The good news is that it's been fixed. All you have to do is wait for
> the fix to hit upstream.
>
> Did you try the patch that Dave linked?
That patch makes no difference to my system.
The condition is false so it doesn't corrupt the flags.
(I printed the values to see.)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: dsi: Modify horizontal front/back porch byte formula
Bilal Wasim 於 2020年11月20日 週五 上午8:30寫道：
>
> Hi CK,
>
> On Fri, 20 Nov 2020 07:23:35 +0800
> Chun-Kuang Hu wrote:
>
> > From: CK Hu
> >
> > In the patch to be fixed, horizontal_backporch_byte become to large
> > for some panel, so roll back that patch. For small hfp or hbp panel,
> > using vm->hfront_porch + vm->hback_porch to calculate
> > horizontal_backporch_byte would make it negtive, so
> > use horizontal_backporch_byte itself to make it positive.
Applied to mediatek-drm-fixes [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
> >
> > Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel with
> > small hfp or hbp")
> >
> > Signed-off-by: CK Hu
> > Signed-off-by: Chun-Kuang Hu
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 61
> > +++--- 1 file changed, 22 insertions(+), 39
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c index 4a188a942c38..65fd99c528af
> > 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -444,7 +444,10 @@ static void mtk_dsi_config_vdo_timing(struct
> > mtk_dsi *dsi) u32 horizontal_sync_active_byte;
> > u32 horizontal_backporch_byte;
> > u32 horizontal_frontporch_byte;
> > + u32 horizontal_front_back_byte;
> > + u32 data_phy_cycles_byte;
> > u32 dsi_tmp_buf_bpp, data_phy_cycles;
> > + u32 delta;
> > struct mtk_phy_timing *timing = >phy_timing;
> >
> > struct videomode *vm = >vm;
> > @@ -466,50 +469,30 @@ static void mtk_dsi_config_vdo_timing(struct
> > mtk_dsi *dsi) horizontal_sync_active_byte = (vm->hsync_len *
> > dsi_tmp_buf_bpp - 10);
> > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > - horizontal_backporch_byte = vm->hback_porch *
> > dsi_tmp_buf_bpp;
> > + horizontal_backporch_byte = vm->hback_porch *
> > dsi_tmp_buf_bpp - 10; else
> > horizontal_backporch_byte = (vm->hback_porch +
> > vm->hsync_len) *
> > - dsi_tmp_buf_bpp;
> > + dsi_tmp_buf_bpp - 10;
> >
> > data_phy_cycles = timing->lpx + timing->da_hs_prepare +
> > - timing->da_hs_zero + timing->da_hs_exit;
> > -
> > - if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> > - if ((vm->hfront_porch + vm->hback_porch) *
> > dsi_tmp_buf_bpp >
> > - data_phy_cycles * dsi->lanes + 18) {
> > - horizontal_frontporch_byte =
> > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > - (data_phy_cycles * dsi->lanes + 18) *
> > - vm->hfront_porch /
> > - (vm->hfront_porch + vm->hback_porch);
> > -
> > - horizontal_backporch_byte =
> > - horizontal_backporch_byte -
> > - (data_phy_cycles * dsi->lanes + 18) *
> > - vm->hback_porch /
> > - (vm->hfront_porch + vm->hback_porch);
> > - } else {
> > - DRM_WARN("HFP less than d-phy, FPS will
> > under 60Hz\n");
> > - horizontal_frontporch_byte =
> > vm->hfront_porch *
> > - dsi_tmp_buf_bpp;
> > - }
> > + timing->da_hs_zero + timing->da_hs_exit +
> > 3; +
> > + delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 :
> > 12; +
> > + horizontal_frontporch_byte = vm->hfront_porch *
> > dsi_tmp_buf_bpp;
> > + horizontal_front_back_byte = horizontal_frontporch_byte +
> > horizontal_backporch_byte;
> > + data_phy_cycles_byte = data_phy_cycles * dsi->lanes + delta;
> > +
> > + if (horizontal_front_back_byte > data_phy_cycles_byte) {
> > + horizontal_frontporch_byte -= data_phy_cycles_byte *
> > +
> > horizontal_frontporch_byte /
> > +
> > horizontal_front_back_byte; +
> > + horizontal_backporch_byte -= data_phy_cycles_byte *
> > +
> > horizontal_backporch_byte /
> > +
> > horizontal_front_back_byte; } else {
> > - if ((vm->hfront_porch + vm->hback_porch) *
> > dsi_tmp_buf_bpp >
> > - data_phy_cycles * dsi->lanes + 12) {
> > - horizontal_frontporch_byte =
> > - vm->hfront_porch * dsi_tmp_buf_bpp -
> > - (data_phy_cycles * dsi->lanes + 12) *
> > - vm->hfront_porch /
> > - (vm->hfront_porch + vm->hback_porch);
> > - horizontal_backporch_byte =
> > horizontal_backporch_byte -
> > - (data_phy_cycles * dsi->lanes + 12) *
> > - vm->hback_porch /
> > - (vm->hfront_porch +
Re: [PATCH v6 04/17] misc/habana: Use FOLL_LONGTERM for userptr
On Thu, Nov 19, 2020 at 4:41 PM Daniel Vetter wrote:
>
> These are persistent, not just for the duration of a dma operation.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Oded Gabbay
> Cc: Omer Shpigelman
> Cc: Ofir Bitton
> Cc: Tomer Tayar
> Cc: Moti Haimovski
> Cc: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: Pawel Piskorski
> Signed-off-by: Daniel Vetter
> ---
> drivers/misc/habanalabs/common/memory.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/common/memory.c
> b/drivers/misc/habanalabs/common/memory.c
> index 0b220221873d..d08c41b90fec 100644
> --- a/drivers/misc/habanalabs/common/memory.c
> +++ b/drivers/misc/habanalabs/common/memory.c
> @@ -1298,7 +1298,8 @@ static int get_user_memory(struct hl_device *hdev, u64
> addr, u64 size,
> return -ENOMEM;
> }
>
> - rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
> + rc = pin_user_pages_fast(start, npages,
> +FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
> userptr->pages);
>
> if (rc != npages) {
> --
> 2.29.2
>
This patch and the previous one (03/17 misc/habana: Stop using
frame_vector helpers) are both:
Reviewed-by: Oded Gabbay
Thanks,
Oded
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-20.45 189/2417] ./usr/include/drm/amdgpu_drm.h:874:4: error: unknown type name 'uint32_t'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-20.45 head: 1807abbb3a7f17fc931a15d7fd4365ea148c6bb1 commit: b46fcb031f1ca11f48ea670680cb5eed851e9870 [189/2417] drm/amdgpu: [hybrid] add query for aperture va range config: x86_64-randconfig-a011-20201120 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 3ded927cf80ac519f9f9c4664fef08787f7c537d) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git git fetch --no-tags radeon-alex amd-20.45 git checkout b46fcb031f1ca11f48ea670680cb5eed851e9870 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from :1: >> ./usr/include/drm/amdgpu_drm.h:874:4: error: unknown type name 'uint32_t' uint32_t aperture; ^ ./usr/include/drm/amdgpu_drm.h:875:4: error: unknown type name 'uint32_t' uint32_t _pad; ^ >> ./usr/include/drm/amdgpu_drm.h:1102:2: error: unknown type name 'uint64_t' uint64_t start; ^ ./usr/include/drm/amdgpu_drm.h:1103:2: error: unknown type name 'uint64_t' uint64_t end; ^ 4 errors generated. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
