Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev8)
Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Wednesday, May 24, 2017 1:52 AM > To: Puthikorn Voravootivat > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to > intel_dp_aux_backlight driver (rev8) > > == Series Details == > > Series: Enhancement to intel_dp_aux_backlight driver (rev8) > URL : https://patchwork.freedesktop.org/series/21086/ > State : success > > == Summary == > > Series 21086v8 Enhancement to intel_dp_aux_backlight driver > https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/8/mbox/ > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:431s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:438s And to be investigated...why not logs. Resending when clear. > fi-bdw-5557u failed to collect. IGT log at Patchwork_4792/fi-bdw-5557u/igt.log > fi-bsw-n3050 failed to collect. IGT log at Patchwork_4792/fi-bsw-n3050/igt.log > fi-bxt-j4205 failed to collect. IGT log at Patchwork_4792/fi-bxt-j4205/igt.log > fi-byt-j1900 failed to collect. IGT log at Patchwork_4792/fi-byt-j1900/igt.log > fi-byt-n2820 failed to collect. IGT log at Patchwork_4792/fi-byt-n2820/igt.log > fi-hsw-4770 failed to collect. IGT log at Patchwork_4792/fi-hsw-4770/igt.log > fi-hsw-4770r failed to collect. IGT log at Patchwork_4792/fi-hsw-4770r/igt.log > fi-ilk-650 failed to collect. IGT log at Patchwork_4792/fi-ilk-650/igt.log > fi-ivb- > 3520m failed to collect. IGT log at Patchwork_4792/fi-ivb-3520m/igt.log > fi-ivb-3770 failed to collect. IGT log at Patchwork_4792/fi-ivb-3770/igt.log > fi-kbl-7500u failed to collect. IGT log at Patchwork_4792/fi-kbl-7500u/igt.log > fi-kbl-7560u failed to collect. IGT log at Patchwork_4792/fi-kbl-7560u/igt.log > fi-skl-6260u failed to collect. IGT log at Patchwork_4792/fi-skl-6260u/igt.log > fi-skl-6700hq failed to collect. IGT log at > Patchwork_4792/fi-skl-6700hq/igt.log > fi-skl-6700k failed to collect. IGT log at Patchwork_4792/fi-skl-6700k/igt.log > fi-skl-6770hq failed to collect. IGT log at > Patchwork_4792/fi-skl-6770hq/igt.log > fi-snb-2520m failed to collect. IGT log at Patchwork_4792/fi-snb-2520m/igt.log > fi-snb-2600 failed to collect. IGT log at Patchwork_4792/fi-snb-2600/igt.log > > 26f8446d6f098e0f05c009f29f7f086decf8 drm-tip: 2017y-05m-23d-21h- > 09m-34s UTC integration manifest > 9306eb3 drm/i915: Set PWM divider to match desired frequency in vbt 45be0dd > drm: Add definition for eDP backlight frequency > 98ab393 drm/i915: Add option to support dynamic backlight via DPCD > 51873e2 drm/i915: Allow choosing how to adjust brightness if both supported > a782c81 drm/i915: Drop AUX backlight enable check for backlight control > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4792/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Disable and remove decoupled MMIO feature
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Wednesday, May 24, 2017 1:13 AM > To: Chen, Kai > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for Disable and remove decoupled > MMIO > feature > > == Series Details == > > Series: Disable and remove decoupled MMIO feature > URL : https://patchwork.freedesktop.org/series/24851/ > State : success > > == Summary == > > Series 24851v1 Disable and remove decoupled MMIO feature > https://patchwork.freedesktop.org/api/1.0/series/24851/revisions/1/mbox/ > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:437s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:439s And here...to be investigated. > fi-bdw-5557u failed to collect. IGT log at Patchwork_4791/fi-bdw-5557u/igt.log > fi-bxt-j4205 failed to collect. IGT log at Patchwork_4791/fi-bxt-j4205/igt.log > fi-byt-j1900 failed to collect. IGT log at Patchwork_4791/fi-byt-j1900/igt.log > fi-hsw-4770 failed to collect. IGT log at Patchwork_4791/fi-hsw-4770/igt.log > fi-hsw-4770r failed to collect. IGT log at Patchwork_4791/fi-hsw-4770r/igt.log > fi-ilk-650 failed to collect. IGT log at Patchwork_4791/fi-ilk-650/igt.log > fi-ivb- > 3520m failed to collect. IGT log at Patchwork_4791/fi-ivb-3520m/igt.log > fi-ivb-3770 failed to collect. IGT log at Patchwork_4791/fi-ivb-3770/igt.log > fi-kbl-7500u failed to collect. IGT log at Patchwork_4791/fi-kbl-7500u/igt.log > fi-kbl-7560u failed to collect. IGT log at Patchwork_4791/fi-kbl-7560u/igt.log > fi-skl-6260u failed to collect. IGT log at Patchwork_4791/fi-skl-6260u/igt.log > fi-skl-6700hq failed to collect. IGT log at > Patchwork_4791/fi-skl-6700hq/igt.log > fi-skl-6700k failed to collect. IGT log at Patchwork_4791/fi-skl-6700k/igt.log > fi-skl-6770hq failed to collect. IGT log at > Patchwork_4791/fi-skl-6770hq/igt.log > fi-snb-2520m failed to collect. IGT log at Patchwork_4791/fi-snb-2520m/igt.log > fi-snb-2600 failed to collect. IGT log at Patchwork_4791/fi-snb-2600/igt.log > > 26f8446d6f098e0f05c009f29f7f086decf8 drm-tip: 2017y-05m-23d-21h- > 09m-34s UTC integration manifest > 4b06135 drm/i915: Remove decoupled MMIO code > eb3aab9 drm/i915: Disable decoupled MMIO > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4791/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Silence compiler warning in igt_ctx_exec (rev2)
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Tuesday, May 23, 2017 11:01 PM > To: Chris Wilson > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Silence > compiler > warning in igt_ctx_exec (rev2) > > == Series Details == > > Series: drm/i915/selftests: Silence compiler warning in igt_ctx_exec (rev2) > URL : https://patchwork.freedesktop.org/series/24787/ > State : success > > == Summary == > > Series 24787v2 drm/i915/selftests: Silence compiler warning in igt_ctx_exec > https://patchwork.freedesktop.org/api/1.0/series/24787/revisions/2/mbox/ > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:431s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:442s Same here...will be investigated. > fi-bdw-5557u failed to collect. IGT log at Patchwork_4790/fi-bdw-5557u/igt.log > fi-bsw-n3050 failed to collect. IGT log at Patchwork_4790/fi-bsw-n3050/igt.log > fi-bxt-j4205 failed to collect. IGT log at Patchwork_4790/fi-bxt-j4205/igt.log > fi-hsw-4770 failed to collect. IGT log at Patchwork_4790/fi-hsw-4770/igt.log > fi-hsw-4770r failed to collect. IGT log at Patchwork_4790/fi-hsw-4770r/igt.log > fi-ilk-650 failed to collect. IGT log at Patchwork_4790/fi-ilk-650/igt.log > fi-ivb- > 3520m failed to collect. IGT log at Patchwork_4790/fi-ivb-3520m/igt.log > fi-ivb-3770 failed to collect. IGT log at Patchwork_4790/fi-ivb-3770/igt.log > fi-kbl-7500u failed to collect. IGT log at Patchwork_4790/fi-kbl-7500u/igt.log > fi-kbl-7560u failed to collect. IGT log at Patchwork_4790/fi-kbl-7560u/igt.log > fi-skl-6260u failed to collect. IGT log at Patchwork_4790/fi-skl-6260u/igt.log > fi-skl-6700hq failed to collect. IGT log at > Patchwork_4790/fi-skl-6700hq/igt.log > fi-skl-6700k failed to collect. IGT log at Patchwork_4790/fi-skl-6700k/igt.log > fi-skl-6770hq failed to collect. IGT log at > Patchwork_4790/fi-skl-6770hq/igt.log > fi-snb-2520m failed to collect. IGT log at Patchwork_4790/fi-snb-2520m/igt.log > fi-snb-2600 failed to collect. IGT log at Patchwork_4790/fi-snb-2600/igt.log > > c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h- > 42m-41s UTC integration manifest > 160a9c9 drm/i915/selftests: Silence compiler warning in igt_ctx_exec > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4790/ Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for SKL render decompression support
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Tuesday, May 23, 2017 10:40 PM > To: Daniel Stone > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for SKL render decompression support > > == Series Details == > > Series: SKL render decompression support > URL : https://patchwork.freedesktop.org/series/24838/ > State : success > > == Summary == > > Series 24838v1 SKL render decompression support > https://patchwork.freedesktop.org/api/1.0/series/24838/revisions/1/mbox/ > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:433s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:439s > fi-bdw-5557u failed to collect. IGT log at Patchwork_4789/fi-bdw-5557u/igt.log Yep, noticed, will be investigating and sending correct results when received. > fi-bsw-n3050 failed to collect. IGT log at Patchwork_4789/fi-bsw-n3050/igt.log > fi-byt-n2820 failed to collect. IGT log at Patchwork_4789/fi-byt-n2820/igt.log > fi-hsw-4770 failed to collect. IGT log at Patchwork_4789/fi-hsw-4770/igt.log > fi-hsw-4770r failed to collect. IGT log at Patchwork_4789/fi-hsw-4770r/igt.log > fi-ilk-650 failed to collect. IGT log at Patchwork_4789/fi-ilk-650/igt.log > fi-ivb- > 3520m failed to collect. IGT log at Patchwork_4789/fi-ivb-3520m/igt.log > fi-ivb-3770 failed to collect. IGT log at Patchwork_4789/fi-ivb-3770/igt.log > fi-kbl-7500u failed to collect. IGT log at Patchwork_4789/fi-kbl-7500u/igt.log > fi-kbl-7560u failed to collect. IGT log at Patchwork_4789/fi-kbl-7560u/igt.log > fi-skl-6260u failed to collect. IGT log at Patchwork_4789/fi-skl-6260u/igt.log > fi-skl-6700hq failed to collect. IGT log at > Patchwork_4789/fi-skl-6700hq/igt.log > fi-skl-6700k failed to collect. IGT log at Patchwork_4789/fi-skl-6700k/igt.log > fi-skl-6770hq failed to collect. IGT log at > Patchwork_4789/fi-skl-6770hq/igt.log > fi-snb-2520m failed to collect. IGT log at Patchwork_4789/fi-snb-2520m/igt.log > fi-snb-2600 failed to collect. IGT log at Patchwork_4789/fi-snb-2600/igt.log > > c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h- > 42m-41s UTC integration manifest > eb9a614 drm/i915: Implement .get_format_info() hook for CCS > f4fc298 drm: Add explict alignment for formats > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4789/ Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2)
Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Tuesday, May 23, 2017 10:27 PM > To: nagar...@emeril.freedesktop.org; Nagaraju, Vathsala > > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: disable psr2 for > resolution greater than 32X20 (rev2) > > == Series Details == > > Series: drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2) > URL : https://patchwork.freedesktop.org/series/17737/ > State : success > > == Summary == > > Series 17737v2 drm/i915/psr: disable psr2 for resolution greater than 32X20 > https://patchwork.freedesktop.org/api/1.0/series/17737/revisions/2/mbox/ > > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:434s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:438s > fi-bdw-5557u failed to collect. IGT log at Patchwork_4788/fi-bdw-5557u/igt.log Something wrong in CI. This was just test to see if one occurrence but no. Investigating... > fi-bsw-n3050 failed to collect. IGT log at Patchwork_4788/fi-bsw-n3050/igt.log > fi-bxt-j4205 failed to collect. IGT log at Patchwork_4788/fi-bxt-j4205/igt.log > fi-byt-j1900 failed to collect. IGT log at Patchwork_4788/fi-byt-j1900/igt.log > fi-byt-n2820 failed to collect. IGT log at Patchwork_4788/fi-byt-n2820/igt.log > fi-hsw-4770 failed to collect. IGT log at Patchwork_4788/fi-hsw-4770/igt.log > fi-hsw-4770r failed to collect. IGT log at Patchwork_4788/fi-hsw-4770r/igt.log > fi-ilk-650 failed to collect. IGT log at Patchwork_4788/fi-ilk-650/igt.log > fi-ivb- > 3520m failed to collect. IGT log at Patchwork_4788/fi-ivb-3520m/igt.log > fi-ivb-3770 failed to collect. IGT log at Patchwork_4788/fi-ivb-3770/igt.log > fi-kbl-7500u failed to collect. IGT log at Patchwork_4788/fi-kbl-7500u/igt.log > fi-kbl-7560u failed to collect. IGT log at Patchwork_4788/fi-kbl-7560u/igt.log > fi-skl-6260u failed to collect. IGT log at Patchwork_4788/fi-skl-6260u/igt.log > fi-skl-6700hq failed to collect. IGT log at > Patchwork_4788/fi-skl-6700hq/igt.log > fi-skl-6700k failed to collect. IGT log at Patchwork_4788/fi-skl-6700k/igt.log > fi-skl-6770hq failed to collect. IGT log at > Patchwork_4788/fi-skl-6770hq/igt.log > fi-snb-2520m failed to collect. IGT log at Patchwork_4788/fi-snb-2520m/igt.log > fi-snb-2600 failed to collect. IGT log at Patchwork_4788/fi-snb-2600/igt.log > > c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h- > 42m-41s UTC integration manifest > a293db4 drm/i915/psr: disable psr2 for resolution greater than 32X20 > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4788/ Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] Aubinator cleanups
Whoops, wrong list :( On 24/05/17 02:14, Lionel Landwerlin wrote: Hi, Mark kindly pointed me at some coverity issues in aubinator. Here are some cleanups. Cheers, Lionel Landwerlin (3): aubinator: fix double free aubinator: be consistent on exit code aubinator: report error on unknown device id src/intel/tools/aubinator_error_decode.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] aubinator: report error on unknown device id
Since we're going to stop aubinator without a valid device id, better
report an error. This also silences a Coverity warning.
CID: 1405004
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator_error_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator_error_decode.c
b/src/intel/tools/aubinator_error_decode.c
index a41292238cb..636f56a3365 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -635,7 +635,7 @@ read_data_file(FILE *file)
if (matched == 1) {
if (!gen_get_device_info(reg, &devinfo)) {
printf("Unable to identify devid=%x\n", reg);
- return;
+ exit(EXIT_FAILURE);
}
disasm = gen_disasm_create(reg);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] aubinator: be consistent on exit code
We're using both exit(1) & exit(EXIT_FAILURE), settle for one, same
for success.
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator_error_decode.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/intel/tools/aubinator_error_decode.c
b/src/intel/tools/aubinator_error_decode.c
index 506d39012b8..a41292238cb 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -587,7 +587,7 @@ read_data_file(FILE *file)
count = ascii85_decode(line+1, &data, line[0] == ':');
if (count == 0) {
fprintf(stderr, "ASCII85 decode failed.\n");
-exit(1);
+exit(EXIT_FAILURE);
}
if (strcmp(buffer_name, "user") == 0) {
@@ -718,7 +718,7 @@ read_data_file(FILE *file)
data = realloc(data, data_size * sizeof (uint32_t));
if (data == NULL) {
fprintf(stderr, "Out of memory.\n");
-exit(1);
+exit(EXIT_FAILURE);
}
}
@@ -824,7 +824,7 @@ main(int argc, char *argv[])
if (help || argc == 1) {
print_help(argv[0], stderr);
- exit(0);
+ exit(EXIT_SUCCESS);
}
if (optind >= argc) {
@@ -847,7 +847,7 @@ main(int argc, char *argv[])
}
} else {
read_data_file(stdin);
- exit(0);
+ exit(EXIT_SUCCESS);
}
} else {
path = argv[optind];
@@ -855,7 +855,7 @@ main(int argc, char *argv[])
if (error != 0) {
fprintf(stderr, "Error opening %s: %s\n",
path, strerror(errno));
- exit(1);
+ exit(EXIT_FAILURE);
}
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] aubinator: fix double free
Free previously allocated filename outside the for loop.
CID: 1405014
Signed-off-by: Lionel Landwerlin
---
src/intel/tools/aubinator_error_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/tools/aubinator_error_decode.c
b/src/intel/tools/aubinator_error_decode.c
index 37c66ec0f68..506d39012b8 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -874,8 +874,8 @@ main(int argc, char *argv[])
file = fopen(filename, "r");
if (!file) {
int minor;
+ free(filename);
for (minor = 0; minor < 64; minor++) {
-free(filename);
ret = asprintf(&filename, "%s/%d/i915_error_state", path, minor);
assert(ret > 0);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] Aubinator cleanups
Hi, Mark kindly pointed me at some coverity issues in aubinator. Here are some cleanups. Cheers, Lionel Landwerlin (3): aubinator: fix double free aubinator: be consistent on exit code aubinator: report error on unknown device id src/intel/tools/aubinator_error_decode.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
Your patch also fixes the original warning reported in: https://lkml.org/lkml/2017/5/21/1 Signed-off-by: Nick Desaulniers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> -Original Message- > From: Bloomfield, Jon > Sent: Tuesday, May 23, 2017 7:28 AM > To: 'Chris Wilson' > Cc: intel-gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT > > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Tuesday, May 23, 2017 12:33 AM > > To: Bloomfield, Jon > > Cc: intel-gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT > > It's an uncached mmio write. It is strongly ordered and serial. Besides > > if you feel it is wrong, fix the bug at source. > > Strongly ordered is not enough, nor is being uncached - that just ensures the > PTE > writes have left the CPU. We need to ensure they have left the GAM before > we > allow any following Aperture accesses to reach the GAM. On the other hand > it > may be that the write to the flushctl reg will explicitly cause the h/w to > clear > the > fifo. I'll check with hw. H/W have confirmed that the flushing write is not sufficient to avoid the bug. In their words [almost]: "You need the read. The [FLSH_CTRL write] will invalidate the GTLB. However, it won't ensure a [Aperture] read isn't in the pipe." So the mmio read needs to stay, and we're left with where to issue it. I placed it in the _cb function because it is only needed for BXT and doing it there avoids any (admittedly small) extra overhead for other devices. But I have no strong opinion on this, so if you really want it to go into the main function I'll move it. I do think it should be conditional though. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev8)
== Series Details == Series: Enhancement to intel_dp_aux_backlight driver (rev8) URL : https://patchwork.freedesktop.org/series/21086/ State : success == Summary == Series 21086v8 Enhancement to intel_dp_aux_backlight driver https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/8/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:431s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-bdw-5557u failed to collect. IGT log at Patchwork_4792/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4792/fi-bsw-n3050/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4792/fi-bxt-j4205/igt.log fi-byt-j1900 failed to collect. IGT log at Patchwork_4792/fi-byt-j1900/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4792/fi-byt-n2820/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4792/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4792/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4792/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4792/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4792/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4792/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4792/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4792/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4792/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4792/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4792/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4792/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4792/fi-snb-2600/igt.log 26f8446d6f098e0f05c009f29f7f086decf8 drm-tip: 2017y-05m-23d-21h-09m-34s UTC integration manifest 9306eb3 drm/i915: Set PWM divider to match desired frequency in vbt 45be0dd drm: Add definition for eDP backlight frequency 98ab393 drm/i915: Add option to support dynamic backlight via DPCD 51873e2 drm/i915: Allow choosing how to adjust brightness if both supported a782c81 drm/i915: Drop AUX backlight enable check for backlight control == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4792/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 3/5] drm/i915: Add option to support dynamic backlight via DPCD
This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/i915_params.c| 5
drivers/gpu/drm/i915/i915_params.h| 3 +-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 42 ++-
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 13cf3f1572ab..6eaf660e74da 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
+ .enable_dbc = false,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
+
+module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
+MODULE_PARM_DESC(enable_dbc,
+ "Enable support for dynamic backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index ac02efce6e22..2de3e2850b54 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,7 +67,8 @@
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
func(int, enable_dpcd_backlight); \
- func(bool, enable_gvt)
+ func(bool, enable_gvt); \
+ func(bool, enable_dbc)
#define MEMBER(T, member) T member
struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 16ba1924308d..f1b7855a2d2a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -100,11 +100,26 @@ intel_dp_aux_set_backlight(struct intel_connector
*connector, u32 level)
}
}
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+ u32 min, u32 max)
+{
+ u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+ if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc)) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+ }
+}
+
static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
- uint8_t dpcd_buf = 0;
- uint8_t edp_backlight_mode = 0;
+ uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
@@ -113,18 +128,15 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
return;
}
+ new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
- dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
- DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
- }
+ new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+ new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
/* Do nothing when it is already DPCD mode */
@@ -133,6 +145,20 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
break;
}
+ if (i915.enable_dbc &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
+ new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+ intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+ DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+ }
+
+ if (new_dpcd_buf != dpcd_buf) {
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+ }
+ }
+
set_aux_
[Intel-gfx] [PATCH v9 5/5] drm/i915: Set PWM divider to match desired frequency in vbt
Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 82 +++
1 file changed, 82 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index f1b7855a2d2a..b7cd44550127 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -116,10 +116,85 @@ intel_dp_aux_set_dynamic_backlight_percent(struct
intel_dp *intel_dp,
}
}
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+ int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
+ u8 pn, pn_min, pn_max;
+
+ /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+ freq = dev_priv->vbt.backlight.pwm_freq_hz;
+ DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+ if (!freq) {
+ DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+ return;
+ }
+
+ fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+
+ /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - FxP is within 25% of desired value.
+* Note: 25% is arbitrary value and may need some tweak.
+*/
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
+ DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+ return;
+ }
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
+ DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+ return;
+ }
+ pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+ fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
+ fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
+ if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+ DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+ return;
+ }
+
+ for (pn = pn_max; pn >= pn_min; pn--) {
+ f = clamp(DIV_ROUND_CLOSEST(fxp , 1 << pn), 1, 255);
+ fxp_actual = f << pn;
+ if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+ break;
+ }
+
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+ return;
+ }
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+ DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+ return;
+ }
+}
+
static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
uint8_t dpcd_buf, new_dpcd_buf, edp_backlight_mode;
+ bool freq_cap;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
@@ -152,6 +227,10 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
+ freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
+ if (freq_cap)
+ new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
@@ -159,6 +238,9 @@ static void intel_dp_aux_enable_backlight(struct
intel_connector *co
[Intel-gfx] [PATCH v9 4/5] drm: Add definition for eDP backlight frequency
This patch adds the following definition - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap register which only use bit 0:4 - Base frequency (27 MHz) for backlight PWM frequency generator. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan --- include/drm/drm_dp_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index c0bd0d7651a9..eaa307f6ae8c 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -572,10 +572,12 @@ #define DP_EDP_PWMGEN_BIT_COUNT 0x724 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 +# define DP_EDP_PWMGEN_BIT_COUNT_MASK (0x1f << 0) #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 #define DP_EDP_BACKLIGHT_FREQ_SET 0x728 +# define DP_EDP_BACKLIGHT_FREQ_BASE_KHZ 27000 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b -- 2.13.0.219.gdb65acc882-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 0/5] Enhancement to intel_dp_aux_backlight driver
This patch set contain 5 patches. Another 4 patches in previous version was already merged in v7. - First two patches allow choosing which way to adjust brightness if both PWM pin and AUX are supported - Next patch adds support for dynamic brightness. - Last two patches set the PWM freqency to match data in panel vbt. Change log: v9: - Fix nits in v8 v8: - Drop 4 patches that was already merged - Move DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check to patch #2 to avoid behavior change if only apply patch #1 - Add TODO to warn about enable backlight twice in patch #2 - Use DIV_ROUND_CLOSEST instead of just "/" in patch #5 - Fix bug calculate pn in patch #5 - Clarify commit message / code comment in patch #5 v7: - Add check in intel_dp_pwm_pin_display_control_capable in patch #4 - Add option in patch #6 to enable DPCD or not - Change definition in patch #8 and implementation in #9 to use Khz - Fix compiler warning from build bot in patch #9 v6: - Address review from Dhinakaran - Make PWM frequency to have highest value of Pn that make the frequency still within 25% of desired frequency. v5: - Split first patch in v4 to 3 patches - Bump priority for "Correctly enable backlight brightness adjustment via DPCD" - Make logic clearer for the case that both PWM pin and AUX are supported - Add more log when write to register fail - Add log when enable DBC v4: - Rebase / minor typo fix. v3: - Add new implementation of PWM frequency patch v2: - Drop PWM frequency patch - Address suggestion from Jani Nikula Puthikorn Voravootivat (5): drm/i915: Drop AUX backlight enable check for backlight control drm/i915: Allow choosing how to adjust brightness if both supported drm/i915: Add option to support dynamic backlight via DPCD drm: Add definition for eDP backlight frequency drm/i915: Set PWM divider to match desired frequency in vbt drivers/gpu/drm/i915/i915_params.c| 13 ++- drivers/gpu/drm/i915/i915_params.h| 5 +- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 156 +++--- include/drm/drm_dp_helper.h | 2 + 4 files changed, 157 insertions(+), 19 deletions(-) -- 2.13.0.219.gdb65acc882-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 1/5] drm/i915: Drop AUX backlight enable check for backlight control
There are some panel that
(1) does not support display backlight enable via AUX
(2) support display backlight adjustment via AUX
(3) support display backlight enable via eDP BL_ENABLE pin
The current driver required that (1) must be support to enable (2).
This patch drops that requirement.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b87c5a381d6a..a0995c00fc84 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
{
uint8_t reg_val = 0;
+ /* Early return when display use other mechanism to enable backlight. */
+ if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+ return;
+
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
®_val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -165,10 +169,8 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
* the panel can support backlight control over the aux channel
*/
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
- (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
- !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] &
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+ !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
--
2.13.0.219.gdb65acc882-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 2/5] drm/i915: Allow choosing how to adjust brightness if both supported
Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.
Signed-off-by: Puthikorn Voravootivat
---
drivers/gpu/drm/i915/i915_params.c| 8 +---
drivers/gpu/drm/i915/i915_params.h| 2 +-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 ++
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
- .enable_dpcd_backlight = false,
+ .enable_dpcd_backlight = -1,
.enable_gvt = false,
};
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int,
0600);
MODULE_PARM_DESC(enable_dpcd_backlight,
- "Enable support for DPCD backlight control (default:false)");
+ "Enable support for DPCD backlight control "
+ "(-1:disable (default), 0:Use PWM pin if both supported, "
+ "1:Use DPCD if both supported");
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
- func(bool, enable_dpcd_backlight); \
+ func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
#define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index a0995c00fc84..16ba1924308d 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -43,6 +43,9 @@ static void set_aux_backlight_enable(struct intel_dp
*intel_dp, bool enable)
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
+ /* TODO: If the panel also support enabling backlight via BL_ENABLE pin,
+* the backlight will be enabled again in _intel_edp_backlight_on()
+*/
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
reg_val) != 1) {
DRM_DEBUG_KMS("Failed to %s aux backlight\n",
@@ -168,20 +171,35 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
/* Check the eDP Display control capabilities registers to determine if
* the panel can support backlight control over the aux channel
*/
- if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
- (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
- !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
+ if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
}
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+
+ /* Check the eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+ return (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+ (intel_dp->edp_dpcd[2] &
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP);
+}
+
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
{
struct intel_panel *panel = &intel_connector->panel;
- if (!i915.enable_dpcd_backlight)
+ if (i915.enable_dpcd_backlight == -1)
+ return -ENODEV;
+
+ if (i915.enable_dpcd_backlight == 0 &&
+ intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
if (!intel_dp_aux_display_control_capable(intel_connector))
--
2.13.0.219.gdb65acc882-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/67] drm/i915/cnp: Panel Power sequence changes for CNP PCH.
On Thu, Apr 13, 2017 at 11:48:41PM +, Vivi, Rodrigo wrote:
> On Fri, 2017-04-07 at 17:48 +0300, Ville Syrjälä wrote:
> > On Thu, Apr 06, 2017 at 12:15:02PM -0700, Rodrigo Vivi wrote:
> > > As for BXT, PP_DIVISOR was removed from CNP PCH and power
> > > cycle delay has been moved to PP_CONTROL.
> > >
> > > Cc: Jani Nikula
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/intel_dp.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index b38cba7..da111cb 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -788,7 +788,7 @@ static void intel_pps_get_registers(struct
> > > drm_i915_private *dev_priv,
> > > regs->pp_stat = PP_STATUS(pps_idx);
> > > regs->pp_on = PP_ON_DELAYS(pps_idx);
> > > regs->pp_off = PP_OFF_DELAYS(pps_idx);
> > > - if (!IS_GEN9_LP(dev_priv))
> > > + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
> >
> > GEN >= 10 all over might be more future proof.
>
> True, but I didn't want to loose the track that this part is on the PCH.
> for the core
>
> Could we let it like this and in the future if we decide that this is
> the case we change?!
Sorry, I dropped this discussion through the cracks somehow. IIRC the
patch didn't seem to have any real issues, so I think we can go with
it as is, so
Reviewed-by: Ville Syrjälä
>
> >
> > > regs->pp_div = PP_DIVISOR(pps_idx);
> > > }
> > >
> > > @@ -5198,7 +5198,7 @@ static void
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >
> > > pp_on = I915_READ(regs.pp_on);
> > > pp_off = I915_READ(regs.pp_off);
> > > - if (!IS_GEN9_LP(dev_priv)) {
> > > + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
> > > I915_WRITE(regs.pp_ctrl, pp_ctl);
> >
> > Slightly unrelated, but I wonder what this write is doing in the BXT+
> > branch. I'm thinking it should either be done unconditionally, or we
> > should just nuke it since I think Imre's early pps unlock thing should
> > have already done it if needed, I think.
> >
> > > pp_div = I915_READ(regs.pp_div);
> > > }
> > > @@ -5216,7 +5216,7 @@ static void
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > > seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
> > > PANEL_POWER_DOWN_DELAY_SHIFT;
> > >
> > > - if (IS_GEN9_LP(dev_priv)) {
> > > + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > > u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
> > > BXT_POWER_CYCLE_DELAY_SHIFT;
> > > if (tmp > 0)
> > > @@ -5373,7 +5373,7 @@ static void
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > >(seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
> > > /* Compute the divisor for the pp clock, simply match the Bspec
> > >* formula. */
> > > - if (IS_GEN9_LP(dev_priv)) {
> > > + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
> > > pp_div = I915_READ(regs.pp_ctrl);
> > > pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
> > > pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
> > > @@ -5407,7 +5407,7 @@ static void
> > > intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> > > DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x,
> > > PP_OFF %#x, PP_DIV %#x\n",
> > > I915_READ(regs.pp_on),
> > > I915_READ(regs.pp_off),
> > > - IS_GEN9_LP(dev_priv) ?
> > > + (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
> > > (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
> > > I915_READ(regs.pp_div));
> > > }
> > > --
> > > 1.9.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Disable and remove decoupled MMIO feature
== Series Details == Series: Disable and remove decoupled MMIO feature URL : https://patchwork.freedesktop.org/series/24851/ State : success == Summary == Series 24851v1 Disable and remove decoupled MMIO feature https://patchwork.freedesktop.org/api/1.0/series/24851/revisions/1/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:437s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-bdw-5557u failed to collect. IGT log at Patchwork_4791/fi-bdw-5557u/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4791/fi-bxt-j4205/igt.log fi-byt-j1900 failed to collect. IGT log at Patchwork_4791/fi-byt-j1900/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4791/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4791/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4791/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4791/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4791/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4791/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4791/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4791/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4791/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4791/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4791/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4791/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4791/fi-snb-2600/igt.log 26f8446d6f098e0f05c009f29f7f086decf8 drm-tip: 2017y-05m-23d-21h-09m-34s UTC integration manifest 4b06135 drm/i915: Remove decoupled MMIO code eb3aab9 drm/i915: Disable decoupled MMIO == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4791/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] Disable and remove decoupled MMIO feature
From: Kai Chen In theory, decoupled mmio should require less cycles for single read/write operation by avoiding frequent software forcewake. However, it turns out this design not to be true on HW reality and not to provide any decoupling benefit. It also introduces problems which cause failures in intel-gpu-tools tests (gem), and also cause driver code and debugging more complex. The patch set is organized as follows: - Patch 1 is to disable decoupled MMIO. This patch can also be backported to other shipped kernel as a quick fix. - Patch 2 is to totally remove implemented decoupled MMIO code on top of Patch 1. Kai Chen (2): drm/i915: Disable decoupled MMIO drm/i915: Remove decoupled MMIO code drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/i915/i915_pci.c | 1 - drivers/gpu/drm/i915/i915_reg.h | 7 -- drivers/gpu/drm/i915/intel_uncore.c | 126 4 files changed, 137 deletions(-) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Remove decoupled MMIO code
From: Kai Chen
This is a follow-up patch to the previous patch ([PATCH[1/2] drm/i915:
Disable decoupled MMIO) to remove the dead code for decoupled MMIO
implementation, as it won't be used any longer on GEN9LP.
Therefore, this patch reverts:
commit 85ee17ebeedd1af0dccd98f82ab4e644e29d84c0
Author: Praveen Paneri
Date: Tue Nov 15 22:49:20 2016 +0530
drm/i915/bxt: Broxton decoupled MMIO
Signed-off-by: Kai Chen
---
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_reg.h | 7 --
drivers/gpu/drm/i915/intel_uncore.c | 126
3 files changed, 136 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a6f2047..41ff031 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -703,7 +703,6 @@ struct intel_csr {
func(has_aliasing_ppgtt); \
func(has_csr); \
func(has_ddi); \
- func(has_decoupled_mmio); \
func(has_dp_mst); \
func(has_fbc); \
func(has_fpga_dbg); \
@@ -2944,8 +2943,6 @@ intel_info(const struct drm_i915_private *dev_priv)
#define GT_FREQUENCY_MULTIPLIER 50
#define GEN9_FREQ_SCALER 3
-#define HAS_DECOUPLED_MMIO(dev_priv) (INTEL_INFO(dev_priv)->has_decoupled_mmio)
-
#include "i915_trace.h"
static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private
*dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee144ec..78872f9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7792,13 +7792,6 @@ enum {
#define SKL_FUSE_PG1_DIST_STATUS (1<<26)
#define SKL_FUSE_PG2_DIST_STATUS (1<<25)
-/* Decoupled MMIO register pair for kernel driver */
-#define GEN9_DECOUPLED_REG0_DW0_MMIO(0xF00)
-#define GEN9_DECOUPLED_REG0_DW1_MMIO(0xF04)
-#define GEN9_DECOUPLED_DW1_GO (1<<31)
-#define GEN9_DECOUPLED_PD_SHIFT28
-#define GEN9_DECOUPLED_OP_SHIFT24
-
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index a9a6933..3901800 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -400,8 +400,6 @@ check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
static void __intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
bool restore_forcewake)
{
- struct intel_device_info *info = mkwrite_device_info(dev_priv);
-
/* clear out unclaimed reg detection bit */
if (check_for_unclaimed_mmio(dev_priv))
DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
@@ -414,9 +412,6 @@ static void __intel_uncore_early_sanitize(struct
drm_i915_private *dev_priv,
GT_FIFO_CTL_RC6_POLICY_STALL);
}
- if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST))
- info->has_decoupled_mmio = false;
-
intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
}
@@ -801,78 +796,6 @@ unclaimed_reg_debug(struct drm_i915_private *dev_priv,
__unclaimed_reg_debug(dev_priv, reg, read, before);
}
-enum decoupled_power_domain {
- GEN9_DECOUPLED_PD_BLITTER = 0,
- GEN9_DECOUPLED_PD_RENDER,
- GEN9_DECOUPLED_PD_MEDIA,
- GEN9_DECOUPLED_PD_ALL
-};
-
-enum decoupled_ops {
- GEN9_DECOUPLED_OP_WRITE = 0,
- GEN9_DECOUPLED_OP_READ
-};
-
-static const enum decoupled_power_domain fw2dpd_domain[] = {
- GEN9_DECOUPLED_PD_RENDER,
- GEN9_DECOUPLED_PD_BLITTER,
- GEN9_DECOUPLED_PD_ALL,
- GEN9_DECOUPLED_PD_MEDIA,
- GEN9_DECOUPLED_PD_ALL,
- GEN9_DECOUPLED_PD_ALL,
- GEN9_DECOUPLED_PD_ALL
-};
-
-/*
- * Decoupled MMIO access for only 1 DWORD
- */
-static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv,
-u32 reg,
-enum forcewake_domains fw_domain,
-enum decoupled_ops operation)
-{
- enum decoupled_power_domain dp_domain;
- u32 ctrl_reg_data = 0;
-
- dp_domain = fw2dpd_domain[fw_domain - 1];
-
- ctrl_reg_data |= reg;
- ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT);
- ctrl_reg_data |= (dp_domain << GEN9_DECOUPLED_PD_SHIFT);
- ctrl_reg_data |= GEN9_DECOUPLED_DW1_GO;
- __raw_i915_write32(dev_priv, GEN9_DECOUPLED_REG0_DW1, ctrl_reg_data);
-
- if (wait_for_atomic((__raw_i915_read32(dev_priv,
- GEN9_DECOUPLED_REG0_DW1) &
- GEN9_DECOUPLED_DW1_GO) == 0,
- FORCEWAKE_ACK_TIMEOUT_MS))
- DRM_ERROR("Decoupled MMIO wait timed ou
[Intel-gfx] [PATCH 1/2] drm/i915: Disable decoupled MMIO
From: Kai Chen
The decoupled MMIO feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts more difficult, so
let's disable it.
Fixes: 85ee17ebeedd ("drm/i915/bxt: Broxton decoupled MMIO")
Cc: Zhe Wang
Cc: Praveen Paneri
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Kai Chen
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2c..cf43dc1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -385,7 +385,6 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.has_gmbus_irq = 1, \
.has_logical_ring_contexts = 1, \
.has_guc = 1, \
- .has_decoupled_mmio = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/5] drm/i915: Add option to support dynamic backlight via DPCD
Yeah, looks fine to me.
-DK
From: put...@google.com [mailto:put...@google.com] On Behalf Of Puthikorn
Voravootivat
Sent: Friday, May 19, 2017 2:00 PM
To: Pandiyan, Dhinakaran
Cc: put...@chromium.org; dri-de...@lists.freedesktop.org;
intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com
Subject: Re: [Intel-gfx] [PATCH v8 3/5] drm/i915: Add option to support dynamic
backlight via DPCD
Hi Dhinakaran,
Quick question
So what is the update about adding new option in i915_params?
Is this patch good to go after fixing the 2 points you mentioned?
Thanks
On Wed, May 17, 2017 at 1:33 PM, Pandiyan, Dhinakaran
mailto:dhinakaran.pandi...@intel.com>> wrote:
On Tue, 2017-05-16 at 17:34 -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.
>
> Signed-off-by: Puthikorn Voravootivat
> mailto:put...@chromium.org>>
> ---
> drivers/gpu/drm/i915/i915_params.c| 5
> drivers/gpu/drm/i915/i915_params.h| 3 +-
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 40
> +++
> 3 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 13cf3f1572ab..6eaf660e74da 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
> .inject_load_failure = 0,
> .enable_dpcd_backlight = -1,
> .enable_gvt = false,
> + .enable_dbc = false,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
> module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> MODULE_PARM_DESC(enable_gvt,
> "Enable support for Intel GVT-g graphics virtualization host
> support(default:false)");
> +
> +module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
> +MODULE_PARM_DESC(enable_dbc,
> + "Enable support for dynamic backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index ac02efce6e22..2de3e2850b54 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -67,7 +67,8 @@
> func(bool, nuclear_pageflip); \
> func(bool, enable_dp_mst); \
> func(int, enable_dpcd_backlight); \
> - func(bool, enable_gvt)
> + func(bool, enable_gvt); \
> + func(bool, enable_dbc)
>
> #define MEMBER(T, member) T member
> struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 16ba1924308d..c0eeb8fc2013 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -100,10 +100,27 @@ intel_dp_aux_set_backlight(struct intel_connector
> *connector, u32 level)
> }
> }
>
> +/*
> + * Set minimum / maximum dynamic brightness percentage. This value is
> expressed
> + * as the percentage of normal brightness in 5% increments.
> + */
> +static void
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> + dbc, sizeof(dbc) < 0)) {
Incorrect parentheses placement and return value check.
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + }
> +}
> +
> static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
> uint8_t dpcd_buf = 0;
> + uint8_t new_dpcd_buf = 0;
nit: unnecessary initialization.
> uint8_t edp_backlight_mode = 0;
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> @@ -113,18 +130,15 @@ static void intel_dp_aux_enable_backlight(struct
> intel_connector *connector)
> return;
> }
>
> + new_dpcd_buf = dpcd_buf;
> edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
>
> switch (edp_backlight_mode) {
> case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
> case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
> case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
> - dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> - dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> - DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
> - }
> + new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> + new_dpcd_buf |
Re: [Intel-gfx] [CI v2 2/2] drm/i915/guc: Introduce buffer based cmd transport
On Tue, May 23, 2017 at 11:59:46AM -0700, Daniele Ceraolo Spurio wrote:
> On 22/05/17 04:30, Michal Wajdeczko wrote:
> >+static int ctch_init(struct intel_guc *guc,
> >+ struct intel_guc_ct_channel *ctch)
> >+{
> >+struct i915_vma *vma;
> >+void *blob;
> >+int err;
> >+int i;
> >+
> >+GEM_BUG_ON(ctch->vma);
> >+
> >+#if INTEL_GUC_CT_MAX_CHANNELS > 1
>
> Bikeshed: after reviewing the GuC design intent for CT buffers I
> think we can remove the ida logic completely, even if
> INTEL_GUC_CT_MAX_CHANNELS > 1. Currently we don't expect more than 1
> pair, but, if my understanding is correct, in case we ever need more
> than 1 channel the number should be statically determined and not a
> dynamic thing. I would therefore prefer a static define for it.
> e.g.:
>
> #define GUC_KMD_CTCH 0
>
> and if we ever have more:
>
> #define GUC_xxx_CTCH 1
> #define GUC_yyy_CTCH 2
>
> We can then pass in the owner when we open the channel:
>
> ctch_open(guc, ctch, GUC_KMD_CTCH);
If we do forsee that we don't need an ida for the at least the near
future, can we kill it? I'm still dubious about having
INTEL_GUC_CT_MAX_CHANNELS around not tied to any hw/fw concepts or
limits. At the least if you do split the ida into a separate patch, you
can apply it when you need it later.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Silence compiler warning in igt_ctx_exec (rev2)
== Series Details == Series: drm/i915/selftests: Silence compiler warning in igt_ctx_exec (rev2) URL : https://patchwork.freedesktop.org/series/24787/ State : success == Summary == Series 24787v2 drm/i915/selftests: Silence compiler warning in igt_ctx_exec https://patchwork.freedesktop.org/api/1.0/series/24787/revisions/2/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:431s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:442s fi-bdw-5557u failed to collect. IGT log at Patchwork_4790/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4790/fi-bsw-n3050/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4790/fi-bxt-j4205/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4790/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4790/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4790/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4790/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4790/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4790/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4790/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4790/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4790/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4790/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4790/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4790/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4790/fi-snb-2600/igt.log c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h-42m-41s UTC integration manifest 160a9c9 drm/i915/selftests: Silence compiler warning in igt_ctx_exec == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4790/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftests: Silence compiler warning in igt_ctx_exec
The compiler doesn't always spot the guard that object is allocated on
the first pass, leading to:
drivers/gpu/drm/i915/selftests/i915_gem_context.c: warning: 'obj' may be used
uninitialized in this function [-Wuninitialized]: => 370:8
v2: Make it more obvious by setting obj to NULL on the first pass and
any later pass where we need to reallocate.
Reported-by: Geert Uytterhoeven
Fixes: 791ff39ae32a ("drm/i915: Live testing for context execution")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Matthew Auld
c: # v4.12-rc1+
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 1afb8b06e3e1..12b85b3278cd 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -320,7 +320,7 @@ static unsigned long max_dwords(struct drm_i915_gem_object
*obj)
static int igt_ctx_exec(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = NULL;
struct drm_file *file;
IGT_TIMEOUT(end_time);
LIST_HEAD(objects);
@@ -359,7 +359,7 @@ static int igt_ctx_exec(void *arg)
}
for_each_engine(engine, i915, id) {
- if (dw == 0) {
+ if (!obj) {
obj = create_test_object(ctx, file, &objects);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
@@ -376,8 +376,10 @@ static int igt_ctx_exec(void *arg)
goto out_unlock;
}
- if (++dw == max_dwords(obj))
+ if (++dw == max_dwords(obj)) {
+ obj = NULL;
dw = 0;
+ }
ndwords++;
}
ncontexts++;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/67] drm/i915/cnl: DDI - PLL mapping
On Thu, 2017-05-04 at 16:11 +0300, Ville Syrjälä wrote:
> On Thu, May 04, 2017 at 03:02:07PM +0200, Maarten Lankhorst wrote:
> > Op 04-05-17 om 14:44 schreef Ville Syrjälä:
> > > On Thu, May 04, 2017 at 03:35:51PM +0300, Ander Conselvan De Oliveira
> > > wrote:
> > >> On Fri, 2017-04-07 at 18:12 -0300, Paulo Zanoni wrote:
> > >>> Em Qui, 2017-04-06 às 12:15 -0700, Rodrigo Vivi escreveu:
> > One of the steps for PLL (un)initialization is to (un)map
> > the correspondent DDI that is actually using that PLL.
> >
> > So, let's do this step following the places already stablished
> > and used so far, although spec put this as part of PLL
> > initialization sequences.
> >
> > v2: Use proper prefix on bits names as suggested by Ander.
> > v3: Add missed "~". Without that the logic was inverted
> > so we were disabling interrupts.
> > Credits-to: Clinton
> > Credits-to: Art
> > v4: Spec is getting updated to do DDI -> PLL mapping
> > and clock on in 2 separated reg writes. (Paulo)
> > Also update bits definitions to use space
> > (1 << 1) instead of (1<<1). (Paulo)
> >
> > Cc: Paulo Zanoni
> > Cc: Art Runyan
> > Cc: Clint Taylor
> > Cc: Ville Syrjälä
> > Cc: Kahola, Mika
> > Cc: Ander Conselvan De Oliveira > m>
> > Signed-off-by: Rodrigo Vivi
> > Reviewed-by: Kahola, Mika
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 9 +
> > drivers/gpu/drm/i915/intel_ddi.c | 23 ---
> > 2 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3cfc65f..dcb8e21 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8150,6 +8150,15 @@ enum {
> > #define DPLL_CFGCR1(id) _MMIO_PIPE((id) - SKL_DPLL1,
> > _DPLL1_CFGCR1, _DPLL2_CFGCR1)
> > #define DPLL_CFGCR2(id) _MMIO_PIPE((id) - SKL_DPLL1,
> > _DPLL1_CFGCR2, _DPLL2_CFGCR2)
> >
> > +/*
> > + * CNL Clocks
> > + */
> > +#define DPCLKA_CFGCR0 _MMIO(0x6C200)
> > +#define DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port)+10))
> > +#define DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port) (3 <<
> > ((port)*2))
> > +#define DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port)((port)*2)
> > +#define DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port) ((pll) <<
> > ((port)*2))
> > +
> > /* BXT display engine PLL */
> > #define BXT_DE_PLL_CTL_MMIO(0x6d000)
> > #define BXT_DE_PLL_RATIO(x) (x) /*
> > {60,65,100} * 19.2MHz */
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 0914ad9..2a901bf 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1621,13 +1621,27 @@ static void intel_ddi_clk_select(struct
> > intel_encoder *encoder,
> > {
> > struct drm_i915_private *dev_priv = to_i915(encoder-
> > > base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > + uint32_t val;
> >
> > if (WARN_ON(!pll))
> > return;
> >
> > - if (IS_GEN9_BC(dev_priv)) {
> > - uint32_t val;
> > + if (IS_CANNONLAKE(dev_priv)) {
> > + /* Configure DPCLKA_CFGCR0 to map the DPLL to the
> > DDI. */
> > + val = I915_READ(DPCLKA_CFGCR0);
> > + val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->id, port);
> > + I915_WRITE(DPCLKA_CFGCR0, val);
> > >>> A question to the Atomic Lords: don't we need some sort of locking
> > >>> around this register since it's used by all ports/clocks? I suppose
> > >>> dev_priv->dpll_lock would do...
> > >>>
> > >>> Maybe the same would apply for gen9_bc.
> > >> If there are modesets happening in parallel for different crtcs, then
> > >> some
> > >> locking is needed. dpll_lock seems like the right call, that's what's
> > >> used to
> > >> avoid the same problem with the enable/disable hooks.
> > > If something is allowing modesets to commit in parallel then probably
> > > the whole world is on fire. Historically connection_mutex has been there
> > > to protect us, but not sure how that goes with nonblocking commits. I
> > > do hope there's still something there to prevents this...
> >
> > During nonblocking modesets we don't hold any locks. It's still possible
> > that we force serialization through some other means, for example grabbing
> > all crtc_states might force serialization previously. But I'm not sure this
> > is guaranteed to happen even for SKL. It might happen for when DDB
> > allocation
[Intel-gfx] ✓ Fi.CI.BAT: success for SKL render decompression support
== Series Details == Series: SKL render decompression support URL : https://patchwork.freedesktop.org/series/24838/ State : success == Summary == Series 24838v1 SKL render decompression support https://patchwork.freedesktop.org/api/1.0/series/24838/revisions/1/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:433s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-bdw-5557u failed to collect. IGT log at Patchwork_4789/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4789/fi-bsw-n3050/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4789/fi-byt-n2820/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4789/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4789/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4789/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4789/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4789/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4789/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4789/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4789/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4789/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4789/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4789/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4789/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4789/fi-snb-2600/igt.log c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h-42m-41s UTC integration manifest eb9a614 drm/i915: Implement .get_format_info() hook for CCS f4fc298 drm: Add explict alignment for formats == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4789/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnp: Backlight support for CNP.
On Thu, 2017-05-04 at 12:24 +0300, Jani Nikula wrote:
> On Wed, 03 May 2017, Anusha Srivatsa wrote:
> > From: Rodrigo Vivi
> >
> > Split out BXT and CNP's setup_backlight(),enable_backlight(),
> > disable_backlight() and hz_to_pwm() into
> > two separate functions instead of reusing BXT function.
> >
> > Reuse set_backlight() and get_backlight() since they have
> > no reference to the utility pin.
> >
> > v2: Reuse BXT functions with controller 0 instead of
> > redefining it. (Jani).
> > Use dev_priv->rawclk_freq instead of getting the value
> > from SFUSE_STRAP.
> > v3: Avoid setup backligh controller along with hooks and
> > fully reuse hooks setup as suggested by Jani.
> > v4: Clean up commit message.
> > v5: Implement per PCH instead per platform.
> >
> > v6: Introduce a new function for CNP.(Jani and Ville)
> >
> > v7: Squash the all CNP Backlight support patches into a
> > single patch. (Jani)
> >
> > v8: Correct indentation, remove unneeded blank lines and
> > correct mail address (Jani).
> >
> > Reviewed-by: Jani Nikula
>
> Yup. What's the plan for merging the series, incl. this patch?
I will:
1. rebase all patches here with cnp - cfl - cnl
2. fix that patch with proper gmbus pin table.
3. provide the workaround on vbt parsing as ville had suggested.
4. re-test on the platforms here.
5. Resubmit only first patches that would be ready for merging already
and start merging those, and continue subminting in small chunks.
So, Jani, could you please review already this
one:https://patchwork.freedesktop.org/patch/155177/
Thanks a lot,
Rodrigo.
> BR,
> Jani.
>
>
> > Suggested-by: Jani Nikula
> > Suggested-by: Ville Syrjala
> > Cc: Ville Syrjala
> > Cc: Jani Nikula
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_panel.c | 88
> > +++---
> > 1 file changed, 83 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index 1978bec..8ee61c1 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct
> > intel_connector *connector)
> > }
> > }
> >
> > +static void cnp_disable_backlight(struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_panel *panel = &connector->panel;
> > + u32 tmp, val;
> > +
> > + intel_panel_actually_set_backlight(connector, 0);
> > +
> > + tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> > + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> > + tmp & ~BXT_BLC_PWM_ENABLE);
> > +}
> > +
> > static void pwm_disable_backlight(struct intel_connector *connector)
> > {
> > struct intel_panel *panel = &connector->panel;
> > @@ -1076,6 +1089,36 @@ static void bxt_enable_backlight(struct
> > intel_connector *connector)
> > pwm_ctl | BXT_BLC_PWM_ENABLE);
> > }
> >
> > +static void cnp_enable_backlight(struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_panel *panel = &connector->panel;
> > + enum pipe pipe = intel_get_pipe_from_connector(connector);
> > + u32 pwm_ctl, val;
> > +
> > + pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> > + if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
> > + DRM_DEBUG_KMS("backlight already enabled\n");
> > + pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
> > + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> > + pwm_ctl);
> > + }
> > +
> > + I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
> > + panel->backlight.max);
> > +
> > + intel_panel_actually_set_backlight(connector, panel->backlight.level);
> > +
> > + pwm_ctl = 0;
> > + if (panel->backlight.active_low_pwm)
> > + pwm_ctl |= BXT_BLC_PWM_POLARITY;
> > +
> > + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
> > + POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
> > + I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
> > + pwm_ctl | BXT_BLC_PWM_ENABLE);
> > +}
> > +
> > static void pwm_enable_backlight(struct intel_connector *connector)
> > {
> > struct intel_panel *panel = &connector->panel;
> > @@ -1645,6 +1688,37 @@ bxt_setup_backlight(struct intel_connector
> > *connector, enum pipe unused)
> > return 0;
> > }
> >
> > +static int
> > +cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_panel *panel = &connector->panel;
> > + u32 pwm_ctl, val;
> > +
> > + panel->backlight.controller = dev_priv->vbt.backlight.controller;
> > +
> > + pwm_ctl = I915_READ(BXT_BLC_PWM_C
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2)
== Series Details == Series: drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2) URL : https://patchwork.freedesktop.org/series/17737/ State : success == Summary == Series 17737v2 drm/i915/psr: disable psr2 for resolution greater than 32X20 https://patchwork.freedesktop.org/api/1.0/series/17737/revisions/2/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-bdw-5557u failed to collect. IGT log at Patchwork_4788/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4788/fi-bsw-n3050/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4788/fi-bxt-j4205/igt.log fi-byt-j1900 failed to collect. IGT log at Patchwork_4788/fi-byt-j1900/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4788/fi-byt-n2820/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4788/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4788/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4788/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4788/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4788/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4788/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4788/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4788/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4788/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4788/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4788/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4788/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4788/fi-snb-2600/igt.log c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h-42m-41s UTC integration manifest a293db4 drm/i915/psr: disable psr2 for resolution greater than 32X20 == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4788/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support
On Tue, 2017-05-09 at 12:16 -0700, Anusha Srivatsa wrote:
> From: Rodrigo Vivi
>
> On CNP PCH based platforms the gmbus is on the south display that
> is on PCH. The existing implementation for previous platforms
> already covers the need for CNP expect for the pin pair configuration
> that follows similar definitions that we had on BXT.
>
> v2: Don't drop "_BXT" as the indicator of the first platform
> supporting this pin numbers. Suggested by Daniel.
> v3: Add missing else and fix register table since CNP GPIO_CTL
> starts on 0xC5014.
> v4: Fix pin number and map according to the current available VBT.
> Re-add pin 4 for port D. Lost during some rebase.
> v5: rebased.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Anusha Srivatsa
Thank you a lot for all the work on these patches.
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> drivers/gpu/drm/i915/intel_hdmi.c | 8 +---
> drivers/gpu/drm/i915/intel_i2c.c | 20 ++--
> 3 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9310d43..18fc7d3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
> #define GMBUS_PIN_DPB 5 /* SDVO, HDMIB */
> #define GMBUS_PIN_DPD 6 /* HDMID */
> #define GMBUS_PIN_RESERVED 7 /* 7 reserved */
> -#define GMBUS_PIN_1_BXT1
> +#define GMBUS_PIN_1_BXT1 /* BXT+ (atom) and CNP+ (big core) */
> #define GMBUS_PIN_2_BXT2
> #define GMBUS_PIN_3_BXT3
> +#define GMBUS_PIN_4_CNP4
> #define GMBUS_NUM_PINS 7 /* including 0 */
> #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base +
> 0x5104) /* command/status */
> #define GMBUS_SW_CLR_INT (1<<31)
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 58d6903..2789681 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1885,19 +1885,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private
> *dev_priv,
>
> switch (port) {
> case PORT_B:
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> ddc_pin = GMBUS_PIN_1_BXT;
> else
> ddc_pin = GMBUS_PIN_DPB;
> break;
> case PORT_C:
> - if (IS_GEN9_LP(dev_priv))
> + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
> ddc_pin = GMBUS_PIN_2_BXT;
> else
> ddc_pin = GMBUS_PIN_DPC;
> break;
> case PORT_D:
> - if (IS_CHERRYVIEW(dev_priv))
> + if (HAS_PCH_CNP(dev_priv))
> + ddc_pin = GMBUS_PIN_4_CNP;
> + else if (IS_CHERRYVIEW(dev_priv))
> ddc_pin = GMBUS_PIN_DPD_CHV;
> else
> ddc_pin = GMBUS_PIN_DPD;
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index b6401e8..3eb4a91 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -68,11 +68,25 @@ static const struct gmbus_pin gmbus_pins_bxt[] = {
> [GMBUS_PIN_3_BXT] = { "misc", GPIOD },
> };
>
> +/*
> + * FIXME: Spec maps 3-misc-0xc541c and 4-portd-0xc5420.
> + * However, current available pre-prod VBT maps:
> + * portD to pin 3 using 0xc5420.
> + */
We cannot use this patch since it would break CFL.
We need to add the spec table and workaround the vbt parsing on cnl for
now.
I will send new version soon.
> +static const struct gmbus_pin gmbus_pins_cnp[] = {
> + [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
> + [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
> + [GMBUS_PIN_3_BXT] = { "misc", GPIOE },
> + [GMBUS_PIN_4_CNP] = { "dpd", GPIOD },
> +};
> +
> /* pin is expected to be valid */
> static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private
> *dev_priv,
>unsigned int pin)
> {
> - if (IS_GEN9_LP(dev_priv))
> + if (HAS_PCH_CNP(dev_priv))
> + return &gmbus_pins_cnp[pin];
> + else if (IS_GEN9_LP(dev_priv))
> return &gmbus_pins_bxt[pin];
> else if (IS_GEN9_BC(dev_priv))
> return &gmbus_pins_skl[pin];
> @@ -87,7 +101,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private
> *dev_priv,
> {
> unsigned int size;
>
> - if (IS_GEN9_LP(dev_priv))
> + if (HAS_PCH_CNP(dev_priv))
> + size = ARRAY_SIZE(gmbus_pins_cnp);
> + else if (IS_GEN9_LP(dev_priv))
> size = ARRAY_SIZE(gmbus_pins_bxt);
> else if (IS_GEN9_BC(dev_priv))
> size = ARRAY_SIZE(gmbus_pins_skl);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
Re: [Intel-gfx] [PATCH v5 4/5] drm/i915/gvt: Dmabuf support for GVT-g
On Tue, 23 May 2017 18:32:00 +0800
Xiaoguang Chen wrote:
> dmabuf for GVT-g can be exported to users who can use the dmabuf to show
> the desktop of vm which use intel vgpu.
>
> Currently we provide query and create new dmabuf operations.
>
> Users of dmabuf can cache some created dmabufs and related information
> such as the framebuffer's address, size, tiling mode, width, height etc.
> When refresh the screen first query the currnet vgpu's frambuffer and
> compare with the cached ones(address, size, tiling, width, height etc)
> if found one then reuse the found dmabuf to gain performance improvment.
>
> If there is no dmabuf created yet or not found in the cached dmabufs then
> need to create a new dmabuf. To create a dmabuf first a gem object will
> be created and the backing storage of this gem object is the vgpu's
> framebuffer(primary/cursor).
> Set caching mode, change tiling mode and set domains of this gem object
> is not supported.
> Then associate this gem object to a dmabuf and export this dmabuf.
> A file descriptor will be generated for this dmabuf and this file
> descriptor can be sent to user space to do display.
>
> Signed-off-by: Xiaoguang Chen
> ---
> drivers/gpu/drm/i915/gvt/Makefile | 2 +-
> drivers/gpu/drm/i915/gvt/dmabuf.c | 276
> +
> drivers/gpu/drm/i915/gvt/dmabuf.h | 53 +++
> drivers/gpu/drm/i915/gvt/gvt.h | 1 +
> drivers/gpu/drm/i915/i915_gem.c| 8 +
> drivers/gpu/drm/i915/i915_gem_object.h | 9 ++
> 6 files changed, 348 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
> create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
>
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> b/drivers/gpu/drm/i915/gvt/Makefile
> index 192ca26..e480f7d 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -2,7 +2,7 @@ GVT_DIR := gvt
> GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o
> firmware.o \
> interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
> - fb_decoder.o
> + fb_decoder.o dmabuf.o
>
> ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) -Wall
> i915-y += $(addprefix $(GVT_DIR)/,
> $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> new file mode 100644
> index 000..415453b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -0,0 +1,276 @@
> +/*
> + * Copyright 2017 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + *Zhiyuan Lv
> + *
> + * Contributors:
> + *Xiaoguang Chen
> + */
> +
> +#include
> +#include
> +
> +#include "i915_drv.h"
> +#include "gvt.h"
> +
> +#define GEN8_DECODE_PTE(pte) \
> + ((dma_addr_t)(u64)pte) >> 12) & 0x7ffULL) << 12))
> +
> +static struct sg_table *intel_vgpu_gem_get_pages(
> + struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> + struct sg_table *st;
> + struct scatterlist *sg;
> + int i, ret;
> + gen8_pte_t __iomem *gtt_entries;
> + unsigned int fb_gma = 0, fb_size = 0;
> + struct intel_vgpu_plane_info *plane_info;
> +
> + plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
I can't find where gvt_plane_info is defined, but it's curious why it's
not already this type.
> + if (WARN_ON(!plane_info))
> + return ERR_PTR(-EINVAL);
> +
> + fb_gma = plane_info->start;
> + fb_size = plane_info->size;
> +
> + st = kmalloc(sizeof(*st), GFP_KERNEL);
> + if (!st) {
> + ret = -ENOMEM;
> + return ERR_PTR(ret);
> +
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf
On Tue, 23 May 2017 18:32:01 +0800
Xiaoguang Chen wrote:
> User space will try to create a management fd for the dma-buf operation.
> Using this management fd user can query the plane information and create
> a dma-buf fd if necessary.
> GVT-g will handle the life cycle of the management fd and will align the
> life cycle of the fd with the vfio device.
> User space should handle the life cycle of the created dma-buf fd close
> the dma-buf fd timely when finishing use.
The user cannot be expected to do this, each dmabuf fd also needs to
take a reference to the vfio device. You'll need to find a way to hook
into the dmabuf release function.
> Signed-off-by: Xiaoguang Chen
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 25
> drivers/gpu/drm/i915/gvt/dmabuf.h | 21 ---
> drivers/gpu/drm/i915/gvt/fb_decoder.h | 2 -
> drivers/gpu/drm/i915/gvt/gvt.c| 2 +
> drivers/gpu/drm/i915/gvt/gvt.h| 4 ++
> drivers/gpu/drm/i915/gvt/kvmgt.c | 107
> ++
> include/uapi/linux/vfio.h | 50 +++-
> 7 files changed, 175 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 415453b..a72b86efb 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "gvt.h"
> @@ -45,9 +46,9 @@ static struct sg_table *intel_vgpu_gem_get_pages(
> int i, ret;
> gen8_pte_t __iomem *gtt_entries;
> unsigned int fb_gma = 0, fb_size = 0;
> - struct intel_vgpu_plane_info *plane_info;
> + struct plane_info *plane_info;
>
> - plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
> + plane_info = (struct plane_info *)obj->gvt_plane_info;
> if (WARN_ON(!plane_info))
> return ERR_PTR(-EINVAL);
>
> @@ -81,9 +82,9 @@ static struct sg_table *intel_vgpu_gem_get_pages(
> static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
> struct sg_table *pages)
> {
> - struct intel_vgpu_plane_info *plane_info;
> + struct plane_info *plane_info;
>
> - plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
> + plane_info = (struct plane_info *)obj->gvt_plane_info;
> if (WARN_ON(!plane_info))
> return;
>
> @@ -98,7 +99,7 @@ static const struct drm_i915_gem_object_ops
> intel_vgpu_gem_ops = {
> };
>
> static struct drm_i915_gem_object *intel_vgpu_create_gem(struct drm_device
> *dev,
> - struct intel_vgpu_plane_info *info)
> + struct plane_info *info)
> {
> struct drm_i915_private *pri = dev->dev_private;
> struct drm_i915_gem_object *obj;
> @@ -141,14 +142,14 @@ static struct drm_i915_gem_object
> *intel_vgpu_create_gem(struct drm_device *dev,
> return obj;
> }
>
> -static struct intel_vgpu_plane_info *intel_vgpu_get_plane_info(
> +static struct plane_info *intel_vgpu_get_plane_info(
> struct drm_device *dev,
> struct intel_vgpu *vgpu, uint32_t plane_id)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_vgpu_primary_plane_format *p;
> struct intel_vgpu_cursor_plane_format *c;
> - struct intel_vgpu_plane_info *info;
> + struct plane_info *info;
> struct intel_vgpu_pipe_format *pipe;
>
> info = kmalloc(sizeof(*info), GFP_KERNEL);
> @@ -159,7 +160,7 @@ static struct intel_vgpu_plane_info
> *intel_vgpu_get_plane_info(
> if (pipe == NULL)
> return NULL;
>
> - if (plane_id == INTEL_GVT_PLANE_PRIMARY) {
> + if (plane_id == VFIO_PRIMARY_PLANE) {
> p = &pipe->primary;
> if (p != NULL) {
> info->start = p->base;
> @@ -175,7 +176,7 @@ static struct intel_vgpu_plane_info
> *intel_vgpu_get_plane_info(
> gvt_vgpu_err("invalid primary plane\n");
> return NULL;
> }
> - } else if (plane_id == INTEL_GVT_PLANE_CURSOR) {
> + } else if (plane_id == VFIO_CURSOR_PLANE) {
> c = &pipe->cursor;
> if (c != NULL) {
> info->start = c->base;
> @@ -228,7 +229,7 @@ static struct intel_vgpu_plane_info
> *intel_vgpu_get_plane_info(
> int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args)
> {
> struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
> - struct intel_vgpu_plane_info *info = args;
> + struct plane_info *info = args;
>
> info = intel_vgpu_get_plane_info(dev, vgpu, info->plane_id);
> if (info == NULL)
> @@ -242,8 +243,8 @@ int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu,
> void *args)
> struct dma_buf *dmabuf;
> struct drm_i915_gem_object *obj;
> struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
> - struct intel_vgpu_dmabuf *gvt_d
Re: [Intel-gfx] [PATCH 39/67] drm/i915/cnl: Implement voltage swing sequence.
On Wed, 2017-05-17 at 18:13 -0700, Manasi Navare wrote:
> On Thu, Apr 06, 2017 at 12:15:35PM -0700, Rodrigo Vivi wrote:
> > This is an important part of the DDI initalization as well as
> > for changing the voltage during DisplayPort link training.
> >
> > This new sequence for Cannonlake is more like Broxton style
> > but still with different registers, different table and
> > different steps.
> >
> > v2: Do not write to DW4_GRP to avoid overwrite individual loadgen.
> > Fix PORT_CL_DW5 SUS Clock Config set.
> > v3: As previous platforms use only eDP table if low voltage was
> > requested.
> > v4: fix Werror:maybe uninitialized (Paulo)
> > v5: Rebase on top of dw2_swing_sel changes
> > on previous patches.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_ddi.c | 176
> > ++-
> > drivers/gpu/drm/i915/intel_dp.c | 2 +-
> > 3 files changed, 177 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index d4f7460..55ffec7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1663,6 +1663,7 @@ enum skl_disp_power_wells {
> >
> > #define CNL_PORT_CL1CM_DW5 _MMIO(0x162014)
> > #define CL_POWER_DOWN_ENABLE (1 << 4)
> > +#define SUS_CLOCK_CONFIG (3 << 0)
> >
> > #define _PORT_CL1CM_DW9_A 0x162024
> > #define _PORT_CL1CM_DW9_BC 0x6C024
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 3c31a22..a4d7061 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1720,6 +1720,173 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
> > *encoder)
> > DP_TRAIN_VOLTAGE_SWING_MASK;
> > }
> >
> > +static const struct cnl_ddi_buf_trans *
> > +cnl_get_buf_trans_hdmi(struct drm_i915_private *dev_priv,
> > + u32 voltage, int *n_entries)
> > +{
> > + if (voltage == VOLTAGE_INFO_0_85V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_85V);
> > + return cnl_ddi_translations_hdmi_0_85V;
> > + } else if (voltage == VOLTAGE_INFO_0_95V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_0_95V);
> > + return cnl_ddi_translations_hdmi_0_95V;
> > + } else if (voltage == VOLTAGE_INFO_1_05V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_hdmi_1_05V);
> > + return cnl_ddi_translations_hdmi_1_05V;
> > + }
> > + return NULL;
> > +}
> > +
> > +static const struct cnl_ddi_buf_trans *
> > +cnl_get_buf_trans_dp(struct drm_i915_private *dev_priv,
> > +u32 voltage, int *n_entries)
> > +{
> > + if (voltage == VOLTAGE_INFO_0_85V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_85V);
> > + return cnl_ddi_translations_dp_0_85V;
> > + } else if (voltage == VOLTAGE_INFO_0_95V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_0_95V);
> > + return cnl_ddi_translations_dp_0_95V;
> > + } else if (voltage == VOLTAGE_INFO_1_05V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_dp_1_05V);
> > + return cnl_ddi_translations_dp_1_05V;
> > + }
> > + return NULL;
> > +}
> > +
> > +static const struct cnl_ddi_buf_trans *
> > +cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
> > + u32 voltage, int *n_entries)
> > +{
> > + if (dev_priv->vbt.edp.low_vswing) {
> > + if (voltage == VOLTAGE_INFO_0_85V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_85V);
> > + return cnl_ddi_translations_dp_0_85V;
> > + } else if (voltage == VOLTAGE_INFO_0_95V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_0_95V);
> > + return cnl_ddi_translations_edp_0_95V;
> > + } else if (voltage == VOLTAGE_INFO_1_05V) {
> > + *n_entries = ARRAY_SIZE(cnl_ddi_translations_edp_1_05V);
> > + return cnl_ddi_translations_edp_1_05V;
> > + }
> > + return NULL;
> > + } else {
> > + return cnl_get_buf_trans_dp(dev_priv, voltage, n_entries);
> > + }
> > +}
> > +
> > +static void cnl_ddi_vswing_program(struct drm_i915_private *dev_priv,
> > + u32 level, enum port port, int type)
> > +{
> > + const struct cnl_ddi_buf_trans *ddi_translations = NULL;
> > + u32 n_entries, val, voltage;
> > + int ln;
> > +
> > + /*
> > +* Values for each port type are listed in
> > +* voltage swing programming tables.
> > +* Vccio voltage found in PORT_COMP_DW3.
> > +*/
> > + voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> > +
> > + if (type == INTEL_OUTPUT_HDMI) {
> > + ddi_translations = cnl_get_b
Re: [Intel-gfx] [PATCH 37/67] drm/i915/cnl: Add registers related to voltage swing sequences.
On Wed, 2017-05-17 at 17:59 -0700, Manasi Navare wrote:
> On Thu, Apr 06, 2017 at 12:15:33PM -0700, Rodrigo Vivi wrote:
> > This are the registers and bits needed for the voltage swing
> > sequence on Cannonlake.
> >
> > v2: Remove CL_DW5 that was wrongly defined.
> > v3: Use (1 << 1) instead of (1<<1) as Paulo suggested
> > Change DW2 swing sel upper and lower macros to do the
> > bit selection instead of definint a table that doesn't
> > match the spec. It is based on a Manasi version of it.
> > Credits-to: Manasi.
> >
> > Cc: Paulo Zanoni
> > Cc: Manasi Navare
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 140
> >
> > 1 file changed, 140 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 5777925..d4f7460 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1688,6 +1688,146 @@ enum skl_disp_power_wells {
> > #define OCL2_LDOFUSE_PWR_DIS (1 << 6)
> > #define BXT_PORT_CL1CM_DW30(phy) _BXT_PHY((phy), _PORT_CL1CM_DW30_BC)
> >
> > +#define _CNL_PORT_PCS_DW1_GRP_AE 0x162304
> > +#define _CNL_PORT_PCS_DW1_GRP_B0x162384
> > +#define _CNL_PORT_PCS_DW1_GRP_C0x162B04
> > +#define _CNL_PORT_PCS_DW1_GRP_D0x162B84
> > +#define _CNL_PORT_PCS_DW1_GRP_F0x162A04
> > +#define _CNL_PORT_PCS_DW1_LN0_AE 0x162404
> > +#define _CNL_PORT_PCS_DW1_LN0_B0x162604
> > +#define _CNL_PORT_PCS_DW1_LN0_C0x162C04
> > +#define _CNL_PORT_PCS_DW1_LN0_D0x162E04
> > +#define _CNL_PORT_PCS_DW1_LN0_F0x162804
> > +#define CNL_PORT_PCS_DW1_GRP(port) _MMIO_PORT6(port, \
> > + _CNL_PORT_PCS_DW1_GRP_AE, \
> > + _CNL_PORT_PCS_DW1_GRP_B, \
> > + _CNL_PORT_PCS_DW1_GRP_C, \
> > + _CNL_PORT_PCS_DW1_GRP_D, \
> > + _CNL_PORT_PCS_DW1_GRP_AE, \
> > + _CNL_PORT_PCS_DW1_GRP_F)
> > +#define CNL_PORT_PCS_DW1_LN0(port) _MMIO_PORT6(port, \
> > + _CNL_PORT_PCS_DW1_LN0_AE, \
> > + _CNL_PORT_PCS_DW1_LN0_B, \
> > + _CNL_PORT_PCS_DW1_LN0_C, \
> > + _CNL_PORT_PCS_DW1_LN0_D, \
> > + _CNL_PORT_PCS_DW1_LN0_AE, \
> > + _CNL_PORT_PCS_DW1_LN0_F)
> > +#define COMMON_KEEPER_EN (1 << 26)
> > +
> > +#define _CNL_PORT_TX_DW2_GRP_AE0x162348
> > +#define _CNL_PORT_TX_DW2_GRP_B 0x1623C8
> > +#define _CNL_PORT_TX_DW2_GRP_C 0x162B48
> > +#define _CNL_PORT_TX_DW2_GRP_D 0x162BC8
> > +#define _CNL_PORT_TX_DW2_GRP_F 0x162A48
> > +#define _CNL_PORT_TX_DW2_LN0_AE0x162448
> > +#define _CNL_PORT_TX_DW2_LN0_B 0x162648
> > +#define _CNL_PORT_TX_DW2_LN0_C 0x162C48
> > +#define _CNL_PORT_TX_DW2_LN0_D 0x162E48
> > +#define _CNL_PORT_TX_DW2_LN0_F 0x162A48
> > +#define CNL_PORT_TX_DW2_GRP(port) _MMIO_PORT6(port, \
> > + _CNL_PORT_TX_DW2_GRP_AE, \
> > + _CNL_PORT_TX_DW2_GRP_B, \
> > + _CNL_PORT_TX_DW2_GRP_C, \
> > + _CNL_PORT_TX_DW2_GRP_D, \
> > + _CNL_PORT_TX_DW2_GRP_AE, \
> > + _CNL_PORT_TX_DW2_GRP_F)
> > +#define CNL_PORT_TX_DW2_LN0(port) _MMIO_PORT6(port, \
> > + _CNL_PORT_TX_DW2_LN0_AE, \
> > + _CNL_PORT_TX_DW2_LN0_B, \
> > + _CNL_PORT_TX_DW2_LN0_C, \
> > + _CNL_PORT_TX_DW2_LN0_D, \
> > + _CNL_PORT_TX_DW2_LN0_AE, \
> > + _CNL_PORT_TX_DW2_LN0_F)
> > +#define SWING_SEL_UPPER(x) ((x >> 3) << 15)
> > +#define SWING_SEL_LOWER(x) ((x & 0x7) << 11)
> > +#define RCOMP_SCALAR(x) ((x) << 0)
> > +
> > +#define _CNL_PORT_TX_DW4_GRP_AE0x162350
> > +#define _CNL_PORT_TX_DW4_GRP_B 0x1623D0
> > +#define _CNL_PORT_TX_DW4_GRP_C 0x162B50
> > +#define _CNL_PORT_TX_DW4_GRP_D 0x162BD0
> > +#define _CNL_PORT_TX_DW4_GRP_F 0x162A50
> > +#define _CNL_PORT_TX_DW4_LN0_AE0x162450
Re: [Intel-gfx] [PATCH 36/67] drm/i915: Add MMIO helper for 6 ports with different offsets.
On Wed, May 17, 2017 at 12:20 PM, Manasi Navare wrote: > On Thu, Apr 06, 2017 at 12:15:32PM -0700, Rodrigo Vivi wrote: >> Also new registers can have different mmio offsets >> per different lane per port. >> >> v2: Use _PICK as PORT3 instead of creating a new >> macro with if per port. >> >> Signed-off-by: Rodrigo Vivi >> --- >> drivers/gpu/drm/i915/i915_reg.h | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index c38c1fd..5777925 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -64,6 +64,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) >> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PIPE3(pipe, a, b, c)) >> #define _PORT3(port, ...) _PICK(port, __VA_ARGS__) >> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PORT3(pipe, a, b, c)) >> +#define _PORT6(port, ...) _PICK(port, __VA_ARGS__) > > Why do we need to define _PORT6() as a separate macro when all it has to do > is _PICK between given ports so we can jsut use _PORT3 and it will pick > amongst the > _VA_ARGS_. It was just my OCD refusing to use "3" for "6"... Any idea for a better generic name for the PORT3? > > Jani/Ville am I correct? > > Manasi >> +#define _MMIO_PORT6(port, a, b, c, d, e, f) _MMIO(_PORT6(port, a, b, c, d, >> e, f)) >> +#define _MMIO_PORT6_LN(port, ln, a0, a1, b, c, d, e, f) >> \ >> + _MMIO(_PORT6(port, a0, b, c, d, e, f) + (ln * (a1 - a0))) >> #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) >> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) >> >> -- >> 1.9.1 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr: Clean-up intel_enable_source_psr1()
On Fri, May 5, 2017 at 2:02 PM, Jim Bride wrote:
> On SKL+ there is a bit in SRD_CTL that software is not supposed to
> modify, but we currently clobber that bit when we enable PSR. In
> order to preserve the value of that bit, go ahead and read SRD_CTL and
> do a field-wise setting of the various bits that we need to initialize
> before writing the register back out. Additionally, go ahead and
> explicitly disable single-frame update since we aren't currently
> supporting it.
>
> v2: Do a field-wise init on EDP_PSR_MAX_SLEEP_TIME even though we
> always set it to the max value. (Rodrigo)
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Wayne Boyer
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_psr.c | 21 +++--
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index ee8170c..3a63555 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3584,18 +3584,22 @@ enum {
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
> +#define EDP_PSR_MAX_SLEEP_TIME_MASK (0x1f<<20)
> #define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
> #define EDP_PSR_SKIP_AUX_EXIT(1<<12)
> #define EDP_PSR_TP1_TP2_SEL (0<<11)
> #define EDP_PSR_TP1_TP3_SEL (1<<11)
> +#define EDP_PSR_TP2_TP3_TIME_MASK (3<<8)
> #define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
> #define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
> #define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
> #define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
> +#define EDP_PSR_TP1_TIME_MASK (0x3<<4)
> #define EDP_PSR_TP1_TIME_500us (0<<4)
> #define EDP_PSR_TP1_TIME_100us (1<<4)
> #define EDP_PSR_TP1_TIME_2500us (2<<4)
> #define EDP_PSR_TP1_TIME_0us (3<<4)
> +#define EDP_PSR_IDLE_FRAME_MASK (0xf<<0)
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> #define EDP_PSR_AUX_CTL
> _MMIO(dev_priv->psr_mmio_base + 0x10)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3780d0..068c382 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -280,17 +280,32 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> * with the 5 or 6 idle patterns.
> */
> uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - uint32_t val = EDP_PSR_ENABLE;
> + uint32_t val = I915_READ(EDP_PSR_CTL);
>
> + val |= EDP_PSR_ENABLE;
> +
> + val &= ~EDP_PSR_MAX_SLEEP_TIME_MASK;
> val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> +
> + val &= ~EDP_PSR_IDLE_FRAME_MASK;
> val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>
> + val &= ~EDP_PSR_MIN_LINK_ENTRY_TIME_MASK;
> if (IS_HASWELL(dev_priv))
> val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>
> - if (dev_priv->psr.link_standby)
> + if (dev_priv->psr.link_standby) {
> val |= EDP_PSR_LINK_STANDBY;
>
> + /* SFU should only be enabled with link standby, but for
> +* now we do not support it. */
/* goes to next line
> + val &= ~BDW_PSR_SINGLE_FRAME;
> + } else {
> + val &= ~EDP_PSR_LINK_STANDBY;
> + val &= ~BDW_PSR_SINGLE_FRAME;
probably better to do this out of the if to avoid duplication. Comment above
already explain it well.
with these feel free to use:
Reviewed-by: Rodrigo Vivi
> + }
> +
> + val &= ~EDP_PSR_TP1_TIME_MASK;
> if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
> val |= EDP_PSR_TP1_TIME_2500us;
> else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
> @@ -300,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP1_TIME_0us;
>
> + val &= ~EDP_PSR_TP2_TP3_TIME_MASK;
> if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> val |= EDP_PSR_TP2_TP3_TIME_2500us;
> else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
> @@ -309,6 +325,7 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP2_TP3_TIME_0us;
>
> + val &= ~EDP_PSR_TP1_TP3_SEL;
> if (intel_dp_source_supports_hbr2(intel_dp) &&
> drm_dp_tps3_supported(intel_dp->dpcd))
> val |= EDP_PSR_TP1_TP3_SEL;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI v2 2/2] drm/i915/guc: Introduce buffer based cmd transport
On 22/05/17 04:30, Michal Wajdeczko wrote:
Buffer based command transport can replace MMIO based mechanism.
It may be used to perform host-2-guc and guc-to-host communication.
Portions of this patch are based on work by:
Michel Thierry
Robert Beckett
Daniele Ceraolo Spurio
v2: use gem_object_pin_map (Chris)
don't use DEBUG_RATELIMITED (Chris)
don't track action stats (Chris)
simplify next fence (Chris)
use READ_ONCE (Chris)
move blob allocation to new function (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Oscar Mateo
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_guc_ct.c | 468 ++
drivers/gpu/drm/i915/intel_guc_ct.h | 97 +++
drivers/gpu/drm/i915/intel_guc_fwif.h | 44
drivers/gpu/drm/i915/intel_uc.c | 25 +-
drivers/gpu/drm/i915/intel_uc.h | 4 +-
8 files changed, 641 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.c
create mode 100644 drivers/gpu/drm/i915/intel_guc_ct.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7b05fb8..16dccf5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -58,6 +58,7 @@ i915-y += i915_cmd_parser.o \
# general-purpose microcontroller (GuC) support
i915-y += intel_uc.o \
+ intel_guc_ct.o \
intel_guc_log.o \
intel_guc_loader.o \
intel_huc.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d703897..6c78469 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -869,6 +869,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
i915_workqueues_cleanup(dev_priv);
err_engines:
i915_engines_cleanup(dev_priv);
+ intel_uc_cleanup(dev_priv);
return ret;
}
@@ -883,6 +884,7 @@ static void i915_driver_cleanup_early(struct
drm_i915_private *dev_priv)
intel_irq_fini(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
+ intel_uc_cleanup(dev_priv);
}
static int i915_mmio_setup(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 17883a8..453eea5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -760,6 +760,7 @@ struct intel_csr {
func(has_gmbus_irq); \
func(has_gmch_display); \
func(has_guc); \
+ func(has_guc_ct); \
func(has_hotplug); \
func(has_l3_dpf); \
func(has_llc); \
@@ -2947,6 +2948,7 @@ intel_info(const struct drm_i915_private *dev_priv)
* properties, so we have separate macros to test them.
*/
#define HAS_GUC(dev_priv) ((dev_priv)->info.has_guc)
+#define HAS_GUC_CT(dev_priv) ((dev_priv)->info.has_guc_ct)
#define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
#define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c
b/drivers/gpu/drm/i915/intel_guc_ct.c
new file mode 100644
index 000..869a7ad
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -0,0 +1,468 @@
+/*
+ * Copyright © 2016-2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "i915_drv.h"
+#include "intel_guc_ct.h"
+
+enum { CTB_SEND = 0, CTB_RECV = 1 };
+
+static inline const char *guc_ct_buffer_type_to_str(u32 type)
+{
+ switch (type) {
+ case INTEL_GUC_CT_BUFFER_TYPE_SEND:
+ return "SEND";
+ case INTEL_GUC_CT_BUFFER_TYPE_RECV:
+ return "RECV";
+ default:
+ return "";
+
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Silence compiler warning in igt_ctx_exec
On ma, 2017-05-22 at 13:21 +0100, Chris Wilson wrote:
> The compiler doesn't always spot the guard that object is allocated on
> the first pass, leading to:
>
> drivers/gpu/drm/i915/selftests/i915_gem_context.c: warning: 'obj' may be used
> uninitialized in this function [-Wuninitialized]: => 370:8
>
> Reported-by: Geert Uytterhoeven
> Fixes: 791ff39ae32a ("drm/i915: Live testing for context execution")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Matthew Auld
> c: # v4.12-rc1+
Maybe should be "Cc:" too? Code is,
Reviewed-by: Joonas Lahtinen
I'm not sure if this is the best way to address similar problems.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
A bit of history on the commit message pointing the commit that
introduced the issue is desired.
With that in place feel free to use:
Reviewed-by: Rodrigo Vivi
On Tue, 2017-05-23 at 22:27 +0530, vathsala nagaraju wrote:
> psr1 is also disabled for panel resolution greater than 32X20.
> Added psr2 check to disable only for psr2 panels having resolution
> greater than 32X20.
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Cc: Yaroslav Shabalin
> Signed-off-by: vathsala nagaraju
> ---
> drivers/gpu/drm/i915/intel_psr.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index c3780d0..559f1ab 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -435,8 +435,9 @@ static bool intel_psr_match_conditions(struct intel_dp
> *intel_dp)
> }
>
> /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
> - if (intel_crtc->config->pipe_src_w > 3200 ||
> - intel_crtc->config->pipe_src_h > 2000) {
> + if (dev_priv->psr.psr2_support &&
> + (intel_crtc->config->pipe_src_w > 3200 ||
> + intel_crtc->config->pipe_src_h > 2000)) {
> dev_priv->psr.psr2_support = false;
> return false;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Convert i915_gem_object_ops->flags values to use BIT()
On ti, 2017-05-23 at 11:31 +0100, Chris Wilson wrote: > Having just watched someone add a new value, 0x3, without realising that > the flags were bit values, I have come to appreciate the value in using > BIT. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2)
== Series Details == Series: drm/i915/psr: disable psr2 for resolution greater than 32X20 (rev2) URL : https://patchwork.freedesktop.org/series/17737/ State : success == Summary == Series 17737v2 drm/i915/psr: disable psr2 for resolution greater than 32X20 https://patchwork.freedesktop.org/api/1.0/series/17737/revisions/2/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:439s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-bdw-5557u failed to collect. IGT log at Patchwork_4787/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4787/fi-bsw-n3050/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4787/fi-bxt-j4205/igt.log fi-byt-j1900 failed to collect. IGT log at Patchwork_4787/fi-byt-j1900/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4787/fi-byt-n2820/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4787/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4787/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4787/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4787/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4787/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4787/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4787/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4787/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4787/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4787/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4787/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4787/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4787/fi-snb-2600/igt.log c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h-42m-41s UTC integration manifest 999711c drm/i915/psr: disable psr2 for resolution greater than 32X20 == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4787/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for SKL render decompression support
== Series Details == Series: SKL render decompression support URL : https://patchwork.freedesktop.org/series/24838/ State : success == Summary == Series 24838v1 SKL render decompression support https://patchwork.freedesktop.org/api/1.0/series/24838/revisions/1/mbox/ fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:436s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:448s fi-bdw-5557u failed to collect. IGT log at Patchwork_4786/fi-bdw-5557u/igt.log fi-bsw-n3050 failed to collect. IGT log at Patchwork_4786/fi-bsw-n3050/igt.log fi-bxt-j4205 failed to collect. IGT log at Patchwork_4786/fi-bxt-j4205/igt.log fi-byt-j1900 failed to collect. IGT log at Patchwork_4786/fi-byt-j1900/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4786/fi-byt-n2820/igt.log fi-hsw-4770 failed to collect. IGT log at Patchwork_4786/fi-hsw-4770/igt.log fi-hsw-4770r failed to collect. IGT log at Patchwork_4786/fi-hsw-4770r/igt.log fi-ilk-650 failed to collect. IGT log at Patchwork_4786/fi-ilk-650/igt.log fi-ivb-3520m failed to collect. IGT log at Patchwork_4786/fi-ivb-3520m/igt.log fi-ivb-3770 failed to collect. IGT log at Patchwork_4786/fi-ivb-3770/igt.log fi-kbl-7500u failed to collect. IGT log at Patchwork_4786/fi-kbl-7500u/igt.log fi-kbl-7560u failed to collect. IGT log at Patchwork_4786/fi-kbl-7560u/igt.log fi-skl-6260u failed to collect. IGT log at Patchwork_4786/fi-skl-6260u/igt.log fi-skl-6700hq failed to collect. IGT log at Patchwork_4786/fi-skl-6700hq/igt.log fi-skl-6700k failed to collect. IGT log at Patchwork_4786/fi-skl-6700k/igt.log fi-skl-6770hq failed to collect. IGT log at Patchwork_4786/fi-skl-6770hq/igt.log fi-snb-2520m failed to collect. IGT log at Patchwork_4786/fi-snb-2520m/igt.log fi-snb-2600 failed to collect. IGT log at Patchwork_4786/fi-snb-2600/igt.log c6d01bed4870cb979003bbbfb38b0e7ebf036794 drm-tip: 2017y-05m-23d-14h-42m-41s UTC integration manifest e98bbaa0 drm/i915: Implement .get_format_info() hook for CCS f3722c5 drm: Add explict alignment for formats == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4786/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
psr1 is also disabled for panel resolution greater than 32X20.
Added psr2 check to disable only for psr2 panels having resolution
greater than 32X20.
Cc: Rodrigo Vivi
Cc: Jim Bride
Cc: Yaroslav Shabalin
Signed-off-by: vathsala nagaraju
---
drivers/gpu/drm/i915/intel_psr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c3780d0..559f1ab 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -435,8 +435,9 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
}
/* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
- if (intel_crtc->config->pipe_src_w > 3200 ||
- intel_crtc->config->pipe_src_h > 2000) {
+ if (dev_priv->psr.psr2_support &&
+ (intel_crtc->config->pipe_src_w > 3200 ||
+intel_crtc->config->pipe_src_h > 2000)) {
dev_priv->psr.psr2_support = false;
return false;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 0/3] SKL render decompression support
Hi, Here's the kernel counterpart to the Mesa series exposing Y-tiled CCS at: https://lists.freedesktop.org/archives/mesa-dev/2017-May/156184.html All the patches are Ville's, I've just rebased and squashed. They depend on Ben's last modifier-advertisement series, plus the fixup I sent in reply to that. They may want to be squashed/split differently, and Yf-tiled CCS is totally untested. I've been using Weston as a test vehicle, built from the atomic series which is currently blocked on review for earlier parts, and cleanups for the latter parts: git://git.collabora.com/git/user/daniels/weston # wip/2017-04/atomic-v11-WIP I'm currently dying of the flu & away next week as well, so anyone who wants this done sooner should just take this over and not block on me. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 1/3] drm: Add explict alignment for formats
From: Ville Syrjälä
hsub and vsub are used to indicate format subsampling, and currently
framebuffers cannot be allocated with a width not aligned to this value.
However, for auxiliary compressed planes this is undesirable: the
generic userspace does not know to quantise width/height, but the
non-generic allocator can pad the stride/size in an acceptable way.
Add explicit halign/valign members which allow a particular format to
have more loose (or strict) alignment requirements than its subsampling.
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/drm_framebuffer.c | 7 +--
include/drm/drm_fourcc.h | 2 ++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index fc8ef42203ec..7ab8ea7f7a9f 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -149,6 +149,7 @@ static int framebuffer_check(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *r)
{
const struct drm_format_info *info;
+ int halign, valign;
int i;
/* check if the format is supported at all */
@@ -164,12 +165,14 @@ static int framebuffer_check(struct drm_device *dev,
/* now let the driver pick its own format info */
info = drm_get_format_info(dev, r);
- if (r->width == 0) {
+ halign = info->halign ? : info->hsub;
+ if (r->width == 0 || r->width % halign){
DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
return -EINVAL;
}
- if (r->height == 0) {
+ valign = info->valign ? : info->vsub;
+ if (r->height == 0 || r->height % valign) {
DRM_DEBUG_KMS("bad framebuffer height %u\n", r->height);
return -EINVAL;
}
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 6942e84b6edd..a6aff4d091e8 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -46,6 +46,8 @@ struct drm_format_info {
u8 cpp[3];
u8 hsub;
u8 vsub;
+ u8 halign; /* specified only if != hsub */
+ u8 valign; /* specified only if != vsub */
};
/**
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 2/3] drm/i915: Implement .get_format_info() hook for CCS
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts of the main surface are compressed and which are not. The location
of CCS is provided by userspace as just another plane with its own offset.
By providing our own format information for the CCS formats, we should
be able to make framebuffer_check() do the right thing for the CCS
surface as well.
Note that we'll return the same format info for both Y and Yf tiled
format as that's what happens with the non-CCS Y vs. Yf as well. If
desired, we could potentially return a unique pointer for each
pixel_format+tiling+ccs combination, in which case we immediately be
able to tell if any of that stuff changed by just comparing the
pointers. But that does sound a bit wasteful space wise.
v2: Drop the 'dev' argument from the hook
v3: Include the description of the CCS surface layout
v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Reviewed-by: Ben Widawsky (v3)
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_display.c | 51
include/uapi/drm/drm_fourcc.h| 20 ++
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 847064152563..b20e89396e04 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2452,6 +2452,56 @@ static unsigned int intel_fb_modifier_to_tiling(uint64_t
fb_modifier)
}
}
+/*
+ * 1 byte of CCS actually corresponds to 16x8 pixels on the main
+ * surface, and the memory layout for the CCS tile us 64x64 bytes.
+ * But since we're pretending the CCS tile is 128 bytes wide we
+ * adjust hsub/vsub here accordingly to 8x16 so that the
+ * bytes<->x/y conversions come out correct. We don't require any
+ * CCS block size alignment of the fb under the assumption that the
+ * hardware will handle things correctly of only a single pixel
+ * gets touched. The compression should be lossless so any garbage
+ * pixels as part of the same block shouldn't cause visual artifacts.
+ */
+static const struct drm_format_info ccs_formats[] = {
+ { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .halign = 1, .valign = 1, },
+ { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .halign = 1, .valign = 1, },
+ { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .halign = 1, .valign = 1, },
+ { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = {
4, 1, },
+ .hsub = 8, .vsub = 16, .halign = 1, .valign = 1, },
+};
+
+static const struct drm_format_info *
+lookup_format_info(const struct drm_format_info formats[],
+ int num_formats, u32 format)
+{
+ int i;
+
+ for (i = 0; i < num_formats; i++) {
+ if (formats[i].format == format)
+ return &formats[i];
+ }
+
+ return NULL;
+}
+
+static const struct drm_format_info *
+intel_get_format_info(const struct drm_mode_fb_cmd2 *cmd)
+{
+ switch (cmd->modifier[0]) {
+ case I915_FORMAT_MOD_Y_TILED_CCS:
+ case I915_FORMAT_MOD_Yf_TILED_CCS:
+ return lookup_format_info(ccs_formats,
+ ARRAY_SIZE(ccs_formats),
+ cmd->pixel_format);
+ default:
+ return NULL;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -14725,6 +14775,7 @@ static void intel_atomic_state_free(struct
drm_atomic_state *state)
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
+ .get_format_info = intel_get_format_info,
.output_poll_changed = intel_fbdev_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 47f0175e29c0..500c4c7ba5a9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -263,6 +263,26 @@ extern "C" {
#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
/*
+ * Intel color control surface (CCS) for render compression
+ *
+ * The framebuffer format must be one of the 8:8:8:8 RGB formats.
+ * The main surface will be plane index 0 and must be Y/Yf-tiled,
+ * the CCS will be plane index 1.
+ *
+ * Each CCS tile matches a 1024x512 pixel area of the main surface.
+ * To match certain aspects of the 3D hardware the
[Intel-gfx] [RFC PATCH 3/3] drm/i915: Add render decompression support
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
location of CCS is provided by userspace as just another plane with its
own offset.
Add the required stuff to validate the user provided AUX plane metadata
and convert the user provided linear offset into something the hardware
can consume.
Due to hardware limitations we require that the main surface and
the AUX surface (CCS) be part of the same bo. The hardware also
makes life hard by not allowing you to provide separate x/y offsets
for the main and AUX surfaces (excpet with NV12), so finding suitable
offsets for both requires a bit of work. Assuming we still want keep
playing tricks with the offsets. I've just gone with a dumb "search
backward for suitable offsets" approach, which is far from optimal,
but it works.
Also not all planes will be capable of scanning out compressed surfaces,
and eg. 90/270 degree rotation is not supported in combination with
decompression either.
This patch may contain work from at least the following people:
* Vandana Kannan
* Daniel Vetter
* Ben Widawsky
v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
Put the AUX register defines to the correct place
Fix up the slightly bogus rotation check
v4: Advertise modifiers (Daniel)
Cc: Paulo Zanoni
Cc: Daniel Vetter
Cc: Ben Widawsky
Cc: Jason Ekstrand
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Sotne
Reviewed-by: Ben Widawsky (v1)
---
drivers/gpu/drm/i915/i915_reg.h | 23
drivers/gpu/drm/i915/intel_display.c | 259 ---
drivers/gpu/drm/i915/intel_pm.c | 29 +++-
drivers/gpu/drm/i915/intel_sprite.c | 7 +
4 files changed, 299 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 89888adb9af1..fc294cbe8932 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5905,6 +5905,10 @@ enum {
#define _PLANE_KEYMSK_2_A 0x70298
#define _PLANE_KEYMAX_1_A 0x701a0
#define _PLANE_KEYMAX_2_A 0x702a0
+#define _PLANE_AUX_DIST_1_A0x701c0
+#define _PLANE_AUX_DIST_2_A0x702c0
+#define _PLANE_AUX_OFFSET_1_A 0x701c4
+#define _PLANE_AUX_OFFSET_2_A 0x702c4
#define _PLANE_COLOR_CTL_1_A 0x701CC /* GLK+ */
#define _PLANE_COLOR_CTL_2_A 0x702CC /* GLK+ */
#define _PLANE_COLOR_CTL_3_A 0x703CC /* GLK+ */
@@ -6011,6 +6015,24 @@ enum {
#define PLANE_NV12_BUF_CFG(pipe, plane)\
_MMIO_PLANE(plane, _PLANE_NV12_BUF_CFG_1(pipe),
_PLANE_NV12_BUF_CFG_2(pipe))
+#define _PLANE_AUX_DIST_1_B0x711c0
+#define _PLANE_AUX_DIST_2_B0x712c0
+#define _PLANE_AUX_DIST_1(pipe) \
+ _PIPE(pipe, _PLANE_AUX_DIST_1_A, _PLANE_AUX_DIST_1_B)
+#define _PLANE_AUX_DIST_2(pipe) \
+ _PIPE(pipe, _PLANE_AUX_DIST_2_A, _PLANE_AUX_DIST_2_B)
+#define PLANE_AUX_DIST(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
+
+#define _PLANE_AUX_OFFSET_1_B 0x711c4
+#define _PLANE_AUX_OFFSET_2_B 0x712c4
+#define _PLANE_AUX_OFFSET_1(pipe) \
+ _PIPE(pipe, _PLANE_AUX_OFFSET_1_A, _PLANE_AUX_OFFSET_1_B)
+#define _PLANE_AUX_OFFSET_2(pipe) \
+ _PIPE(pipe, _PLANE_AUX_OFFSET_2_A, _PLANE_AUX_OFFSET_2_B)
+#define PLANE_AUX_OFFSET(pipe, plane) \
+ _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
+
#define _PLANE_COLOR_CTL_1_B 0x711CC
#define _PLANE_COLOR_CTL_2_B 0x712CC
#define _PLANE_COLOR_CTL_3_B 0x713CC
@@ -6494,6 +6516,7 @@ enum {
# define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
#define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define SKL_RC_HASH_OUTSIDE (1 << 15)
#define DPA_MASK_VBLANK_SRD (1 << 15)
#define FORCE_ARB_IDLE_PLANES (1 << 14)
#define SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b20e89396e04..2f7a35eb95d1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -94,6 +94,8 @@ static const uint32_t skl_primary_formats[] = {
};
static const uint64_t skl_format_modifiers[] = {
+ I915_FORMAT_MOD_Y_TILED_CCS,
+ I915_FORMAT_MOD_Yf_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
I915_FORMAT_MOD_X_TILED,
@@ -2018,11 +2020,19 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int plane)
Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob
Hi Ben,
On 16 May 2017 at 22:31, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
If you take the attached fixup, this is:
Reviewed-by: Daniel Stone
The rest of the series looks fine to me, so you can take my Acked-by,
but I'm currently off work sick and am away next week, so please don't
block on me for merging.
Cheers,
Daniel
commit 250f3b2c2a824516b18fe21623ddc86ccf31eddb
Author: Daniel Stone
Date: Tue May 23 17:36:55 2017 +0100
fixup! drm: Create a format/modifier blob
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index f5b032b5f761..083231750583 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -77,18 +77,12 @@ modifiers_ptr(struct drm_format_modifier_blob *blob)
static int create_in_format_blob(struct drm_device *dev, struct drm_plane
*plane)
{
const struct drm_mode_config *config = &dev->mode_config;
- const uint64_t *temp_modifiers = plane->modifiers;
- unsigned int format_modifier_count = 0;
struct drm_property_blob *blob = NULL;
struct drm_format_modifier *mod;
size_t blob_size = 0, formats_size, modifiers_size;
struct drm_format_modifier_blob *blob_data;
int i, j, ret = 0;
- if (plane->modifiers)
- while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
- format_modifier_count++;
-
formats_size = sizeof(*plane->format_types) * plane->format_count;
if (WARN_ON(!formats_size)) {
/* 0 formats are never expected */
@@ -96,7 +90,7 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
}
modifiers_size =
- sizeof(struct drm_format_modifier) * format_modifier_count;
+ sizeof(struct drm_format_modifier) * plane->modifier_count;
blob_size = sizeof(struct drm_format_modifier_blob);
blob_size += ALIGN(formats_size, 8);
@@ -110,7 +104,7 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
blob_data->version = FORMAT_BLOB_CURRENT;
blob_data->count_formats = plane->format_count;
blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
- blob_data->count_modifiers = format_modifier_count;
+ blob_data->count_modifiers = plane->modifier_count;
/* Modifiers offset is a pointer to a struct with a 64 bit field so it
* should be naturally aligned to 8B.
@@ -125,7 +119,7 @@ static int create_in_format_blob(struct drm_device *dev,
struct drm_plane *plane
goto done;
mod = modifiers_ptr(blob_data);
- for (i = 0; i < format_modifier_count; i++) {
+ for (i = 0; i < plane->modifier_count; i++) {
for (j = 0; j < plane->format_count; j++) {
if (plane->funcs->format_mod_supported(plane,
plane->format_types[j],
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: New ddb allocation algorithm
Hi, On Thursday 18 May 2017 04:45 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op do 18-05-2017 om 15:39 [+0530]: From: "Kumar, Mahesh" This patch implements new DDB allocation algorithm as per HW team recommendation. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of enabling same watermark level for each plane in crtc, for efficient power saving. Changes since v1: - Rebase on top of Paulo's patch series Changes since v2: - Fix the for loop condition to enable WM Changes since v3: - Fix crash in cursor i-g-t reported by Maarten - Rebase after addressing Paulo's comments - Few other ULT fixes Changes since v4: - Rebase on drm-tip - Added separate function to enable WM levels Changes since v5: - Fix a crash identified in skl-6770HQ system Changes since v6: - Address review comments from Matt Changes since v7: - Fix failure return in skl_compute_plane_wm (Matt) - fix typo Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst Hm just to be sure it works as intended I tested this against full kms, testsuite and it seems to cause FIFO underruns on my KBL with the kms_atomic_transition test. I think we shouldn't merge this until all those fifo underruns have been fixed, especially because FIFO underruns may result in a complete lockup of the gpu. After debugging I found when, only cursor plane is enabled, that time total_data_rate is coming 0 because we don't include cursor for total_data_rate calculation. And because of this we return from skl_allocate_pipe_ddb function without enabling WM levels for cursor plane. As a result cursor plane is enabled without WM getting enabled & resulting "fifo under-run" Fixing it by doing cursor_plane wm enable calculation irrespective of total_data_rate calculation. -Mahesh Sorry for the bad news, Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Tuesday, May 23, 2017 1:41 AM > To: Bloomfield, Jon > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT > > On Mon, May 22, 2017 at 11:07:25AM -0700, Jon Bloomfield wrote: > > BXT requires accesses to the GTT (i.e. PTE updates) to be serialized > > when IOMMU is enabled. This patch guarantees this by wrapping all > > updates in stop_machine and using a flushing read to guarantee that > > the GTT writes have reached their destination before restarting. > > > > Testcase? igt/gem_concurrent_blit shows the failure. I was using a combination of tests, run in parallel to hit this bug. I need to get hold of a system again to re-run. Are you saying you have also repro'd the bug just with gem_concurrent_blit or just suggesting that it might be a good candidate ? I'll also re-try without the flushing read, but I'm wary of removing this unless I can understand why the mmio write has the same effect. It might be luck. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size
On Tue, May 23, 2017 at 02:57:16PM +0100, Matthew Auld wrote:
> On 23 May 2017 at 13:54, Chris Wilson wrote:
> > On Tue, May 23, 2017 at 01:42:56PM +0100, Matthew Auld wrote:
> >> On 16 May 2017 at 10:59, Chris Wilson wrote:
> >> > This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;
> >> But wouldn't this assume that sg->length is exactly a page size, I
> >> would have imagined it would be possible for shmem to give us two or
> >> more continuous super-pages, or am I missing something?
> >
> > I'd actually report obj->mm.phys_page_sizes = sg_mask; and cook a value for
> > obj->mm.gtt_pages_sizes:
> >
> > obj->mm.gtt_page_sizes = 0;
> > for_each_set_bit(bit, &i915->info.supported_gtt_pages_size) { //
> > add salt
> > if (obj->mm.phys_page_sizes & ~0u << bit)
> > obj->mm.gtt_page_sizes |= BIT(bit);
> > }
> Nifty.
>
> So in mixed-mode what would be the alignment strategy? Align to
> largest, smallest, don't align at all etc. For example if we were
> unlucky and got something like 4K->2M? The obj->mm.gtt_page_sizes
> should always be representative of how we end up inserting it into the
> gtt, right? Would it not be more apt to move the gtt_page_sizes
> tracking to when we do the insert?
My first thought was align to worst (and then hope for the best, i.e.
that we can make use of that alignment, I'm still thinking even if we
get a huge physical page, wasting that alignment in a 48b aperture still
isn't terrible -- caveats if we need to fit inside the low 4G!).
Reporting the actual GTT sizes used might be useful for debug, but the
focus should be on tracking the values that make the code simpler :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 23, 2017 12:33 AM
> To: Bloomfield, Jon
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
>
> On Mon, May 22, 2017 at 10:18:31PM +, Bloomfield, Jon wrote:
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Monday, May 22, 2017 1:05 PM
> > > To: Bloomfield, Jon
> > > Cc: intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> > >
> > > On Mon, May 22, 2017 at 11:07:25AM -0700, Jon Bloomfield wrote:
> > > > BXT requires accesses to the GTT (i.e. PTE updates) to be serialized
> > > > when IOMMU is enabled.
> > >
> > > Serialised with what, since all writes are serialized already?
> >
> > Fair cop guv. I'll reword.
> >
> > >
> > > The reason is that you need to explain the hw model you are protecting,
> for
> > > example do clears need to be protected?
> > >
> > > > This patch guarantees this by wrapping all updates in stop_machine and
> > > > using a flushing read to guarantee that the GTT writes have reached
> > > > their destination before restarting.
> > >
> > > If you mention which patch you are reinstating (for a new problem) and
> cc
> > > the author, he might point out what has changed in the meantime.
> >
> > I don't understand. I'm not re-instating any patches to my knowledge, so
> it's a bit hard to cc the author.
>
> Please then review history before submitting *copied* code.
>
> > > Note, the flush here is not about ensuring the GTT writes reach their
> > > destination.
> > >
> > > > Signed-off-by: Jon Bloomfield
> > >
> > > If you are the author and sender, what is John's s-o-b doing afterwards?
> > This patch was previously signed off by John.
> >
> > >
> > > > Signed-off-by: John Harrison
> > > > ---
> > > > drivers/gpu/drm/i915/i915_gem_gtt.c | 106
> > > >
> > > > 1 file changed, 106 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > index 7c769d7..6360d92 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > @@ -2191,6 +2191,100 @@ static void gen8_ggtt_clear_range(struct
> > > i915_address_space *vm,
> > > > gen8_set_pte(>t_base[i], scratch_pte); }
> > > >
> > > > +#ifdef CONFIG_INTEL_IOMMU
> > > > +struct insert_page {
> > > > + struct i915_address_space *vm;
> > > > + dma_addr_t addr;
> > > > + u64 offset;
> > > > + enum i915_cache_level level;
> > > > +};
> > > > +
> > > > +static int gen8_ggtt_insert_page__cb(void *_arg) {
> > > > + struct insert_page *arg = _arg;
> > > > +
> > > > + struct drm_i915_private *dev_priv = arg->vm->i915;
> > > > +
> > > > + gen8_ggtt_insert_page(arg->vm, arg->addr,
> > > > + arg->offset, arg->level, 0);
> > > > +
> > > > + POSTING_READ(GFX_FLSH_CNTL_GEN6);
> > >
> > > This is now just a call to i915_ggtt_invalidate() because we are now also
> > > responsible for invalidating the guc tlbs as well as the chipset.
> > > And more importantly it is already done by gen8_ggtt_insert_page.
> > >
> > > All the POSTING_READ(GFX_FLSH_CNTL_GEN6) are spurious.
> >
> > Are you sure - The purpose of the register read is to ensure that all the
> > PTE
> writes are flushed from the h/w queue
> > before we restart the machine. It is critical that all the PTE writes have
> > left
> this queue before any other accesses are
> > allowed to begin.
> > Isn't the invalidate a posted write ? If so, it won't drain the queue.
> > Even if the invalidate is guaranteed to effect this pipeline flish, the
> clear_page path doesn't call invalidate, so it's
> > certainly required there.
>
> It's an uncached mmio write. It is strongly ordered and serial. Besides
> if you feel it is wrong, fix the bug at source.
Strongly ordered is not enough, nor is being uncached - that just ensures the
PTE
writes have left the CPU. We need to ensure they have left the GAM before we
allow any following Aperture accesses to reach the GAM. On the other hand it
may be that the write to the flushctl reg will explicitly cause the h/w to
clear the
fifo. I'll check with hw.
Re fixing at source: Assuming you mean just put the read into the gtt functions
next to the invalidate, then I can do that, but it would mean either another
bxt/iommu test or executing the read unconditionally for all gens. Are you happy
with that, and if so which ?
>
> > > > static void gen6_ggtt_clear_range(struct i915_address_space *vm,
> > > > u64 start, u64 length)
> > > > {
> > > > @@ -2789,6 +2883,18 @@ static int gen8_gmch_probe(struct i915_ggtt
> > > > *ggtt)
> > > >
> > > > ggtt->base.insert_entries = gen8_ggtt_insert_entries;
>
[Intel-gfx] [linux-next-20170523] possible circular locking dependency detected
Hello,
[9.610781] ==
[9.610784] WARNING: possible circular locking dependency detected
[9.610789] 4.12.0-rc2-next-20170523-dbg-dirty #231 Not tainted
[9.610791] --
[9.610795] Xorg/341 is trying to acquire lock:
[9.610798] (cpu_hotplug_lock.rw_sem){++}, at: []
apply_wqattrs_lock+0x9/0x19
[9.610816]
but task is already holding lock:
[9.610818] (&dev_priv->mm_lock){+.+.+.}, at: []
i915_gem_userptr_init__mmu_notifier+0x85/0x213
[9.610834]
which lock already depends on the new lock.
[9.610837]
the existing dependency chain (in reverse order) is:
[9.610839]
-> #5 (&dev_priv->mm_lock){+.+.+.}:
[9.610854]lock_acquire+0x46/0x60
[9.610861]__mutex_lock+0x90/0x7b5
[9.610867]mutex_lock_nested+0x16/0x18
[9.610872]i915_gem_userptr_init__mmu_notifier+0x85/0x213
[9.610878]i915_gem_userptr_ioctl+0x1cd/0x2b6
[9.610884]drm_ioctl+0x258/0x373
[9.610893]vfs_ioctl+0x13/0x2f
[9.610899]do_vfs_ioctl+0x5eb/0x5fe
[9.610905]SyS_ioctl+0x3e/0x5c
[9.610913]entry_SYSCALL_64_fastpath+0x18/0xad
[9.610915]
-> #4 (&mm->mmap_sem){++}:
[9.610926]lock_acquire+0x46/0x60
[9.610933]__might_fault+0x5c/0x7f
[9.610939]filldir+0xb3/0x125
[9.610947]call_filldir+0xb9/0xde
[9.610952]ext4_readdir+0x1ff/0x676
[9.610958]iterate_dir+0x93/0x13d
[9.610964]SyS_getdents+0xa4/0x117
[9.610971]entry_SYSCALL_64_fastpath+0x18/0xad
[9.610973]
-> #3 (&type->i_mutex_dir_key#2){++}:
[9.610986]lock_acquire+0x46/0x60
[9.610992]down_read+0x39/0x5d
[9.610997]lookup_slow+0x7c/0x17f
[9.611002]walk_component+0xcd/0x214
[9.611007]link_path_walk+0xfa/0x44a
[9.611013]path_openat+0x213/0x6f9
[9.611018]do_filp_open+0x48/0x9e
[9.611024]file_open_name+0xe7/0xe9
[9.611028]filp_open+0x2d/0x44
[9.611032]kernel_read_file_from_path+0x33/0x6c
[9.611039]_request_firmware+0x39d/0x629
[9.611044]request_firmware_work_func+0x23/0x55
[9.611049]process_one_work+0x1c3/0x323
[9.611055]worker_thread+0x1ee/0x2c0
[9.611060]kthread+0x127/0x12f
[9.611064]ret_from_fork+0x2e/0x40
[9.611066]
-> #2 (umhelper_sem){.+}:
[9.611077]lock_acquire+0x46/0x60
[9.611083]down_read+0x39/0x5d
[9.611088]usermodehelper_read_trylock+0x51/0x100
[9.611092]_request_firmware+0x2dc/0x629
[9.611097]request_firmware_direct+0x36/0x48
[9.611103]request_microcode_fw+0x54/0x88
[9.611107]reload_store+0xaa/0x114
[9.64]dev_attr_store+0x14/0x1e
[9.611121]sysfs_kf_write+0x44/0x4b
[9.611127]kernfs_fop_write+0x117/0x161
[9.611132]__vfs_write+0x21/0xe7
[9.611137]vfs_write+0xdc/0x165
[9.611142]SyS_write+0x4c/0x89
[9.611149]entry_SYSCALL_64_fastpath+0x18/0xad
[9.611151]
-> #1 (microcode_mutex){+.+.+.}:
[9.611162]lock_acquire+0x46/0x60
[9.611167]__mutex_lock+0x90/0x7b5
[9.611173]mutex_lock_nested+0x16/0x18
[9.611181]microcode_init+0xb8/0x1d7
[9.611187]do_one_initcall+0x8b/0x121
[9.611192]kernel_init_freeable+0x139/0x1c2
[9.611197]kernel_init+0x9/0xe6
[9.611201]ret_from_fork+0x2e/0x40
[9.611203]
-> #0 (cpu_hotplug_lock.rw_sem){++}:
[9.611214]__lock_acquire+0xec4/0x1444
[9.611219]lock_acquire+0x46/0x60
[9.611226]get_online_cpus+0x38/0x98
[9.611231]apply_wqattrs_lock+0x9/0x19
[9.611237]apply_workqueue_attrs+0x15/0x2f
[9.611244]__alloc_workqueue_key+0x2b2/0x457
[9.611250]i915_gem_userptr_init__mmu_notifier+0xfb/0x213
[9.611255]i915_gem_userptr_ioctl+0x1cd/0x2b6
[9.611260]drm_ioctl+0x258/0x373
[9.611266]vfs_ioctl+0x13/0x2f
[9.611272]do_vfs_ioctl+0x5eb/0x5fe
[9.611278]SyS_ioctl+0x3e/0x5c
[9.611284]entry_SYSCALL_64_fastpath+0x18/0xad
[9.611287]
other info that might help us debug this:
[9.611290] Chain exists of:
cpu_hotplug_lock.rw_sem --> &mm->mmap_sem -->
&dev_priv->mm_lock
[9.611301] Possible unsafe locking scenario:
[9.611304]CPU0CPU1
[9.611306]
[9.611308] lock(&dev_priv->mm_lock);
[9.
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf
Hi,
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index ae46105..285dc16 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -502,10 +502,58 @@ struct vfio_pci_hot_reset {
>
> #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE +
> 13)
>
> +/**
> + * VFIO_DEVICE_GET_FD - _IO(VFIO_TYPE, VFIO_BASE + 14, __u32)
> + *
> + * Create a fd for a vfio device based on the input type
> + * Vendor driver should handle this ioctl to create a fd and manage
> the
> + * life cycle of this fd.
> + *
> + * Return: a fd if vendor support that type, -errno if not supported
> + */
> +
> +#define VFIO_DEVICE_GET_FD _IO(VFIO_TYPE, VFIO_BASE + 14)
> +
> +#define VFIO_DEVICE_DMABUF_MGR_FD0 /* Supported fd types */
> +
> +/*
> + * VFIO_DEVICE_QUERY_PLANE - _IO(VFIO_TYPE, VFIO_BASE + 15, struct
> plane_info)
> + * Query plane information for a plane
> + */
> +struct plane_info {
That is a pretty generic name. vfio_vgpu_plane_info? Or
vfio_dmabuf_plane_info?
> + __u32 plane_id;
> + __u32 drm_format;
> + __u32 width;
> + __u32 height;
> + __u32 stride;
> + __u32 start;
> + __u32 x_pos;
> + __u32 y_pos;
> + __u32 size;
> + __u64 drm_format_mod;
> +};
> +
> +#define VFIO_PRIMARY_PLANE 1
> +#define VFIO_CURSOR_PLANE2
I think we should use "enum drm_plane_type" values instead of creating
something new.
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm/i915/gvt: Dmabuf support for GVT-g
Hi,
> + } else if (plane_id == INTEL_GVT_PLANE_CURSOR) {
> + c = &pipe->cursor;
> + if (c != NULL) {
> + info->start = c->base;
> + info->width = c->width;
> + info->height = c->height;
> + info->stride = c->width * (c->bpp / 8);
> + info->drm_format_mod = 0;
> + info->x_pos = c->x_pos;
> + info->y_pos = c->y_pos;
> + info->size = (((info->stride * c->height *
> c->bpp) / 8)
> + + (PAGE_SIZE - 1)) >>
> PAGE_SHIFT;
Leaves info->drm_format unset.
> +struct intel_vgpu_plane_info {
> + uint32_t plane_id;
> + uint32_t drm_format;
> + uint32_t width;
> + uint32_t height;
> + uint32_t stride;
> + uint32_t start;
> + uint32_t x_pos;
> + uint32_t y_pos;
> + uint32_t size;
> + uint64_t drm_format_mod;
> +};
drm_format_mod is unaligned. Should be avoided, otherwise the struct
layout is different on i386 and x86_64.
Patch 5/5 moves around this struct. Better have a separate patch
adding the structs and ioctls, order it before this one, so you don't
have to rename the stuff just added ...
> +struct intel_vgpu_dmabuf {
> + uint32_t fd;
> + struct intel_vgpu_plane_info plane_info;
> +};
Has alignment problems too.
cheers,
Gerd
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size
On 23 May 2017 at 13:54, Chris Wilson wrote:
> On Tue, May 23, 2017 at 01:42:56PM +0100, Matthew Auld wrote:
>> On 16 May 2017 at 10:59, Chris Wilson wrote:
>> > On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
>> >> In preparation for supporting huge gtt pages for the ppgtt, we introduce
>> >> a gtt_page_size member for gem objects. We fill in the gtt page size by
>> >> scanning the sg table to determine the max page size which satisfies the
>> >> alignment for each sg entry.
>> >>
>> >> Signed-off-by: Matthew Auld
>> >> Cc: Joonas Lahtinen
>> >> Cc: Chris Wilson
>> >> Cc: Daniel Vetter
>> >> ---
>> >> drivers/gpu/drm/i915/i915_drv.h| 2 ++
>> >> drivers/gpu/drm/i915/i915_gem.c| 23 +++
>> >> drivers/gpu/drm/i915/i915_gem_object.h | 2 ++
>> >> 3 files changed, 27 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> >> b/drivers/gpu/drm/i915/i915_drv.h
>> >> index e18f11f77f35..a7a108d18a2d 100644
>> >> --- a/drivers/gpu/drm/i915/i915_drv.h
>> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> >> @@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>> >> #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
>> >> #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
>> >> #define USES_FULL_48BIT_PPGTT(dev_priv) (i915.enable_ppgtt == 3)
>> >> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
>> >> + ((dev_priv)->info.page_size_mask & (page_size))
>> >>
>> >> #define HAS_OVERLAY(dev_priv)
>> >> ((dev_priv)->info.has_overlay)
>> >> #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> >> b/drivers/gpu/drm/i915/i915_gem.c
>> >> index 0c1cbe98c994..6a5e864d7710 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem.c
>> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> >> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct
>> >> drm_i915_gem_object *obj,
>> >> if (!IS_ERR(pages))
>> >> obj->ops->put_pages(obj, pages);
>> >>
>> >> + obj->gtt_page_size = 0;
>> >> +
>> >> unlock:
>> >> mutex_unlock(&obj->mm.lock);
>> >> }
>> >> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct
>> >> drm_i915_gem_object *obj)
>> >> void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>> >>struct sg_table *pages)
>> >> {
>> >> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> >> + unsigned long supported_page_sizes =
>> >> INTEL_INFO(i915)->page_size_mask;
>> >> + struct scatterlist *sg;
>> >> + unsigned int sg_mask = 0;
>> >> + unsigned int i;
>> >> + unsigned int bit;
>> >> +
>> >> lockdep_assert_held(&obj->mm.lock);
>> >>
>> >> obj->mm.get_page.sg_pos = pages->sgl;
>> >> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct
>> >> drm_i915_gem_object *obj,
>> >> __i915_gem_object_pin_pages(obj);
>> >> obj->mm.quirked = true;
>> >> }
>> >> +
>> >> + for_each_sg(pages->sgl, sg, pages->nents, i)
>> >> + sg_mask |= sg->length;
>> >> +
>> >> + GEM_BUG_ON(!sg_mask);
>> >> +
>> >
>> > This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;
>> But wouldn't this assume that sg->length is exactly a page size, I
>> would have imagined it would be possible for shmem to give us two or
>> more continuous super-pages, or am I missing something?
>
> I'd actually report obj->mm.phys_page_sizes = sg_mask; and cook a value for
> obj->mm.gtt_pages_sizes:
>
> obj->mm.gtt_page_sizes = 0;
> for_each_set_bit(bit, &i915->info.supported_gtt_pages_size) { // add
> salt
> if (obj->mm.phys_page_sizes & ~0u << bit)
> obj->mm.gtt_page_sizes |= BIT(bit);
> }
Nifty.
So in mixed-mode what would be the alignment strategy? Align to
largest, smallest, don't align at all etc. For example if we were
unlucky and got something like 4K->2M? The obj->mm.gtt_page_sizes
should always be representative of how we end up inserting it into the
gtt, right? Would it not be more apt to move the gtt_page_sizes
tracking to when we do the insert?
>
> Certainly for the internal objects we will have a variety of different
> orders.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size
On Tue, May 23, 2017 at 01:42:56PM +0100, Matthew Auld wrote:
> On 16 May 2017 at 10:59, Chris Wilson wrote:
> > On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
> >> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> >> a gtt_page_size member for gem objects. We fill in the gtt page size by
> >> scanning the sg table to determine the max page size which satisfies the
> >> alignment for each sg entry.
> >>
> >> Signed-off-by: Matthew Auld
> >> Cc: Joonas Lahtinen
> >> Cc: Chris Wilson
> >> Cc: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h| 2 ++
> >> drivers/gpu/drm/i915/i915_gem.c| 23 +++
> >> drivers/gpu/drm/i915/i915_gem_object.h | 2 ++
> >> 3 files changed, 27 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index e18f11f77f35..a7a108d18a2d 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >> #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
> >> #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
> >> #define USES_FULL_48BIT_PPGTT(dev_priv) (i915.enable_ppgtt == 3)
> >> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
> >> + ((dev_priv)->info.page_size_mask & (page_size))
> >>
> >> #define HAS_OVERLAY(dev_priv)
> >> ((dev_priv)->info.has_overlay)
> >> #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index 0c1cbe98c994..6a5e864d7710 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct
> >> drm_i915_gem_object *obj,
> >> if (!IS_ERR(pages))
> >> obj->ops->put_pages(obj, pages);
> >>
> >> + obj->gtt_page_size = 0;
> >> +
> >> unlock:
> >> mutex_unlock(&obj->mm.lock);
> >> }
> >> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct
> >> drm_i915_gem_object *obj)
> >> void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
> >>struct sg_table *pages)
> >> {
> >> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> >> + unsigned long supported_page_sizes =
> >> INTEL_INFO(i915)->page_size_mask;
> >> + struct scatterlist *sg;
> >> + unsigned int sg_mask = 0;
> >> + unsigned int i;
> >> + unsigned int bit;
> >> +
> >> lockdep_assert_held(&obj->mm.lock);
> >>
> >> obj->mm.get_page.sg_pos = pages->sgl;
> >> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct
> >> drm_i915_gem_object *obj,
> >> __i915_gem_object_pin_pages(obj);
> >> obj->mm.quirked = true;
> >> }
> >> +
> >> + for_each_sg(pages->sgl, sg, pages->nents, i)
> >> + sg_mask |= sg->length;
> >> +
> >> + GEM_BUG_ON(!sg_mask);
> >> +
> >
> > This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;
> But wouldn't this assume that sg->length is exactly a page size, I
> would have imagined it would be possible for shmem to give us two or
> more continuous super-pages, or am I missing something?
I'd actually report obj->mm.phys_page_sizes = sg_mask; and cook a value for
obj->mm.gtt_pages_sizes:
obj->mm.gtt_page_sizes = 0;
for_each_set_bit(bit, &i915->info.supported_gtt_pages_size) { // add
salt
if (obj->mm.phys_page_sizes & ~0u << bit)
obj->mm.gtt_page_sizes |= BIT(bit);
}
Certainly for the internal objects we will have a variety of different
orders.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size
On 16 May 2017 at 10:59, Chris Wilson wrote:
> On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
>> In preparation for supporting huge gtt pages for the ppgtt, we introduce
>> a gtt_page_size member for gem objects. We fill in the gtt page size by
>> scanning the sg table to determine the max page size which satisfies the
>> alignment for each sg entry.
>>
>> Signed-off-by: Matthew Auld
>> Cc: Joonas Lahtinen
>> Cc: Chris Wilson
>> Cc: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_drv.h| 2 ++
>> drivers/gpu/drm/i915/i915_gem.c| 23 +++
>> drivers/gpu/drm/i915/i915_gem_object.h | 2 ++
>> 3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index e18f11f77f35..a7a108d18a2d 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>> #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
>> #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
>> #define USES_FULL_48BIT_PPGTT(dev_priv) (i915.enable_ppgtt == 3)
>> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
>> + ((dev_priv)->info.page_size_mask & (page_size))
>>
>> #define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay)
>> #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 0c1cbe98c994..6a5e864d7710 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct
>> drm_i915_gem_object *obj,
>> if (!IS_ERR(pages))
>> obj->ops->put_pages(obj, pages);
>>
>> + obj->gtt_page_size = 0;
>> +
>> unlock:
>> mutex_unlock(&obj->mm.lock);
>> }
>> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct
>> drm_i915_gem_object *obj)
>> void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>>struct sg_table *pages)
>> {
>> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> + unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
>> + struct scatterlist *sg;
>> + unsigned int sg_mask = 0;
>> + unsigned int i;
>> + unsigned int bit;
>> +
>> lockdep_assert_held(&obj->mm.lock);
>>
>> obj->mm.get_page.sg_pos = pages->sgl;
>> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct
>> drm_i915_gem_object *obj,
>> __i915_gem_object_pin_pages(obj);
>> obj->mm.quirked = true;
>> }
>> +
>> + for_each_sg(pages->sgl, sg, pages->nents, i)
>> + sg_mask |= sg->length;
>> +
>> + GEM_BUG_ON(!sg_mask);
>> +
>
> This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;
But wouldn't this assume that sg->length is exactly a page size, I
would have imagined it would be possible for shmem to give us two or
more continuous super-pages, or am I missing something?
>
> And it should be obj->mm.gtt_page_sizes.
>
> Then latter steps can make decisions based on the most strict
> requirements, or least strict etc.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: dma-buf support for GVT-g (rev5)
== Series Details == Series: drm/i915/gvt: dma-buf support for GVT-g (rev5) URL : https://patchwork.freedesktop.org/series/23686/ State : success == Summary == Series 23686v5 drm/i915/gvt: dma-buf support for GVT-g https://patchwork.freedesktop.org/api/1.0/series/23686/revisions/5/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-snb-2600) fdo#100125 Test kms_force_connector_basic: Subgroup prune-stale-modes: pass -> SKIP (fi-snb-2520m) fdo#101048 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101048 https://bugs.freedesktop.org/show_bug.cgi?id=101048 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:432s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:587s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:515s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:489s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:487s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:436s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:499s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:440s fi-snb-2520m total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:532s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:405s 46468fb47d8b68443c409eadd0414e2bd5fb8738 drm-tip: 2017y-05m-23d-10h-55m-00s UTC integration manifest 4c03515 drm/i915/gvt: Adding interface so user space can get the dma-buf 73c94cf drm/i915/gvt: Dmabuf support for GVT-g c7d7456 drm/i915/gvt: Frame buffer decoder support for GVT-g fe17891 drm/i915/gvt: OpRegion support for GVT-g 1acfa90 drm/i915/gvt: Extend the GVT-g architecture to support vfio device region == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4785/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, 23 May 2017, Tvrtko Ursulin wrote:
> On 23/05/2017 10:56, Jani Nikula wrote:
>> On Tue, 23 May 2017, Chris Wilson wrote:
>>> On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Reported-by: Nick Desaulniers
Cc: Nick Desaulniers
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index a637cc05cc4a..ecaa21f106c8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private
*i915)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
- if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
+ if (wait_for_engine(engine, 50)) {
+ GEM_WARN(1, "%s wait for idle timeout", engine->name);
>>>
>>> Nice touching adding the engine->name
>>> Reviewed-by: Chris Wilson
>>>
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h
b/drivers/gpu/drm/i915/i915_gem.h
index ee54597465b6..cefc6cf96a60 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,7 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
#define GEM_WARN_ON(expr) WARN_ON(expr)
+#define GEM_WARN(condition, format, ...) WARN(condition, format,
__VA_ARGS__)
#define GEM_DEBUG_DECL(var) var
#define GEM_DEBUG_EXEC(expr) expr
@@ -38,6 +39,7 @@
#else
#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
+#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
>>>
>>> WARNs can be used as part of an if(), so perhaps
>>>
>>> #define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition),
>>> 0)
>>> #define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
>>
>> Sorry, I just can't resist the "told you so" here.
>>
>> If you come up with a local pattern that's deceptively similar to a
>> widely used one, with the crucial difference that you can't use anything
>> with required side effects in it, you'll screw it up eventually.
>>
>> if (GEM_WARN_ON(wait_for_engine(engine, 50))) looks completely natural
>> and "obviously correct" in code, but is dead wrong. This won't be the
>> last time.
>
> I would also prefer to make it consistent.
>
> There are two other users of GEM_WARN_ON in i915_vma_bind to consider
> what to do with, but anyway it would be a much better solution.
My suggestion is to make GEM_WARN_ON and friends that are conditional to
CONFIG_DRM_I915_DEBUG_GEM unusable as expressions. Make them fail to
build within if (...) for both CONFIG_DRM_I915_DEBUG_GEM=y and =n. Then
if you need that kind of construct, handle it with something like:
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) && condition) {
GEM_WARN(...);
...
}
maybe wrapping that IS_ENABLED bit in a more manageable macro.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On 23/05/2017 12:07, Chris Wilson wrote:
On Tue, May 23, 2017 at 11:51:46AM +0100, Tvrtko Ursulin wrote:
On 23/05/2017 11:30, Chris Wilson wrote:
On Tue, May 23, 2017 at 11:09:17AM +0100, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:36:34AM +0100, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
I would also say
Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to idle from
seqno wrap")
as that's the patch that assumes wait_for_idle included the wait on
engines.
Hmm, actually that was only to prevent a DEBUG_GEM failure so not a
relevant citation for fixes?
And actually, this if for debug only code so the Fixes 25112b64b3d2 is
wrong as well as we as introducing a change in behaviour (making the
debug only code run all the time) with no urgent need for backporting.
Which part is for debug code only? Without it i915_gem_wait_for_idle
is left with no checking for irq idleness, but it only seqno based.
If that is what you say is debug only I think we need to mark it
better in the code.
The code for waiting on engines was added purely to solve an issue
created by GEM_BUG_ONs presuming a strict order between context-switch,
retirement and seqno update on wrap. It is not observable, i.e. has no
effect, outside of DRM_I915_DEBUG_GEM. This patch is introducing an
observable effect for production systems by declaring the machine wedged,
which is far more severe than the normal course of events to first try a
reset. I'm suggesting that we should be in no hurry to call set-wedged
here without first allowing it to percolate through linux-next.
But that means broken GEM_WARN_ON semantics were actually correct in
this case, even if non-obviously so. Which is why I said which should
mark it better in the code. And by that I mean the call site of
wait_engines in i915_gem_wait_for_idle should be #ifdef GEM_DEBUG (I
can't suggest GEM_WARN_ON!).
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 11:51:46AM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/2017 11:30, Chris Wilson wrote:
> >On Tue, May 23, 2017 at 11:09:17AM +0100, Chris Wilson wrote:
> >>On Tue, May 23, 2017 at 10:36:34AM +0100, Chris Wilson wrote:
> >>>On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Waiting for engines needs to happen even in the non-debug builds
> so it is incorrect to wrap it in a GEM_WARN_ON.
>
> Call it unconditionally and add GEM_WARN so that the debug
> warning can still be emitted when things go bad.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part
> of i915_gem_wait_for_idle()")
> >>>
> >>>I would also say
> >>>Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to
> >>>idle from seqno wrap")
> >>>as that's the patch that assumes wait_for_idle included the wait on
> >>>engines.
> >>
> >>Hmm, actually that was only to prevent a DEBUG_GEM failure so not a
> >>relevant citation for fixes?
> >
> >And actually, this if for debug only code so the Fixes 25112b64b3d2 is
> >wrong as well as we as introducing a change in behaviour (making the
> >debug only code run all the time) with no urgent need for backporting.
>
> Which part is for debug code only? Without it i915_gem_wait_for_idle
> is left with no checking for irq idleness, but it only seqno based.
> If that is what you say is debug only I think we need to mark it
> better in the code.
The code for waiting on engines was added purely to solve an issue
created by GEM_BUG_ONs presuming a strict order between context-switch,
retirement and seqno update on wrap. It is not observable, i.e. has no
effect, outside of DRM_I915_DEBUG_GEM. This patch is introducing an
observable effect for production systems by declaring the machine wedged,
which is far more severe than the normal course of events to first try a
reset. I'm suggesting that we should be in no hurry to call set-wedged
here without first allowing it to percolate through linux-next.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Convert i915_gem_object_ops->flags values to use BIT()
== Series Details == Series: drm/i915: Convert i915_gem_object_ops->flags values to use BIT() URL : https://patchwork.freedesktop.org/series/24823/ State : warning == Summary == Series 24823v1 drm/i915: Convert i915_gem_object_ops->flags values to use BIT() https://patchwork.freedesktop.org/api/1.0/series/24823/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-snb-2600) Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:585s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:517s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:419s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:418s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:574s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:464s fi-skl-6700hqtotal:278 pass:260 dwarn:1 dfail:0 fail:0 skip:17 time:569s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:468s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:498s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-snb-2600 total:278 pass:247 dwarn:1 dfail:0 fail:1 skip:29 time:410s f0db4d0afaead343e29f6c4609d4b912ad3304c1 drm-tip: 2017y-05m-23d-07h-43m-17s UTC integration manifest 70c68ba drm/i915: Convert i915_gem_object_ops->flags values to use BIT() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4784/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,v2,1/3] drm/i915: Remove misleading comment in request_alloc
On Tue, May 23, 2017 at 11:49:39AM +0100, Chris Wilson wrote: > On Tue, May 23, 2017 at 10:42:04AM -, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [CI,v2,1/3] drm/i915: Remove misleading > > comment in request_alloc > > URL : https://patchwork.freedesktop.org/series/24822/ > > State : failure > > > > == Summary == > > > > Series 24822v1 Series without cover letter > > https://patchwork.freedesktop.org/api/1.0/series/24822/revisions/1/mbox/ > > > > Test gem_exec_flush: > > Subgroup basic-batch-kernel-default-uc: > > pass -> FAIL (fi-snb-2600) fdo#17 > > Test kms_flip: > > Subgroup basic-flip-vs-dpms: > > dmesg-warn -> DMESG-FAIL (fi-skl-6700hq) fdo#101144 > > Subgroup basic-flip-vs-modeset: > > pass -> SKIP (fi-skl-6700hq) fdo#100867 > > Subgroup basic-flip-vs-wf_vblank: > > pass -> SKIP (fi-skl-6700hq) fdo#99739 > > Subgroup basic-plain-flip: > > pass -> SKIP (fi-skl-6700hq) > > ... > As scary as they are, they are not the result of this patch. > Someone needs to give fi-skl-6700hq a cup of tea and tell it to calm > down. And pushed to repair GuC after my breakage. Thanks for the fix, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On 23/05/2017 11:30, Chris Wilson wrote:
On Tue, May 23, 2017 at 11:09:17AM +0100, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:36:34AM +0100, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
I would also say
Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to idle from
seqno wrap")
as that's the patch that assumes wait_for_idle included the wait on
engines.
Hmm, actually that was only to prevent a DEBUG_GEM failure so not a
relevant citation for fixes?
And actually, this if for debug only code so the Fixes 25112b64b3d2 is
wrong as well as we as introducing a change in behaviour (making the
debug only code run all the time) with no urgent need for backporting.
Which part is for debug code only? Without it i915_gem_wait_for_idle is
left with no checking for irq idleness, but it only seqno based. If that
is what you say is debug only I think we need to mark it better in the code.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,v2,1/3] drm/i915: Remove misleading comment in request_alloc
On Tue, May 23, 2017 at 10:42:04AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,v2,1/3] drm/i915: Remove misleading comment > in request_alloc > URL : https://patchwork.freedesktop.org/series/24822/ > State : failure > > == Summary == > > Series 24822v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/24822/revisions/1/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> FAIL (fi-snb-2600) fdo#17 > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> DMESG-FAIL (fi-skl-6700hq) fdo#101144 > Subgroup basic-flip-vs-modeset: > pass -> SKIP (fi-skl-6700hq) fdo#100867 > Subgroup basic-flip-vs-wf_vblank: > pass -> SKIP (fi-skl-6700hq) fdo#99739 > Subgroup basic-plain-flip: > pass -> SKIP (fi-skl-6700hq) ... As scary as they are, they are not the result of this patch. Someone needs to give fi-skl-6700hq a cup of tea and tell it to calm down. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,v2,1/3] drm/i915: Remove misleading comment in request_alloc
== Series Details == Series: series starting with [CI,v2,1/3] drm/i915: Remove misleading comment in request_alloc URL : https://patchwork.freedesktop.org/series/24822/ State : failure == Summary == Series 24822v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/24822/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> DMESG-FAIL (fi-skl-6700hq) fdo#101144 Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-6700hq) fdo#100867 Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (fi-skl-6700hq) fdo#99739 Subgroup basic-plain-flip: pass -> SKIP (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: pass -> SKIP (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) Subgroup hang-read-crc-pipe-b: pass -> FAIL (fi-skl-6700hq) Subgroup hang-read-crc-pipe-c: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-a-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-b: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-c: pass -> FAIL (fi-skl-6700hq) Subgroup nonblocking-crc-pipe-c-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-a-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-b: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-b-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-c: pass -> FAIL (fi-skl-6700hq) Subgroup read-crc-pipe-c-frame-sequence: pass -> FAIL (fi-skl-6700hq) Subgroup suspend-read-crc-pipe-a: pass -> FAIL (fi-skl-6700hq) Subgroup suspend-read-crc-pipe-b: skip -> INCOMPLETE (fi-bsw-n3050) fdo#100989 Test pm_backlight: Subgroup basic-brightness: pass -> FAIL (fi-skl-6700hq) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#100867 https://bugs.freedesktop.org/show_bug.cgi?id=100867 fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739 fdo#100989 https://bugs.freedesktop.org/show_bug.cgi?id=100989 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:431s fi-bsw-n3050 total:236 pass:204 dwarn:0 dfail:0 fail:0 skip:31 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:495s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:492s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:488s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:423s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:452s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:553s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:443s fi-skl-6700hqtotal:278 pass:239 dwarn:0 dfail:1 fail:17 skip:21 time:426s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:490s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:420s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:409s f0db4d0afaead343e29f6c4609d4b912ad3304c1 drm-tip: 2017y-05m-23d-07h-43m-17s UTC integration manifes
[Intel-gfx] [PATCH v5 4/5] drm/i915/gvt: Dmabuf support for GVT-g
dmabuf for GVT-g can be exported to users who can use the dmabuf to show
the desktop of vm which use intel vgpu.
Currently we provide query and create new dmabuf operations.
Users of dmabuf can cache some created dmabufs and related information
such as the framebuffer's address, size, tiling mode, width, height etc.
When refresh the screen first query the currnet vgpu's frambuffer and
compare with the cached ones(address, size, tiling, width, height etc)
if found one then reuse the found dmabuf to gain performance improvment.
If there is no dmabuf created yet or not found in the cached dmabufs then
need to create a new dmabuf. To create a dmabuf first a gem object will
be created and the backing storage of this gem object is the vgpu's
framebuffer(primary/cursor).
Set caching mode, change tiling mode and set domains of this gem object
is not supported.
Then associate this gem object to a dmabuf and export this dmabuf.
A file descriptor will be generated for this dmabuf and this file
descriptor can be sent to user space to do display.
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/Makefile | 2 +-
drivers/gpu/drm/i915/gvt/dmabuf.c | 276 +
drivers/gpu/drm/i915/gvt/dmabuf.h | 53 +++
drivers/gpu/drm/i915/gvt/gvt.h | 1 +
drivers/gpu/drm/i915/i915_gem.c| 8 +
drivers/gpu/drm/i915/i915_gem_object.h | 9 ++
6 files changed, 348 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c
create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index 192ca26..e480f7d 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -2,7 +2,7 @@ GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
- fb_decoder.o
+ fb_decoder.o dmabuf.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) -Wall
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
new file mode 100644
index 000..415453b
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright 2017 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Zhiyuan Lv
+ *
+ * Contributors:
+ *Xiaoguang Chen
+ */
+
+#include
+#include
+
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define GEN8_DECODE_PTE(pte) \
+ ((dma_addr_t)(u64)pte) >> 12) & 0x7ffULL) << 12))
+
+static struct sg_table *intel_vgpu_gem_get_pages(
+ struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i, ret;
+ gen8_pte_t __iomem *gtt_entries;
+ unsigned int fb_gma = 0, fb_size = 0;
+ struct intel_vgpu_plane_info *plane_info;
+
+ plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
+ if (WARN_ON(!plane_info))
+ return ERR_PTR(-EINVAL);
+
+ fb_gma = plane_info->start;
+ fb_size = plane_info->size;
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st) {
+ ret = -ENOMEM;
+ return ERR_PTR(ret);
+ }
+
+ ret = sg_alloc_table(st, fb_size, GFP_KERNEL);
+ if (ret) {
+ kfree(st);
+ return ERR_PTR(ret);
+ }
+ gtt_entries = (gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
+ (fb_gma >> PAGE_SHIFT);
+ for_each_sg(st->sgl, sg, fb_size, i) {
+ sg->offset = 0;
+
[Intel-gfx] [PATCH v5 3/5] drm/i915/gvt: Frame buffer decoder support for GVT-g
decode frambuffer attributes of primary, cursor and sprite plane
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/Makefile | 3 +-
drivers/gpu/drm/i915/gvt/display.c| 2 +-
drivers/gpu/drm/i915/gvt/display.h| 2 +
drivers/gpu/drm/i915/gvt/fb_decoder.c | 479 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 170
drivers/gpu/drm/i915/gvt/gvt.h| 1 +
6 files changed, 655 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index b123c20..192ca26 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
- execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+ execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+ fb_decoder.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) -Wall
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index e0261fc..f5f63c5 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
}
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64
resolution);
void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
#endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..d4404fd
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,479 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Kevin Tian
+ *
+ * Contributors:
+ *Bing Niu
+ *Xu Han
+ *Ping Gao
+ *Xiaoguang Chen
+ *Yang Liu
+ *
+ */
+
+#include
+#include "i915_drv.h"
+#include "gvt.h"
+
+/* The below definitions are required by guest. */
+// [63:0] x:R:G:B 16:16:16:16 little endian
+#define DRM_FORMAT_XRGB161616_GVT fourcc_code('X', 'R', '4', '8')
+// [63:0] x:B:G:R 16:16:16:16 little endian
+#define DRM_FORMAT_XBGR161616_GVT fourcc_code('X', 'B', '4', '8')
+
+#define FORMAT_NUM 16
+struct pixel_format {
+ int drm_format; /* Pixel format in DRM definition */
+ int bpp;/* Bits per pixel, 0 indicates invalid */
+ char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format primary_pixel_formats[FORMAT_NUM] = {
+ [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+ [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+ [0x6] = {DRM_FORMAT_XRGB, 32,
+ "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+ [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+ "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
+ [0xa] = {DRM_FORMAT_XRGB2101010, 32,
+ "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xc] = {DRM_FORMAT_XRGB161616_
[Intel-gfx] [PATCH v5 2/5] drm/i915/gvt: OpRegion support for GVT-g
OpRegion is needed to support display related operation for
intel vgpu.
A vfio device region is added to intel vgpu to deliver the
host OpRegion information to user space so user space can
construct the OpRegion for vgpu.
Signed-off-by: Bing Niu
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c| 97 +
drivers/gpu/drm/i915/gvt/opregion.c | 8 ++-
2 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 3c6a02b..389f072 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,6 +53,8 @@ static const struct intel_gvt_ops *intel_gvt_ops;
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
#define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
+#define OPREGION_SIGNATURE "IntelGraphicsMem"
+
struct vfio_region;
struct intel_vgpu_regops {
size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
@@ -436,6 +438,92 @@ static void kvmgt_protect_table_del(struct
kvmgt_guest_info *info,
}
}
+static size_t intel_vgpu_reg_rw_opregion(struct intel_vgpu *vgpu, char *buf,
+ size_t count, loff_t *ppos, bool iswrite)
+{
+ unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) -
+ VFIO_PCI_NUM_REGIONS;
+ void *base = vgpu->vdev.region[i].data;
+ loff_t pos = *ppos & VFIO_PCI_OFFSET_MASK;
+
+ if (pos >= vgpu->vdev.region[i].size || iswrite) {
+ gvt_vgpu_err("invalid op or offset for Intel vgpu OpRegion\n");
+ return -EINVAL;
+ }
+ count = min(count, (size_t)(vgpu->vdev.region[i].size - pos));
+ memcpy(buf, base + pos, count);
+
+ return count;
+}
+
+static void intel_vgpu_reg_release_opregion(struct intel_vgpu *vgpu,
+ struct vfio_region *region)
+{
+ memunmap(region->data);
+}
+
+static const struct intel_vgpu_regops intel_vgpu_regops_opregion = {
+ .rw = intel_vgpu_reg_rw_opregion,
+ .release = intel_vgpu_reg_release_opregion,
+};
+
+static int intel_vgpu_register_reg(struct intel_vgpu *vgpu,
+ unsigned int type, unsigned int subtype,
+ const struct intel_vgpu_regops *ops,
+ size_t size, u32 flags, void *data)
+{
+ struct vfio_region *region;
+
+ region = krealloc(vgpu->vdev.region,
+ (vgpu->vdev.num_regions + 1) * sizeof(*region),
+ GFP_KERNEL);
+ if (!region)
+ return -ENOMEM;
+
+ vgpu->vdev.region = region;
+ vgpu->vdev.region[vgpu->vdev.num_regions].type = type;
+ vgpu->vdev.region[vgpu->vdev.num_regions].subtype = subtype;
+ vgpu->vdev.region[vgpu->vdev.num_regions].ops = ops;
+ vgpu->vdev.region[vgpu->vdev.num_regions].size = size;
+ vgpu->vdev.region[vgpu->vdev.num_regions].flags = flags;
+ vgpu->vdev.region[vgpu->vdev.num_regions].data = data;
+ vgpu->vdev.num_regions++;
+
+ return 0;
+}
+
+static int intel_vgpu_reg_init_opregion(struct intel_vgpu *vgpu)
+{
+ unsigned int addr;
+ void *base;
+ int ret;
+
+ addr = vgpu->gvt->opregion.opregion_pa;
+ if (!addr || !(~addr))
+ return -ENODEV;
+
+ base = memremap(addr, OPREGION_SIZE, MEMREMAP_WB);
+ if (!base)
+ return -ENOMEM;
+
+ if (memcmp(base, OPREGION_SIGNATURE, 16)) {
+ memunmap(base);
+ return -EINVAL;
+ }
+
+ ret = intel_vgpu_register_reg(vgpu,
+ PCI_VENDOR_ID_INTEL | VFIO_REGION_TYPE_PCI_VENDOR_TYPE,
+ VFIO_REGION_SUBTYPE_INTEL_IGD_OPREGION,
+ &intel_vgpu_regops_opregion, OPREGION_SIZE,
+ VFIO_REGION_INFO_FLAG_READ, base);
+ if (ret) {
+ memunmap(base);
+ return ret;
+ }
+
+ return ret;
+}
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -467,6 +555,15 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
vgpu->vdev.mdev = mdev;
mdev_set_drvdata(mdev, vgpu);
+ ret = intel_vgpu_reg_init_opregion(vgpu);
+ if (ret) {
+ gvt_vgpu_err("create OpRegion failed\n");
+ goto out;
+ }
+
+ gvt_dbg_core("create OpRegion succeeded for mdev:%s\n",
+ dev_name(mdev_dev(mdev)));
+
gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
dev_name(mdev_dev(mdev)));
ret = 0;
diff --git a/drivers/gpu/drm/i915/gvt/opregion.c
b/drivers/gpu/drm/i915/gvt/opregion.c
index 3117991..5c7496d 100644
--- a/drivers/gpu/drm/i915/gvt/opregion.c
+++ b/drivers/gpu/drm/i915/gvt/opregion.c
@@ -114,6 +114,7 @@ void intel_vgpu_clean_opregion(struct intel_vgpu *vgpu)
int intel_vgpu_in
[Intel-gfx] [PATCH v5 5/5] drm/i915/gvt: Adding interface so user space can get the dma-buf
User space will try to create a management fd for the dma-buf operation.
Using this management fd user can query the plane information and create
a dma-buf fd if necessary.
GVT-g will handle the life cycle of the management fd and will align the
life cycle of the fd with the vfio device.
User space should handle the life cycle of the created dma-buf fd close
the dma-buf fd timely when finishing use.
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 25
drivers/gpu/drm/i915/gvt/dmabuf.h | 21 ---
drivers/gpu/drm/i915/gvt/fb_decoder.h | 2 -
drivers/gpu/drm/i915/gvt/gvt.c| 2 +
drivers/gpu/drm/i915/gvt/gvt.h| 4 ++
drivers/gpu/drm/i915/gvt/kvmgt.c | 107 ++
include/uapi/linux/vfio.h | 50 +++-
7 files changed, 175 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 415453b..a72b86efb 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -29,6 +29,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "gvt.h"
@@ -45,9 +46,9 @@ static struct sg_table *intel_vgpu_gem_get_pages(
int i, ret;
gen8_pte_t __iomem *gtt_entries;
unsigned int fb_gma = 0, fb_size = 0;
- struct intel_vgpu_plane_info *plane_info;
+ struct plane_info *plane_info;
- plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
+ plane_info = (struct plane_info *)obj->gvt_plane_info;
if (WARN_ON(!plane_info))
return ERR_PTR(-EINVAL);
@@ -81,9 +82,9 @@ static struct sg_table *intel_vgpu_gem_get_pages(
static void intel_vgpu_gem_put_pages(struct drm_i915_gem_object *obj,
struct sg_table *pages)
{
- struct intel_vgpu_plane_info *plane_info;
+ struct plane_info *plane_info;
- plane_info = (struct intel_vgpu_plane_info *)obj->gvt_plane_info;
+ plane_info = (struct plane_info *)obj->gvt_plane_info;
if (WARN_ON(!plane_info))
return;
@@ -98,7 +99,7 @@ static const struct drm_i915_gem_object_ops
intel_vgpu_gem_ops = {
};
static struct drm_i915_gem_object *intel_vgpu_create_gem(struct drm_device
*dev,
- struct intel_vgpu_plane_info *info)
+ struct plane_info *info)
{
struct drm_i915_private *pri = dev->dev_private;
struct drm_i915_gem_object *obj;
@@ -141,14 +142,14 @@ static struct drm_i915_gem_object
*intel_vgpu_create_gem(struct drm_device *dev,
return obj;
}
-static struct intel_vgpu_plane_info *intel_vgpu_get_plane_info(
+static struct plane_info *intel_vgpu_get_plane_info(
struct drm_device *dev,
struct intel_vgpu *vgpu, uint32_t plane_id)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_vgpu_primary_plane_format *p;
struct intel_vgpu_cursor_plane_format *c;
- struct intel_vgpu_plane_info *info;
+ struct plane_info *info;
struct intel_vgpu_pipe_format *pipe;
info = kmalloc(sizeof(*info), GFP_KERNEL);
@@ -159,7 +160,7 @@ static struct intel_vgpu_plane_info
*intel_vgpu_get_plane_info(
if (pipe == NULL)
return NULL;
- if (plane_id == INTEL_GVT_PLANE_PRIMARY) {
+ if (plane_id == VFIO_PRIMARY_PLANE) {
p = &pipe->primary;
if (p != NULL) {
info->start = p->base;
@@ -175,7 +176,7 @@ static struct intel_vgpu_plane_info
*intel_vgpu_get_plane_info(
gvt_vgpu_err("invalid primary plane\n");
return NULL;
}
- } else if (plane_id == INTEL_GVT_PLANE_CURSOR) {
+ } else if (plane_id == VFIO_CURSOR_PLANE) {
c = &pipe->cursor;
if (c != NULL) {
info->start = c->base;
@@ -228,7 +229,7 @@ static struct intel_vgpu_plane_info
*intel_vgpu_get_plane_info(
int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void *args)
{
struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
- struct intel_vgpu_plane_info *info = args;
+ struct plane_info *info = args;
info = intel_vgpu_get_plane_info(dev, vgpu, info->plane_id);
if (info == NULL)
@@ -242,8 +243,8 @@ int intel_vgpu_create_dmabuf(struct intel_vgpu *vgpu, void
*args)
struct dma_buf *dmabuf;
struct drm_i915_gem_object *obj;
struct drm_device *dev = &vgpu->gvt->dev_priv->drm;
- struct intel_vgpu_dmabuf *gvt_dmabuf = args;
- struct intel_vgpu_plane_info *info;
+ struct dmabuf_info *gvt_dmabuf = args;
+ struct plane_info *info;
int ret;
info = intel_vgpu_get_plane_info(dev, vgpu,
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
b/drivers/gpu/drm/i915/gvt/dmabuf.h
index 43562af..e49bd4f 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.h
+++ b/dr
[Intel-gfx] [PATCH v5 0/5] drm/i915/gvt: Dma-buf support for GVT-g
v4->v5: 1) fix bug while checking whether the gem obj is gvt's dma-buf when user change caching mode or domains. Add a helper function to do it. 2) add definition for the query plane and create dma-buf. v3->v4: 1) fix bug while checking whether the gem obj is gvt's dma-buf when set caching mode or doamins. v2->v3: 1) add a field gvt_plane_info in the drm_i915_gem_obj structure to save the decoded plane information to avoid look up while need the plane info. 2) declare a new flag I915_GEM_OBJECT_IS_GVT_DMABUF in drm_i915_gem_object to represent the gem obj for gvt's dma-buf. The tiling mode, caching mode and domains can not be changed for this kind of gem object. 3) change dma-buf related information to be more generic. So other vendor can use the same interface. v1->v2: 1) create a management fd for dma-buf operations. 2) alloc gem object's backing storage in gem obj's get_pages() callback. This patch set adds the dma-buf support for intel GVT-g. dma-buf is a uniform mechanism to share DMA buffers across different devices and sub-systems. dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer to other users or sub-systems so they can use the dma-buf to show the desktop of a vm which uses intel vgpu. The main idea is we create a gem object and set vgpu's framebuffer as the backing storage of this gem object. And associate this gem obj to a dma-buf object then export this dma-buf at the meantime generate a file descriptor for this dma-buf. Finally deliver this file descriptor to user space. And user can use this dma-buf fd to do render or other operations. User need to create a fd(for intel GVT-g dma-buf support it is a:dma-buf management fd) then user can use this fd to query the plane information or create a dma-buf. The life cycle of this fd is managed by GVT-g user do not need to care about that. We have an example program on how to use the dma-buf. You can download the program to have a try. Good luck :) git repo: https://github.com/01org/igvtg-qemu branch:kvmgt_dmabuf_example Xiaoguang Chen (5): drm/i915/gvt: Extend the GVT-g architecture to support vfio device region drm/i915/gvt: OpRegion support for GVT-g drm/i915/gvt: Frame buffer decoder support for GVT-g drm/i915/gvt: Dmabuf support for GVT-g drm/i915/gvt: Adding interface so user space can get the dma-buf drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c | 2 +- drivers/gpu/drm/i915/gvt/display.h | 2 + drivers/gpu/drm/i915/gvt/dmabuf.c | 277 +++ drivers/gpu/drm/i915/gvt/dmabuf.h | 32 +++ drivers/gpu/drm/i915/gvt/fb_decoder.c | 479 + drivers/gpu/drm/i915/gvt/fb_decoder.h | 168 drivers/gpu/drm/i915/gvt/gvt.c | 2 + drivers/gpu/drm/i915/gvt/gvt.h | 6 + drivers/gpu/drm/i915/gvt/kvmgt.c | 225 +++- drivers/gpu/drm/i915/gvt/opregion.c| 8 +- drivers/gpu/drm/i915/i915_gem.c| 8 + drivers/gpu/drm/i915/i915_gem_object.h | 9 + include/uapi/linux/vfio.h | 50 +++- 14 files changed, 1264 insertions(+), 7 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.c create mode 100644 drivers/gpu/drm/i915/gvt/dmabuf.h create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/5] drm/i915/gvt: Extend the GVT-g architecture to support vfio device region
Signed-off-by: Xiaoguang Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 1ae0b40..3c6a02b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -53,11 +53,21 @@ static const struct intel_gvt_ops *intel_gvt_ops;
#define VFIO_PCI_INDEX_TO_OFFSET(index) ((u64)(index) << VFIO_PCI_OFFSET_SHIFT)
#define VFIO_PCI_OFFSET_MASK(((u64)(1) << VFIO_PCI_OFFSET_SHIFT) - 1)
+struct vfio_region;
+struct intel_vgpu_regops {
+ size_t (*rw)(struct intel_vgpu *vgpu, char *buf,
+ size_t count, loff_t *ppos, bool iswrite);
+ void (*release)(struct intel_vgpu *vgpu,
+ struct vfio_region *region);
+};
+
struct vfio_region {
u32 type;
u32 subtype;
size_t size;
u32 flags;
+ const struct intel_vgpu_regops *ops;
+ void*data;
};
struct kvmgt_pgfn {
@@ -642,7 +652,7 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev, char
*buf,
int ret = -EINVAL;
- if (index >= VFIO_PCI_NUM_REGIONS) {
+ if (index >= VFIO_PCI_NUM_REGIONS + vgpu->vdev.num_regions) {
gvt_vgpu_err("invalid index: %u\n", index);
return -EINVAL;
}
@@ -676,8 +686,11 @@ static ssize_t intel_vgpu_rw(struct mdev_device *mdev,
char *buf,
case VFIO_PCI_BAR5_REGION_INDEX:
case VFIO_PCI_VGA_REGION_INDEX:
case VFIO_PCI_ROM_REGION_INDEX:
+ break;
default:
- gvt_vgpu_err("unsupported region: %u\n", index);
+ index -= VFIO_PCI_NUM_REGIONS;
+ return vgpu->vdev.region[index].ops->rw(vgpu, buf, count,
+ ppos, is_write);
}
return ret == 0 ? count : ret;
@@ -940,7 +953,8 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
info.flags = VFIO_DEVICE_FLAGS_PCI;
info.flags |= VFIO_DEVICE_FLAGS_RESET;
- info.num_regions = VFIO_PCI_NUM_REGIONS;
+ info.num_regions = VFIO_PCI_NUM_REGIONS +
+ vgpu->vdev.num_regions;
info.num_irqs = VFIO_PCI_NUM_IRQS;
return copy_to_user((void __user *)arg, &info, minsz) ?
@@ -1061,6 +1075,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
}
if (caps.size) {
+ info.flags |= VFIO_REGION_INFO_FLAG_CAPS;
if (info.argsz < sizeof(info) + caps.size) {
info.argsz = sizeof(info) + caps.size;
info.cap_offset = 0;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Convert i915_gem_object_ops->flags values to use BIT()
Having just watched someone add a new value, 0x3, without realising that
the flags were bit values, I have come to appreciate the value in using
BIT.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_object.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index 174cf923c236..35e1a27729dc 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -37,8 +37,8 @@
struct drm_i915_gem_object_ops {
unsigned int flags;
-#define I915_GEM_OBJECT_HAS_STRUCT_PAGE 0x1
-#define I915_GEM_OBJECT_IS_SHRINKABLE 0x2
+#define I915_GEM_OBJECT_HAS_STRUCT_PAGE BIT(0)
+#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 11:09:17AM +0100, Chris Wilson wrote:
> On Tue, May 23, 2017 at 10:36:34AM +0100, Chris Wilson wrote:
> > On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Waiting for engines needs to happen even in the non-debug builds
> > > so it is incorrect to wrap it in a GEM_WARN_ON.
> > >
> > > Call it unconditionally and add GEM_WARN so that the debug
> > > warning can still be emitted when things go bad.
> > >
> > > Signed-off-by: Tvrtko Ursulin
> > > Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part
> > > of i915_gem_wait_for_idle()")
> >
> > I would also say
> > Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to
> > idle from seqno wrap")
> > as that's the patch that assumes wait_for_idle included the wait on
> > engines.
>
> Hmm, actually that was only to prevent a DEBUG_GEM failure so not a
> relevant citation for fixes?
And actually, this if for debug only code so the Fixes 25112b64b3d2 is
wrong as well as we as introducing a change in behaviour (making the
debug only code run all the time) with no urgent need for backporting.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] HAX: Enable GuC submission for CI
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..9dcc8a0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_loading = 0,
- .enable_guc_submission = 0,
+ .enable_guc_loading = 1,
+ .enable_guc_submission = 1,
.guc_log_level = -1,
.guc_firmware_path = NULL,
.huc_firmware_path = NULL,
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v2 1/3] drm/i915: Remove misleading comment in request_alloc
Passing NULL ctx to request_alloc would lead to null-ptr-deref. v2: Let's not replace the comment with a BUG_ON Signed-off-by: Michał Winiarski Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index 1ccf252..0d1e0d8 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -538,9 +538,6 @@ submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state) * * @engine: engine that we wish to issue the request on. * @ctx: context that the request will be associated with. - * This can be NULL if the request is not directly related to - * any specific user context, in which case this function will - * choose an appropriate context to use. * * Returns a pointer to the allocated request if successful, * or an error code if not. -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/guc: Skip port assign on first iteration of GuC dequeue
If port[0] is occupied and we're trying to dequeue request from
different context, we will inevitably hit BUG_ON in port_assign.
Let's skip it - similar to what we're doing in execlists counterpart.
Fixes: 77f0d0e925e8a0 ("drm/i915/execlists: Pack the count into the low bits of
the port.request")
Cc: Chris Wilson
Cc: Michał Wajdeczko
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Signed-off-by: Michał Winiarski
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 777f48e..e6e0c6e 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -681,7 +681,8 @@ static bool i915_guc_dequeue(struct intel_engine_cs *engine)
goto done;
}
- port_assign(port, last);
+ if (submit)
+ port_assign(port, last);
port++;
}
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 10:36:34AM +0100, Chris Wilson wrote:
> On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Waiting for engines needs to happen even in the non-debug builds
> > so it is incorrect to wrap it in a GEM_WARN_ON.
> >
> > Call it unconditionally and add GEM_WARN so that the debug
> > warning can still be emitted when things go bad.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
> > i915_gem_wait_for_idle()")
>
> I would also say
> Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to idle
> from seqno wrap")
> as that's the patch that assumes wait_for_idle included the wait on
> engines.
Hmm, actually that was only to prevent a DEBUG_GEM failure so not a
relevant citation for fixes?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On 23/05/2017 10:56, Jani Nikula wrote:
On Tue, 23 May 2017, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Reported-by: Nick Desaulniers
Cc: Nick Desaulniers
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a637cc05cc4a..ecaa21f106c8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private *i915)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
- if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
+ if (wait_for_engine(engine, 50)) {
+ GEM_WARN(1, "%s wait for idle timeout", engine->name);
Nice touching adding the engine->name
Reviewed-by: Chris Wilson
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index ee54597465b6..cefc6cf96a60 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,7 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
#define GEM_WARN_ON(expr) WARN_ON(expr)
+#define GEM_WARN(condition, format, ...) WARN(condition, format, __VA_ARGS__)
#define GEM_DEBUG_DECL(var) var
#define GEM_DEBUG_EXEC(expr) expr
@@ -38,6 +39,7 @@
#else
#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
+#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
WARNs can be used as part of an if(), so perhaps
#define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
#define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
Sorry, I just can't resist the "told you so" here.
If you come up with a local pattern that's deceptively similar to a
widely used one, with the crucial difference that you can't use anything
with required side effects in it, you'll screw it up eventually.
if (GEM_WARN_ON(wait_for_engine(engine, 50))) looks completely natural
and "obviously correct" in code, but is dead wrong. This won't be the
last time.
I would also prefer to make it consistent.
There are two other users of GEM_WARN_ON in i915_vma_bind to consider
what to do with, but anyway it would be a much better solution.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
Hi Yaroslav Shabalin, This restriction is only for PSR2. Will provide the fix. Regards, Vathsala From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Yaroslav Shabalin Sent: Tuesday, May 23, 2017 4:59 AM To: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20 Hi! I'm not sure if this is suitable way to report bugs but seems that this change breaks PSR support on my laptop. I have Dell XPS 15 9550 with Skylake i7-6700HQ CPU, 4K screen resolution (3840x2160) and Arch Linux installed. Having i915.enable_psr=1 boot parameter on kernels <= 4.10 I get the following: -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: yes Enabled: yes Active: yes Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: yes However on kernel 4.11 (which I believe has this commit merged) PSR is not enabled with native screen resolution. -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: no Enabled: no Active: no Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: no If I change resolution to lower value (i.e. 3200x1800) PSR gets enabled as on <= 4.10 kernel. That is very sad because without PSR CPU never goes deeper than PC7 increasing idle power consumption by ~1W. I would really appreciate if someone investigate this issue. Is this resolution restriction really needed and should block PSR fully? Seems that on older kernels it wasn't a problem. Please let me know if you need any additional diagnostic information. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
Hi! I'm not sure if this is suitable way to report bugs but seems that this change breaks PSR support on my laptop. I have Dell XPS 15 9550 with Skylake i7-6700HQ CPU, 4K screen resolution (3840x2160) and Arch Linux installed. Having i915.enable_psr=1 boot parameter on kernels <= 4.10 I get the following: -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: yes Enabled: yes Active: yes Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: yes However on kernel 4.11 (which I believe has this commit merged) PSR is not enabled with native screen resolution. -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: no Enabled: no Active: no Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: no If I change resolution to lower value (i.e. 3200x1800) PSR gets enabled as on <= 4.10 kernel. That is very sad because without PSR CPU never goes deeper than PC7 increasing idle power consumption by ~1W. I would really appreciate if someone investigate this issue. Is this resolution restriction really needed and should block PSR fully? Seems that on older kernels it wasn't a problem. Please let me know if you need any additional diagnostic information. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, 23 May 2017, Chris Wilson wrote:
> On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> Waiting for engines needs to happen even in the non-debug builds
>> so it is incorrect to wrap it in a GEM_WARN_ON.
>>
>> Call it unconditionally and add GEM_WARN so that the debug
>> warning can still be emitted when things go bad.
>>
>> Signed-off-by: Tvrtko Ursulin
>> Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
>> i915_gem_wait_for_idle()")
>> Cc: Chris Wilson
>> Cc: Joonas Lahtinen
>> Cc: Daniel Vetter
>> Cc: Jani Nikula
>> Cc: intel-gfx@lists.freedesktop.org
>> Reported-by: Nick Desaulniers
>> Cc: Nick Desaulniers
>> ---
>> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
>> drivers/gpu/drm/i915/i915_gem.h | 2 ++
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index a637cc05cc4a..ecaa21f106c8 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private
>> *i915)
>> enum intel_engine_id id;
>>
>> for_each_engine(engine, i915, id) {
>> -if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
>> +if (wait_for_engine(engine, 50)) {
>> +GEM_WARN(1, "%s wait for idle timeout", engine->name);
>
> Nice touching adding the engine->name
> Reviewed-by: Chris Wilson
>
>> i915_gem_set_wedged(i915);
>> return -EIO;
>> }
>> diff --git a/drivers/gpu/drm/i915/i915_gem.h
>> b/drivers/gpu/drm/i915/i915_gem.h
>> index ee54597465b6..cefc6cf96a60 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.h
>> +++ b/drivers/gpu/drm/i915/i915_gem.h
>> @@ -30,6 +30,7 @@
>> #ifdef CONFIG_DRM_I915_DEBUG_GEM
>> #define GEM_BUG_ON(expr) BUG_ON(expr)
>> #define GEM_WARN_ON(expr) WARN_ON(expr)
>> +#define GEM_WARN(condition, format, ...) WARN(condition, format,
>> __VA_ARGS__)
>>
>> #define GEM_DEBUG_DECL(var) var
>> #define GEM_DEBUG_EXEC(expr) expr
>> @@ -38,6 +39,7 @@
>> #else
>> #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
>> #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
>> +#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
>
> WARNs can be used as part of an if(), so perhaps
>
> #define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
> #define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
Sorry, I just can't resist the "told you so" here.
If you come up with a local pattern that's deceptively similar to a
widely used one, with the crucial difference that you can't use anything
with required side effects in it, you'll screw it up eventually.
if (GEM_WARN_ON(wait_for_engine(engine, 50))) looks completely natural
and "obviously correct" in code, but is dead wrong. This won't be the
last time.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 10:45:44AM +0100, Tvrtko Ursulin wrote:
>
> On 23/05/2017 10:29, Chris Wilson wrote:
> >On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Waiting for engines needs to happen even in the non-debug builds
> >>so it is incorrect to wrap it in a GEM_WARN_ON.
> >>
> >>Call it unconditionally and add GEM_WARN so that the debug
> >>warning can still be emitted when things go bad.
> >>
> >>Signed-off-by: Tvrtko Ursulin
> >>Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
> >>i915_gem_wait_for_idle()")
> >>Cc: Chris Wilson
> >>Cc: Joonas Lahtinen
> >>Cc: Daniel Vetter
> >>Cc: Jani Nikula
> >>Cc: intel-gfx@lists.freedesktop.org
> >>Reported-by: Nick Desaulniers
> >>Cc: Nick Desaulniers
> >>---
> >> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> >> drivers/gpu/drm/i915/i915_gem.h | 2 ++
> >> 2 files changed, 4 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>b/drivers/gpu/drm/i915/i915_gem.c
> >>index a637cc05cc4a..ecaa21f106c8 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>@@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private
> >>*i915)
> >>enum intel_engine_id id;
> >>
> >>for_each_engine(engine, i915, id) {
> >>- if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
> >>+ if (wait_for_engine(engine, 50)) {
> >>+ GEM_WARN(1, "%s wait for idle timeout", engine->name);
> >
> >Nice touching adding the engine->name
> >Reviewed-by: Chris Wilson
> >
> >>i915_gem_set_wedged(i915);
> >>return -EIO;
> >>}
> >>diff --git a/drivers/gpu/drm/i915/i915_gem.h
> >>b/drivers/gpu/drm/i915/i915_gem.h
> >>index ee54597465b6..cefc6cf96a60 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem.h
> >>+++ b/drivers/gpu/drm/i915/i915_gem.h
> >>@@ -30,6 +30,7 @@
> >> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> >> #define GEM_BUG_ON(expr) BUG_ON(expr)
> >> #define GEM_WARN_ON(expr) WARN_ON(expr)
> >>+#define GEM_WARN(condition, format, ...) WARN(condition, format,
> >>__VA_ARGS__)
> >>
> >> #define GEM_DEBUG_DECL(var) var
> >> #define GEM_DEBUG_EXEC(expr) expr
> >>@@ -38,6 +39,7 @@
> >> #else
> >> #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> >> #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
> >>+#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
> >
> >WARNs can be used as part of an if(), so perhaps
> >
> >#define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
> >#define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
>
> Doesn't work for statements. :( I don't know, more compiler trickery
> needed...
Unless it turns out to be easy, go with simple and we can play later
when needed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On 23/05/2017 10:29, Chris Wilson wrote:
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Reported-by: Nick Desaulniers
Cc: Nick Desaulniers
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a637cc05cc4a..ecaa21f106c8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private *i915)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
- if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
+ if (wait_for_engine(engine, 50)) {
+ GEM_WARN(1, "%s wait for idle timeout", engine->name);
Nice touching adding the engine->name
Reviewed-by: Chris Wilson
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index ee54597465b6..cefc6cf96a60 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,7 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
#define GEM_WARN_ON(expr) WARN_ON(expr)
+#define GEM_WARN(condition, format, ...) WARN(condition, format, __VA_ARGS__)
#define GEM_DEBUG_DECL(var) var
#define GEM_DEBUG_EXEC(expr) expr
@@ -38,6 +39,7 @@
#else
#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
+#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
WARNs can be used as part of an if(), so perhaps
#define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
#define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
Doesn't work for statements. :( I don't know, more compiler trickery
needed...
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable GEN9LP decoupled mmio
On Tue, 23 May 2017, Tvrtko Ursulin wrote:
> On 23/05/2017 01:18, kai.c...@intel.com wrote:
>> From: Kai Chen
>>
>> This change is used as a backport fix from top of drm-intel ([PATCH]
>> drm/i915: Disable decoupled mmio for GEN9LP) to disable decoupled mmio
>> on GEN9LP for those shipped kernels as a quick fix.
>
> Should we have a more complete commit message for the backportable
> commit instead? Perhaps copy the one from the full patch, and change it
> there to refer to this one and explain that it is removing previously
> disabled code?
>
> For example:
>
> """
> The decoupled mmio feature doesn't work as intended by HW team. Enabling
> it with forcewake will only make debugging efforts more difficult, so
> let's disable it.
> """
I want a two-patch series, with this patch here as 1/2, with the dim
fixes blob and cc: stable from below, and a proper commit message. Patch
2/2 is the other patch with the dead code removal, on top of this one.
BR,
Jani.
>
>
>> V2:
>> - Add signed-off-by
>>
>> Signed-off-by: Kai Chen
>
> Adding the dim fixes blob:
>
> Fixes: 85ee17ebeedd ("drm/i915/bxt: Broxton decoupled MMIO")
> Cc: Zhe Wang
> Cc: Praveen Paneri
> Cc: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.10+
>
> Regards,
>
> Tvrtko
>
>> ---
>> drivers/gpu/drm/i915/i915_pci.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index f80db2c..cf43dc1 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -385,7 +385,6 @@ static const struct intel_device_info
>> intel_skylake_gt3_info = {
>> .has_gmbus_irq = 1, \
>> .has_logical_ring_contexts = 1, \
>> .has_guc = 1, \
>> -.has_decoupled_mmio = 1, \
>> .has_aliasing_ppgtt = 1, \
>> .has_full_ppgtt = 1, \
>> .has_full_48bit_ppgtt = 1, \
>>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Waiting for engines needs to happen even in the non-debug builds
> so it is incorrect to wrap it in a GEM_WARN_ON.
>
> Call it unconditionally and add GEM_WARN so that the debug
> warning can still be emitted when things go bad.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
> i915_gem_wait_for_idle()")
I would also say
Fixes: 7a453fb82f86 ("drm/i915: Remove redudant wait for each engine to idle
from seqno wrap")
as that's the patch that assumes wait_for_idle included the wait on
engines.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix waiting for engines to idle
== Series Details == Series: drm/i915: Fix waiting for engines to idle URL : https://patchwork.freedesktop.org/series/24821/ State : success == Summary == Series 24821v1 drm/i915: Fix waiting for engines to idle https://patchwork.freedesktop.org/api/1.0/series/24821/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:451s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:433s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:586s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:495s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:491s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:564s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:278 pass:260 dwarn:1 dfail:0 fail:0 skip:17 time:576s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:468s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:508s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:415s f0db4d0afaead343e29f6c4609d4b912ad3304c1 drm-tip: 2017y-05m-23d-07h-43m-17s UTC integration manifest f7002d6 drm/i915: Fix waiting for engines to idle == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4782/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/14] drm/i915/perf: add GLK support
On 22/05/17 20:04, Matthew Auld wrote: On 05/17, Lionel Landwerlin wrote: Signed-off-by: Lionel Landwerlin Hmm, are we not missing the GEN9_OA_DEBUG_DISABLE_CLK_RATIO_REPORTS part, so disabling slice/unslice clock ratio change reports, like we do on all other gen9 platforms? Ah yes, thanks! For the timestamp base are we just assuming it's the same as BXT, or did you find it somewhere in the bspec, because I had no such luck? Yes, but you can actually verify this experimentally. The oa-exponents IGT tests will fail if that's not correct. Otherwise assuming the configs are indeed correct and with a proper commit message: Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
On Tue, May 23, 2017 at 10:19:31AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Waiting for engines needs to happen even in the non-debug builds
> so it is incorrect to wrap it in a GEM_WARN_ON.
>
> Call it unconditionally and add GEM_WARN so that the debug
> warning can still be emitted when things go bad.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
> i915_gem_wait_for_idle()")
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
> Reported-by: Nick Desaulniers
> Cc: Nick Desaulniers
> ---
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> drivers/gpu/drm/i915/i915_gem.h | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a637cc05cc4a..ecaa21f106c8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private
> *i915)
> enum intel_engine_id id;
>
> for_each_engine(engine, i915, id) {
> - if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
> + if (wait_for_engine(engine, 50)) {
> + GEM_WARN(1, "%s wait for idle timeout", engine->name);
Nice touching adding the engine->name
Reviewed-by: Chris Wilson
> i915_gem_set_wedged(i915);
> return -EIO;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
> index ee54597465b6..cefc6cf96a60 100644
> --- a/drivers/gpu/drm/i915/i915_gem.h
> +++ b/drivers/gpu/drm/i915/i915_gem.h
> @@ -30,6 +30,7 @@
> #ifdef CONFIG_DRM_I915_DEBUG_GEM
> #define GEM_BUG_ON(expr) BUG_ON(expr)
> #define GEM_WARN_ON(expr) WARN_ON(expr)
> +#define GEM_WARN(condition, format, ...) WARN(condition, format, __VA_ARGS__)
>
> #define GEM_DEBUG_DECL(var) var
> #define GEM_DEBUG_EXEC(expr) expr
> @@ -38,6 +39,7 @@
> #else
> #define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
> #define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
> +#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
WARNs can be used as part of an if(), so perhaps
#define GEM_WARN(condition, format, ...) (BUILD_BUG_ON_INVALID(condition), 0)
#define GEM_WARN_ON(expr) GEM_WARN((expr), 0)
?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
Hi Shablin, I will look In to it and provide the fix. Regards, Vathsala From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Yaroslav Shabalin Sent: Tuesday, May 23, 2017 2:45 PM To: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20 Hi! I'm not sure if this is suitable way to report bugs but seems that this change (https://github.com/torvalds/linux/commit/acf45d11050abd751dcec986ab121cb2367dcbba) breaks PSR support on my laptop. I have Dell XPS 15 9550 with Skylake i7-6700HQ CPU, 4K screen resolution (3840x2160) and Arch Linux installed. Adding i915.enable_psr=1 boot parameter on kernels <= 4.10 I get the following: -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: yes Enabled: yes Active: yes Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: yes However on kernel 4.11 (which I believe has this commit merged) PSR is not enabled with native screen resolution. -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: no Enabled: no Active: no Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: no If I change resolution to lower value (i.e. 3200x1800) PSR gets enabled as on <= 4.10 kernel. That is very sad because without PSR CPU never goes deeper than PC7 adding ~1W to idle power consumption. I would really appreciate if someone investigate this issue. Is this resolution restriction really needed and should block PSR fully? Seems that on older kernels it wasn't a problem. Please let me know if you need any additional diagnostic information. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix waiting for engines to idle
From: Tvrtko Ursulin
Waiting for engines needs to happen even in the non-debug builds
so it is incorrect to wrap it in a GEM_WARN_ON.
Call it unconditionally and add GEM_WARN so that the debug
warning can still be emitted when things go bad.
Signed-off-by: Tvrtko Ursulin
Fixes: 25112b64b3d2 ("drm/i915: Wait for all engines to be idle as part of
i915_gem_wait_for_idle()")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Reported-by: Nick Desaulniers
Cc: Nick Desaulniers
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a637cc05cc4a..ecaa21f106c8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3332,7 +3332,8 @@ static int wait_for_engines(struct drm_i915_private *i915)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
- if (GEM_WARN_ON(wait_for_engine(engine, 50))) {
+ if (wait_for_engine(engine, 50)) {
+ GEM_WARN(1, "%s wait for idle timeout", engine->name);
i915_gem_set_wedged(i915);
return -EIO;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index ee54597465b6..cefc6cf96a60 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,7 @@
#ifdef CONFIG_DRM_I915_DEBUG_GEM
#define GEM_BUG_ON(expr) BUG_ON(expr)
#define GEM_WARN_ON(expr) WARN_ON(expr)
+#define GEM_WARN(condition, format, ...) WARN(condition, format, __VA_ARGS__)
#define GEM_DEBUG_DECL(var) var
#define GEM_DEBUG_EXEC(expr) expr
@@ -38,6 +39,7 @@
#else
#define GEM_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#define GEM_WARN_ON(expr) (BUILD_BUG_ON_INVALID(expr), 0)
+#define GEM_WARN(condition, format, ...) BUILD_BUG_ON_INVALID(condition)
#define GEM_DEBUG_DECL(var)
#define GEM_DEBUG_EXEC(expr) do { } while (0)
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: disable psr2 for resolution greater than 32X20
Hi! I'm not sure if this is suitable way to report bugs but seems that this change ( https://github.com/torvalds/linux/commit/acf45d11050abd751dcec986ab121cb2367dcbba) breaks PSR support on my laptop. I have Dell XPS 15 9550 with Skylake i7-6700HQ CPU, 4K screen resolution (3840x2160) and Arch Linux installed. Adding i915.enable_psr=1 boot parameter on kernels <= 4.10 I get the following: -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: yes Enabled: yes Active: yes Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: yes However on kernel 4.11 (which I believe has this commit merged) PSR is not enabled with native screen resolution. -> cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes Source_OK: no Enabled: no Active: no Busy frontbuffer bits: 0x000 Re-enable work scheduled: no Main link in standby mode: no HW Enabled & Active bit: no If I change resolution to lower value (i.e. 3200x1800) PSR gets enabled as on <= 4.10 kernel. That is very sad because without PSR CPU never goes deeper than PC7 adding ~1W to idle power consumption. I would really appreciate if someone investigate this issue. Is this resolution restriction really needed and should block PSR fully? Seems that on older kernels it wasn't a problem. Please let me know if you need any additional diagnostic information. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
On Mon, May 22, 2017 at 11:07:25AM -0700, Jon Bloomfield wrote: > BXT requires accesses to the GTT (i.e. PTE updates) to be serialized > when IOMMU is enabled. This patch guarantees this by wrapping all > updates in stop_machine and using a flushing read to guarantee that > the GTT writes have reached their destination before restarting. > Testcase? igt/gem_concurrent_blit shows the failure. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: mark wait_for_engine() __maybe_unused
Hi,
On 21/05/2017 05:03, Nick Desaulniers wrote:
This solves a warning when compiling the driver with Clang, -Werror enabled,
and CONFIG_DRM_I915_DEBUG_GEM unset, since Clang warns that:
drivers/gpu/drm/i915/i915_gem.c:3274:12: error: function
'wait_for_engine' is not needed
and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static int wait_for_engine(struct intel_engine_cs *engine, int
timeout_ms)
^
You have actually uncovered a bug here where the call is not supposed to
be optional in the first place. I'll send a different fix and copy you
on it.
Regards,
Tvrtko
Signed-off-by: Nick Desaulniers
---
Additionally, it only has one call site. Should I mark it inline, too, while
I'm at it?
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b6ac3df18b58..73b82fb94b0e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3271,7 +3271,8 @@ static int wait_for_timeline(struct i915_gem_timeline
*tl, unsigned int flags)
return 0;
}
-static int wait_for_engine(struct intel_engine_cs *engine, int timeout_ms)
+static __maybe_unused int wait_for_engine(
+ struct intel_engine_cs *engine, int timeout_ms)
{
return wait_for(intel_engine_is_idle(engine), timeout_ms);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915/guc: Skip port assign on first iteration of GuC dequeue
On Tue, May 23, 2017 at 12:07:49AM +0200, Michał Winiarski wrote:
> If port[0] is occupied and we're trying to dequeue request from
> different context, we will inevitably hit BUG_ON in port_assign.
> Let's skip it - similar to what we're doing in execlists counterpart.
>
> Fixes: 77f0d0e925e8a0 ("drm/i915/execlists: Pack the count into the low bits
> of the port.request")
> Cc: Chris Wilson
> Cc: Michał Wajdeczko
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Signed-off-by: Michał Winiarski
Reviewed-by: Chris Wilson
Can you split out the first two and resend with a CI prefix + a guc
enabling patch? Let's get this fixed first.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable GEN9LP decoupled mmio
On 23/05/2017 01:18, kai.c...@intel.com wrote:
From: Kai Chen
This change is used as a backport fix from top of drm-intel ([PATCH]
drm/i915: Disable decoupled mmio for GEN9LP) to disable decoupled mmio
on GEN9LP for those shipped kernels as a quick fix.
Should we have a more complete commit message for the backportable
commit instead? Perhaps copy the one from the full patch, and change it
there to refer to this one and explain that it is removing previously
disabled code?
For example:
"""
The decoupled mmio feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts more difficult, so
let's disable it.
"""
V2:
- Add signed-off-by
Signed-off-by: Kai Chen
Adding the dim fixes blob:
Fixes: 85ee17ebeedd ("drm/i915/bxt: Broxton decoupled MMIO")
Cc: Zhe Wang
Cc: Praveen Paneri
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2c..cf43dc1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -385,7 +385,6 @@ static const struct intel_device_info
intel_skylake_gt3_info = {
.has_gmbus_irq = 1, \
.has_logical_ring_contexts = 1, \
.has_guc = 1, \
- .has_decoupled_mmio = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
