[PATCH 2/2] drm/edid: Add alternate clock for SMPTE 4K
[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
[How]
Remove the exception
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/drm_edid.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fcd7ae29049d..ed2782c53a93 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3126,9 +3126,6 @@ static enum hdmi_picture_aspect
drm_get_hdmi_aspect_ratio(const u8 video_code)
static unsigned int
hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
{
- if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
- return hdmi_mode->clock;
-
return cea_mode_alternate_clock(hdmi_mode);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/edid: Add aspect ratios to HDMI 4K modes
[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
Current code doesn't take aspect ratio into consideration while
constructing avi infoframe. Should modify that.
[How]
Inherit Ville Syrjälä's work
"drm/edid: Prep for HDMI VIC aspect ratio" at
https://patchwork.kernel.org/patch/11174639/
Add picture_aspect_ratio attributes to edid_4k_modes[] and
construct VIC and HDMI_VIC by taking aspect ratio into
consideration.
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/drm_edid.c | 45 +-
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 77a39fc76045..fcd7ae29049d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1288,25 +1288,25 @@ static const struct drm_display_mode edid_4k_modes[] = {
3840, 4016, 4104, 4400, 0,
2160, 2168, 2178, 2250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 30, },
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 2 - 3840x2160@25Hz */
{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
3840, 4896, 4984, 5280, 0,
2160, 2168, 2178, 2250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 25, },
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 3 - 3840x2160@24Hz */
{ DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
3840, 5116, 5204, 5500, 0,
2160, 2168, 2178, 2250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 24, },
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
/* 4 - 4096x2160@24Hz (SMPTE) */
{ DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000,
4096, 5116, 5204, 5500, 0,
2160, 2168, 2178, 2250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
- .vrefresh = 24, },
+ .vrefresh = 24, HDMI_PICTURE_ASPECT_256_135},
};
/*** DDC fetch and block validation ***/
@@ -3110,6 +3110,11 @@ static enum hdmi_picture_aspect
drm_get_cea_aspect_ratio(const u8 video_code)
return edid_cea_modes[video_code].picture_aspect_ratio;
}
+static enum hdmi_picture_aspect drm_get_hdmi_aspect_ratio(const u8 video_code)
+{
+ return edid_4k_modes[video_code].picture_aspect_ratio;
+}
+
/*
* Calculate the alternate clock for HDMI modes (those from the HDMI vendor
* specific block).
@@ -3136,6 +3141,9 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const
struct drm_display_mode *to_
if (!to_match->clock)
return 0;
+ if (to_match->picture_aspect_ratio)
+ match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
const struct drm_display_mode *hdmi_mode = &edid_4k_modes[vic];
unsigned int clock1, clock2;
@@ -3171,6 +3179,9 @@ static u8 drm_match_hdmi_mode(const struct
drm_display_mode *to_match)
if (!to_match->clock)
return 0;
+ if (to_match->picture_aspect_ratio)
+ match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_4k_modes); vic++) {
const struct drm_display_mode *hdmi_mode = &edid_4k_modes[vic];
unsigned int clock1, clock2;
@@ -5118,6 +5129,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode)
{
enum hdmi_picture_aspect picture_aspect;
+ u8 vic, hdmi_vic;
int err;
if (!frame || !mode)
@@ -5130,7 +5142,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
frame->pixel_repeat = 1;
- frame->video_code = drm_mode_cea_vic(connector, mode);
+ vic = drm_mode_cea_vic(connector, mode);
+ hdmi_vic = drm_mode_hdmi_vic(connector, mode);
frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
@@ -5144,11 +5157,15 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
/*
* Populate picture aspect ratio from either
-* user input (if specified) or from the CEA mode list.
+* user input (if specified) or from the CEA/HDMI mode lists.
*/
picture_aspect = mode->picture_aspect_ratio;
- if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
- picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
+ if (picture_aspec
[Bug 111796] [CI][SHARDS] igt@gem_eio@in-flight-suspend - crash - Received signal SIGSEGV
https://bugs.freedesktop.org/show_bug.cgi?id=111796 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #4 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/33. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112086] [CI][RESUME]igt@i915_pm_rpm@modeset-non-lpsp - skip - Test requirement: setup_environment(), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=112086 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #8 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/35. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110600] [IGT runner] be more consistent with checks on display/outputs
https://bugs.freedesktop.org/show_bug.cgi?id=110600 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/24. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111637] Document configuration shadowing and clean up handling that in igt_core
https://bugs.freedesktop.org/show_bug.cgi?id=111637 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/30. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111630] Generate a list of tags for the machine that runs the testsuite
https://bugs.freedesktop.org/show_bug.cgi?id=111630 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #2 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/29. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111638] Include tools/ in documentation
https://bugs.freedesktop.org/show_bug.cgi?id=111638 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/31. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111651] [CI][RESUME] igt@gem_ctx_shared@q-independent-bsd[12] - Skip - mmio base not known
https://bugs.freedesktop.org/show_bug.cgi?id=111651 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #5 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/32. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110754] Add tests checking how stable the CRCs are
https://bugs.freedesktop.org/show_bug.cgi?id=110754 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/26. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110619] Dump process stacktraces in case a test hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110619 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/25. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111329] [CI][SHARDS] igt@gem_ctx_isolation@vcs1-nonpriv - fail - igt@gem_ctx_isolation@vcs1-nonpriv - fail - Failed assertion: num_errors == 0, registers mistached between nonpriv read/writes
https://bugs.freedesktop.org/show_bug.cgi?id=111329 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #9 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111011] [CI][BAT][VEGA M]: igt@kms_addfb_basic@* - warn/fail - Failed assertion: __gem_set_tiling(fd, handle, tiling, stride) == 0
https://bugs.freedesktop.org/show_bug.cgi?id=111011 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #4 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/27. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110580] [CI][BAT] igt@.* - skip - Chamelium ports not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110580 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #63 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/20. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110598] [IGT runner] allow tests to attach test-specific results
https://bugs.freedesktop.org/show_bug.cgi?id=110598 Bug 110598 depends on bug 110597, which changed state. Bug 110597 Summary: [IGT runner] allow attachments to results.json https://bugs.freedesktop.org/show_bug.cgi?id=110597 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110598] [IGT runner] allow tests to attach test-specific results
https://bugs.freedesktop.org/show_bug.cgi?id=110598 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/22. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110597] [IGT runner] allow attachments to results.json
https://bugs.freedesktop.org/show_bug.cgi?id=110597 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/21. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110320] Improve igt_assert for timing checks
https://bugs.freedesktop.org/show_bug.cgi?id=110320 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/18. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110599] [IGT runner] Per-test external watchdog
https://bugs.freedesktop.org/show_bug.cgi?id=110599 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/23. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109941] [CI] igt@i915_pm_rpm@module-reload - crash
https://bugs.freedesktop.org/show_bug.cgi?id=109941 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #5 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/15. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110313] [CI][SHARDS] igt@kms_lease@lease-uevent - fail - Failed assertion: igt_lease_change_detected(uevent_monitor, 1)
https://bugs.freedesktop.org/show_bug.cgi?id=110313 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #8 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/17. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110521] Make skips easily parseable by machines
https://bugs.freedesktop.org/show_bug.cgi?id=110521 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/19. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109719] [igt_runner] Collect pstore data and attach it to dmesg output when resuming or reporting
https://bugs.freedesktop.org/show_bug.cgi?id=109719 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #2 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/14. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #16 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/13. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110249] IGT command line tools load redundant GUI libraries
https://bugs.freedesktop.org/show_bug.cgi?id=110249 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #8 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/16. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108891] Test enumeration becomes funky on some tests due to fd FILE* stream change
https://bugs.freedesktop.org/show_bug.cgi?id=108891 Martin Peres changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #6 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/11. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102670] [CI] igt@kms_cursor_legacy@*flip-vs-cursor-* Failed assertion: get_vblank(display->drm_fd, pipe, 0) == *
https://bugs.freedesktop.org/show_bug.cgi?id=102670 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #18 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107310] intel-gpu-overlay crashes on startup, being aborted
https://bugs.freedesktop.org/show_bug.cgi?id=107310 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #4 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/7. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108044] [CI][BAT] igt@drv_selftest@live_hangcheck - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108044 Martin Peres changed: What|Removed |Added Resolution|--- |MOVED Status|NEEDINFO|RESOLVED --- Comment #5 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/8. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99426] gem_mmap_gtt swap tests are too long - perf: interrupt took too long
https://bugs.freedesktop.org/show_bug.cgi?id=99426 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Martin Peres --- -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/1. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
On Mon, Nov 11, 2019 at 04:06:46PM -0800, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> thoroughly documented.
>
> The pin_longterm*() variants also set FOLL_LONGTERM, in addition
> to FOLL_PIN:
>
> pin_user_pages()
> pin_user_pages_remote()
> pin_user_pages_fast()
>
> pin_longterm_pages()
> pin_longterm_pages_remote()
> pin_longterm_pages_fast()
>
> All pages that are pinned via the above calls, must be unpinned via
> put_user_page().
>
> The underlying rules are:
>
> * These are gup-internal flags, so the call sites should not directly
> set FOLL_PIN nor FOLL_LONGTERM. That behavior is enforced with
> assertions, for the new FOLL_PIN flag. However, for the pre-existing
> FOLL_LONGTERM flag, which has some call sites that still directly
> set FOLL_LONGTERM, there is no assertion yet.
>
> * Call sites that want to indicate that they are going to do DirectIO
> ("DIO") or something with similar characteristics, should call a
> get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
> will:
> * Start with "pin_user_pages" instead of "get_user_pages". That
> makes it easy to find and audit the call sites.
> * Set FOLL_PIN
>
> * For pages that are received via FOLL_PIN, those pages must be returned
> via put_user_page().
>
> Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
> in this documentation. (I've reworded it and expanded upon it.)
>
> Reviewed-by: Jérôme Glisse
> Cc: Mike Rapoport
> Cc: Jonathan Corbet
> Cc: Ira Weiny
> Signed-off-by: John Hubbard
> ---
Reviewed-by: Mike Rapoport # Documentation
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/pin_user_pages.rst | 218 ++
> include/linux/mm.h| 62 +-
> mm/gup.c | 260 --
> 4 files changed, 514 insertions(+), 27 deletions(-)
> create mode 100644 Documentation/core-api/pin_user_pages.rst
>
> diff --git a/Documentation/core-api/index.rst
> b/Documentation/core-api/index.rst
> index ab0eae1c153a..413f7d7c8642 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -31,6 +31,7 @@ Core utilities
> generic-radix-tree
> memory-allocation
> mm-api
> + pin_user_pages
> gfp_mask-from-fs-io
> timekeeping
> boot-time-mm
> diff --git a/Documentation/core-api/pin_user_pages.rst
> b/Documentation/core-api/pin_user_pages.rst
> new file mode 100644
> index ..ce819e709435
> --- /dev/null
> +++ b/Documentation/core-api/pin_user_pages.rst
> @@ -0,0 +1,218 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +
> +pin_user_pages() and related calls
> +
> +
> +.. contents:: :local:
> +
> +Overview
> +
> +
> +This document describes the following functions: ::
> +
> + pin_user_pages
> + pin_user_pages_fast
> + pin_user_pages_remote
> +
> + pin_longterm_pages
> + pin_longterm_pages_fast
> + pin_longterm_pages_remote
> +
> +Basic description of FOLL_PIN
> +=
> +
> +FOLL_PIN and FOLL_LONGTERM are flags that can be passed to the
> get_user_pages*()
> +("gup") family of functions. FOLL_PIN has significant interactions and
> +interdependencies with FOLL_LONGTERM, so both are covered here.
> +
> +Both FOLL_PIN and FOLL_LONGTERM are internal to gup, meaning that neither
> +FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This
> allows
> +the associated wrapper functions (pin_user_pages() and others) to set the
> +correct combination of these flags, and to check for problems as well.
> +
> +FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
> +multiple threads and call sites are free to pin the same struct pages, via
> both
> +FOLL_PIN and FOLL_GET. It's just the call site that needs to choose one or
> the
> +other, not the struct page(s).
> +
> +The FOLL_PIN implementation is nearly the same as FOLL_GET, except that
> FOLL_PIN
> +uses a different reference counting technique.
> +
> +FOLL_PIN is a prerequisite to FOLL_LONGTGERM. Another way of saying that is,
> +FOLL_LONGTERM is a specific case, more restrictive case of FOLL_PIN.
> +
> +Which flags are set by each wrapper
> +===
> +
> +Only FOLL_PIN and FOLL_LONGTERM are covered here. These flags are added to
> +whatever flags the caller provides::
> +
> + Functiongup flags (FOLL_PIN or FOLL_LONGTERM only)
> + --
> + pin_user_pages FOLL_PIN
> + pin_user_pages_fast FOLL_PIN
> + pin_user_pages_remote FOLL_PIN
> +
> + pin_longterm_pages FOLL
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 --- Comment #22 from Haxk20 (haxk...@gmail.com) --- (In reply to Michel Dänzer from comment #21) > (In reply to Haxk20 from comment #20) > > Not only that but it started happening in video too on firefox and that is > > really horrible. > > Sounds like you're referring to > https://gitlab.freedesktop.org/xorg/xserver/issues/924 ? I thought we'd just > established that's not using PRIME, in which case it's probably not directly > related to this. Yes. I will reopen that bug again as you closed it but well its not solved yet. -- 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 205497] New: Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 Bug ID: 205497 Summary: Attempt to read amd gpu id causes a freeze Product: Drivers Version: 2.5 Kernel Version: 5.3.9 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: l...@fedoraproject.org Regression: No Created attachment 285871 --> https://bugzilla.kernel.org/attachment.cgi?id=285871&action=edit Script from radeontop to read AMD gpu ids Running an utility named radeontop on an AMD APU causes a freeze while attempting to read amdgpu ids. Attached is the script. It will be nice to provide a better method to read AMD GPU cards. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: Fix old-style declaration
On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
[]
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
[]
> @@ -69,7 +69,7 @@
> #define DC_LOGGER \
> dc->ctx->logger
>
> -const static char DC_BUILD_ID[] = "production-build";
> +static const char DC_BUILD_ID[] = "production-build";
DC_BUILD_ID is used exactly once.
Maybe just use it directly and remove DC_BUILD_ID instead?
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 1fdba13..803dc14 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -69,8 +69,6 @@
#define DC_LOGGER \
dc->ctx->logger
-const static char DC_BUILD_ID[] = "production-build";
-
/**
* DOC: Overview
*
@@ -815,7 +813,7 @@ struct dc *dc_create(const struct dc_init_data *init_params)
if (dc->res_pool->dmcu != NULL)
dc->versions.dmcu_version = dc->res_pool->dmcu->dmcu_version;
- dc->build_id = DC_BUILD_ID;
+ dc->build_id = "production-build";
DC_LOG_DC("Display Core initialized\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
variable refresh rate API
Not sure if this was suggested before -- I couldn't find any relevant threads from a google search: One solution to the problem of applications submitting a frame scheduled a long ways into the future then immediately after that getting user input and wanting to present a new frame right away is to allow changing the scheduled presentation time of already submitted frames, assuming the hardware hasn't started presenting yet. Jacob Lifshay ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 17/23] media/v4l2-core: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Reviewed-by: Ira Weiny
Cc: Mauro Carvalho Chehab
Signed-off-by: John Hubbard
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 28262190c3ab..9b9c5b37bf59 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -183,12 +183,12 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
-flags | FOLL_LONGTERM, dma->pages, NULL);
+ err = pin_longterm_pages(data & PAGE_MASK, dma->nr_pages,
+flags, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages: err=%d [%d]\n", err,
+ dprintk(1, "pin_longterm_pages: err=%d [%d]\n", err,
dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
@@ -349,11 +349,8 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
if (dma->pages) {
- for (i = 0; i < dma->nr_pages; i++) {
- if (dma->direction == DMA_FROM_DEVICE)
- set_page_dirty_lock(dma->pages[i]);
- put_page(dma->pages[i]);
- }
+ put_user_pages_dirty_lock(dma->pages, dma->nr_pages,
+ dma->direction == DMA_FROM_DEVICE);
kfree(dma->pages);
dma->pages = NULL;
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204609] amdgpu: powerplay failed send message
https://bugzilla.kernel.org/show_bug.cgi?id=204609 --- Comment #3 from Guido Winkelmann (guido-kern-b...@unknownsite.de) --- Created attachment 285867 --> https://bugzilla.kernel.org/attachment.cgi?id=285867&action=edit dmesg output from another system -- 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 v3 23/23] mm/gup: remove support for gup(FOLL_LONGTERM)
Now that all other kernel callers of get_user_pages(FOLL_LONGTERM)
have been converted to pin_longterm_pages(), lock it down:
1) Add an assertion to get_user_pages(), preventing callers from
passing FOLL_LONGTERM (in addition to the existing assertion that
prevents FOLL_PIN).
2) Remove the associated GUP_LONGTERM_BENCHMARK test.
Signed-off-by: John Hubbard
---
mm/gup.c | 8
mm/gup_benchmark.c | 9 +
tools/testing/selftests/vm/gup_benchmark.c | 7 ++-
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc164c2ee6b5..db73ba216dff 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1743,11 +1743,11 @@ long get_user_pages(unsigned long start, unsigned long
nr_pages,
struct vm_area_struct **vmas)
{
/*
-* FOLL_PIN must only be set internally by the pin_user_page*() and
-* pin_longterm_*() APIs, never directly by the caller, so enforce that
-* with an assertion:
+* FOLL_PIN and FOLL_LONGTERM must only be set internally by the
+* pin_user_page*() and pin_longterm_*() APIs, never directly by the
+* caller, so enforce that with an assertion:
*/
- if (WARN_ON_ONCE(gup_flags & FOLL_PIN))
+ if (WARN_ON_ONCE(gup_flags & (FOLL_PIN | FOLL_LONGTERM)))
return -EINVAL;
return __gup_longterm_locked(current, current->mm, start, nr_pages,
diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
index 8f980d91dbf5..679f0e6a0adb 100644
--- a/mm/gup_benchmark.c
+++ b/mm/gup_benchmark.c
@@ -6,7 +6,7 @@
#include
#define GUP_FAST_BENCHMARK _IOWR('g', 1, struct gup_benchmark)
-#define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
+/* Command 2 has been deleted. */
#define GUP_BENCHMARK _IOWR('g', 3, struct gup_benchmark)
#define PIN_FAST_BENCHMARK _IOWR('g', 4, struct gup_benchmark)
#define PIN_LONGTERM_BENCHMARK _IOWR('g', 5, struct gup_benchmark)
@@ -28,7 +28,6 @@ static void put_back_pages(int cmd, struct page **pages,
unsigned long nr_pages)
switch (cmd) {
case GUP_FAST_BENCHMARK:
- case GUP_LONGTERM_BENCHMARK:
case GUP_BENCHMARK:
for (i = 0; i < nr_pages; i++)
put_page(pages[i]);
@@ -97,11 +96,6 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
nr = get_user_pages_fast(addr, nr, gup->flags,
pages + i);
break;
- case GUP_LONGTERM_BENCHMARK:
- nr = get_user_pages(addr, nr,
- gup->flags | FOLL_LONGTERM,
- pages + i, NULL);
- break;
case GUP_BENCHMARK:
nr = get_user_pages(addr, nr, gup->flags, pages + i,
NULL);
@@ -159,7 +153,6 @@ static long gup_benchmark_ioctl(struct file *filep,
unsigned int cmd,
switch (cmd) {
case GUP_FAST_BENCHMARK:
- case GUP_LONGTERM_BENCHMARK:
case GUP_BENCHMARK:
case PIN_FAST_BENCHMARK:
case PIN_LONGTERM_BENCHMARK:
diff --git a/tools/testing/selftests/vm/gup_benchmark.c
b/tools/testing/selftests/vm/gup_benchmark.c
index 03928e47a86f..836b7082db13 100644
--- a/tools/testing/selftests/vm/gup_benchmark.c
+++ b/tools/testing/selftests/vm/gup_benchmark.c
@@ -15,7 +15,7 @@
#define PAGE_SIZE sysconf(_SC_PAGESIZE)
#define GUP_FAST_BENCHMARK _IOWR('g', 1, struct gup_benchmark)
-#define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
+/* Command 2 has been deleted. */
#define GUP_BENCHMARK _IOWR('g', 3, struct gup_benchmark)
/*
@@ -49,7 +49,7 @@ int main(int argc, char **argv)
char *file = "/dev/zero";
char *p;
- while ((opt = getopt(argc, argv, "m:r:n:f:abctTLUuwSH")) != -1) {
+ while ((opt = getopt(argc, argv, "m:r:n:f:abctTUuwSH")) != -1) {
switch (opt) {
case 'a':
cmd = PIN_FAST_BENCHMARK;
@@ -75,9 +75,6 @@ int main(int argc, char **argv)
case 'T':
thp = 0;
break;
- case 'L':
- cmd = GUP_LONGTERM_BENCHMARK;
- break;
case 'U':
cmd = GUP_BENCHMARK;
break;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 22/23] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage
It's good to have basic unit test coverage of the new FOLL_PIN behavior. Fortunately, the gup_benchmark unit test is extremely fast (a few milliseconds), so adding it the the run_vmtests suite is going to cause no noticeable change in running time. So, add two new invocations to run_vmtests: 1) Run gup_benchmark with normal get_user_pages(). 2) Run gup_benchmark with pin_user_pages(). This is much like the first call, except that it sets FOLL_PIN. Running these two in quick succession also provide a visual comparison of the running times, which is convenient. The new invocations are fairly early in the run_vmtests script, because with test suites, it's usually preferable to put the shorter, faster tests first, all other things being equal. Signed-off-by: John Hubbard --- tools/testing/selftests/vm/run_vmtests | 22 ++ 1 file changed, 22 insertions(+) diff --git a/tools/testing/selftests/vm/run_vmtests b/tools/testing/selftests/vm/run_vmtests index 951c507a27f7..93e8dc9a7cad 100755 --- a/tools/testing/selftests/vm/run_vmtests +++ b/tools/testing/selftests/vm/run_vmtests @@ -104,6 +104,28 @@ echo "NOTE: The above hugetlb tests provide minimal coverage. Use" echo " https://github.com/libhugetlbfs/libhugetlbfs.git for" echo " hugetlb regression testing." +echo "" +echo "running 'gup_benchmark -U' (normal/slow gup)" +echo "" +./gup_benchmark -U +if [ $? -ne 0 ]; then + echo "[FAIL]" + exitcode=1 +else + echo "[PASS]" +fi + +echo "--" +echo "running gup_benchmark -c (pin_user_pages)" +echo "--" +./gup_benchmark -c +if [ $? -ne 0 ]; then + echo "[FAIL]" + exitcode=1 +else + echo "[PASS]" +fi + echo "---" echo "running userfaultfd" echo "---" -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/23] net/xdp: set FOLL_PIN via pin_user_pages()
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
convert from the get_user_pages()/put_page() model, to the
pin_user_pages()/put_user_page() model, the only change required
here is to change get_user_pages() to pin_longterm_pages().
Reviewed-by: Ira Weiny
Acked-by: Björn Töpel
Signed-off-by: John Hubbard
---
net/xdp/xdp_umem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 3049af269fbf..66c814863cfd 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -291,8 +291,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
return -ENOMEM;
down_read(¤t->mm->mmap_sem);
- npgs = get_user_pages(umem->address, umem->npgs,
- gup_flags | FOLL_LONGTERM, &umem->pgs[0], NULL);
+ npgs = pin_longterm_pages(umem->address, umem->npgs, gup_flags,
+ &umem->pgs[0], NULL);
up_read(¤t->mm->mmap_sem);
if (npgs != umem->npgs) {
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 21/23] mm/gup_benchmark: support pin_user_pages() and related calls
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new corresponding pin_*() functions:
* pin_user_pages(): via the '-c' command line option
* pin_longterm_pages(): via the '-b' command line option
* pin_user_pages_fast(): via the '-a' command line option
Also, add an option for clarity: '-u' for what is now (still) the
default choice: get_user_pages_fast().
Also, for the three commands that set FOLL_PIN, verify that the pages
really are dma-pinned, via the new is_dma_pinned() routine.
Those commands are:
PIN_FAST_BENCHMARK : calls pin_user_pages_fast()
PIN_LONGTERM_BENCHMARK : calls pin_longterm_pages()
PIN_BENCHMARK : calls pin_user_pages()
In between the calls to pin_*() and put_user_pages(),
check each page: if page_dma_pinned() returns false, then
WARN and return.
Do this outside of the benchmark timestamps, so that it doesn't
affect reported times.
Signed-off-by: John Hubbard
---
mm/gup_benchmark.c | 73 --
tools/testing/selftests/vm/gup_benchmark.c | 23 ++-
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
index 7fc44d25eca7..8f980d91dbf5 100644
--- a/mm/gup_benchmark.c
+++ b/mm/gup_benchmark.c
@@ -8,6 +8,9 @@
#define GUP_FAST_BENCHMARK _IOWR('g', 1, struct gup_benchmark)
#define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
#define GUP_BENCHMARK _IOWR('g', 3, struct gup_benchmark)
+#define PIN_FAST_BENCHMARK _IOWR('g', 4, struct gup_benchmark)
+#define PIN_LONGTERM_BENCHMARK _IOWR('g', 5, struct gup_benchmark)
+#define PIN_BENCHMARK _IOWR('g', 6, struct gup_benchmark)
struct gup_benchmark {
__u64 get_delta_usec;
@@ -19,6 +22,44 @@ struct gup_benchmark {
__u64 expansion[10];/* For future use */
};
+static void put_back_pages(int cmd, struct page **pages, unsigned long
nr_pages)
+{
+ int i;
+
+ switch (cmd) {
+ case GUP_FAST_BENCHMARK:
+ case GUP_LONGTERM_BENCHMARK:
+ case GUP_BENCHMARK:
+ for (i = 0; i < nr_pages; i++)
+ put_page(pages[i]);
+ break;
+
+ case PIN_FAST_BENCHMARK:
+ case PIN_LONGTERM_BENCHMARK:
+ case PIN_BENCHMARK:
+ put_user_pages(pages, nr_pages);
+ break;
+ }
+}
+
+static void verify_dma_pinned(int cmd, struct page **pages,
+ unsigned long nr_pages)
+{
+ int i;
+
+ switch (cmd) {
+ case PIN_FAST_BENCHMARK:
+ case PIN_LONGTERM_BENCHMARK:
+ case PIN_BENCHMARK:
+ for (i = 0; i < nr_pages; i++) {
+ if (WARN(!page_dma_pinned(pages[i]),
+"pages[%d] is NOT dma-pinned\n", i))
+ break;
+ }
+ break;
+ }
+}
+
static int __gup_benchmark_ioctl(unsigned int cmd,
struct gup_benchmark *gup)
{
@@ -65,6 +106,18 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
nr = get_user_pages(addr, nr, gup->flags, pages + i,
NULL);
break;
+ case PIN_FAST_BENCHMARK:
+ nr = pin_user_pages_fast(addr, nr, gup->flags,
+pages + i);
+ break;
+ case PIN_LONGTERM_BENCHMARK:
+ nr = pin_longterm_pages(addr, nr, gup->flags, pages + i,
+ NULL);
+ break;
+ case PIN_BENCHMARK:
+ nr = pin_user_pages(addr, nr, gup->flags, pages + i,
+ NULL);
+ break;
default:
return -1;
}
@@ -75,15 +128,22 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
}
end_time = ktime_get();
+ /* Shifting the meaning of nr_pages: now it is actual number pinned: */
+ nr_pages = i;
+
gup->get_delta_usec = ktime_us_delta(end_time, start_time);
gup->size = addr - gup->addr;
+ /*
+* Take an un-benchmark-timed moment to verify DMA pinned
+* state: print a warning if any non-dma-pinned pages are found:
+*/
+ verify_dma_pinned(cmd, pages, nr_pages);
+
start_time = ktime_get();
- for (i = 0; i < nr_pages; i++) {
- if (!pages[i])
- break;
- put_page(pages[i]);
- }
+
+ put_back_pages(cmd, pages, nr_pages);
+
end_time = ktime_get();
gup->put_delta_usec = ktime_us_delta(end
[PATCH v3 20/23] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
phrases in the function calls.
Signed-off-by: John Hubbard
---
mm/gup_benchmark.c | 9 ++---
tools/testing/selftests/vm/gup_benchmark.c | 6 +-
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/mm/gup_benchmark.c b/mm/gup_benchmark.c
index 7dd602d7f8db..7fc44d25eca7 100644
--- a/mm/gup_benchmark.c
+++ b/mm/gup_benchmark.c
@@ -48,18 +48,21 @@ static int __gup_benchmark_ioctl(unsigned int cmd,
nr = (next - addr) / PAGE_SIZE;
}
+ /* Filter out most gup flags: only allow a tiny subset here: */
+ gup->flags &= FOLL_WRITE;
+
switch (cmd) {
case GUP_FAST_BENCHMARK:
- nr = get_user_pages_fast(addr, nr, gup->flags & 1,
+ nr = get_user_pages_fast(addr, nr, gup->flags,
pages + i);
break;
case GUP_LONGTERM_BENCHMARK:
nr = get_user_pages(addr, nr,
- (gup->flags & 1) | FOLL_LONGTERM,
+ gup->flags | FOLL_LONGTERM,
pages + i, NULL);
break;
case GUP_BENCHMARK:
- nr = get_user_pages(addr, nr, gup->flags & 1, pages + i,
+ nr = get_user_pages(addr, nr, gup->flags, pages + i,
NULL);
break;
default:
diff --git a/tools/testing/selftests/vm/gup_benchmark.c
b/tools/testing/selftests/vm/gup_benchmark.c
index 485cf06ef013..389327e9b30a 100644
--- a/tools/testing/selftests/vm/gup_benchmark.c
+++ b/tools/testing/selftests/vm/gup_benchmark.c
@@ -18,6 +18,9 @@
#define GUP_LONGTERM_BENCHMARK _IOWR('g', 2, struct gup_benchmark)
#define GUP_BENCHMARK _IOWR('g', 3, struct gup_benchmark)
+/* Just the flags we need, copied from mm.h: */
+#define FOLL_WRITE 0x01/* check pte is writable */
+
struct gup_benchmark {
__u64 get_delta_usec;
__u64 put_delta_usec;
@@ -85,7 +88,8 @@ int main(int argc, char **argv)
}
gup.nr_pages_per_call = nr_pages;
- gup.flags = write;
+ if (write)
+ gup.flags |= FOLL_WRITE;
fd = open("/sys/kernel/debug/gup_benchmark", O_RDWR);
if (fd == -1)
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/23] mm/gup: track FOLL_PIN pages
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Pages that have been pinned via FOLL_PIN are identifiable via a
new function call:
bool page_dma_pinned(struct page *page);
What to do in response to encountering such a page, is left to later
patchsets. There is discussion about this in [1].
This also changes a BUG_ON(), to a WARN_ON(), in follow_page_mask().
Suggested-by: Jan Kara
Suggested-by: Jérôme Glisse
Signed-off-by: John Hubbard
---
include/linux/mm.h | 75
include/linux/mmzone.h | 2 +
include/linux/page_ref.h | 10 +++
mm/gup.c | 190 +--
mm/huge_memory.c | 54 ++-
mm/hugetlb.c | 39 +++-
mm/vmstat.c | 2 +
7 files changed, 322 insertions(+), 50 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 11e0086d64a4..19b3fa68a4da 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1054,6 +1054,8 @@ static inline __must_check bool try_get_page(struct page
*page)
return true;
}
+__must_check bool user_page_ref_inc(struct page *page);
+
static inline void put_page(struct page *page)
{
page = compound_head(page);
@@ -1071,31 +1073,70 @@ static inline void put_page(struct page *page)
__put_page(page);
}
-/**
- * put_user_page() - release a gup-pinned page
- * @page:pointer to page to be released
+/*
+ * GUP_PIN_COUNTING_BIAS, and the associated functions that use it, overload
+ * the page's refcount so that two separate items are tracked: the original
page
+ * reference count, and also a new count of how many get_user_pages() calls
were
+ * made against the page. ("gup-pinned" is another term for the latter).
+ *
+ * With this scheme, get_user_pages() becomes special: such pages are marked
+ * as distinct from normal pages. As such, the new put_user_page() call (and
+ * its variants) must be used in order to release gup-pinned pages.
+ *
+ * Choice of value:
*
- * Pages that were pinned via get_user_pages*() must be released via
- * either put_user_page(), or one of the put_user_pages*() routines
- * below. This is so that eventually, pages that are pinned via
- * get_user_pages*() can be separately tracked and uniquely handled. In
- * particular, interactions with RDMA and filesystems need special
- * handling.
+ * By making GUP_PIN_COUNTING_BIAS a power of two, debugging of page reference
+ * counts with respect to get_user_pages() and put_user_page() becomes simpler,
+ * due to the fact that adding an even power of two to the page refcount has
+ * the effect of using only the upper N bits, for the code that counts up using
+ * the bias value. This means that the lower bits are left for the exclusive
+ * use of the original code that increments and decrements by one (or at least,
+ * by much smaller values than the bias value).
*
- * put_user_page() and put_page() are not interchangeable, despite this early
- * implementation that makes them look the same. put_user_page() calls must
- * be perfectly matched up with get_user_page() calls.
+ * Of course, once the lower bits overflow into the upper bits (and this is
+ * OK, because subtraction recovers the original values), then visual
inspection
+ * no longer suffices to directly view the separate counts. However, for normal
+ * applications that don't have huge page reference counts, this won't be an
+ * issue.
+ *
+ * Locking: the lockless algorithm described in page_cache_get_speculative()
+ * and page_cache_gup_pin_speculative() provides safe operation for
+ * get_user_pages and page_mkclean and other calls that race to set up page
+ * table entries.
*/
-static inline void put_user_page(struct page *page)
-{
- put_page(page);
-}
+#define GUP_PIN_COUNTING_BIAS (1UL << 10)
+void put_user_page(struct page *page);
void put_user_pages_dirty_lock(struct page **pages, unsigned long npages,
bool make_dirty);
-
void put_user_pages(struct page **pages, unsigned long npages);
+/**
+ * page_dma_pinned() - report if a page is pinned for DMA.
+ *
+ * This function checks if a page has been pinned via a call to
+ * pin_user_pages*() or pin_longterm_pages*().
+ *
+ * The return value is partially fuzzy: false is not fuzzy, because it means
+ * "definitely not pinned for DMA", but true means "probably pinned for DMA,
but
+ * possibly a false positive due to having at least GUP_PIN_COUNTING_BIAS worth
+ * of normal page references".
+ *
+ * False positives are OK, because: a) it's unlikely for a page to get that
many
+ * refcounts, and b) all the callers of this routine are expected to be able to
+ * deal gracefully with a false positive.
+ *
+ * For more in
[PATCH v3 11/23] IB/{core, hw, umem}: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via put_user_page*() calls, but
infiniband was already doing that as part of an earlier
commit.
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 10 -
drivers/infiniband/core/umem_odp.c | 24 ++---
drivers/infiniband/hw/hfi1/user_pages.c | 4 ++--
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +--
drivers/infiniband/hw/qib/qib_user_pages.c | 8 +++
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c| 9
drivers/infiniband/sw/siw/siw_mem.c | 5 ++---
8 files changed, 31 insertions(+), 34 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 3d664a2539eb..7f03f72e6dce 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -271,11 +271,11 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
sg = umem->sg_head.sgl;
while (npages) {
- ret = get_user_pages_fast(cur_base,
- min_t(unsigned long, npages,
- PAGE_SIZE /
- sizeof(struct page *)),
- gup_flags | FOLL_LONGTERM, page_list);
+ ret = pin_longterm_pages_fast(cur_base,
+ min_t(unsigned long, npages,
+ PAGE_SIZE /
+ sizeof(struct page *)),
+ gup_flags, page_list);
if (ret < 0)
goto umem_release;
diff --git a/drivers/infiniband/core/umem_odp.c
b/drivers/infiniband/core/umem_odp.c
index 163ff7ba92b7..b0ae039f884d 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -495,9 +495,8 @@ EXPORT_SYMBOL(ib_umem_odp_release);
* The function returns -EFAULT if the DMA mapping operation fails. It returns
* -EAGAIN if a concurrent invalidation prevents us from updating the page.
*
- * The page is released via put_user_page even if the operation failed. For
- * on-demand pinning, the page is released whenever it isn't stored in the
- * umem.
+ * The page is released via put_page even if the operation failed. For
on-demand
+ * pinning, the page is released whenever it isn't stored in the umem.
*/
static int ib_umem_odp_map_dma_single_page(
struct ib_umem_odp *umem_odp,
@@ -542,7 +541,7 @@ static int ib_umem_odp_map_dma_single_page(
}
out:
- put_user_page(page);
+ put_page(page);
if (remove_existing_mapping) {
ib_umem_notifier_start_account(umem_odp);
@@ -639,13 +638,14 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp
*umem_odp, u64 user_virt,
/*
* Note: this might result in redundent page getting. We can
* avoid this by checking dma_list to be 0 before calling
-* get_user_pages. However, this make the code much more
-* complex (and doesn't gain us much performance in most use
-* cases).
+* get_user_pages. However, this makes the code much
+* more complex (and doesn't gain us much performance in most
+* use cases).
*/
npages = get_user_pages_remote(owning_process, owning_mm,
- user_virt, gup_num_pages,
- flags, local_page_list, NULL, NULL);
+ user_virt, gup_num_pages,
+ flags, local_page_list, NULL,
+ NULL);
up_read(&owning_mm->mmap_sem);
if (npages < 0) {
@@ -665,7 +665,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp,
u64 user_virt,
ret = -EFAULT;
break;
}
- put_user_page(local_page_list[j]);
+ put_page(local_page_list[j]);
continue;
}
@@ -692,8 +692,8 @@ int ib_umem_odp_map_dma_pages(struct ib_umem_odp *umem_odp,
u64 user_virt,
* ib_umem_odp_map_dma_single_page().
*/
if (npages - (j + 1) > 0)
- put_user_pages(&local_page_list[j+1
[PATCH v3 19/23] powerpc: book3s64: convert to pin_longterm_pages() and put_user_page()
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
3. Release each page in mem->hpages[] (instead of mem->hpas[]), because
that is the array that pin_longterm_pages() filled in. This is more
accurate and should be a little safer from a maintenance point of
view.
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index 56cc84520577..69d79cb50d47 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -103,9 +103,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
unsigned long ua,
for (entry = 0; entry < entries; entry += chunk) {
unsigned long n = min(entries - entry, chunk);
- ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
- FOLL_WRITE | FOLL_LONGTERM,
- mem->hpages + entry, NULL);
+ ret = pin_longterm_pages(ua + (entry << PAGE_SHIFT), n,
+FOLL_WRITE, mem->hpages + entry, NULL);
if (ret == n) {
pinned += n;
continue;
@@ -167,9 +166,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
unsigned long ua,
return 0;
free_exit:
- /* free the reference taken */
- for (i = 0; i < pinned; i++)
- put_page(mem->hpages[i]);
+ /* free the references taken */
+ put_user_pages(mem->hpages, pinned);
vfree(mem->hpas);
kfree(mem);
@@ -212,10 +210,9 @@ static void mm_iommu_unpin(struct
mm_iommu_table_group_mem_t *mem)
if (!page)
continue;
- if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
- SetPageDirty(page);
+ put_user_pages_dirty_lock(&mem->hpages[i], 1,
+ MM_IOMMU_TABLE_GROUP_PAGE_DIRTY);
- put_page(page);
mem->hpas[i] = 0;
}
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/23] fs/io_uring: set FOLL_PIN via pin_user_pages()
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling put_user_page() instead of put_page(). Therefore, in order to
convert from the get_user_pages()/put_page() model, to the
pin_user_pages()/put_user_page() model, the only change required
here is to change get_user_pages() to pin_longterm_pages().
Reviewed-by: Ira Weiny
Reviewed-by: Jens Axboe
Signed-off-by: John Hubbard
---
fs/io_uring.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index f9a38998f2fc..0f307f2c7cac 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -3433,9 +3433,8 @@ static int io_sqe_buffer_register(struct io_ring_ctx
*ctx, void __user *arg,
ret = 0;
down_read(¤t->mm->mmap_sem);
- pret = get_user_pages(ubuf, nr_pages,
- FOLL_WRITE | FOLL_LONGTERM,
- pages, vmas);
+ pret = pin_longterm_pages(ubuf, nr_pages, FOLL_WRITE, pages,
+ vmas);
if (pret == nr_pages) {
/* don't support file backed memory */
for (j = 0; j < nr_pages; j++) {
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/23] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of process_vm_rw_single_vec().
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/process_vm_access.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index 357aa7bef6c0..fd20ab675b85 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -42,12 +42,11 @@ static int process_vm_rw_pages(struct page **pages,
if (copy > len)
copy = len;
- if (vm_write) {
+ if (vm_write)
copied = copy_page_from_iter(page, offset, copy, iter);
- set_page_dirty_lock(page);
- } else {
+ else
copied = copy_page_to_iter(page, offset, copy, iter);
- }
+
len -= copied;
if (copied < copy && iov_iter_count(iter))
return -EFAULT;
@@ -96,7 +95,7 @@ static int process_vm_rw_single_vec(unsigned long addr,
flags |= FOLL_WRITE;
while (!rc && nr_pages && iov_iter_count(iter)) {
- int pages = min(nr_pages, max_pages_per_loop);
+ int pinned_pages = min(nr_pages, max_pages_per_loop);
int locked = 1;
size_t bytes;
@@ -106,14 +105,15 @@ static int process_vm_rw_single_vec(unsigned long addr,
* current/current->mm
*/
down_read(&mm->mmap_sem);
- pages = get_user_pages_remote(task, mm, pa, pages, flags,
- process_pages, NULL, &locked);
+ pinned_pages = pin_user_pages_remote(task, mm, pa, pinned_pages,
+flags, process_pages,
+NULL, &locked);
if (locked)
up_read(&mm->mmap_sem);
- if (pages <= 0)
+ if (pinned_pages <= 0)
return -EFAULT;
- bytes = pages * PAGE_SIZE - start_offset;
+ bytes = pinned_pages * PAGE_SIZE - start_offset;
if (bytes > len)
bytes = len;
@@ -122,10 +122,12 @@ static int process_vm_rw_single_vec(unsigned long addr,
vm_write);
len -= bytes;
start_offset = 0;
- nr_pages -= pages;
- pa += pages * PAGE_SIZE;
- while (pages)
- put_page(process_pages[--pages]);
+ nr_pages -= pinned_pages;
+ pa += pinned_pages * PAGE_SIZE;
+
+ /* If vm_write is set, the pages need to be made dirty: */
+ put_user_pages_dirty_lock(process_pages, pinned_pages,
+ vm_write);
}
return rc;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/23] vfio, mm: pin_longterm_pages (FOLL_PIN) and put_user_page() conversion
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages().
Note that this effectively changes the code's behavior in
vfio_iommu_type1.c: put_pfn(): it now ultimately calls
set_page_dirty_lock(), instead of set_page_dirty(). This is
probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Cc: Alex Williamson
Signed-off-by: John Hubbard
---
drivers/vfio/vfio_iommu_type1.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 017689b7c32b..07bec0bdd316 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -327,9 +327,8 @@ static int put_pfn(unsigned long pfn, int prot)
{
if (!is_invalid_reserved_pfn(pfn)) {
struct page *page = pfn_to_page(pfn);
- if (prot & IOMMU_WRITE)
- SetPageDirty(page);
- put_page(page);
+
+ put_user_pages_dirty_lock(&page, 1, prot & IOMMU_WRITE);
return 1;
}
return 0;
@@ -348,8 +347,8 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
flags |= FOLL_WRITE;
down_read(&mm->mmap_sem);
- ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
- page, vmas, NULL);
+ ret = pin_longterm_pages_remote(NULL, mm, vaddr, 1, flags, page, vmas,
+ NULL);
/*
* The lifetime of a vaddr_get_pfn() page pin is
* userspace-controlled. In the fs-dax case this could
@@ -359,7 +358,7 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
*/
if (ret > 0 && vma_is_fsdax(vmas[0])) {
ret = -EOPNOTSUPP;
- put_page(page[0]);
+ put_user_page(page[0]);
}
up_read(&mm->mmap_sem);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204609] amdgpu: powerplay failed send message
https://bugzilla.kernel.org/show_bug.cgi?id=204609 Guido Winkelmann (guido-kern-b...@unknownsite.de) changed: What|Removed |Added CC||guido-kern-bugs@unknownsite ||.de --- Comment #2 from Guido Winkelmann (guido-kern-b...@unknownsite.de) --- I have very similar problems with Kernel 5.4-rc7. In my case it's a Sapphire 5700XT, and I am using Gentoo instead of Ubuntu, however, the problems start way before any userspace code is loaded. In my case, the problems cause long delays on system boot, once before loading init, once while X is loading. As a very rough estimate, I think the delays amount to about 2 minutes. Once X is loaded, I can no longer see any delays. All sensors on the board are completely non-functional. Here is a sample output from "sensors": == amdgpu-pci-0a00 Adapter: PCI adapter vddgfx: +0.75 V ERROR: Can't get value of subfeature fan1_input: I/O error fan1: N/A (min =0 RPM, max = 3200 RPM) ERROR: Can't get value of subfeature temp1_input: I/O error edge: N/A (crit = +118.0°C, hyst = -273.1°C) (emerg = +99.0°C) ERROR: Can't get value of subfeature temp2_input: I/O error junction: N/A (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) ERROR: Can't get value of subfeature temp3_input: I/O error mem: N/A (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) ERROR: Can't get value of subfeature power1_average: I/O error power1: N/A (cap = 195.00 W) k10temp-pci-00c3 Adapter: PCI adapter Tdie: +31.5°C (high = +70.0°C) Tctl: +41.5°C == I did not experience any of these problems with 5.3.10. I have three monitors connected to this board, all of them via DisplayPort. I am attaching another dmesg log. -- 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 v3 02/23] mm/gup: factor out duplicate code from four routines
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static functions, thus reducing the
overall line count and the code's complexity.
Also, take the opportunity to slightly improve the efficiency of the
error cases, by doing a mass subtraction of the refcount, surrounded
by get_page()/put_page().
Also, further simplify (slightly), by waiting until the the successful
end of each routine, to increment *nr.
Reviewed-by: Jérôme Glisse
Cc: Ira Weiny
Cc: Christoph Hellwig
Cc: Aneesh Kumar K.V
Signed-off-by: John Hubbard
---
mm/gup.c | 104 ---
1 file changed, 45 insertions(+), 59 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 85caf76b3012..199da99e8ffc 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1969,6 +1969,34 @@ static int __gup_device_huge_pud(pud_t pud, pud_t *pudp,
unsigned long addr,
}
#endif
+static int __record_subpages(struct page *page, unsigned long addr,
+unsigned long end, struct page **pages, int nr)
+{
+ int nr_recorded_pages = 0;
+
+ do {
+ pages[nr] = page;
+ nr++;
+ page++;
+ nr_recorded_pages++;
+ } while (addr += PAGE_SIZE, addr != end);
+ return nr_recorded_pages;
+}
+
+static void put_compound_head(struct page *page, int refs)
+{
+ /* Do a get_page() first, in case refs == page->_refcount */
+ get_page(page);
+ page_ref_sub(page, refs);
+ put_page(page);
+}
+
+static void __huge_pt_done(struct page *head, int nr_recorded_pages, int *nr)
+{
+ *nr += nr_recorded_pages;
+ SetPageReferenced(head);
+}
+
#ifdef CONFIG_ARCH_HAS_HUGEPD
static unsigned long hugepte_addr_end(unsigned long addr, unsigned long end,
unsigned long sz)
@@ -1998,33 +2026,20 @@ static int gup_hugepte(pte_t *ptep, unsigned long sz,
unsigned long addr,
/* hugepages are never "special" */
VM_BUG_ON(!pfn_valid(pte_pfn(pte)));
- refs = 0;
head = pte_page(pte);
-
page = head + ((addr & (sz-1)) >> PAGE_SHIFT);
- do {
- VM_BUG_ON(compound_head(page) != head);
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(head, refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pte_val(pte) != pte_val(*ptep))) {
- /* Could be optimized better */
- *nr -= refs;
- while (refs--)
- put_page(head);
+ put_compound_head(head, refs);
return 0;
}
- SetPageReferenced(head);
+ __huge_pt_done(head, refs, nr);
return 1;
}
@@ -2071,29 +2086,19 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
unsigned long addr,
pages, nr);
}
- refs = 0;
page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
- do {
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(pmd_page(orig), refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
- *nr -= refs;
- while (refs--)
- put_page(head);
+ put_compound_head(head, refs);
return 0;
}
- SetPageReferenced(head);
+ __huge_pt_done(head, refs, nr);
return 1;
}
@@ -2114,29 +2119,19 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp,
unsigned long addr,
pages, nr);
}
- refs = 0;
page = pud_page(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
- do {
- pages[*nr] = page;
- (*nr)++;
- page++;
- refs++;
- } while (addr += PAGE_SIZE, addr != end);
+ refs = __record_subpages(page, addr, end, pages, *nr);
head = try_get_compound_head(pud_page(orig), refs);
- if (!head) {
- *nr -= refs;
+ if (!head)
return 0;
- }
if (unlikely(pud_val(orig) != pud_val(*pudp))) {
- *nr -= refs;
- while (refs--)
- put_page(head);
+ put_c
[PATCH v3 07/23] media/v4l2-core: set pages dirty upon releasing DMA buffers
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling set_page_dirty_lock() if the CPU pages
were potentially receiving data from the device.
Acked-by: Hans Verkuil
Cc: Mauro Carvalho Chehab
Signed-off-by: John Hubbard
---
drivers/media/v4l2-core/videobuf-dma-sg.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 66a6c6c236a7..28262190c3ab 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
BUG_ON(dma->sglen);
if (dma->pages) {
- for (i = 0; i < dma->nr_pages; i++)
+ for (i = 0; i < dma->nr_pages; i++) {
+ if (dma->direction == DMA_FROM_DEVICE)
+ set_page_dirty_lock(dma->pages[i]);
put_page(dma->pages[i]);
+ }
kfree(dma->pages);
dma->pages = NULL;
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/23] drm/via: set FOLL_PIN via pin_user_pages_fast()
Convert drm/via to use the new pin_user_pages_fast() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the drm/via driver was already calling put_user_page() instead of put_page(). Therefore, in order to convert from the get_user_pages()/put_page() model, to the pin_user_pages()/put_user_page() model, the only change required is to change get_user_pages() to pin_user_pages(). Acked-by: Daniel Vetter Reviewed-by: Jérôme Glisse Reviewed-by: Ira Weiny Signed-off-by: John Hubbard --- drivers/gpu/drm/via/via_dmablit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/via/via_dmablit.c b/drivers/gpu/drm/via/via_dmablit.c index 3db000aacd26..37c5e572993a 100644 --- a/drivers/gpu/drm/via/via_dmablit.c +++ b/drivers/gpu/drm/via/via_dmablit.c @@ -239,7 +239,7 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg, drm_via_dmablit_t *xfer) vsg->pages = vzalloc(array_size(sizeof(struct page *), vsg->num_pages)); if (NULL == vsg->pages) return -ENOMEM; - ret = get_user_pages_fast((unsigned long)xfer->mem_addr, + ret = pin_user_pages_fast((unsigned long)xfer->mem_addr, vsg->num_pages, vsg->direction == DMA_FROM_DEVICE ? FOLL_WRITE : 0, vsg->pages); -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/23] mm/gup: track dma-pinned pages: FOLL_PIN, FOLL_LONGTERM
Hi,
The cover letter is long, so the more important stuff is first:
* Jason, if you or someone could look at the the VFIO cleanup (patch 8)
and conversion to FOLL_PIN (patch 18), to make sure it's use of
remote and longterm gup matches what we discussed during the review
of v2, I'd appreciate it.
* Also for Jason and IB: as noted below, in patch 11, I am (too?) boldly
converting from put_user_pages() to release_pages().
* Jerome, I am going to take a look at doing your FOLL_GET change idea
(some callers should set FOLL_GET) separately, because it blew up "a
little bit" in my face. It's definitely a separate--tiny, but risky--project.
It also looks more reasonable when applied on top of this series here
(and it conflicts a lot), so I'm going to send it as a follow-up.
Changes since v2:
* Added a patch to convert IB/umem from normal gup, to gup_fast(). This
is also posted separately, in order to hopefully get some runtime
testing.
* Changed the page devmap code to be a little clearer,
thanks to Jerome for that.
* Split out the page devmap changes into a separate patch (and moved
Ira's Signed-off-by to that patch).
* Fixed my bug in IB: ODP code does not require pin_user_pages()
semantics. Therefore, revert the put_user_page() calls to put_page(),
and leave the get_user_pages() call as-is.
* As part of the revert, I am proposing here a change directly
from put_user_pages(), to release_pages(). I'd feel better if
someone agrees that this is the best way. It uses the more
efficient release_pages(), instead of put_page() in a loop,
and keep the change to just a few character on one line,
but OTOH it is not a pure revert.
* Loosened the FOLL_LONGTERM restrictions in the
__get_user_pages_locked() implementation, and used that in order
to fix up a VFIO bug. Thanks to Jason for that idea.
* Note the use of release_pages() in IB: is that OK?
* Added a few more WARN's and clarifying comments nearby.
* Many documentation improvements in various comments.
* Moved the new pin_user_pages.rst from Documentation/vm/ to
Documentation/core-api/ .
* Commit descriptions: added clarifying notes to the three patches
(drm/via, fs/io_uring, net/xdp) that already had put_user_page()
calls in place.
* Collected all pending Reviewed-by and Acked-by tags, from v1 and v2
email threads.
* Lot of churn from v2 --> v3, so it's possible that new bugs
sneaked in.
NOT DONE: separate patchset is required:
* __get_user_pages_locked(): stop compensating for
buggy callers who failed to set FOLL_GET. Instead, assert
that FOLL_GET is set (and fail if it's not).
==
Original cover letter (edited to fix up the patch description numbers)
This applies cleanly to linux-next and mmotm, and also to linux.git if
linux-next's commit 20cac10710c9 ("mm/gup_benchmark: fix MAP_HUGETLB
case") is first applied there.
This provides tracking of dma-pinned pages. This is a prerequisite to
solving the larger problem of proper interactions between file-backed
pages, and [R]DMA activities, as discussed in [1], [2], [3], and in
a remarkable number of email threads since about 2017. :)
A new internal gup flag, FOLL_PIN is introduced, and thoroughly
documented in the last patch's Documentation/vm/pin_user_pages.rst.
I believe that this will provide a good starting point for doing the
layout lease work that Ira Weiny has been working on. That's because
these new wrapper functions provide a clean, constrained, systematically
named set of functionality that, again, is required in order to even
know if a page is "dma-pinned".
In contrast to earlier approaches, the page tracking can be
incrementally applied to the kernel call sites that, until now, have
been simply calling get_user_pages() ("gup"). In other words, opt-in by
changing from this:
get_user_pages() (sets FOLL_GET)
put_page()
to this:
pin_user_pages() (sets FOLL_PIN)
put_user_page()
Because there are interdependencies with FOLL_LONGTERM, a similar
conversion as for FOLL_PIN, was applied. The change was from this:
get_user_pages(FOLL_LONGTERM) (also sets FOLL_GET)
put_page()
to this:
pin_longterm_pages() (sets FOLL_PIN | FOLL_LONGTERM)
put_user_page()
Patch summary:
* Patches 1-8: refactoring and preparatory cleanup, independent fixes
* Patch 9: introduce pin_user_pages(), FOLL_PIN, but no functional
changes yet
* Patches 10-15: Convert existing put_user_page() callers, to use the
new pin*()
* Patch 16: Activate tracking of FOLL_PIN pages.
* Patches 17-19: convert FOLL_LONGTERM callers
* Patches: 20-22: gup_benchmark and run_vmtests support
* Patch 23: enforce FOLL_LONGTERM as a gup-internal (only) flag
Testing:
* I've done some overall kernel
[PATCH v3 09/23] mm/gup: introduce pin_user_pages*() and FOLL_PIN
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented.
The pin_longterm*() variants also set FOLL_LONGTERM, in addition
to FOLL_PIN:
pin_user_pages()
pin_user_pages_remote()
pin_user_pages_fast()
pin_longterm_pages()
pin_longterm_pages_remote()
pin_longterm_pages_fast()
All pages that are pinned via the above calls, must be unpinned via
put_user_page().
The underlying rules are:
* These are gup-internal flags, so the call sites should not directly
set FOLL_PIN nor FOLL_LONGTERM. That behavior is enforced with
assertions, for the new FOLL_PIN flag. However, for the pre-existing
FOLL_LONGTERM flag, which has some call sites that still directly
set FOLL_LONGTERM, there is no assertion yet.
* Call sites that want to indicate that they are going to do DirectIO
("DIO") or something with similar characteristics, should call a
get_user_pages()-like wrapper call that sets FOLL_PIN. These wrappers
will:
* Start with "pin_user_pages" instead of "get_user_pages". That
makes it easy to find and audit the call sites.
* Set FOLL_PIN
* For pages that are received via FOLL_PIN, those pages must be returned
via put_user_page().
Thanks to Jan Kara and Vlastimil Babka for explaining the 4 cases
in this documentation. (I've reworded it and expanded upon it.)
Reviewed-by: Jérôme Glisse
Cc: Mike Rapoport
Cc: Jonathan Corbet
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pin_user_pages.rst | 218 ++
include/linux/mm.h| 62 +-
mm/gup.c | 260 --
4 files changed, 514 insertions(+), 27 deletions(-)
create mode 100644 Documentation/core-api/pin_user_pages.rst
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ab0eae1c153a..413f7d7c8642 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -31,6 +31,7 @@ Core utilities
generic-radix-tree
memory-allocation
mm-api
+ pin_user_pages
gfp_mask-from-fs-io
timekeeping
boot-time-mm
diff --git a/Documentation/core-api/pin_user_pages.rst
b/Documentation/core-api/pin_user_pages.rst
new file mode 100644
index ..ce819e709435
--- /dev/null
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -0,0 +1,218 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+pin_user_pages() and related calls
+
+
+.. contents:: :local:
+
+Overview
+
+
+This document describes the following functions: ::
+
+ pin_user_pages
+ pin_user_pages_fast
+ pin_user_pages_remote
+
+ pin_longterm_pages
+ pin_longterm_pages_fast
+ pin_longterm_pages_remote
+
+Basic description of FOLL_PIN
+=
+
+FOLL_PIN and FOLL_LONGTERM are flags that can be passed to the
get_user_pages*()
+("gup") family of functions. FOLL_PIN has significant interactions and
+interdependencies with FOLL_LONGTERM, so both are covered here.
+
+Both FOLL_PIN and FOLL_LONGTERM are internal to gup, meaning that neither
+FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This allows
+the associated wrapper functions (pin_user_pages() and others) to set the
+correct combination of these flags, and to check for problems as well.
+
+FOLL_PIN and FOLL_GET are mutually exclusive for a given gup call. However,
+multiple threads and call sites are free to pin the same struct pages, via both
+FOLL_PIN and FOLL_GET. It's just the call site that needs to choose one or the
+other, not the struct page(s).
+
+The FOLL_PIN implementation is nearly the same as FOLL_GET, except that
FOLL_PIN
+uses a different reference counting technique.
+
+FOLL_PIN is a prerequisite to FOLL_LONGTGERM. Another way of saying that is,
+FOLL_LONGTERM is a specific case, more restrictive case of FOLL_PIN.
+
+Which flags are set by each wrapper
+===
+
+Only FOLL_PIN and FOLL_LONGTERM are covered here. These flags are added to
+whatever flags the caller provides::
+
+ Functiongup flags (FOLL_PIN or FOLL_LONGTERM only)
+ --
+ pin_user_pages FOLL_PIN
+ pin_user_pages_fast FOLL_PIN
+ pin_user_pages_remote FOLL_PIN
+
+ pin_longterm_pages FOLL_PIN | FOLL_LONGTERM
+ pin_longterm_pages_fast FOLL_PIN | FOLL_LONGTERM
+ pin_longterm_pages_remote FOLL_PIN | FOLL_LONGTERM
+
+Tracking dma-pinned pages
+=
+
+Some of the key design constraints, and solutions, for tracking dma-pinned
+pages:
+
+* An actual reference count, per struct page, is required. This is because
+ multiple processes may pin and un
[PATCH v3 10/23] goldish_pipe: convert to pin_user_pages() and put_user_page()
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is probably more accurate.
As Christoph Hellwig put it, "set_page_dirty() is only safe if we are
dealing with a file backed page where we have reference on the inode it
hangs off." [1]
Another side effect is that the release code is simplified because
the page[] loop is now in gup.c instead of here, so just delete the
local release_user_pages() entirely, and call
put_user_pages_dirty_lock() directly, instead.
[1] https://lore.kernel.org/r/20190723153640.gb...@lst.de
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 7ed2a21a0bac..635a8bc1b480 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -274,7 +274,7 @@ static int pin_goldfish_pages(unsigned long first_page,
*iter_last_page_size = last_page_size;
}
- ret = get_user_pages_fast(first_page, requested_pages,
+ ret = pin_user_pages_fast(first_page, requested_pages,
!is_write ? FOLL_WRITE : 0,
pages);
if (ret <= 0)
@@ -285,18 +285,6 @@ static int pin_goldfish_pages(unsigned long first_page,
return ret;
}
-static void release_user_pages(struct page **pages, int pages_count,
- int is_write, s32 consumed_size)
-{
- int i;
-
- for (i = 0; i < pages_count; i++) {
- if (!is_write && consumed_size > 0)
- set_page_dirty(pages[i]);
- put_page(pages[i]);
- }
-}
-
/* Populate the call parameters, merging adjacent pages together */
static void populate_rw_params(struct page **pages,
int pages_count,
@@ -372,7 +360,8 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
*consumed_size = pipe->command_buffer->rw_params.consumed_size;
- release_user_pages(pipe->pages, pages_count, is_write, *consumed_size);
+ put_user_pages_dirty_lock(pipe->pages, pages_count,
+ !is_write && *consumed_size > 0);
mutex_unlock(&pipe->lock);
return 0;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/23] goldish_pipe: rename local pin_user_pages() routine
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_pipe.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index cef0133aa47a..7ed2a21a0bac 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -257,12 +257,12 @@ static int goldfish_pipe_error_convert(int status)
}
}
-static int pin_user_pages(unsigned long first_page,
- unsigned long last_page,
- unsigned int last_page_size,
- int is_write,
- struct page *pages[MAX_BUFFERS_PER_COMMAND],
- unsigned int *iter_last_page_size)
+static int pin_goldfish_pages(unsigned long first_page,
+ unsigned long last_page,
+ unsigned int last_page_size,
+ int is_write,
+ struct page *pages[MAX_BUFFERS_PER_COMMAND],
+ unsigned int *iter_last_page_size)
{
int ret;
int requested_pages = ((last_page - first_page) >> PAGE_SHIFT) + 1;
@@ -354,9 +354,9 @@ static int transfer_max_buffers(struct goldfish_pipe *pipe,
if (mutex_lock_interruptible(&pipe->lock))
return -ERESTARTSYS;
- pages_count = pin_user_pages(first_page, last_page,
-last_page_size, is_write,
-pipe->pages, &iter_last_page_size);
+ pages_count = pin_goldfish_pages(first_page, last_page,
+last_page_size, is_write,
+pipe->pages, &iter_last_page_size);
if (pages_count < 0) {
mutex_unlock(&pipe->lock);
return pages_count;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/23] IB/umem: use get_user_pages_fast() to pin DMA pages
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Ira Weiny
Cc: Jason Gunthorpe
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 24244a2f68cc..3d664a2539eb 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -271,16 +271,13 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
sg = umem->sg_head.sgl;
while (npages) {
- down_read(&mm->mmap_sem);
- ret = get_user_pages(cur_base,
-min_t(unsigned long, npages,
- PAGE_SIZE / sizeof (struct page *)),
-gup_flags | FOLL_LONGTERM,
-page_list, NULL);
- if (ret < 0) {
- up_read(&mm->mmap_sem);
+ ret = get_user_pages_fast(cur_base,
+ min_t(unsigned long, npages,
+ PAGE_SIZE /
+ sizeof(struct page *)),
+ gup_flags | FOLL_LONGTERM, page_list);
+ if (ret < 0)
goto umem_release;
- }
cur_base += ret * PAGE_SIZE;
npages -= ret;
@@ -288,8 +285,6 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
sg = ib_umem_add_sg_table(sg, page_list, ret,
dma_get_max_seg_size(context->device->dma_device),
&umem->sg_nents);
-
- up_read(&mm->mmap_sem);
}
sg_mark_end(sg);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/23] vfio, mm: fix get_user_pages_remote() and FOLL_LONGTERM
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
FOLL_LONGTERM callers, but we can actually allow FOLL_LONGTERM callers
that do not set the "locked" arg.
Update the code and comments accordingly, and update the VFIO caller
to take advantage of this, fixing a bug as a result: the VFIO caller
is logically a FOLL_LONGTERM user.
Thanks to Jason Gunthorpe for pointing out a clean way to fix this.
Suggested-by: Jason Gunthorpe
Cc: Jerome Glisse
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/vfio/vfio_iommu_type1.c | 30 +-
mm/gup.c| 13 -
2 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index d864277ea16f..017689b7c32b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -348,24 +348,20 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned
long vaddr,
flags |= FOLL_WRITE;
down_read(&mm->mmap_sem);
- if (mm == current->mm) {
- ret = get_user_pages(vaddr, 1, flags | FOLL_LONGTERM, page,
-vmas);
- } else {
- ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
- vmas, NULL);
- /*
-* The lifetime of a vaddr_get_pfn() page pin is
-* userspace-controlled. In the fs-dax case this could
-* lead to indefinite stalls in filesystem operations.
-* Disallow attempts to pin fs-dax pages via this
-* interface.
-*/
- if (ret > 0 && vma_is_fsdax(vmas[0])) {
- ret = -EOPNOTSUPP;
- put_page(page[0]);
- }
+ ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
+ page, vmas, NULL);
+ /*
+* The lifetime of a vaddr_get_pfn() page pin is
+* userspace-controlled. In the fs-dax case this could
+* lead to indefinite stalls in filesystem operations.
+* Disallow attempts to pin fs-dax pages via this
+* interface.
+*/
+ if (ret > 0 && vma_is_fsdax(vmas[0])) {
+ ret = -EOPNOTSUPP;
+ put_page(page[0]);
}
+
up_read(&mm->mmap_sem);
if (ret == 1) {
diff --git a/mm/gup.c b/mm/gup.c
index 933524de6249..cfe6dc5fc343 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1167,13 +1167,16 @@ long get_user_pages_remote(struct task_struct *tsk,
struct mm_struct *mm,
struct vm_area_struct **vmas, int *locked)
{
/*
-* FIXME: Current FOLL_LONGTERM behavior is incompatible with
+* Current FOLL_LONGTERM behavior is incompatible with
* FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on
-* vmas. As there are no users of this flag in this call we simply
-* disallow this option for now.
+* vmas. However, this only comes up if locked is set, and there are
+* callers that do request FOLL_LONGTERM, but do not set locked. So,
+* allow what we can.
*/
- if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
- return -EINVAL;
+ if (gup_flags & FOLL_LONGTERM) {
+ if (WARN_ON_ONCE(locked))
+ return -EINVAL;
+ }
return __get_user_pages_locked(tsk, mm, start, nr_pages, pages, vmas,
locked,
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/23] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return a bool,
with no side effects.
* Add a new routine, put_devmap_managed_page(), to handle checking
what kind of page it is, and what kind of refcount handling it
requires.
* Rename __put_devmap_managed_page() to free_devmap_managed_page(),
and limit the functionality to unconditionally freeing a devmap
page.
This is originally based on a separate patch by Ira Weiny, which
applied to an early version of the put_user_page() experiments.
Since then, Jérôme Glisse suggested the refactoring described above.
Suggested-by: Jérôme Glisse
Signed-off-by: Ira Weiny
Signed-off-by: John Hubbard
---
include/linux/mm.h | 27 ---
mm/memremap.c | 67 --
2 files changed, 53 insertions(+), 41 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a2adf95b3f9c..96228376139c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -967,9 +967,10 @@ static inline bool is_zone_device_page(const struct page
*page)
#endif
#ifdef CONFIG_DEV_PAGEMAP_OPS
-void __put_devmap_managed_page(struct page *page);
+void free_devmap_managed_page(struct page *page);
DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
-static inline bool put_devmap_managed_page(struct page *page)
+
+static inline bool page_is_devmap_managed(struct page *page)
{
if (!static_branch_unlikely(&devmap_managed_key))
return false;
@@ -978,7 +979,6 @@ static inline bool put_devmap_managed_page(struct page
*page)
switch (page->pgmap->type) {
case MEMORY_DEVICE_PRIVATE:
case MEMORY_DEVICE_FS_DAX:
- __put_devmap_managed_page(page);
return true;
default:
break;
@@ -986,6 +986,27 @@ static inline bool put_devmap_managed_page(struct page
*page)
return false;
}
+static inline bool put_devmap_managed_page(struct page *page)
+{
+ bool is_devmap = page_is_devmap_managed(page);
+
+ if (is_devmap) {
+ int count = page_ref_dec_return(page);
+
+ /*
+* devmap page refcounts are 1-based, rather than 0-based: if
+* refcount is 1, then the page is free and the refcount is
+* stable because nobody holds a reference on the page.
+*/
+ if (count == 1)
+ free_devmap_managed_page(page);
+ else if (!count)
+ __put_page(page);
+ }
+
+ return is_devmap;
+}
+
#else /* CONFIG_DEV_PAGEMAP_OPS */
static inline bool put_devmap_managed_page(struct page *page)
{
diff --git a/mm/memremap.c b/mm/memremap.c
index 03ccbdfeb697..bc7e2a27d025 100644
--- a/mm/memremap.c
+++ b/mm/memremap.c
@@ -410,48 +410,39 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
EXPORT_SYMBOL_GPL(get_dev_pagemap);
#ifdef CONFIG_DEV_PAGEMAP_OPS
-void __put_devmap_managed_page(struct page *page)
+void free_devmap_managed_page(struct page *page)
{
- int count = page_ref_dec_return(page);
+ /* Clear Active bit in case of parallel mark_page_accessed */
+ __ClearPageActive(page);
+ __ClearPageWaiters(page);
+
+ mem_cgroup_uncharge(page);
/*
-* If refcount is 1 then page is freed and refcount is stable as nobody
-* holds a reference on the page.
+* When a device_private page is freed, the page->mapping field
+* may still contain a (stale) mapping value. For example, the
+* lower bits of page->mapping may still identify the page as
+* an anonymous page. Ultimately, this entire field is just
+* stale and wrong, and it will cause errors if not cleared.
+* One example is:
+*
+* migrate_vma_pages()
+*migrate_vma_insert_page()
+* page_add_new_anon_rmap()
+*__page_set_anon_rmap()
+* ...checks page->mapping, via PageAnon(page) call,
+*and incorrectly concludes that the page is an
+*anonymous page. Therefore, it incorrectly,
+*silently fails to set up the new anon rmap.
+*
+* For other types of ZONE_DEVICE pages, migration is either
+* handled differently or not done at all, so there is no need
+* to clear page->mapping.
*/
- if (count == 1) {
- /* Clear Active bit in case of parallel mark_page_accessed */
- __ClearPageActive(page);
- __ClearPageWaiters(page);
-
- mem_cgroup_uncharge(page);
-
- /*
-* When a device_private page is freed, the page->mapping field
-
[PATCH v3 01/23] mm/gup: pass flags arg to __gup_device_* functions
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 8f236a335ae9..85caf76b3012 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1890,7 +1890,8 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
#if defined(CONFIG_ARCH_HAS_PTE_DEVMAP) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
static int __gup_device_huge(unsigned long pfn, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
int nr_start = *nr;
struct dev_pagemap *pgmap = NULL;
@@ -1916,13 +1917,14 @@ static int __gup_device_huge(unsigned long pfn,
unsigned long addr,
}
static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
unsigned long fault_pfn;
int nr_start = *nr;
fault_pfn = pmd_pfn(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
- if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
+ if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
return 0;
if (unlikely(pmd_val(orig) != pmd_val(*pmdp))) {
@@ -1933,13 +1935,14 @@ static int __gup_device_huge_pmd(pmd_t orig, pmd_t
*pmdp, unsigned long addr,
}
static int __gup_device_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
unsigned long fault_pfn;
int nr_start = *nr;
fault_pfn = pud_pfn(orig) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
- if (!__gup_device_huge(fault_pfn, addr, end, pages, nr))
+ if (!__gup_device_huge(fault_pfn, addr, end, flags, pages, nr))
return 0;
if (unlikely(pud_val(orig) != pud_val(*pudp))) {
@@ -1950,14 +1953,16 @@ static int __gup_device_huge_pud(pud_t orig, pud_t
*pudp, unsigned long addr,
}
#else
static int __gup_device_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
BUILD_BUG();
return 0;
}
static int __gup_device_huge_pud(pud_t pud, pud_t *pudp, unsigned long addr,
- unsigned long end, struct page **pages, int *nr)
+unsigned long end, unsigned int flags,
+struct page **pages, int *nr)
{
BUILD_BUG();
return 0;
@@ -2062,7 +2067,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned
long addr,
if (pmd_devmap(orig)) {
if (unlikely(flags & FOLL_LONGTERM))
return 0;
- return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
+ return __gup_device_huge_pmd(orig, pmdp, addr, end, flags,
+pages, nr);
}
refs = 0;
@@ -2092,7 +2098,8 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned
long addr,
}
static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
- unsigned long end, unsigned int flags, struct page **pages, int
*nr)
+ unsigned long end, unsigned int flags,
+ struct page **pages, int *nr)
{
struct page *head, *page;
int refs;
@@ -2103,7 +2110,8 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned
long addr,
if (pud_devmap(orig)) {
if (unlikely(flags & FOLL_LONGTERM))
return 0;
- return __gup_device_huge_pud(orig, pudp, addr, end, pages, nr);
+ return __gup_device_huge_pud(orig, pudp, addr, end, flags,
+pages, nr);
}
refs = 0;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/23] mm/gup: move try_get_compound_head() to top, fix minor issues
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Signed-off-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 199da99e8ffc..933524de6249 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -29,6 +29,21 @@ struct follow_page_context {
unsigned int page_mask;
};
+/*
+ * Return the compound head page with ref appropriately incremented,
+ * or NULL if that failed.
+ */
+static inline struct page *try_get_compound_head(struct page *page, int refs)
+{
+ struct page *head = compound_head(page);
+
+ if (WARN_ON_ONCE(page_ref_count(head) < 0))
+ return NULL;
+ if (unlikely(!page_cache_add_speculative(head, refs)))
+ return NULL;
+ return head;
+}
+
/**
* put_user_pages_dirty_lock() - release and optionally dirty gup-pinned pages
* @pages: array of pages to be maybe marked dirty, and definitely released.
@@ -1793,20 +1808,6 @@ static void __maybe_unused undo_dev_pagemap(int *nr, int
nr_start,
}
}
-/*
- * Return the compund head page with ref appropriately incremented,
- * or NULL if that failed.
- */
-static inline struct page *try_get_compound_head(struct page *page, int refs)
-{
- struct page *head = compound_head(page);
- if (WARN_ON_ONCE(page_ref_count(head) < 0))
- return NULL;
- if (unlikely(!page_cache_add_speculative(head, refs)))
- return NULL;
- return head;
-}
-
#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
unsigned int flags, struct page **pages, int *nr)
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112234] [REGRESSION] navi10: writing to pp_table fails (5.4-rc6 = working)
https://bugs.freedesktop.org/show_bug.cgi?id=112234 Matt Coffin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matt Coffin --- This was resolved on amd-staging-drm-next by https://patchwork.freedesktop.org/series/69284/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix unsigned variable compared to less than zero
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 2:44 PM Gustavo A. R. Silva
wrote:
>
>
>
> On 11/11/19 11:46, Mikita Lipski wrote:
> >
> > Thanks for catching it!
> >
>
> Glad to help out. :)
>
> > Reviewed-by: Mikita Lipski
> >
>
> Thanks
> --
> Gustavo
>
> >
> > On 11.11.2019 12:25, Gustavo A. R. Silva wrote:
> >> Currenly, the error check below on variable*vcpi_slots* is always
> >> false because it is a uint64_t type variable, hence, the values
> >> this variable can hold are never less than zero:
> >>
> >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
> >> 4870 if (dm_new_connector_state->vcpi_slots < 0) {
> >> 4871 DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
> >> (int)dm_new_connector_stat e->vcpi_slots);
> >> 4872 return dm_new_connector_state->vcpi_slots;
> >> 4873 }
> >>
> >> Fix this by making*vcpi_slots* of int type
> >>
> >> Addresses-Coverity: 1487838 ("Unsigned compared against 0")
> >> Fixes: b4c578f08378 ("drm/amd/display: Add MST atomic routines")
> >> Signed-off-by: Gustavo A. R. Silva
> >> ---
> >> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> >> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> >> index 6db07e9e33ab..a8fc90a927d6 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> >> @@ -403,7 +403,7 @@ struct dm_connector_state {
> >> bool underscan_enable;
> >> bool freesync_capable;
> >> uint8_t abm_level;
> >> -uint64_t vcpi_slots;
> >> +int vcpi_slots;
> >> uint64_t pbn;
> >> };
> >> -- 2.23.0
> >
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/18] media/v4l2-core: set pages dirty upon releasing DMA buffers
On 11/10/19 2:10 AM, Hans Verkuil wrote:
> On 11/3/19 10:17 PM, John Hubbard wrote:
>> After DMA is complete, and the device and CPU caches are synchronized,
>> it's still required to mark the CPU pages as dirty, if the data was
>> coming from the device. However, this driver was just issuing a
>> bare put_page() call, without any set_page_dirty*() call.
>>
>> Fix the problem, by calling set_page_dirty_lock() if the CPU pages
>> were potentially receiving data from the device.
>>
>> Cc: Mauro Carvalho Chehab
>> Signed-off-by: John Hubbard
>
> Acked-by: Hans Verkuil
>
> Looks good, thanks!
>
Hi Hans, it's great that you could take a look at this and the other v4l2
patch, much appreciated.
thanks,
--
John Hubbard
NVIDIA
>> ---
>> drivers/media/v4l2-core/videobuf-dma-sg.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
>> b/drivers/media/v4l2-core/videobuf-dma-sg.c
>> index 66a6c6c236a7..28262190c3ab 100644
>> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
>> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
>> @@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
>> BUG_ON(dma->sglen);
>>
>> if (dma->pages) {
>> -for (i = 0; i < dma->nr_pages; i++)
>> +for (i = 0; i < dma->nr_pages; i++) {
>> +if (dma->direction == DMA_FROM_DEVICE)
>> +set_page_dirty_lock(dma->pages[i]);
>> put_page(dma->pages[i]);
>> +}
>> kfree(dma->pages);
>> dma->pages = NULL;
>> }
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205491] Green external display after wake up
https://bugzilla.kernel.org/show_bug.cgi?id=205491 --- Comment #1 from Łukasz Żarnowiecki (luk...@zarnowiecki.pl) --- Created attachment 285865 --> https://bugzilla.kernel.org/attachment.cgi?id=285865&action=edit lspci -- 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 205491] New: Green external display after wake up
https://bugzilla.kernel.org/show_bug.cgi?id=205491 Bug ID: 205491 Summary: Green external display after wake up Product: Drivers Version: 2.5 Kernel Version: 5.3.10 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: luk...@zarnowiecki.pl Regression: No Created attachment 285863 --> https://bugzilla.kernel.org/attachment.cgi?id=285863&action=edit dmesg After my laptop is waking up from suspend, the external monitor displays whole green screen. Plugin out and in HDMI cable fixes problem. In dmesg there are few different crashes related to amdgpu. -- 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 111691] inconsistent cursor movement speed when using AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #18 from Daniel Suarez --- (In reply to Jaap Buurman from comment #17) > (In reply to takios+fdbugs from comment #16) > > I ran into the same issue but after installing linux kernel 5.4rc2 it was > > fixed. > > That's good to hear! Does anyone know whether the fix will be backported to > the 5.3 kernel? It's gonna take a while before 5.4 becomes mainline. I do not believe it will get backported since most effort is going towards 5.4, but you can try a ditro like Manjaro that officially supports the RC kernels -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: remove set but not used variable 'bpc'
On Mon, Nov 11, 2019 at 1:01 PM Alex Deucher wrote:
>
> Applied. Thanks!
I've dropped this as it leads to a warning in the code since
get_color_depth is no longer used. Care to fix that up as well?
Thanks!
Alex
>
> Alex
>
> On Sun, Nov 10, 2019 at 9:30 PM YueHaibing wrote:
> >
> > Fixes gcc '-Wunused-but-set-variable' warning:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> > get_pbn_from_timing:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
> > variable bpc set but not used [-Wunused-but-set-variable]
> >
> > It is not used since commit e49f69363adf ("drm/amd/display: use
> > proper formula to calculate bandwidth from timing")
> >
> > Signed-off-by: YueHaibing
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > index bdc8be3..53394e2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> > @@ -2653,13 +2653,11 @@ static int get_color_depth(enum dc_color_depth
> > color_depth)
> >
> > static struct fixed31_32 get_pbn_from_timing(struct pipe_ctx *pipe_ctx)
> > {
> > - uint32_t bpc;
> > uint64_t kbps;
> > struct fixed31_32 peak_kbps;
> > uint32_t numerator;
> > uint32_t denominator;
> >
> > - bpc =
> > get_color_depth(pipe_ctx->stream_res.pix_clk_params.color_depth);
> > kbps = dc_bandwidth_in_kbps_from_timing(&pipe_ctx->stream->timing);
> >
> > /*
> > --
> > 2.7.4
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205185] amdgpu compile failure
https://bugzilla.kernel.org/show_bug.cgi?id=205185 --- Comment #2 from Stijn Tintel (stijn+b...@linux-ipv6.be) --- Thanks. Enabling that symbol fixes the compile failure. This wasn't a problem in 5.3.0 - 5.3.4, so there's a regression introduced in 5.3.5, which should still be fixed. Probably needs a dependency in some Kconfig file. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix unsigned variable compared to less than zero
On 11/11/19 11:46, Mikita Lipski wrote:
>
> Thanks for catching it!
>
Glad to help out. :)
> Reviewed-by: Mikita Lipski
>
Thanks
--
Gustavo
>
> On 11.11.2019 12:25, Gustavo A. R. Silva wrote:
>> Currenly, the error check below on variable*vcpi_slots* is always
>> false because it is a uint64_t type variable, hence, the values
>> this variable can hold are never less than zero:
>>
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
>> 4870 if (dm_new_connector_state->vcpi_slots < 0) {
>> 4871 DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
>> (int)dm_new_connector_stat e->vcpi_slots);
>> 4872 return dm_new_connector_state->vcpi_slots;
>> 4873 }
>>
>> Fix this by making*vcpi_slots* of int type
>>
>> Addresses-Coverity: 1487838 ("Unsigned compared against 0")
>> Fixes: b4c578f08378 ("drm/amd/display: Add MST atomic routines")
>> Signed-off-by: Gustavo A. R. Silva
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>> index 6db07e9e33ab..a8fc90a927d6 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
>> @@ -403,7 +403,7 @@ struct dm_connector_state {
>> bool underscan_enable;
>> bool freesync_capable;
>> uint8_t abm_level;
>> - uint64_t vcpi_slots;
>> + int vcpi_slots;
>> uint64_t pbn;
>> };
>> -- 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: replace incorrect Compliance/Margin magic numbers with PCI_EXP_LNKCTL2 definitions
From: Bjorn Helgaas Add definitions for these PCIe Link Control 2 register fields: Enter Compliance Transmit Margin and use them in amdgpu and radeon. NOTE: This is a functional change because "7 << 9" was apparently a typo. That mask included the high order bit of Transmit Margin, the Enter Modified Compliance bit, and the Compliance SOS bit, but I think what was intended was the 3-bit Transmit Margin field at bits 9:7. Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/cik.c | 14 ++ drivers/gpu/drm/amd/amdgpu/si.c | 10 +++--- drivers/gpu/drm/radeon/cik.c | 14 ++ drivers/gpu/drm/radeon/si.c | 14 ++ include/uapi/linux/pci_regs.h| 2 ++ 5 files changed, 39 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c index b81bb414fcb3..e4a595cdd4c1 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik.c +++ b/drivers/gpu/drm/amd/amdgpu/cik.c @@ -1498,13 +1498,19 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) /* linkctl2 */ pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~((1 << 4) | (7 << 9)); - tmp16 |= (bridge_cfg2 & ((1 << 4) | (7 << 9))); + tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN); + tmp16 |= (bridge_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); pci_write_config_word(root, bridge_pos + PCI_EXP_LNKCTL2, tmp16); pci_read_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~((1 << 4) | (7 << 9)); - tmp16 |= (gpu_cfg2 & ((1 << 4) | (7 << 9))); + tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN); + tmp16 |= (gpu_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); pci_write_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); tmp = RREG32_PCIE(ixPCIE_LC_CNTL4); diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c index 493af42152f2..cf543410a424 100644 --- a/drivers/gpu/drm/amd/amdgpu/si.c +++ b/drivers/gpu/drm/amd/amdgpu/si.c @@ -1737,12 +1737,16 @@ static void si_pcie_gen3_enable(struct amdgpu_device *adev) pci_write_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL, tmp16); pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~((1 << 4) | (7 << 9)); - tmp16 |= (bridge_cfg2 & ((1 << 4) | (7 << 9))); + tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN); + tmp16 |= (bridge_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN)); pci_write_config_word(root, bridge_pos + PCI_EXP_LNKCTL2, tmp16); pci_read_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~((1 << 4) | (7 << 9)); + tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN); tmp16 |= (gpu_cfg2 & ((1 << 4) | (7 << 9))); pci_write_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 62eab82a64f9..95ffa0bff2d8 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -9619,13 +9619,19 @@ static void cik_pcie_gen3_enable(struct radeon_device *rdev) /* linkctl2 */ pci_read_config_word(root, bridge_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~((1 << 4) | (7 << 9)); - tmp16 |= (bridge_cfg2 & ((1 << 4) | (7 << 9))); + tmp16 &= ~(PCI_EXP_LNKCTL2_ENTER_COMP | + PCI_EXP_LNKCTL2_TX_MARGIN); + tmp16 |= (bridge_cfg2 & + (PCI_EXP_LNKCTL2_ENTER_COMP | +
[PATCH v2 0/2] drm: replace magic numbers
From: Bjorn Helgaas amdgpu and radeon do a bit of mucking with the PCIe Link Control 2 register, some of it using hard-coded magic numbers. The idea here is to replace those with #defines. I don't intend the Target Link Speed patch to change anything, so it should be straightforward to review. Since v1: - Add my signed-off-by and Alex's reviewed-by. Bjorn Helgaas (2): drm: replace incorrect Compliance/Margin magic numbers with PCI_EXP_LNKCTL2 definitions drm: replace Target Link Speed magic numbers with PCI_EXP_LNKCTL2 definitions drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++ drivers/gpu/drm/amd/amdgpu/si.c | 18 +++--- drivers/gpu/drm/radeon/cik.c | 22 ++ drivers/gpu/drm/radeon/si.c | 22 ++ include/uapi/linux/pci_regs.h| 2 ++ 5 files changed, 55 insertions(+), 31 deletions(-) -- 2.24.0.rc1.363.gb1bccd3e3d-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: replace Target Link Speed magic numbers with PCI_EXP_LNKCTL2 definitions
From: Bjorn Helgaas Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2 definitions. No functional change intended. Signed-off-by: Bjorn Helgaas Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/cik.c | 8 drivers/gpu/drm/amd/amdgpu/si.c | 8 drivers/gpu/drm/radeon/cik.c | 8 drivers/gpu/drm/radeon/si.c | 8 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c index e4a595cdd4c1..3067bb874032 100644 --- a/drivers/gpu/drm/amd/amdgpu/cik.c +++ b/drivers/gpu/drm/amd/amdgpu/cik.c @@ -1527,13 +1527,13 @@ static void cik_pcie_gen3_enable(struct amdgpu_device *adev) WREG32_PCIE(ixPCIE_LC_SPEED_CNTL, speed_cntl); pci_read_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~0xf; + tmp16 &= ~PCI_EXP_LNKCTL2_TLS; if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) - tmp16 |= 3; /* gen3 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2) - tmp16 |= 2; /* gen2 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else - tmp16 |= 1; /* gen1 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ pci_write_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); speed_cntl = RREG32_PCIE(ixPCIE_LC_SPEED_CNTL); diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c index cf543410a424..d5c83d82063b 100644 --- a/drivers/gpu/drm/amd/amdgpu/si.c +++ b/drivers/gpu/drm/amd/amdgpu/si.c @@ -1762,13 +1762,13 @@ static void si_pcie_gen3_enable(struct amdgpu_device *adev) WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); pci_read_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~0xf; + tmp16 &= ~PCI_EXP_LNKCTL2_TLS; if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN3) - tmp16 |= 3; + tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (adev->pm.pcie_gen_mask & CAIL_PCIE_LINK_SPEED_SUPPORT_GEN2) - tmp16 |= 2; + tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else - tmp16 |= 1; + tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ pci_write_config_word(adev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL); diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c index 95ffa0bff2d8..a280442c81aa 100644 --- a/drivers/gpu/drm/radeon/cik.c +++ b/drivers/gpu/drm/radeon/cik.c @@ -9647,13 +9647,13 @@ static void cik_pcie_gen3_enable(struct radeon_device *rdev) WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); pci_read_config_word(rdev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~0xf; + tmp16 &= ~PCI_EXP_LNKCTL2_TLS; if (speed_cap == PCIE_SPEED_8_0GT) - tmp16 |= 3; /* gen3 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (speed_cap == PCIE_SPEED_5_0GT) - tmp16 |= 2; /* gen2 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else - tmp16 |= 1; /* gen1 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ pci_write_config_word(rdev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL); diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c index 69993d34d1e9..529e70a42019 100644 --- a/drivers/gpu/drm/radeon/si.c +++ b/drivers/gpu/drm/radeon/si.c @@ -7230,13 +7230,13 @@ static void si_pcie_gen3_enable(struct radeon_device *rdev) WREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL, speed_cntl); pci_read_config_word(rdev->pdev, gpu_pos + PCI_EXP_LNKCTL2, &tmp16); - tmp16 &= ~0xf; + tmp16 &= ~PCI_EXP_LNKCTL2_TLS; if (speed_cap == PCIE_SPEED_8_0GT) - tmp16 |= 3; /* gen3 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_8_0GT; /* gen3 */ else if (speed_cap == PCIE_SPEED_5_0GT) - tmp16 |= 2; /* gen2 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_5_0GT; /* gen2 */ else - tmp16 |= 1; /* gen1 */ + tmp16 |= PCI_EXP_LNKCTL2_TLS_2_5GT; /* gen1 */ pci_write_config_word(rdev->pdev, gpu_pos + PCI_EXP_LNKCTL2, tmp16); speed_cntl = RREG32_PCIE_PORT(PCIE_LC_SPEED_CNTL); -- 2.24.0.rc1.363.gb1bccd3e3d-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: atyfb: only use ioremap_uc() on i386 and ia64
ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 79d548746efd..bdbaca7200b2 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3420,11 +3420,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.20.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111922] amdgpu fails to resume on 5.2 kernel [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=111922 --- Comment #9 from Marek Olšák --- Userspace doesn't know when suspend/resume is happening, so it can't hang on suspend/resume. My guess is it's something in DAL. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-dkms-5.2 2158/2834] drivers/gpu/drm/ttm/ttm_bo_vm.c:128:6: error: 'vma' undeclared
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 607b18ba116eb1642b01fb9d38a164cc492e9044 [2158/2834] drm/amdkcl: Test
whether vm_fault->{address/vma} is available
config: x86_64-randconfig-a004-201944 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
git checkout 607b18ba116eb1642b01fb9d38a164cc492e9044
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from include/linux/kobject.h:23:0,
from include/linux/device.h:16,
from include/drm/drm_print.h:32,
from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/kref.h:36:28: note: previous definition of 'kref_read' was here
static inline unsigned int kref_read(const struct kref *kref)
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_kref.h: In function 'kref_read':
include/kcl/kcl_kref.h:9:21: error: passing argument 1 of 'atomic_read' from
incompatible pointer type [-Werror=incompatible-pointer-types]
return atomic_read(&kref->refcount);
^
In file included from arch/x86/include/asm/atomic.h:265:0,
from include/linux/atomic.h:7,
from include/linux/rcupdate.h:25,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/asm-generic/atomic-instrumented.h:24:1: note: expected 'const
atomic_t * {aka const struct *}' but argument is of type 'const
refcount_t * {aka const struct refcount_struct *}'
atomic_read(const atomic_t *v)
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: At top level:
include/kcl/kcl_mm_types.h:10:3: error: conflicting types for 'pfn_t'
} pfn_t;
^
In file included from include/asm-generic/memory_model.h:5:0,
from arch/x86/include/asm/page.h:76,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/pfn.h:15:3: note: previous declaration of 'pfn_t' was here
} pfn_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:33:13: error: conflicting types for 'vm_fault_t'
typedef int vm_fault_t;
^
In file included from include/drm/drm_mm.h:43:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm_types.h:631:32: note: previous declaration of 'vm_fault_t'
was here
typedef __bitwise unsigned int vm_fault_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:35:26: error: conflicting types for
'vmf_insert_mixed'
static inline vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma,
^
In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm.h:2587:12: note: previous declaration of 'vmf_insert_mixed'
was here
vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: In function 'vmf_insert_mixed':
include/kcl/kcl_mm_types.h:41:8: error: implicit declaration of functio
Re: [PATCH -next] drm/amd/display: remove set but not used variable 'bpc'
Applied. Thanks!
Alex
On Sun, Nov 10, 2019 at 9:30 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> get_pbn_from_timing:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
> variable bpc set but not used [-Wunused-but-set-variable]
>
> It is not used since commit e49f69363adf ("drm/amd/display: use
> proper formula to calculate bandwidth from timing")
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> index bdc8be3..53394e2 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
> @@ -2653,13 +2653,11 @@ static int get_color_depth(enum dc_color_depth
> color_depth)
>
> static struct fixed31_32 get_pbn_from_timing(struct pipe_ctx *pipe_ctx)
> {
> - uint32_t bpc;
> uint64_t kbps;
> struct fixed31_32 peak_kbps;
> uint32_t numerator;
> uint32_t denominator;
>
> - bpc =
> get_color_depth(pipe_ctx->stream_res.pix_clk_params.color_depth);
> kbps = dc_bandwidth_in_kbps_from_timing(&pipe_ctx->stream->timing);
>
> /*
> --
> 2.7.4
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amd/display: remove set but not used variable 'ds_port'
Applied. thanks!
Alex
On Sun, Nov 10, 2019 at 9:29 PM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
> dp_wa_power_up_0010FA:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2320:35: warning:
> variable ds_port set but not used [-Wunused-but-set-variable]
>
> It is never used, so can be removed.
>
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 65de32f..b814b74 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -2910,7 +2910,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
> uint8_t *dpcd_data,
> int length)
> {
> int retry = 0;
> - union dp_downstream_port_present ds_port = { 0 };
>
> if (!link->dpcd_caps.dpcd_rev.raw) {
> do {
> @@ -2923,9 +2922,6 @@ static void dp_wa_power_up_0010FA(struct dc_link *link,
> uint8_t *dpcd_data,
> } while (retry++ < 4 && !link->dpcd_caps.dpcd_rev.raw);
> }
>
> - ds_port.byte = dpcd_data[DP_DOWNSTREAMPORT_PRESENT -
> -DP_DPCD_REV];
> -
> if (link->dpcd_caps.dongle_type == DISPLAY_DONGLE_DP_VGA_CONVERTER) {
> switch (link->dpcd_caps.branch_dev_id) {
> /* 0010FA active dongles (DP-VGA, DP-DLDVI converters) power
> down
> --
> 2.7.4
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: remove set but not used variable 'threshold', 'state'
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 3:07 AM zhengbin wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c: In function
> fiji_populate_single_graphic_level:
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c:943:11: warning: variable
> threshold set but not used [-Wunused-but-set-variable]
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c: In function
> fiji_populate_memory_timing_parameters:
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c:1504:8: warning: variable
> state set but not used [-Wunused-but-set-variable]
>
> They are introduced by commit 2e112b4ae3ba ("drm/amd/pp:
> remove fiji_smc/smumgr split."), but never used,
> so remove it.
>
> Reported-by: Hulk Robot
> Signed-off-by: zhengbin
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> index da025b1..32ebb38 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> @@ -940,7 +940,7 @@ static int fiji_populate_single_graphic_level(struct
> pp_hwmgr *hwmgr,
> {
> int result;
> /* PP_Clocks minClocks; */
> - uint32_t threshold, mvdd;
> + uint32_t mvdd;
> struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
> struct phm_ppt_v1_information *table_info =
> (struct phm_ppt_v1_information *)(hwmgr->pptable);
> @@ -973,8 +973,6 @@ static int fiji_populate_single_graphic_level(struct
> pp_hwmgr *hwmgr,
> level->VoltageDownHyst = 0;
> level->PowerThrottle = 0;
>
> - threshold = clock * data->fast_watermark_threshold / 100;
> -
> data->display_timing.min_clock_in_sr =
> hwmgr->display_config->min_core_set_clock_in_sr;
>
> if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
> PHM_PlatformCaps_SclkDeepSleep))
> @@ -1501,7 +1499,7 @@ static int
> fiji_populate_memory_timing_parameters(struct pp_hwmgr *hwmgr,
> uint32_t dram_timing;
> uint32_t dram_timing2;
> uint32_t burstTime;
> - ULONG state, trrds, trrdl;
> + ULONG trrds, trrdl;
> int result;
>
> result = atomctrl_set_engine_dram_timings_rv770(hwmgr,
> @@ -1513,7 +1511,6 @@ static int
> fiji_populate_memory_timing_parameters(struct pp_hwmgr *hwmgr,
> dram_timing2 = cgs_read_register(hwmgr->device,
> mmMC_ARB_DRAM_TIMING2);
> burstTime = cgs_read_register(hwmgr->device, mmMC_ARB_BURST_TIME);
>
> - state = PHM_GET_FIELD(burstTime, MC_ARB_BURST_TIME, STATE0);
> trrds = PHM_GET_FIELD(burstTime, MC_ARB_BURST_TIME, TRRDS0);
> trrdl = PHM_GET_FIELD(burstTime, MC_ARB_BURST_TIME, TRRDL0);
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Use static const, not const static
Applied. Thanks! Alex On Mon, Nov 11, 2019 at 9:11 AM zhengbin wrote: > > Move the static keyword to the front of declarations. > > Reported-by: Hulk Robot > Signed-off-by: zhengbin > --- > drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c > b/drivers/gpu/drm/amd/display/dc/core/dc.c > index 1fdba13..0d8c663 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c > @@ -69,7 +69,7 @@ > #define DC_LOGGER \ > dc->ctx->logger > > -const static char DC_BUILD_ID[] = "production-build"; > +static const char DC_BUILD_ID[] = "production-build"; > > /** > * DOC: Overview > -- > 2.7.4 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] remove some set but not used variables in hwmgr
Applied. Thanks! Alex On Sun, Nov 10, 2019 at 11:04 PM Quan, Evan wrote: > > Series is reviewed-by: Evan Quan > > > -Original Message- > > From: zhengbin > > Sent: Monday, November 11, 2019 11:46 AM > > To: rex@amd.com; Quan, Evan ; Deucher, > > Alexander ; Koenig, Christian > > ; Zhou, David(ChunMing) > > ; airl...@linux.ie; dan...@ffwll.ch; amd- > > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > Cc: zhengbi...@huawei.com > > Subject: [PATCH 0/2] remove some set but not used variables in hwmgr > > > > zhengbin (2): > > drm/amd/powerplay: remove set but not used variable > > 'vbios_version','data' > > drm/amd/powerplay: remove set but not used variable 'data' > > > > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 > > drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 -- > > 2 files changed, 6 deletions(-) > > > > -- > > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Fix unsigned variable compared to less than zero
Currenly, the error check below on variable *vcpi_slots* is always
false because it is a uint64_t type variable, hence, the values
this variable can hold are never less than zero:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
4870 if (dm_new_connector_state->vcpi_slots < 0) {
4871 DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
(int)dm_new_connector_stat e->vcpi_slots);
4872 return dm_new_connector_state->vcpi_slots;
4873 }
Fix this by making *vcpi_slots* of int type.
Addresses-Coverity: 1487838 ("Unsigned compared against 0")
Fixes: b4c578f08378 ("drm/amd/display: Add MST atomic routines")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 6db07e9e33ab..a8fc90a927d6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -403,7 +403,7 @@ struct dm_connector_state {
bool underscan_enable;
bool freesync_capable;
uint8_t abm_level;
- uint64_t vcpi_slots;
+ int vcpi_slots;
uint64_t pbn;
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix unsigned variable compared to less than zero
Thanks for catching it!
Reviewed-by: Mikita Lipski
On 11.11.2019 12:25, Gustavo A. R. Silva wrote:
Currenly, the error check below on variable*vcpi_slots* is always
false because it is a uint64_t type variable, hence, the values
this variable can hold are never less than zero:
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
4870 if (dm_new_connector_state->vcpi_slots < 0) {
4871 DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
(int)dm_new_connector_stat e->vcpi_slots);
4872 return dm_new_connector_state->vcpi_slots;
4873 }
Fix this by making*vcpi_slots* of int type
Addresses-Coverity: 1487838 ("Unsigned compared against 0")
Fixes: b4c578f08378 ("drm/amd/display: Add MST atomic routines")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 6db07e9e33ab..a8fc90a927d6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -403,7 +403,7 @@ struct dm_connector_state {
bool underscan_enable;
bool freesync_capable;
uint8_t abm_level;
- uint64_t vcpi_slots;
+ int vcpi_slots;
uint64_t pbn;
};
-- 2.23.0
--
Thanks,
Mikita Lipski
Software Engineer, AMD
mikita.lip...@amd.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205185] amdgpu compile failure
https://bugzilla.kernel.org/show_bug.cgi?id=205185 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Make sure CONFIG_DRM_AMD_DC_DSC_SUPPORT=y in your config. -- 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 111922] amdgpu fails to resume on 5.2 kernel [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=111922 --- Comment #8 from Alex Deucher --- (In reply to Pierre Ossman from comment #7) > I finally got a build environment set up, and the winner is: > > > df8368be1382b442384507a5147c89978cd60702 is the first bad commit > > commit df8368be1382b442384507a5147c89978cd60702 > > Author: Nicholas Kazlauskas > > Date: Wed Feb 27 12:56:36 2019 -0500 > > > > drm/amdgpu: Bump amdgpu version for per-flip plane tiling updates > > > > To help xf86-video-amdgpu and mesa know DC supports updating the > > tiling attributes for a framebuffer per-flip. > > > > Cc: Michel Dänzer > > Signed-off-by: Nicholas Kazlauskas > > Acked-by: Alex Deucher > > Reviewed-by: Marek Olšák > > Signed-off-by: Alex Deucher > > > > :04 04 06a7975c484e74ebdaa4ccf9ee1dc5dac7a0abc9 > > ab68acde511d49b3f96818066bba35f255ce1656 M drivers > > Which seems extremely odd given the contents of that commit. But I guess it > makes userspace change behaviour in a way that provokes the bug? > > I don't think bisect will get me further. Help? Userspace only enables per flip tiling updates if the version of the kernel driver is new enough to support that feature. Maybe this is related to the DCC changes in mesa. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
On 11/11/19 9:57 AM, Thomas Zimmermann wrote: Hi John Am 08.11.19 um 19:07 schrieb John Donnelly: On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote: Hi Am 08.11.19 um 13:55 schrieb John Donnelly: On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote: Hi John Am 07.11.19 um 23:14 schrieb John Donnelly: On Nov 7, 2019, at 10:13 AM, John Donnelly wrote: On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote: Hi John Am 07.11.19 um 14:12 schrieb John Donnelly: Hi Thomas ; Thank you for reaching out. See inline: On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote: Hi John, apparently the vgaarb was not the problem. Am 07.11.19 um 03:29 schrieb John Donnelly: Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver.Specifically starting the GNOME desktop. When you say "text mode", do you mean VGA text mode or the graphical console that emulates text mode? I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. Yes. When you enable graphics mode, does it set the correct resolution? A lot of work went into memory management recently. I could imagine that the driver sets the correct resolution, but then fails to display the correct framebuffer. There is no display at all ; so there is no resolution to mention. If possible, could you try to update to the latest drm-tip and attach the output of /sys/kernel/debug/dri/0/vram-mm I don’t see that file ; Is there something else I need to do ? That file is fairly new and maybe it's not in the mainline kernel yet. See below for how to get it. I built your “tip” ; Still no graphics displayed . mount -t debugfs none /sys/kernel cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff cat /sys/kernel/dri/0/vram-mm In VGA mode : cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used In GRAPHICS mode ( if it matters ) cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used total: 2032, used 1538 free 494 This is interesting. In the graphics mode, you see two buffers of 768 pages each. That's the main framebuffers as used by X (it's double buffered). Then there's a free area and finally two pages for cursor images (also double buffered). That looks as expected. The thing is that in text mode, the areas are allocated. But the driver shouldn't be active, so the file shouldn't exist or only show a single free area. If you want me to double check this I will .I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; Good! Looking through that log file, the card is found at line 79 and the generic X modesetting driver initializes below. That works as expected. I notices that several operations are not permitted (lines 78 and 87). I guess you're starting X from a regular user account? IIRC special permission is required to acquire control of the display. What happens if you start X as root user? I am starting GNOME as root by doing “init 5” from either the console session or from ssh . The default runlevel is 3 on boot . On failing session running your 5.4.0.rc6. 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 237.712] (EE) open /dev/fb0: Permission denied Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 101.334] (EE) open /dev/fb0: Permission denied What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . # cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff When you say “tip”. - Are you referri
Re: [PATCH] drm/amd/display: remove duplicated comparison expression
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 8:38 AM Kazlauskas, Nicholas
wrote:
>
> On 2019-11-09 10:49 a.m., Colin King wrote:
> > From: Colin Ian King
> >
> > There is comparison expression that is duplicated and hence one
> > of the expressions can be removed. Remove it.
> >
> > Addresses-Coverity: ("Same on both sides")
> > Fixes: 12e2b2d4c65f ("drm/amd/display: add dcc programming for dual plane")
> > Signed-off-by: Colin Ian King
>
> Reviewed-by: Nicholas Kazlauskas
>
> Thanks!
>
> Nicholas Kazlauskas
>
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index 1fdba13b3d0f..1fa255e077d0 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -1491,7 +1491,6 @@ static enum surface_update_type
> > get_plane_info_update_type(const struct dc_surfa
> > }
> >
> > if (u->plane_info->plane_size.surface_pitch !=
> > u->surface->plane_size.surface_pitch
> > - || u->plane_info->plane_size.surface_pitch !=
> > u->surface->plane_size.surface_pitch
> > || u->plane_info->plane_size.chroma_pitch !=
> > u->surface->plane_size.chroma_pitch) {
> > update_flags->bits.plane_size_change = 1;
> > elevate_update_type(&update_type, UPDATE_TYPE_MED);
> >
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amd/display: fix spelling mistake "exeuction" -> "execution"
Applied. Thanks!
Alex
On Mon, Nov 11, 2019 at 8:37 AM Kazlauskas, Nicholas
wrote:
>
> On 2019-11-09 2:49 p.m., Colin King wrote:
> > From: Colin Ian King
> >
> > There are spelling mistakes in a DC_ERROR message and a comment.
> > Fix these.
> >
> > Signed-off-by: Colin Ian King
>
> Reviewed-by: Nicholas Kazlauskas
>
> Thanks!
>
> Nicholas Kazlauskas
>
> > ---
> > drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c| 2 +-
> > drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> > b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> > index 61cefe0a3790..b65b66025267 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> > @@ -92,7 +92,7 @@ void dc_dmub_srv_cmd_execute(struct dc_dmub_srv
> > *dc_dmub_srv)
> >
> > status = dmub_srv_cmd_execute(dmub);
> > if (status != DMUB_STATUS_OK)
> > - DC_ERROR("Error starting DMUB exeuction: status=%d\n",
> > status);
> > + DC_ERROR("Error starting DMUB execution: status=%d\n",
> > status);
> > }
> >
> > void dc_dmub_srv_wait_idle(struct dc_dmub_srv *dc_dmub_srv)
> > diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
> > b/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
> > index aa8f0396616d..45e427d1952e 100644
> > --- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
> > +++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h
> > @@ -416,7 +416,7 @@ enum dmub_status dmub_srv_cmd_queue(struct dmub_srv
> > *dmub,
> >* dmub_srv_cmd_execute() - Executes a queued sequence to the dmub
> >* @dmub: the dmub service
> >*
> > - * Begins exeuction of queued commands on the dmub.
> > + * Begins execution of queued commands on the dmub.
> >*
> >* Return:
> >* DMUB_STATUS_OK - success
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205185] amdgpu compile failure
https://bugzilla.kernel.org/show_bug.cgi?id=205185 Stijn Tintel (stijn+b...@linux-ipv6.be) changed: What|Removed |Added Kernel Version|5.3.5 - 5.3.6 |5.3.5 - 5.3.10 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/12] drm/modes: parse_cmdline: Add support for specifying panel_orientation
Hi,
On 11-11-2019 13:53, Maxime Ripard wrote:
Hi Hans,
Thanks for this series (and thanks for bouncing the mails too).
All the previous patches are
Acked-by: Maxime Ripard
Thank you for the review.
On Sun, Nov 10, 2019 at 04:40:58PM +0100, Hans de Goede wrote:
Sometimes we want to override a connector's panel_orientation from the
kernel commandline. Either for testing and for special cases, e.g. a kiosk
like setup which uses a TV mounted in portrait mode.
Users can already specify a "rotate" option through a video= kernel cmdline
option. But that only supports 0/180 degrees (see drm_client_modeset TODO)
and only works for in kernel modeset clients, not for userspace kms users.
The "panel-orientation" connector property OTOH does support 90/270 degrees
as it leaves dealing with the rotation up to userspace and this does work
for userspace kms clients (at least those which support this property).
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Signed-off-by: Hans de Goede
---
Documentation/fb/modedb.rst | 3 ++
drivers/gpu/drm/drm_modes.c | 32 +++
.../gpu/drm/selftests/drm_cmdline_selftests.h | 1 +
.../drm/selftests/test-drm_cmdline_parser.c | 22 +
include/drm/drm_connector.h | 8 +
5 files changed, 66 insertions(+)
diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
index 9c4e3fd39e6d..624d08fd2856 100644
--- a/Documentation/fb/modedb.rst
+++ b/Documentation/fb/modedb.rst
@@ -65,6 +65,9 @@ Valid options are::
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
+ - panel_orientation, one of "normal", "upside_down", "left_side_up", or
+"right_side_up". For KMS drivers only, this sets the "panel orientation"
+property on the kms connector as hint for kms users.
Even though the semantic is a bit different, I think we should remain
consistent and have the same argument than for rotate (ie, steps in
clockwise rotation in steps of 90 degrees).
Well the kernel kms defines for rotation also talk about 90 / 180 / 270":
#define DRM_MODE_ROTATE_0 (1<<0)
#define DRM_MODE_ROTATE_90 (1<<1)
#define DRM_MODE_ROTATE_180 (1<<2)
#define DRM_MODE_ROTATE_270 (1<<3)
Where as the panel orientation uses strings like right_side_up, which means
that the side of the panel which normally is the right side of the panel
is now pointing up as the panel is mounted 90 degrees rotated with its
original right side now pointing up. This IMHO is much clearer then
90 / 270 degrees which are ambiguous and perhaps more importantly this
matches the kernel defines for panel-orientation and matches the
String values enumerated by the enum type panel-orientation connector
property:
static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
{ DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
{ DRM_MODE_PANEL_ORIENTATION_LEFT_UP, "Left Side Up" },
{ DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, "Right Side Up" },
};
So I would prefer to stick to the strings.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add DRM_MODE_TYPE_USERDEF flag to probed modes matching a video= argument
Hi, On 11-11-2019 16:40, Daniel Vetter wrote: On Mon, Nov 11, 2019 at 12:06 PM Hans de Goede wrote: Hi Daniel, On 11-11-2019 11:26, Daniel Vetter wrote: On Mon, Nov 11, 2019 at 10:50 AM Hans de Goede wrote: Hi, On 11-11-2019 10:25, Daniel Vetter wrote: On Sun, Nov 10, 2019 at 7:41 PM Hans de Goede wrote: drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching a video= argument over calculating our own timings for the user specified mode using CVT or GTF. But userspace code which is auto-configuring the mode may want to know that the user has specified that mode on the kernel commandline so that it can pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED. This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just as we would do on the user-specified mode when no matching probed mode is found. Signed-off-by: Hans de Goede Will existing userspace dtrt here with this? Some links to popular ones would be good (since essentially this is uapi fine tuning we need that anyway). With that will get my ack. A valid question, I've gone over what I consider the major userspace kms users: -Xorg xserver modesetting driver does not check for this: [hans@shalem xserver]$ ack DRM_MODE_TYPE_ hw/xfree86/drivers/modesetting/ hw/xfree86/drivers/modesetting/drmmode_display.c 1321:if (kmode->type & DRM_MODE_TYPE_DRIVER) 1323:if (kmode->type & DRM_MODE_TYPE_PREFERRED) -Other Xorg drivers: [hans@shalem driver]$ ls -d xf86-video-* xf86-video-amdgpu xf86-video-intelxf86-video-qxl xf86-video-armsoc xf86-video-modesetting xf86-video-sisusb xf86-video-ati xf86-video-nouveau xf86-video-vmware xf86-video-dummy xf86-video-omap xf86-video-voodoo xf86-video-geode xf86-video-opentegra These all only do the same checks as the Xorg modesetting driver -mutter: [hans@shalem mutter]$ ack DRM_MODE_TYPE_ src/backends/native/meta-output-kms.c 261: if (drm_mode->type & DRM_MODE_TYPE_PREFERRED) So it seems nothing (that I can quickly find) in userspace is using this atm. The reason I wrote this patch is because about a year ago plymouth used to fully rely on the kernel to setup the modes on monitors and would simply inherit the modes setup by the kernel. Basically plymouth was relying on fbcon to load first and setup modes. Deferred fbcon takeover (for flickerfree) means that this is no longer happening. So now plymouth picks a mode itself. When I submitted the plymouth change for plymouth to pick a mode itself the plymouth maintainer (Ray Strode) was afraid that would break plymouth honoring video= arguments. So currently plymouth still relies on the kernel to do the mode setup if a video= argument is present on the kernel commandline. My other recent series, which adds support for e.g. video=HDMI:panel_orientation=right_side_up, made me realize that relying on the kernel for this is no good since the fbcon code has various limitations wrt e.g. hotplug and this of course will not work when fbcon deferred takeover is used and fbcon never loads before plymouth. So I wrote a patch for plymouth to check the DRM_MODE_TYPE_USERDEF flag and prefer a mode with that flag over the PREFERRED mode: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/84 And then I found out that for that code to work with modes which are already in the list of probed modes, I need something like the kernel patch we are discussing now. So if you want a link to an userspace consumer of this, I guess you want a v2 with a link to the plymouth MR added. + maybe a blurb in the commit message that to the best of my knowledge no userspace kms consumers are checking for the DRM_MODE_TYPE_USERDEF flag? And how does just relying on plymouth fix this? The idea is to not automatically fix this, all I want to do is provide enough info to userspace to make an informed decision, plymouth honored the video= resolution, we want to preserve that behavior. Likewise historically and currently compositors / Xorg pretty much ignore video=, I do not want to introduce changes on the kernel side which unilateral force a change here. If compositors want to start honoring a video= provided/selected mode then that is up to them. Given what you figured out in your quick search I think we should set both USERDEF and PREFERRED, otherwise not much will happen here. Plus I guess we need some fixup code to make sure that only the cmdline mode is preferred, and no other mode? Except if all compositors pick the first preferred mode consistently, then I guess we just need to make sure it's first. Changing the meaning of USERDEF to also mean "preferred mode, pls use that" could be fraught with peril, e.g. you run a game on an old compositor (or with direct display) at lower refresh, maybe with a custom mode, then it crashes. And from then on all compositors insist on using your "preferred" mode. Right, I considered usi
[radeon-alex:amd-mainline-dkms-5.2 2114/2834] drivers/gpu/drm/ttm/ttm_bo_manager.c:170:2: error: implicit declaration of function 'drm_mm_debug_table'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 57d7e98d0257bd9795dd3f438d19aa5476554685 [2114/2834] drm/amdkcl: Test
whether drm_{mm_print/debug_printer} is available
config: x86_64-randconfig-a004-201944 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
git checkout 57d7e98d0257bd9795dd3f438d19aa5476554685
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from include/asm-generic/memory_model.h:5:0,
from arch/x86/include/asm/page.h:76,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/pfn.h:15:3: note: previous declaration of 'pfn_t' was here
} pfn_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:33:13: error: conflicting types for 'vm_fault_t'
typedef int vm_fault_t;
^
In file included from include/drm/drm_mm.h:43:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm_types.h:631:32: note: previous declaration of 'vm_fault_t'
was here
typedef __bitwise unsigned int vm_fault_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:35:26: error: conflicting types for
'vmf_insert_mixed'
static inline vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma,
^
In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm.h:2587:12: note: previous declaration of 'vmf_insert_mixed'
was here
vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: In function 'vmf_insert_mixed':
include/kcl/kcl_mm_types.h:41:8: error: implicit declaration of function
'vm_insert_mixed' [-Werror=implicit-function-declaration]
err = vm_insert_mixed(vma, addr, pfn_t_to_pfn(pfn));
^
include/kcl/kcl_mm_types.h: At top level:
include/kcl/kcl_mm_types.h:53:26: error: conflicting types for
'vmf_insert_pfn'
static inline vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma,
^
In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm.h:2583:12: note: previous declaration of 'vmf_insert_pfn'
was here
vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: In function 'vmf_insert_pfn':
include/kcl/kcl_mm_types.h:56:13: error: implicit declaration of function
'vm_insert_pfn' [-Werror=implicit-function-declaration]
int err = vm_insert_pfn(vma, addr, pfn);
^
drivers/gpu/drm/ttm/ttm_bo_manager.c: In function 'ttm_bo_man_get_node':
drivers/gpu/drm/ttm/ttm_bo_manager.c:60:7: error: variable 'sflags' has
initializer but incomplete type
enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
^
drivers/gpu/drm/ttm/ttm_bo_manager.c:60:36: error: 'DRM_MM_SEARCH_BEST'
undeclared (first use in this function)
enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
^
drivers/gpu/drm/ttm/ttm_bo_manager.c:60:36: note: each undeclared identifier
is reported only once for each function it appears in
drivers/gpu/drm/ttm/ttm_bo_manager.c:60:27: error: storage size of 'sflags'
isn't known
enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
^
driver
[PATCH 1/2] drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC
Most kernel interfaces that take a timespec require normalized representation with tv_nsec between 0 and NSEC_PER_SEC. Passing values larger than 0x1ull further behaves differently on 32-bit and 64-bit kernels, and can cause the latter to spend a long time counting seconds in timespec64_sub()/set_normalized_timespec64(). Reject those large values at the user interface to enforce sane and portable behavior. Signed-off-by: Arnd Bergmann --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c index 1f9c01be40d7..95d72dc00280 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c @@ -297,6 +297,9 @@ static int etnaviv_ioctl_gem_cpu_prep(struct drm_device *dev, void *data, if (args->op & ~(ETNA_PREP_READ | ETNA_PREP_WRITE | ETNA_PREP_NOSYNC)) return -EINVAL; + if (args->timeout.tv_nsec > NSEC_PER_SEC) + return -EINVAL; + obj = drm_gem_object_lookup(file, args->handle); if (!obj) return -ENOENT; @@ -360,6 +363,9 @@ static int etnaviv_ioctl_wait_fence(struct drm_device *dev, void *data, if (args->flags & ~(ETNA_WAIT_NONBLOCK)) return -EINVAL; + if (args->timeout.tv_nsec > NSEC_PER_SEC) + return -EINVAL; + if (args->pipe >= ETNA_MAX_PIPES) return -EINVAL; @@ -411,6 +417,9 @@ static int etnaviv_ioctl_gem_wait(struct drm_device *dev, void *data, if (args->flags & ~(ETNA_WAIT_NONBLOCK)) return -EINVAL; + if (args->timeout.tv_nsec > NSEC_PER_SEC) + return -EINVAL; + if (args->pipe >= ETNA_MAX_PIPES) return -EINVAL; -- 2.20.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] [v2] drm/etnaviv: avoid deprecated timespec
struct timespec is being removed from the kernel because it often leads
to code that is not y2038-safe.
In the etnaviv driver, monotonic timestamps are used, which do not suffer
from overflow, but the usage of timespec here gets in the way of removing
the interface completely.
Pass down the user-supplied 64-bit value here rather than converting
it to an intermediate timespec to avoid the conversion.
The conversion is transparent for all regular CLOCK_MONOTONIC values,
but is a small change in behavior for excessively large values: the
existing code would treat e.g. tv_sec=0x1 the same as tv_sec=0
and not block, while the new code it would block for up to 2^31
seconds. The new behavior is more logical here, but if it causes problems,
the truncation can be put back.
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 11 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem.h | 2 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 +++--
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 +++--
6 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 95d72dc00280..3eb0f9223bea 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -282,11 +282,6 @@ static int etnaviv_ioctl_gem_new(struct drm_device *dev,
void *data,
args->flags, &args->handle);
}
-#define TS(t) ((struct timespec){ \
- .tv_sec = (t).tv_sec, \
- .tv_nsec = (t).tv_nsec \
-})
-
static int etnaviv_ioctl_gem_cpu_prep(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -304,7 +299,7 @@ static int etnaviv_ioctl_gem_cpu_prep(struct drm_device
*dev, void *data,
if (!obj)
return -ENOENT;
- ret = etnaviv_gem_cpu_prep(obj, args->op, &TS(args->timeout));
+ ret = etnaviv_gem_cpu_prep(obj, args->op, &args->timeout);
drm_gem_object_put_unlocked(obj);
@@ -357,7 +352,7 @@ static int etnaviv_ioctl_wait_fence(struct drm_device *dev,
void *data,
{
struct drm_etnaviv_wait_fence *args = data;
struct etnaviv_drm_private *priv = dev->dev_private;
- struct timespec *timeout = &TS(args->timeout);
+ struct drm_etnaviv_timespec *timeout = &args->timeout;
struct etnaviv_gpu *gpu;
if (args->flags & ~(ETNA_WAIT_NONBLOCK))
@@ -409,7 +404,7 @@ static int etnaviv_ioctl_gem_wait(struct drm_device *dev,
void *data,
{
struct etnaviv_drm_private *priv = dev->dev_private;
struct drm_etnaviv_gem_wait *args = data;
- struct timespec *timeout = &TS(args->timeout);
+ struct drm_etnaviv_timespec *timeout = &args->timeout;
struct drm_gem_object *obj;
struct etnaviv_gpu *gpu;
int ret;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 32cfa5a48d42..efc656efeb0f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -61,7 +61,7 @@ int etnaviv_gem_prime_pin(struct drm_gem_object *obj);
void etnaviv_gem_prime_unpin(struct drm_gem_object *obj);
void *etnaviv_gem_vmap(struct drm_gem_object *obj);
int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
- struct timespec *timeout);
+ struct drm_etnaviv_timespec *timeout);
int etnaviv_gem_cpu_fini(struct drm_gem_object *obj);
void etnaviv_gem_free_object(struct drm_gem_object *obj);
int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file *file,
@@ -107,11 +107,12 @@ static inline size_t size_vstruct(size_t nelem, size_t
elem_size, size_t base)
* between the specified timeout and the current CLOCK_MONOTONIC time.
*/
static inline unsigned long etnaviv_timeout_to_jiffies(
- const struct timespec *timeout)
+ const struct drm_etnaviv_timespec *timeout)
{
- struct timespec64 ts, to;
-
- to = timespec_to_timespec64(*timeout);
+ struct timespec64 ts, to = {
+ .tv_sec = timeout->tv_sec,
+ .tv_nsec = timeout->tv_nsec,
+ };
ktime_get_ts64(&ts);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index cb1faaac380a..6adea180d629 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -373,7 +373,7 @@ static inline enum dma_data_direction
etnaviv_op_to_dma_dir(u32 op)
}
int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
- struct timespec *timeout)
+ struct drm_etnaviv_timespec *timeout)
{
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
struct drm_device *dev = obj->dev;
@@ -431,7 +431,7 @@ int etnaviv_gem_cpu_fini(struct drm_gem_object *obj)
}
int etnaviv_gem_wait_bo(struct etnaviv_gpu *gpu, struct drm_gem_objec
Re: [PATCH 15/16] drm/etnaviv: use ktime_t for timeouts
On Mon, Nov 11, 2019 at 10:55 AM Lucas Stach wrote:
> >
> > > If that's the case then we should never encounter a genuine 0 timeout
> > > and this change would be okay.
> >
> > That's quite likely, I'd say any program passing {0,0} as a timeout without
> > ETNA_WAIT_NONBLOCK is already broken, but if we leave it like that,
> > it would be best to describe the reasoning in the changelog.
> >
> > Should I change the changelog, or change the patch to restore the
> > current behavior instead?
> >
> > I guess I could fold the change below into my patch to make it transparent
> > to the application again.
>
> If we assume 0 to never be a valid timeout, due to monotonic clock
> starting at 0 and never wrapping then I think we shouldn't introduce
> any additional code complexity to fix up the return value for this
> specific case. I'm not aware of any etnaviv userspace being broken in
> this way to rely on the return value for an invalid timeout input.
>
> Please just amend the commit message to mention the change in behavior
> and why we think it is safe to do.
Russell had some additional concerns that he raised on IRC,
and I did a new simpler implementation of the patch, plus a related
bugfix.
Please have a look at those.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-mainline-dkms-5.2 2104/2834] drivers/gpu/drm/ttm/ttm_bo_manager.c:60:36: error: 'DRM_MM_SEARCH_BEST' undeclared
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: 769e4dc19ad658720b779070764db2fc10a0bbac [2104/2834] drm/amdkcl: Test
whether drm_mm_insert_mode is available
config: x86_64-randconfig-a004-201944 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
git checkout 769e4dc19ad658720b779070764db2fc10a0bbac
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/kref.h:36:28: note: previous definition of 'kref_read' was here
static inline unsigned int kref_read(const struct kref *kref)
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:11:0,
from :0:
include/kcl/kcl_kref.h: In function 'kref_read':
include/kcl/kcl_kref.h:9:21: error: passing argument 1 of 'atomic_read' from
incompatible pointer type [-Werror=incompatible-pointer-types]
return atomic_read(&kref->refcount);
^
In file included from arch/x86/include/asm/atomic.h:265:0,
from include/linux/atomic.h:7,
from include/linux/rcupdate.h:25,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/asm-generic/atomic-instrumented.h:24:1: note: expected 'const
atomic_t * {aka const struct *}' but argument is of type 'const
refcount_t * {aka const struct refcount_struct *}'
atomic_read(const atomic_t *v)
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: At top level:
include/kcl/kcl_mm_types.h:10:3: error: conflicting types for 'pfn_t'
} pfn_t;
^
In file included from include/asm-generic/memory_model.h:5:0,
from arch/x86/include/asm/page.h:76,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/rcupdate.h:27,
from include/linux/rbtree.h:34,
from include/drm/drm_mm.h:41,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/pfn.h:15:3: note: previous declaration of 'pfn_t' was here
} pfn_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:33:13: error: conflicting types for 'vm_fault_t'
typedef int vm_fault_t;
^
In file included from include/drm/drm_mm.h:43:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm_types.h:631:32: note: previous declaration of 'vm_fault_t'
was here
typedef __bitwise unsigned int vm_fault_t;
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h:35:26: error: conflicting types for
'vmf_insert_mixed'
static inline vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma,
^
In file included from include/drm/drm_vma_manager.h:27:0,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/linux/mm.h:2587:12: note: previous declaration of 'vmf_insert_mixed'
was here
vm_fault_t vmf_insert_mixed(struct vm_area_struct *vma, unsigned long addr,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:12:0,
from :0:
include/kcl/kcl_mm_types.h: In function 'vmf_insert_mixed':
include/kcl/kcl_mm_types.h:41:8: error: implicit declaration of function
'vm_insert_mixed' [-Werror=implicit-function-declaration]
err = vm_insert_mixed(vma, addr, pfn_t_to_pfn(pfn));
^
include/kcl/kcl_mm_types.h: At
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi John Am 08.11.19 um 19:07 schrieb John Donnelly: > > >> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote: >> >> Hi >> >> Am 08.11.19 um 13:55 schrieb John Donnelly: >>> >>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote: Hi John Am 07.11.19 um 23:14 schrieb John Donnelly: > > >> On Nov 7, 2019, at 10:13 AM, John Donnelly >> wrote: >> >> >> >>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann >>> wrote: >>> >>> Hi John >>> >>> Am 07.11.19 um 14:12 schrieb John Donnelly: Hi Thomas ; Thank you for reaching out. See inline: > On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann > wrote: > > Hi John, > > apparently the vgaarb was not the problem. > > Am 07.11.19 um 03:29 schrieb John Donnelly: >> Hi, >> >> I am investigating an issue where we lose video activity when the >> display is switched from from “text mode” to “graphic mode” >> on a number of servers using this driver.Specifically starting >> the GNOME desktop. > > When you say "text mode", do you mean VGA text mode or the graphical > console that emulates text mode? > I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>> >>> Yes. >>> >>> > When you enable graphics mode, does it set the correct resolution? A > lot > of work went into memory management recently. I could imagine that the > driver sets the correct resolution, but then fails to display the > correct framebuffer. There is no display at all ; so there is no resolution to mention. > > If possible, could you try to update to the latest drm-tip and attach > the output of > > /sys/kernel/debug/dri/0/vram-mm I don’t see that file ; Is there something else I need to do ? >>> >>> That file is fairly new and maybe it's not in the mainline kernel yet. >>> See below for how to get it. >> >> I built your “tip” ; Still no graphics displayed . >> >> >> mount -t debugfs none /sys/kernel >> >> cat /proc/cmdline >> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ >> root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto >> resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root >> rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >> >> >> cat /sys/kernel/dri/0/vram-mm >> >> In VGA mode : >> >> >> cat /sys/kernel/dri/0/vram-mm >> 0x-0x0300: 768: used >> 0x0300-0x0600: 768: used >> 0x0600-0x07ee: 494: free >> 0x07ee-0x07ef: 1: used >> 0x07ef-0x07f0: 1: used >> >> >> In GRAPHICS mode ( if it matters ) >> >> >> cat /sys/kernel/dri/0/vram-mm >> 0x-0x0300: 768: used >> 0x0300-0x0600: 768: used >> 0x0600-0x07ee: 494: free >> 0x07ee-0x07ef: 1: used >> 0x07ef-0x07f0: 1: used >> total: 2032, used 1538 free 494 >> This is interesting. In the graphics mode, you see two buffers of 768 pages each. That's the main framebuffers as used by X (it's double buffered). Then there's a free area and finally two pages for cursor images (also double buffered). That looks as expected. The thing is that in text mode, the areas are allocated. But the driver shouldn't be active, so the file shouldn't exist or only show a single free area. >>> >>> If you want me to double check this I will .I have GNOME installed >>> , but the machine boots to runlevel 3, then I start the desktop using init >>> 5 I am pretty sure I took that output when the machine was in graphic’s >>> mode at runlevel 5 . >>> >>> >> >> >> >>> >>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>> >>> Good! Looking through that log file, the card is found at line 79 and >>> the generic X modesetting driver initializes below. That works as >>> expected. >>> >>> I notices that several operations are not permitted (lines 78 and 87). I >>> guess you're starting X from a regular user account? IIRC special >>> permission is required to acquire control of the display. What happens >>> if you start X as root user? >> >> >> I am starting GNOME as root by doing “init 5
Re: [PATCH v2 5/5] drm/komeda: add rate limiting disable to err_verbosity
On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> It's possible to get multiple events in a single frame/flip, so add an
> option to print them all.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
> Signed-off-by: Mihail Atanassov
For the whole series:
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
>
> v2: Clean up continuation line warning from checkpatch.
>
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 ++
> drivers/gpu/drm/arm/display/komeda/komeda_event.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index d9fc9c48859a..15f52e304c08 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -224,6 +224,8 @@ struct komeda_dev {
> #define KOMEDA_DEV_PRINT_INFO_EVENTS BIT(2)
> /* Dump DRM state on an error or warning event. */
> #define KOMEDA_DEV_PRINT_DUMP_STATE_ON_EVENT BIT(8)
> + /* Disable rate limiting of event prints (normally one per commit) */
> +#define KOMEDA_DEV_PRINT_DISABLE_RATELIMIT BIT(12)
> };
>
> static inline bool
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> index 7fd624761a2b..bf269683f811 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> @@ -119,7 +119,7 @@ void komeda_print_events(struct komeda_events *evts,
> struct drm_device *dev)
> /* reduce the same msg print, only print the first evt for one frame */
> if (evts->global || is_new_frame(evts))
> en_print = true;
> - if (!en_print)
> + if (!(err_verbosity & KOMEDA_DEV_PRINT_DISABLE_RATELIMIT) && !en_print)
> return;
>
> if (err_verbosity & KOMEDA_DEV_PRINT_ERR_EVENTS)
> --
> 2.23.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/komeda: Add debugfs node to control error verbosity
On Thu, Nov 07, 2019 at 11:42:28AM +, Mihail Atanassov wrote:
> Named 'err_verbosity', currently with only 1 active bit in that
> replicates the existing level - print error events once per flip.
>
> Reviewed-by: James Qian Wang (Arm Technology China)
> Signed-off-by: Mihail Atanassov
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 14 --
> drivers/gpu/drm/arm/display/komeda/komeda_event.c | 9 +++--
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
> 4 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 14d5c5da9e3b..4e46f650fddf 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -58,6 +58,8 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
> mdev->debugfs_root = debugfs_create_dir("komeda", NULL);
> debugfs_create_file("register", 0444, mdev->debugfs_root,
> mdev, &komeda_register_fops);
> + debugfs_create_x16("err_verbosity", 0664, mdev->debugfs_root,
> +&mdev->err_verbosity);
> }
> #endif
>
> @@ -273,6 +275,8 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> goto err_cleanup;
> }
>
> + mdev->err_verbosity = KOMEDA_DEV_PRINT_ERR_EVENTS;
> +
> #ifdef CONFIG_DEBUG_FS
> komeda_debugfs_init(mdev);
> #endif
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index 414200233b64..b5bd3d5898ee 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -202,6 +202,14 @@ struct komeda_dev {
>
> /** @debugfs_root: root directory of komeda debugfs */
> struct dentry *debugfs_root;
> + /**
> + * @err_verbosity: bitmask for how much extra info to print on error
> + *
> + * See KOMEDA_DEV_* macros for details.
> + */
> + u16 err_verbosity;
> + /* Print a single line per error per frame with error events. */
> +#define KOMEDA_DEV_PRINT_ERR_EVENTS BIT(0)
> };
>
> static inline bool
> @@ -219,9 +227,11 @@ void komeda_dev_destroy(struct komeda_dev *mdev);
> struct komeda_dev *dev_to_mdev(struct device *dev);
>
> #ifdef CONFIG_DRM_KOMEDA_ERROR_PRINT
> -void komeda_print_events(struct komeda_events *evts);
> +void komeda_print_events(struct komeda_events *evts, struct drm_device *dev);
> #else
> -static inline void komeda_print_events(struct komeda_events *evts) {}
> +static inline void komeda_print_events(struct komeda_events *evts,
> +struct drm_device *dev)
> +{}
> #endif
>
> int komeda_dev_resume(struct komeda_dev *mdev);
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> index a36fb86cc054..575ed4df74ed 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_event.c
> @@ -107,10 +107,12 @@ static bool is_new_frame(struct komeda_events *a)
> (KOMEDA_EVENT_FLIP | KOMEDA_EVENT_EOW);
> }
>
> -void komeda_print_events(struct komeda_events *evts)
> +void komeda_print_events(struct komeda_events *evts, struct drm_device *dev)
> {
> - u64 print_evts = KOMEDA_ERR_EVENTS;
> + u64 print_evts = 0;
> static bool en_print = true;
> + struct komeda_dev *mdev = dev->dev_private;
> + u16 const err_verbosity = mdev->err_verbosity;
>
> /* reduce the same msg print, only print the first evt for one frame */
> if (evts->global || is_new_frame(evts))
> @@ -118,6 +120,9 @@ void komeda_print_events(struct komeda_events *evts)
> if (!en_print)
> return;
>
> + if (err_verbosity & KOMEDA_DEV_PRINT_ERR_EVENTS)
> + print_evts |= KOMEDA_ERR_EVENTS;
> +
> if ((evts->global | evts->pipes[0] | evts->pipes[1]) & print_evts) {
> char msg[256];
> struct komeda_str str;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index d49772de93e0..e30a5b43caa9 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -48,7 +48,7 @@ static irqreturn_t komeda_kms_irq_handler(int irq, void
> *data)
> memset(&evts, 0, sizeof(evts));
> status = mdev->funcs->irq_handler(mdev, &evts);
>
> - komeda_print_events(&evts);
> + komeda_print_events(&evts, drm);
>
> /* Notify the crtc to handle the events */
> for (i = 0; i < kms->n_crtcs; i++)
> --
> 2.23.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\
Re: [PATCH 1/3] dma_resv: prime lockdep annotations
On Mon, Nov 11, 2019 at 2:11 PM Steven Price wrote:
>
> On 04/11/2019 17:37, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> > really no business holding struct_mutex while doing copy_*_user. But
> > I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> > looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> > copying from/to userspace happens all in v3d_lookup_bos which is
> > outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> > - vmw_execbuf_process: First this does some copies in
> > vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> > Then comes the usual ttm reserve/validate sequence, then actual
> > submission/fencing, then unreserving, and finally some more
> > copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> > details, but looks all safe.
> > - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> > seen, seems to only create a fence and copy it out.
> > - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> > found there.
> > Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> > copying from userspace before even looking up objects through their
> > handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> > qxl_process_single_command. There's a lovely comment before the
> > __copy_from_user_inatomic that the slowpath should be copied from
> > i915, but I guess that never happened. Try not to be unlucky and get
> > your CS data evicted between when it's written and the kernel tries
> > to read it. The only other copy_from_user is for relocs, but those
> > are done before qxl_release_reserve_list(), which seems to be the
> > only thing reserving buffers (in the ttm/dma_resv sense) in that
> > code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> > usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> > everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Chris Wilson
> > Cc: Thomas Zimmermann
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Eric Anholt
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Ben Skeggs
> > Cc: "VMware Graphics"
> > Cc: Thomas Hellstrom
> > Reviewed-by: Christian König
> > Reviewed-by: Chris Wilson
> > Tested-by: Chris Wilson
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/dma-buf/dma-resv.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > /**
> > * DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list
> > *list)
> > kfree_rcu(list, rcu);
> > }
> >
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > + struct mm_struct *mm = mm_alloc();
> > + struct dma_resv obj;
> > +
> > + if (!mm)
> > + return;
> > +
> > + dma_resv_init(&obj);
> > +
> > + down_read(&mm->mmap_sem);
> > + ww_mutex_lock(&obj.lock, NULL);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + fs_reclaim_release(GFP_KERNEL);
> > + ww_mutex_unlock(&obj.lock);
> > + up_read(&mm->mmap_sem);
> > +
>
> Nit: trailing whitespace
>
> > + mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
>
> This expects a function returning int, but dma_resv_lockdep() is void.
> Causing:
>
> drivers/dma-buf/dma-resv.c:119:17: error: initialization of ‘initcall_t’
> {aka ‘int (*)(void)’} from incompatible pointer type ‘void (*)(void)’
> [-Werror=incompatible-pointer-types]
> subsys_initcall(dma_resv_lockdep);
>
> The below fixe
