Re: [Intel-gfx] [PATCH] drm/i915: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in modeset error paths
On Fri, 13 May 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
> about. However error paths everyone cares about, so hiding the error
> debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
> for those instead.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a08c4a45b8d3..4fe5c23f784a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13590,7 +13590,7 @@ static int intel_atomic_commit(struct drm_device *dev,
>
> ret = intel_atomic_prepare_commit(dev, state, nonblock);
> if (ret) {
> - DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret);
> + DRM_DEBUG_KMS("Preparing state failed with %i\n", ret);
> return ret;
> }
--
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 i-g-t] autotools/: Allow building tests/gem_concurrent_{all, blit}
On Sat, 14 May 2016, Marius Vlad wrote: > Introduced by 633ad03c6 (tests: Separate tests with lots of subtests). fatal: ambiguous argument '633ad03c6': unknown revision or path not in the working tree. > > Signed-off-by: Marius Vlad > --- > tests/Makefile.am | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index 32b9115..c2c2025 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -30,6 +30,7 @@ pkglibexec_PROGRAMS = \ > gem_stress \ > $(TESTS_progs) \ > $(TESTS_progs_M) \ > + $(TESTS_progs_XM) \ > $(NULL) > > dist_pkglibexec_SCRIPTS = \ -- 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] FreeBSD i915 driver update
On 13 May 2016 at 03:34, Jani Nikula wrote: > > I don't have any FreeBSD experience and I don't know what kind of team > of developers you have, but it is my educated guess that you'll have > plenty of more productive things to do than trying to maintain a > significant amount of delta with upstream while also trying to stay > up-to-date. There are certainly lots of other things we can do with our time :-) That said, I see another advantage of the new approach here. In the past at any given time we had somewhere between nobody and one or two brave souls working on the driver in FreeBSD. That work required an understanding of the hardware, FreeBSD and Linux interfaces, and context of the previous modifications to the driver. Now we have a much larger team of folks contributing, and the work can more easily be distributed. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links
Load specific firmware versions for the DMC instead of using symbolic
links. The currently recommended versions are: SKL 1.26, KBL 1.01 and
BXT 1.07.
Certain DMC versions need workarounds in the driver which forces us to
have a tight dependency between firmware and driver. In order to be able
to provide a tested and known working configuration we must lock down on
a specific DMC firmware version.
Cc: Rodrigo Vivi
Cc: Imre Deak
Cc: Mika Kuoppala
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/i915/intel_csr.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 2b3b428..ea047cd 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -41,15 +41,15 @@
* be moved to FW_FAILED.
*/
-#define I915_CSR_KBL "i915/kbl_dmc_ver1.bin"
+#define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin"
MODULE_FIRMWARE(I915_CSR_KBL);
#define KBL_CSR_VERSION_REQUIRED CSR_VERSION(1, 1)
-#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
+#define I915_CSR_SKL "i915/skl_dmc_ver1_26.bin"
MODULE_FIRMWARE(I915_CSR_SKL);
-#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 23)
+#define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 26)
-#define I915_CSR_BXT "i915/bxt_dmc_ver1.bin"
+#define I915_CSR_BXT "i915/bxt_dmc_ver1_07.bin"
MODULE_FIRMWARE(I915_CSR_BXT);
#define BXT_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
@@ -286,7 +286,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
uint32_t *dmc_payload;
- uint32_t required_min_version;
+ uint32_t required_version;
if (!fw)
return NULL;
@@ -303,24 +303,23 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
csr->version = css_header->version;
if (IS_KABYLAKE(dev_priv)) {
- required_min_version = KBL_CSR_VERSION_REQUIRED;
+ required_version = KBL_CSR_VERSION_REQUIRED;
} else if (IS_SKYLAKE(dev_priv)) {
- required_min_version = SKL_CSR_VERSION_REQUIRED;
+ required_version = SKL_CSR_VERSION_REQUIRED;
} else if (IS_BROXTON(dev_priv)) {
- required_min_version = BXT_CSR_VERSION_REQUIRED;
+ required_version = BXT_CSR_VERSION_REQUIRED;
} else {
MISSING_CASE(INTEL_REVID(dev_priv));
- required_min_version = 0;
+ required_version = 0;
}
- if (csr->version < required_min_version) {
- DRM_INFO("Refusing to load old DMC firmware v%u.%u,"
-" please upgrade to v%u.%u or later"
- " [" FIRMWARE_URL "].\n",
+ if (csr->version != required_version) {
+ DRM_INFO("Refusing to load DMC firmware v%u.%u,"
+" please use v%u.%u [" FIRMWARE_URL "].\n",
CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version),
-CSR_VERSION_MAJOR(required_min_version),
-CSR_VERSION_MINOR(required_min_version));
+CSR_VERSION_MAJOR(required_version),
+CSR_VERSION_MINOR(required_version));
return NULL;
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/dmc: Step away from symbolic links (rev2)
== Series Details == Series: drm/i915/dmc: Step away from symbolic links (rev2) URL : https://patchwork.freedesktop.org/series/6966/ State : success == Summary == Series 6966v2 drm/i915/dmc: Step away from symbolic links http://patchwork.freedesktop.org/api/1.0/series/6966/revisions/2/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-ivb2-i7-3770) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_905/ 7c7c832 drm-intel-nightly: 2016y-05m-16d-07h-51m-48s UTC integration manifest 0a92540 drm/i915/dmc: Step away from symbolic links ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] autotools/: Allow building tests/gem_concurrent_{all, blit}
Introduced by a633ad03c6 (tests: Separate tests with lots of subtests). v2: Fix commit typo (Jani Nikula). Signed-off-by: Marius Vlad --- tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 32b9115..c2c2025 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -30,6 +30,7 @@ pkglibexec_PROGRAMS = \ gem_stress \ $(TESTS_progs) \ $(TESTS_progs_M) \ + $(TESTS_progs_XM) \ $(NULL) dist_pkglibexec_SCRIPTS = \ -- 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.
Signed-off-by: Marius Vlad
---
assembler/gram.y | 74
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/assembler/gram.y b/assembler/gram.y
index 23e1a57..15b8b64 100644
--- a/assembler/gram.y
+++ b/assembler/gram.y
@@ -509,15 +509,15 @@ static void resolve_subnr(struct brw_reg *reg)
%token BASE ELEMENTSIZE SRCREGION DSTREGION TYPE
%token DEFAULT_EXEC_SIZE_PRAGMA DEFAULT_REG_TYPE_PRAGMA
-%nonassoc SUBREGNUM
-%nonassoc SNDOPR
+%precedence SUBREGNUM
+%precedence SNDOPR
%left PLUS MINUS
%left MULTIPLY DIVIDE
-%right UMINUS
-%nonassoc DOT
-%nonassoc STR_SYMBOL_REG
-%nonassoc EMPTEXECSIZE
-%nonassoc LPAREN
+%precedence UMINUS
+%precedence DOT
+%precedence STR_SYMBOL_REG
+%precedence EMPTEXECSIZE
+%precedence LPAREN
%type exp sndopr
%type simple_int
@@ -655,7 +655,7 @@ declare_elementsize: ELEMENTSIZE EQ exp
$$ = $3;
}
;
-declare_srcregion: /* empty */
+declare_srcregion: %empty /* empty */
{
/* XXX is this default correct?*/
memset (&$$, '\0', sizeof ($$));
@@ -668,7 +668,7 @@ declare_srcregion: /* empty */
$$ = $3;
}
;
-declare_dstregion: /* empty */
+declare_dstregion: %empty /* empty */
{
$$ = 1;
}
@@ -1962,20 +1962,20 @@ msgtarget: NULL_TOKEN
;
urb_allocate: ALLOCATE { $$ = 1; }
- | /* empty */ { $$ = 0; }
+ | %empty /* empty */ { $$ = 0; }
;
urb_used: USED { $$ = 1; }
- | /* empty */ { $$ = 0; }
+ | %empty /* empty */ { $$ = 0; }
;
urb_complete: COMPLETE { $$ = 1; }
- | /* empty */ { $$ = 0; }
+ | %empty /* empty */ { $$ = 0; }
;
urb_swizzle: TRANSPOSE { $$ = BRW_URB_SWIZZLE_TRANSPOSE; }
| INTERLEAVE { $$ = BRW_URB_SWIZZLE_INTERLEAVE; }
- | /* empty */ { $$ = BRW_URB_SWIZZLE_NONE; }
+ | %empty /* empty */ { $$ = BRW_URB_SWIZZLE_NONE; }
;
sampler_datatype:
@@ -1988,11 +1988,11 @@ math_function: INV | LOG | EXP | SQRT | POW | SIN |
COS | SINCOS | INTDIV
| INTMOD | INTDIVMOD
;
-math_signed: /* empty */ { $$ = 0; }
+math_signed: %empty /* empty */ { $$ = 0; }
| SIGNED { $$ = 1; }
;
-math_scalar: /* empty */ { $$ = 0; }
+math_scalar: %empty /* empty */ { $$ = 0; }
| SCALAR { $$ = 1; }
;
@@ -2374,7 +2374,7 @@ addrparam:addrreg COMMA immaddroffset
/* The immaddroffset provides an immediate offset value added to the addresses
* from the address register in register-indirect register access.
*/
-immaddroffset: /* empty */ { $$ = 0; }
+immaddroffset: %empty /* empty */ { $$ = 0; }
| exp
;
@@ -2384,7 +2384,7 @@ subregnum:DOT exp
{
$$ = $2;
}
- | %prec SUBREGNUM
+ | %empty %prec SUBREGNUM
{
/* Default to subreg 0 if unspecified. */
$$ = 0;
@@ -2687,7 +2687,7 @@ relativelocation2:
;
/* 1.4.7: Regions */
-dstregion: /* empty */
+dstregion: %empty /* empty */
{
$$ = DEFAULT_DSTREGION;
}
@@ -2703,7 +2703,7 @@ dstregion:/* empty */
}
;
-region:/* empty */
+region:%empty /* empty */
{
/* XXX is this default value correct?*/
memset (&$$, '\0', sizeof ($$));
@@ -2757,7 +2757,7 @@ indirectregion: region | region_wh
/* regtype returns an integer register type suitable for inserting into an
* instruction.
*/
-regtype: /* empty */
+regtype: %empty /* empty */
{ $$.type = program_defaults.register_type;$$.is_default = 1;}
| TYPE_F { $$.type = BRW_REGISTER_TYPE_F;$$.is_default = 0; }
| TYPE_UD { $$.type = BRW_REGISTER_TYPE_UD;$$.is_default = 0; }
@@ -2768,7 +2768,7 @@ regtype: /* empty */
| TYPE_B { $$.type = BRW_REGISTER_TYPE_B;$$.is_default = 0; }
;
-srcimmtype:/* empty */
+srcimmtype:%empty /* empty */
{
/* XXX change to default when pragma parse is done */
$$ = BRW_REGISTER_TYPE_D;
@@ -2786,7 +2786,7 @@ srcimmtype: /* empty */
/* Returns the swizzle control for an align16 instruction's source operand
* in the src0 fields.
*/
-swizzle: /* empty */
+swizzle: %empty /* empty */
{
$$.reg.dw1.bits.swizzle = BRW_SWIZZLE_NOOP;
}
@@ -2807,7 +2807,7 @@ chansel: X | Y | Z | W
/* Returns a partially completed struct brw_reg, with just the writemask bits
* filled out.
*/
-writemask: /* empty */
+writemask: %empty /* empty */
{
$$.dw1.bits.writemask
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On 13/05/16 16:05, Tvrtko Ursulin wrote:
On 13/05/16 15:47, Jani Nikula wrote:
On Fri, 13 May 2016, Chris Wilson wrote:
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
On 13/05/16 15:04, Jani Nikula wrote:
This is more robust for assignments and comparisons.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index d9d07b70f05c..bb0b6f64000e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -752,7 +752,7 @@ struct intel_csr {
func(has_ddi) sep \
func(has_fpga_dbg)
-#define DEFINE_FLAG(name) u8 name:1
+#define DEFINE_FLAG(name) bool name:1
#define SEP_SEMICOLON ;
struct intel_device_info {
The churn virus spreads? :)
I tried that but it was negatively impacting the compiler. For some
reason it increases .text by 2.5k here. Don't see anything obvious,
would have to look at the code more closely to spot exactly why.
Oh, that's not fun. bool:1 holds such promise for a clear explanation of
the most common form of bitfield.
Really a bummer, especially since assigning any positive even number to
unsigned int foo:1 will result in 0.
That is a pretty strong argument to go for this rather than make sure
all places which set them are correct.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Unfortunately, the compiler doesn't generate such good code when using
'bool' vs. 'u8' for these bitfields.
Firstly, it looks like the compiler DOESN'T combine bool-bitfield tests
such as "if (IS_A() || IS_B())", whereas it does if they're u8. Example:
With bitfields as 'u8'
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
48 8b 57 28 mov0x28(%rdi),%rdx # dev->dev_priv
0f b6 52 30 movzbl 0x30(%rdx),%edx # dev_priv->flag byte
f6 c2 60test $0x60,%dl# (haswell|broadwell)
0f 85 bb 00 00 00 jne12e4 # branch to if-true
else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
83 e2 18and$0x18,%edx # test two more flags
0f 84 1c 01 00 00 je 134e # skip if neither
... code for VLV/CHV ...
(code for HSW/BDW is out-of-line, at the end of the function)
With bitfields as bools:
48 8b 57 28 mov0x28(%rdi),%rdx # dev->dev_priv
0f b6 52 30 movzbl 0x30(%rdx),%edx # dev_priv->flag byte
f6 c2 20test $0x20,%dl# test one flag
75 09 jne1241 # jump if true
f6 c2 40test $0x40,%dl# test other flag
0f 84 b7 00 00 00 je 12f8 # skip if not
... code for HSW/BDW ...
(code for VLV/CHV/other is later)
So that would suggest that the compiler generates more efficient code
for 'u8' (at least it didn't reload the flag byte even in the 'bool'
case). Here's another case:
With bitfields as bools:
dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
0f b6 43 30 movzbl 0x30(%rbx),%eax # flags byte
c0 e8 05shr$0x5,%al # haswell->bit 0
83 e0 01and$0x1,%eax# leaves bit 0 only
3c 01 cmp$0x1,%al # compare to 1u
19 c0 sbb%eax,%eax# convert to 0/-1
25 00 b0 00 00 and$0xb000,%eax # convert to 0/b000
05 00 48 06 00 add$0x64800,%eax# final result
89 83 e8 20 00 00 mov%eax,0x20e8(%rbx)# store it
This is ingenious code, avoiding any branching. Now with 'u8':
0f b6 43 30 movzbl 0x30(%rbx),%eax
83 e0 20and$0x20,%eax # leaves bit 5 only
3c 01 cmp$0x1,%al # compare to 1u
19 c0 sbb%eax,%eax# convert to 0/-1
25 00 b0 00 00 and$0xb000,%eax # etc
05 00 48 06 00 add$0x64800,%eax
89 83 e8 20 00 00 mov%eax,0x20e8(%rbx)
Again it's shorter, because the compiler has been able to extract a
truth-value without shifting the "haswell" bit down to bit 0 first.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915/gvt: Fold vGPU active check into inner functions
Hi,
On 15/05/16 18:32, Zhi Wang wrote:
Fold vGPU related active check into the inner functions. (Kevin)
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
drivers/gpu/drm/i915/i915_vgpu.c| 10 --
drivers/gpu/drm/i915/i915_vgpu.h| 2 +-
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7eab619..5c02c5a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2737,11 +2737,9 @@ static int i915_gem_setup_global_gtt(struct drm_device
*dev,
i915_address_space_init(&ggtt->base, dev_priv);
ggtt->base.total += PAGE_SIZE;
- if (intel_vgpu_active(dev_priv)) {
- ret = intel_vgt_balloon(dev);
- if (ret)
- return ret;
- }
+ ret = intel_vgt_balloon(dev);
+ if (ret)
+ return ret;
if (!HAS_LLC(dev))
ggtt->base.mm.color_adjust = i915_gtt_color_adjust;
@@ -2841,8 +2839,7 @@ void i915_ggtt_cleanup_hw(struct drm_device *dev)
i915_gem_cleanup_stolen(dev);
if (drm_mm_initialized(&ggtt->base.mm)) {
- if (intel_vgpu_active(dev_priv))
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev);
drm_mm_takedown(&ggtt->base.mm);
list_del(&ggtt->base.global_link);
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index d5a7a5e..0b76c70 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -101,10 +101,13 @@ static struct _balloon_info_ bl_info;
* This function is called to deallocate the ballooned-out graphic memory,
when
* driver is unloaded or when ballooning fails.
*/
-void intel_vgt_deballoon(void)
+void intel_vgt_deballoon(struct drm_device *dev)
In the spirit of current driver cleanup you should make
intel_vgt_balloon and deballoon take dev_priv. The former does not use
dev for anything anyway, just to get to dev_priv.
{
int i;
+ if (!intel_vgpu_active(to_i915(dev)))
+ return;
+
DRM_DEBUG("VGT deballoon.\n");
for (i = 0; i < 4; i++) {
@@ -187,6 +190,9 @@ int intel_vgt_balloon(struct drm_device *dev)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
+ if (!intel_vgpu_active(to_i915(dev)))
+ return 0;
Even already has the dev_priv local variable.
+
mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
@@ -258,6 +264,6 @@ int intel_vgt_balloon(struct drm_device *dev)
err:
DRM_ERROR("VGT balloon fail\n");
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index 07e67d5..c0e9569 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -28,6 +28,6 @@
extern void i915_check_vgpu(struct drm_i915_private *dev_priv);
extern int intel_vgt_balloon(struct drm_device *dev);
-extern void intel_vgt_deballoon(void);
+extern void intel_vgt_deballoon(struct drm_device *dev);
#endif /* _I915_VGPU_H_ */
The rest looks good to me.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915: gvt: Introduce the basic architecture of GVT-g
Hi, Just a few comments from a non-assigned reviewer. On 15/05/16 18:32, Zhi Wang wrote: This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v3: Take Joonas' comments: - Change file name i915_gvt.* to intel_gvt.* - Move GVT kernel parameter into intel_gvt.c - Remove redundant debug macros - Change error handling style - Add introductions for some stub functions - Introduce drm/i915_gvt.h. Take Kevin's comments: - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c v2: - Introduce i915_gvt.c. It's necessary to introduce the stubs between i915 driver and GVT-g host, as GVT-g components is configurable in kernel config. When disabled, the stubs here do nothing. Take Joonas' comments: - Replace boolean return value with int. - Replace customized info/warn/debug macros with DRM macros. - Document all non-static functions like i915. - Remove empty and unused functions. - Replace magic number with marcos. - Set GVT-g in kernel config to "n" by default. Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/Kconfig | 15 +++ drivers/gpu/drm/i915/Makefile| 5 + drivers/gpu/drm/i915/gvt/Makefile| 5 + drivers/gpu/drm/i915/gvt/debug.h | 36 ++ drivers/gpu/drm/i915/gvt/gvt.c | 209 +++ drivers/gpu/drm/i915/gvt/gvt.h | 85 ++ drivers/gpu/drm/i915/gvt/hypercall.h | 38 +++ drivers/gpu/drm/i915/gvt/mpt.h | 51 + drivers/gpu/drm/i915/i915_dma.c | 17 ++- drivers/gpu/drm/i915/i915_drv.h | 12 ++ drivers/gpu/drm/i915/intel_gvt.c | 106 ++ drivers/gpu/drm/i915/intel_gvt.h | 49 include/drm/i915_gvt.h | 31 ++ 13 files changed, 655 insertions(+), 4 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/Makefile create mode 100644 drivers/gpu/drm/i915/gvt/debug.h create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h create mode 100644 drivers/gpu/drm/i915/intel_gvt.c create mode 100644 drivers/gpu/drm/i915/intel_gvt.h create mode 100644 include/drm/i915_gvt.h diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 29a32b1..782c97c 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -57,6 +57,21 @@ config DRM_I915_USERPTR If in doubt, say "Y". +config DRM_I915_GVT +bool "Intel GVT-g host driver" +depends on DRM_I915 +default n +help + Enabling GVT-g mediated graphics passthrough technique for Intel i915 pass-through + based integrated graphics card. With GVT-g, it's possible to have one + integrated i915 device shared by multiple VMs. Performance critical + opterations such as apperture accesses and ring buffer operations operations, aperture + are pass-throughed to VM, with a minimal set of conflicting resources passed-through to the host or hypervisor ? + (e.g. display settings) mediated by vGT driver. The benefit of vGT + is on both the performance, given that each VM could directly operate + its aperture space and submit commands like running on native, and + the feature completeness, given that a true GEN hardware is exposed. + menu "drm/i915 Debugging" depends on DRM_I915 depends on EXPERT diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 63c4d2b..e48145b 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -103,6 +103,11 @@ i915-y += i915_vgpu.o # legacy horrors i915-y += i915_dma.o +ifeq ($(CONFIG_DRM_I915_GVT),y) +i915-y += intel_gvt.o +include $(src)/gvt/Makefile +endif + obj-$(CONFIG_DRM_I915) += i915.o CFLAGS_i915_trace_points.o := -I$(src) diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile new file mode 100644 index 000..d0f21a6 --- /dev/null +++ b/drivers/gpu/drm/i915/gvt/Makefile @@ -0,0 +1,5 @@ +GVT_DIR := gvt +GVT_SOURCE := gvt.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/debug.h b/drivers/gpu/drm/i915/gvt/debug.h new file mode 100644 index 000..5b067d2 --- /dev/null +++ b/drivers/gpu/drm/i915/gvt/debug.h @@ -0,0 +1,36 @@ +/* + * 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
Re: [Intel-gfx] [PATCH v2] drm/i915/dmc: Step away from symbolic links
On Mon, 16 May 2016, Patrik Jakobsson wrote: > Load specific firmware versions for the DMC instead of using symbolic > links. The currently recommended versions are: SKL 1.26, KBL 1.01 and > BXT 1.07. > > Certain DMC versions need workarounds in the driver which forces us to > have a tight dependency between firmware and driver. In order to be able > to provide a tested and known working configuration we must lock down on > a specific DMC firmware version. > > Cc: Rodrigo Vivi > Cc: Imre Deak > Cc: Mika Kuoppala > Signed-off-by: Patrik Jakobsson On the general idea, Acked-by: Jani Nikula I guess we'll need to keep the symbolic links around in linux-firmware, pointing to known good firmware versions, and *not* update the links anymore. 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
[Intel-gfx] [PATCH i-g-t] tests/drv_missed_irq_hang: Allow running test under piglit.
This fixes invalid path handling under piglit.
/opt/igt/tests/drv_missed_irq_hang: line 14:
/opt/igt/piglit//opt/igt/tests/../benchmarks/gem_blt: No such file or
directory
Signed-off-by: Marius Vlad
---
tests/drv_missed_irq_hang | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/drv_missed_irq_hang b/tests/drv_missed_irq_hang
index e76c7db..4c07cdd 100755
--- a/tests/drv_missed_irq_hang
+++ b/tests/drv_missed_irq_hang
@@ -11,7 +11,12 @@ oldpath=`pwd`
cd $i915_dfs_path
function blt_wait {
- $oldpath/$SOURCE_DIR/../benchmarks/gem_blt -r 1 -b 64 -t 1 -S >
/dev/null
+ if [ ! -x $oldpath/$SOURCE_DIR/../benchmarks/gem_blt ]; then
+ GEM_BLT=$SOURCE_DIR/../benchmarks/gem_blt
+ else
+ GEM_BLT=$oldpath/$SOURCE_DIR/../benchmarks/gem_blt
+ fi
+ $GEM_BLT -r 1 -b 64 -t 1 -S > /dev/null
}
function check_for_missed_irq {
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/7] drm/i915: DP branch devices
Prep work for DP branch device handling This series of patches reads DPCD register 0x80h for receiver capabilities for DP branch devices. The branch device types are converters for the following standards - DP to VGA - DP to DVI - DP to HDMI - DP++ dual mode - Wireless WiGig DPCD register defines max pixel rate for VGA dongles. This check is carried out during mode validation. Acronyms: DFPDownstream-Facing Port v2: DPCD register read outs moved to drm (Ville, Daniel) Mika Kahola (7): drm: Add missing DP downstream port types drm: Read DPCD receiver capability for DP to VGA converter drm: Read DPCD receiver capability for DP to DVI converter drm: Read DPCD receiver capability for DP to HDMI converter drm: Read DPCD receiver capability for DP++ drm: Read DPCD receiver capability for DP to Wireless Converter drm/i915: Check pixel rate for DP to VGA dongle drivers/gpu/drm/drm_dp_helper.c | 70 +++ drivers/gpu/drm/i915/intel_dp.c | 11 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + include/drm/drm_dp_helper.h | 79 4 files changed, 162 insertions(+) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/7] drm: Add missing DP downstream port types
Add missing DisplayPort downstream port types. The introduced new port types are DP++ and Wireless. Signed-off-by: Mika Kahola --- 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 92d9a52..4049af9 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -210,6 +210,8 @@ # define DP_DS_PORT_TYPE_DVI 2 # define DP_DS_PORT_TYPE_HDMI 3 # define DP_DS_PORT_TYPE_NON_EDID 4 +# define DP_DS_PORT_TYPE_DP_DUALMODE5 +# define DP_DS_PORT_TYPE_WIRELESS 6 # define DP_DS_PORT_HPD(1 << 3) /* offset 1 for VGA is maximum megapixels per second / 8 */ /* offset 2 */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/7] drm: Read DPCD receiver capability for DP to Wireless Converter
Read from DPCD receiver capability field for the
DP to Wireless converter. The only supported wireless
technology on DP1.3 spec is WiGig display extension. If WiGig
display extension is present, then read out the
- number of wde tx on device
- the number of wde txs that can be concurrently active
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
include/drm/drm_dp_helper.h | 13 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f98e4be..2c91771 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -468,6 +468,13 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
bd->dfp.dual_mode.bpc = info[2] &
DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
+ } else if (bd->type & DP_DS_PORT_TYPE_WIRELESS) {
+ bd->dfp.wireless.wireless_tech = info[1] &
DP_DS_WIRELESS_TECH_MASK;
+
+ if (bd->dfp.wireless.wireless_tech == 0x0) {
+ bd->dfp.wireless.number_of_wde_tx_on_device =
info[2] & WIRELESS_MASK;
+ bd->dfp.wireless.wde_tx_concurrency_cap =
(info[2]>>2) & WIRELESS_MASK;
+ }
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c12c64b..a9d278d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -229,6 +229,9 @@
# define YCBCR420_PASS_THROUGH (1<<2)
# define YCBCR444_TO_YCBCR422 (1<<3)
# define YCBCR444_TO_YCBCR420 (1<<4)
+/* offset 3 for Wireless */
+# define DP_DS_WIRELESS_TECH_MASK 0xf
+# define WIRELESS_MASK 3
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -850,6 +853,15 @@ struct drm_dp_dual_mode {
};
/*
+ * DP to Wireless
+ */
+struct drm_dp_wireless {
+ int wireless_tech;
+ int number_of_wde_tx_on_device;
+ int wde_tx_concurrency_cap;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -861,6 +873,7 @@ struct drm_dp_bd {
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
struct drm_dp_dual_mode dual_mode;
+ struct drm_dp_wireless wireless;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/7] drm: Read DPCD receiver capability for DP to VGA converter
Read from DPCD receiver capability field the max allowed
pixel clock and bits per component for DP to VGA converter.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 46
drivers/gpu/drm/i915/intel_drv.h | 2 ++
include/drm/drm_dp_helper.h | 21 ++
3 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index eeaf5a7..c5bec6f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -412,6 +412,52 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct
drm_dp_link *link)
}
EXPORT_SYMBOL(drm_dp_link_power_down);
+/*
+ * drm_dp_bd() - read DisplayPort Receiver Capability Fields for
+ * DP branch devices
+ * @aux: DisplayPort AUX channel
+ * @bd: pointer to a structure containing DP branch device information
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
+{
+ uint8_t info[4];
+ uint8_t dfp;
+ bool detailed_cap_info;
+ int err, size;
+
+ err = drm_dp_dpcd_read(aux, DP_DOWNSTREAMPORT_PRESENT, &dfp,
sizeof(dfp));
+ if (err < 0)
+ return err;
+
+ bd->present = dfp & 0x1;
+
+ if (!bd->present)
+ return 0;
+
+ detailed_cap_info = dfp & DP_DETAILED_CAP_INFO_AVAILABLE;
+
+ size = detailed_cap_info ? 4 : 1;
+
+ err = drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, info, size);
+ if (err < 0)
+ return err;
+
+ bd->type = info[0] & DP_DS_PORT_TYPE_MASK;
+ bd->hpd = info[0] & DP_DS_PORT_HPD;
+
+ if (detailed_cap_info) {
+ if (bd->type & DP_DS_PORT_TYPE_VGA) {
+ bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
+ bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_bd);
+
/**
* drm_dp_link_configure() - configure a DisplayPort link
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 94a44af..7d2d93f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -866,6 +866,8 @@ struct intel_dp {
bool train_set_valid;
+ struct drm_dp_bd bd;
+
/* Displayport compliance testing */
unsigned long compliance_test_type;
unsigned long compliance_test_data;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4049af9..fe6cfdc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -801,10 +801,31 @@ struct drm_dp_link {
unsigned long capabilities;
};
+/*
+ * DP to VGA
+ */
+struct drm_dp_vga {
+ int dot_clk;
+ uint8_t bpc;
+};
+
+/*
+ * Branch device
+ */
+struct drm_dp_bd {
+ bool present;
+ int type;
+ bool hpd;
+ union {
+ struct drm_dp_vga vga;
+ } dfp;
+};
+
int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd);
int drm_dp_aux_register(struct drm_dp_aux *aux);
void drm_dp_aux_unregister(struct drm_dp_aux *aux);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm: Read DPCD receiver capability for DP to HDMI converter
Read from DPCD receiver capability field for DP to HDMI
converter. The features for DP to HDMI converter are
- max TMDS characther clock rate
- max bits per component
- support for conversion from 3D frame sequential to frame pack
- support for YCBCR422 pass through
- support for YCBCR420 pass through
- support for conversion from YCBCR444 to YCBCR422
- support for conversion from YCBCR444 to YCBCR420
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 8
include/drm/drm_dp_helper.h | 19 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f5cf706..ccd0fcb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -456,6 +456,14 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
bd->dfp.dvi.hi_color_depth = info[3] &
DP_DS_DVI_HI_COLOR_DEPTH;
+ } else if (bd->type & DP_DS_PORT_TYPE_HDMI) {
+ bd->dfp.hdmi.tmds_clk = info[1] * 2500;
+ bd->dfp.hdmi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.hdmi.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
+ bd->dfp.hdmi.ycbcr422_pass_through = info[3] &
YCBCR422_PASS_THROUGH;
+ bd->dfp.hdmi.ycbcr420_pass_through = info[3] &
YCBCR420_PASS_THROUGH;
+ bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 =
info[3] & YCBCR444_TO_YCBCR422;
+ bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 =
info[3] & YCBCR444_TO_YCBCR420;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da82459..3607250 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -223,6 +223,12 @@
/* offset 3 for DVI dual link and high color depth */
# define DP_DS_DVI_DUAL_LINK(1<<1)
# define DP_DS_DVI_HI_COLOR_DEPTH (1<<2)
+/* offset 3 for HDMI */
+# define FRAME_SEQ_TO_FRAME_PACK(1<<0)
+# define YCBCR422_PASS_THROUGH (1<<1)
+# define YCBCR420_PASS_THROUGH (1<<2)
+# define YCBCR444_TO_YCBCR422 (1<<3)
+# define YCBCR444_TO_YCBCR420 (1<<4)
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -821,6 +827,18 @@ struct drm_dp_dvi {
bool dual_link;
bool hi_color_depth;
};
+/*
+ * DP to HDMI
+ */
+struct drm_dp_hdmi {
+ int tmds_clk;
+ uint8_t bpc;
+ bool frame_seq_to_frame_pack;
+ bool ycbcr422_pass_through;
+ bool ycbcr420_pass_through;
+ bool conversion_from_ycbcr444_to_ycbcr422;
+ bool conversion_from_ycbcr444_to_ycbcr420;
+};
/*
* Branch device
@@ -832,6 +850,7 @@ struct drm_dp_bd {
union {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
+ struct drm_dp_hdmi hdmi;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915: Check pixel rate for DP to VGA dongle
Prep work to improve DP branch device handling.
Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.
The register defines the pixel rate divided by 8 in MP/s.
v2: DPCD read outs and computation moved to drm (Ville, Daniel)
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3633002..5ec6287 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,12 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ /* DP to VGA dongle may define max pixel rate in DPCD */
+ if (intel_dp->bd.present &&
+ (intel_dp->bd.type & DP_DS_PORT_TYPE_VGA) &&
+ (intel_dp->bd.dfp.vga.dot_clk > 0))
+ max_dotclk = min(max_dotclk, intel_dp->bd.dfp.vga.dot_clk);
+
if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
@@ -4575,6 +4581,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
struct drm_i915_private *dev_priv = dev->dev_private;
enum intel_display_power_domain power_domain;
enum irqreturn ret = IRQ_NONE;
+ int err;
if (intel_dig_port->base.type != INTEL_OUTPUT_EDP &&
intel_dig_port->base.type != INTEL_OUTPUT_HDMI)
@@ -4599,6 +4606,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
power_domain = intel_display_port_aux_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
+ err = drm_dp_bd(&intel_dp->aux, &intel_dp->bd);
+ if (err < 0)
+ DRM_DEBUG_KMS("error reading DPCD[0x80] for DP branch
device\n");
+
if (long_hpd) {
/* indicate that we need to restart link training */
intel_dp->train_set_valid = false;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/7] drm: Read DPCD receiver capability for DP to DVI converter
Read from DPCD receiver capability field for the following
features:
- max TMDS clock rate
- max bits per component
- single or dual link support
- high color depth support
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 5 +
include/drm/drm_dp_helper.h | 14 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c5bec6f..f5cf706 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -451,6 +451,11 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
if (bd->type & DP_DS_PORT_TYPE_VGA) {
bd->dfp.vga.dot_clk = info[1] * 8 * 1000;
bd->dfp.vga.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ } else if (bd->type & DP_DS_PORT_TYPE_DVI) {
+ bd->dfp.dvi.tmds_clk = info[1] * 2500;
+ bd->dfp.dvi.bpc = info[2] & DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.dvi.dual_link = info[3] & DP_DS_DVI_DUAL_LINK;
+ bd->dfp.dvi.hi_color_depth = info[3] &
DP_DS_DVI_HI_COLOR_DEPTH;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index fe6cfdc..da82459 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -220,6 +220,9 @@
# define DP_DS_VGA_10BPC 1
# define DP_DS_VGA_12BPC 2
# define DP_DS_VGA_16BPC 3
+/* offset 3 for DVI dual link and high color depth */
+# define DP_DS_DVI_DUAL_LINK(1<<1)
+# define DP_DS_DVI_HI_COLOR_DEPTH (1<<2)
/* link configuration */
#defineDP_LINK_BW_SET 0x100
@@ -810,6 +813,16 @@ struct drm_dp_vga {
};
/*
+ * DP to DVI
+ */
+struct drm_dp_dvi {
+ int tmds_clk;
+ uint8_t bpc;
+ bool dual_link;
+ bool hi_color_depth;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -818,6 +831,7 @@ struct drm_dp_bd {
bool hpd;
union {
struct drm_dp_vga vga;
+ struct drm_dp_dvi dvi;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/7] drm: Read DPCD receiver capability for DP++
Read from DPCD receiver capability field for the
DP++ devices. The features are
- max TMDS charachter clock
- max bits per component
- support for conversion from 3D frame sequential to
frame pack
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/drm_dp_helper.c | 4
include/drm/drm_dp_helper.h | 10 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ccd0fcb..f98e4be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -464,6 +464,10 @@ int drm_dp_bd(struct drm_dp_aux *aux, struct drm_dp_bd *bd)
bd->dfp.hdmi.ycbcr420_pass_through = info[3] &
YCBCR420_PASS_THROUGH;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr422 =
info[3] & YCBCR444_TO_YCBCR422;
bd->dfp.hdmi.conversion_from_ycbcr444_to_ycbcr420 =
info[3] & YCBCR444_TO_YCBCR420;
+ } else if (bd->type & DP_DS_PORT_TYPE_DP_DUALMODE) {
+ bd->dfp.dual_mode.tmds_clk = info[1] * 2500;
+ bd->dfp.dual_mode.bpc = info[2] &
DP_DS_VGA_MAX_BPC_MASK;
+ bd->dfp.dual_mode.frame_seq_to_frame_pack = info[3] &
FRAME_SEQ_TO_FRAME_PACK;
}
}
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3607250..c12c64b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -841,6 +841,15 @@ struct drm_dp_hdmi {
};
/*
+ * DP to DP++
+ */
+struct drm_dp_dual_mode {
+ int tmds_clk;
+ uint8_t bpc;
+ bool frame_seq_to_frame_pack;
+};
+
+/*
* Branch device
*/
struct drm_dp_bd {
@@ -851,6 +860,7 @@ struct drm_dp_bd {
struct drm_dp_vga vga;
struct drm_dp_dvi dvi;
struct drm_dp_hdmi hdmi;
+ struct drm_dp_dual_mode dual_mode;
} dfp;
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing PPGTT in context creation
On 15/05/16 18:32, Zhi Wang wrote:
Currently ctx->ppgtt would only be initialized when full PPGTT is used.
For aliasing PPGTT mode, ctx->ppgtt will be set when LRC context is
populated.
This patch moves the assignment into i915_gem_create_context() for better
code structure.
Hm, it doesn't move the assignment it adds it.
Previously ctx->ppgtt was always NULL when !USES_FULL_PPGTT. Now it will
point to aliasing ppgtt.
Since there are various places in the code which do "if (ctx->ppgtt)"
(more or less) I think you need to explain why those will still work OK.
i915_gem_context_free for example?
Regards,
Tvrtko
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_context.c | 4 +++-
drivers/gpu/drm/i915/intel_lrc.c| 3 ---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2aedd18..21498e5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -300,6 +300,7 @@ static struct intel_context *
i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
const bool is_global_default_ctx = file_priv == NULL;
struct intel_context *ctx;
int ret = 0;
@@ -337,7 +338,8 @@ i915_gem_create_context(struct drm_device *dev,
}
ctx->ppgtt = ppgtt;
- }
+ } else
+ ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
trace_i915_context_create(ctx);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index db10c96..397fe65 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2286,9 +2286,6 @@ populate_lr_context(struct intel_context *ctx,
u32 *reg_state;
int ret;
- if (!ppgtt)
- ppgtt = dev_priv->mm.aliasing_ppgtt;
-
ret = i915_gem_object_set_to_cpu_domain(ctx_obj, true);
if (ret) {
DRM_DEBUG_DRIVER("Could not set to CPU domain\n");
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 2/7] lib/igt_kms: Fix plane counting in igt_display_init.
From: Robert Foss
Fix issue where the plane counting fails due to the number and
configuration of planes being unlike the intel configuration.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index c2283fd..876f65c 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1289,6 +1289,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
igt_plane_t *plane;
int p = IGT_PLANE_2;
int j, type;
+ uint8_t n_planes = 0;
pipe->crtc_id = resources->crtcs[i];
pipe->display = display;
@@ -1336,8 +1337,10 @@ void igt_display_init(igt_display_t *display, int drm_fd)
break;
}
+ n_planes++;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+
if (is_atomic == 0) {
display->is_atomic = 1;
igt_atomic_fill_plane_props(display, plane,
IGT_NUM_PLANE_PROPS, igt_plane_prop_names);
@@ -1386,8 +1389,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane->is_cursor = true;
}
- /* planes = 1 primary, (p-1) sprites, 1 cursor */
- pipe->n_planes = p + 1;
+ pipe->n_planes = n_planes;
/* make sure we don't overflow the plane array */
igt_assert(pipe->n_planes <= IGT_MAX_PLANES);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 4/7] lib/igt_kms: Added pipe_id_to_vbl_flag() to igt_kms.
From: Robert Foss
Added function pipe_id_to_vbl_flag() to igt_kms.
This function formats a pipe_id into the format
expected by DRM while processing DRM_IOCTL_WAIT_VBLANK.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 16
lib/igt_kms.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9af9603..5ef73c8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2557,3 +2557,19 @@ void igt_reset_connectors(void)
close(fd);
}
}
+
+/**
+ * kmstest_get_vbl_flag:
+ *
+ * Convert a pipe id into the flag representation
+ * expected in DRM while processing DRM_IOCTL_WAIT_VBLANK.
+ */
+uint32_t kmstest_get_vbl_flag(uint32_t pipe_id)
+{
+ if (pipe_id == 0)
+ return 0;
+ else if (pipe_id == 1)
+ return _DRM_VBLANK_SECONDARY;
+ else
+ return pipe_id << 1;
+}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index d9a4e11..9fecf2b 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -400,6 +400,7 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
void igt_enable_connectors(void);
void igt_reset_connectors(void);
+uint32_t kmstest_get_vbl_flag(uint32_t pipe_id);
#define EDID_LENGTH 128
const unsigned char* igt_kms_get_base_edid(void);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 0/7] kms_flip_event_leak and kms_vblank fixes for
From: Robert Foss In addition to the changes made in v4, danvet suggested that the argument for the (newly renamed) helper function kmstest_get_vbl_flag should be changed. I investigated it and found that all of the places where the helper function currently is used, would require more of a rework with changed arguments than with unchanged arguments, so I decided to not change the arguments. Changes since v1: - kms_vblank: Removed un-used members of data_t struct. - Rename plane_counter to n_planes. - Removed un-needed handling CURSOR plane location. - Added names for additional planes in update kmstest_plane_name. Changes since v2: - Rebased onto trunk which already contains kms_flip_event_leak changes. Changes since v3: - kms_vblank.c: Removed drm_fd from data_t, to decrease the number of unrelated changes in the patch. - kms_vblank.c: Changed "int valid_tests" to "unsigned valid_tests". - kms_vblank.c: Changed crtc_id_flag/crtc_id_to_flag to pipe_id_flag/pipe_id_to_flag. - kms_vblank.c: Changed to "vbl.request.type |= crtc_id_flag;". - kms_vblank.c: Moved crtc_id_to_flag to igt_kms.c. - kms_vblank.c: Renamed crtc_id_to_flag to pipe_id_to_vbl_flag. - kms_flip.c: Changed test busy_mode boolean into mode_busy bitfield in struct data. - igt_kms.h: Moved IGT_PLANE_CURSOR position comment. Changes since v4: - kms_vblank.c: Removed whitespace at end of file. - igt_kms: Changed name of helper function to kmstest_get_vbl_flag - igt_kms: Changed kmstest_get_vbl_flag to not set DRM_VBLANK_RELATIVE flag Robert Foss (7): lib/igt_kms: Add support for up to 10 planes. lib/igt_kms: Fix plane counting in igt_display_init. lib/igt_kms: Switch to verbose assert. lib/igt_kms: Added pipe_id_to_vbl_flag() to igt_kms. kms_vblank: Switch from using crtc0 statically to explicitly setting mode. igt_kms: Change igt_wait_for_vblank to use helper function. kms_flip: Change __wait_for_vblank to use helper function. lib/igt_kms.c | 36 ++-- lib/igt_kms.h | 9 ++- tests/kms_flip.c | 8 +-- tests/kms_vblank.c | 161 - 4 files changed, 179 insertions(+), 35 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 5/7] kms_vblank: Switch from using crtc0 statically to explicitly setting mode.
From: Robert Foss
Previously crtc0 was statically used for VBLANK tests, but
that assumption is not valid for the VC4 platform.
Instead we're now explicitly setting the mode.
Also add support for testing all connected connectors during
the same test.
Signed-off-by: Robert Foss
---
tests/kms_vblank.c | 161 -
1 file changed, 136 insertions(+), 25 deletions(-)
diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
index 40ab6fd..9bc4929 100644
--- a/tests/kms_vblank.c
+++ b/tests/kms_vblank.c
@@ -44,6 +44,14 @@
IGT_TEST_DESCRIPTION("Test speed of WaitVblank.");
+typedef struct {
+ igt_display_t display;
+ struct igt_fb primary_fb;
+ igt_output_t *output;
+ enum pipe pipe;
+ uint8_t mode_busy:1;
+} data_t;
+
static double elapsed(const struct timespec *start,
const struct timespec *end,
int loop)
@@ -51,38 +59,119 @@ static double elapsed(const struct timespec *start,
return (1e6*(end->tv_sec - start->tv_sec) + (end->tv_nsec -
start->tv_nsec)/1000)/loop;
}
-static bool crtc0_active(int fd)
+static bool prepare_crtc(data_t *data, int fd, igt_output_t *output)
{
- union drm_wait_vblank vbl;
+ drmModeModeInfo *mode;
+ igt_display_t *display = &data->display;
+ igt_plane_t *primary;
+
+ /* select the pipe we want to use */
+ igt_output_set_pipe(output, data->pipe);
+ igt_display_commit(display);
+
+ if (!output->valid) {
+ igt_output_set_pipe(output, PIPE_ANY);
+ igt_display_commit(display);
+ return false;
+ }
- memset(&vbl, 0, sizeof(vbl));
- vbl.request.type = DRM_VBLANK_RELATIVE;
- return drmIoctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl) == 0;
+ /* create and set the primary plane fb */
+ mode = igt_output_get_mode(output);
+ igt_create_color_fb(fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ LOCAL_DRM_FORMAT_MOD_NONE,
+ 0.0, 0.0, 0.0,
+ &data->primary_fb);
+
+ primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+ igt_plane_set_fb(primary, &data->primary_fb);
+
+ igt_display_commit(display);
+
+ igt_wait_for_vblank(fd, data->pipe);
+
+ return true;
+}
+
+static void cleanup_crtc(data_t *data, int fd, igt_output_t *output)
+{
+ igt_display_t *display = &data->display;
+ igt_plane_t *primary;
+
+ igt_remove_fb(fd, &data->primary_fb);
+
+ primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
+ igt_plane_set_fb(primary, NULL);
+
+ igt_output_set_pipe(output, PIPE_ANY);
+ igt_display_commit(display);
+}
+
+static void run_test(data_t *data, int fd, void (*testfunc)(data_t *, int))
+{
+ igt_display_t *display = &data->display;
+ igt_output_t *output;
+ enum pipe p;
+ unsigned int valid_tests = 0;
+
+ for_each_connected_output(display, output) {
+ for_each_pipe(display, p) {
+ data->pipe = p;
+
+ if (!prepare_crtc(data, fd, output))
+ continue;
+
+ valid_tests++;
+
+ igt_info("Beginning %s on pipe %s, connector %s\n",
+igt_subtest_name(),
+kmstest_pipe_name(data->pipe),
+igt_output_name(output));
+
+ testfunc(data, fd);
+
+ igt_info("\n%s on pipe %s, connector %s: PASSED\n\n",
+igt_subtest_name(),
+kmstest_pipe_name(data->pipe),
+igt_output_name(output));
+
+ /* cleanup what prepare_crtc() has done */
+ cleanup_crtc(data, fd, output);
+ }
+ }
+
+ igt_require_f(valid_tests, "no valid crtc/connector combinations
found\n");
}
-static void accuracy(int fd)
+static void accuracy(data_t *data, int fd)
{
union drm_wait_vblank vbl;
unsigned long target;
+ uint32_t pipe_id_flag;
int n;
memset(&vbl, 0, sizeof(vbl));
+ pipe_id_flag = kmstest_get_vbl_flag(data->pipe);
vbl.request.type = DRM_VBLANK_RELATIVE;
+ vbl.request.type |= pipe_id_flag;
vbl.request.sequence = 1;
do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl);
target = vbl.reply.sequence + 60;
for (n = 0; n < 60; n++) {
vbl.request.type = DRM_VBLANK_RELATIVE;
+ vbl.request.type |= pipe_id_flag;
vbl.request.sequence = 1;
do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl);
vbl.request.type = DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
+ vbl.request.type |= pipe_id_flag;
[Intel-gfx] [PATCH i-g-t v5 1/7] lib/igt_kms: Add support for up to 10 planes.
From: Robert Foss
Increase the number of planes supported to 10.
kmstest_plane_name only previously supported 4 planes,
this patch adds support for up to 10 planes.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 6 ++
lib/igt_kms.h | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f85be1e..c2283fd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -320,6 +320,12 @@ const char *kmstest_plane_name(enum igt_plane plane)
[IGT_PLANE_1] = "plane1",
[IGT_PLANE_2] = "plane2",
[IGT_PLANE_3] = "plane3",
+ [IGT_PLANE_4] = "plane4",
+ [IGT_PLANE_5] = "plane5",
+ [IGT_PLANE_6] = "plane6",
+ [IGT_PLANE_7] = "plane7",
+ [IGT_PLANE_8] = "plane8",
+ [IGT_PLANE_9] = "plane9",
[IGT_PLANE_CURSOR] = "cursor",
};
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 5c83401..d9a4e11 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -54,7 +54,13 @@ enum igt_plane {
IGT_PLANE_PRIMARY = IGT_PLANE_1,
IGT_PLANE_2,
IGT_PLANE_3,
- IGT_PLANE_CURSOR,
+ IGT_PLANE_4,
+ IGT_PLANE_5,
+ IGT_PLANE_6,
+ IGT_PLANE_7,
+ IGT_PLANE_8,
+ IGT_PLANE_9,
+ IGT_PLANE_CURSOR, /* IGT_PLANE_CURSOR is always the last plane. */
IGT_MAX_PLANES,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 7/7] kms_flip: Change __wait_for_vblank to use helper function.
From: Robert Foss
Change __wait_for_vblank() to use kmstest_get_vbl_flag() helper function.
Signed-off-by: Robert Foss
---
tests/kms_flip.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index eda2fcc..0ecca07 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -481,15 +481,15 @@ static int __wait_for_vblank(unsigned int flags, int
crtc_idx,
{
drmVBlank wait_vbl;
int ret;
- unsigned crtc_idx_mask;
+ uint32_t pipe_id_flag;
bool event = !(flags & TEST_VBLANK_BLOCK);
memset(&wait_vbl, 0, sizeof(wait_vbl));
- crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
- igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));
+ pipe_id_flag = kmstest_get_vbl_flag(crtc_idx);
+ igt_assert(!(pipe_id_flag & ~DRM_VBLANK_HIGH_CRTC_MASK));
- wait_vbl.request.type = crtc_idx_mask;
+ wait_vbl.request.type = pipe_id_flag;
if (flags & TEST_VBLANK_ABSOLUTE)
wait_vbl.request.type |= DRM_VBLANK_ABSOLUTE;
else
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: DP branch devices (rev2)
== Series Details == Series: drm/i915: DP branch devices (rev2) URL : https://patchwork.freedesktop.org/series/6658/ State : failure == Summary == Series 6658v2 drm/i915: DP branch devices http://patchwork.freedesktop.org/api/1.0/series/6658/revisions/2/mbox Test drv_module_reload_basic: pass -> SKIP (ro-ivb-i7-3770) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-ivb2-i7-3770) fail -> PASS (ro-hsw-i3-4010u) Test kms_sink_crc_basic: skip -> PASS (ro-skl-i7-6700hq) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:151 dwarn:0 dfail:0 fail:2 skip:61 ro-ivb-i7-3770 total:219 pass:182 dwarn:0 dfail:0 fail:0 skip:37 ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32 ro-skl-i7-6700hq total:214 pass:190 dwarn:0 dfail:0 fail:0 skip:24 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_907/ d381724 drm-intel-nightly: 2016y-05m-16d-12h-14m-04s UTC integration manifest 7dff7f2 drm/i915: Check pixel rate for DP to VGA dongle a19f93e drm: Read DPCD receiver capability for DP to Wireless Converter 631596d drm: Read DPCD receiver capability for DP++ f4447e5 drm: Read DPCD receiver capability for DP to HDMI converter 283c01a drm: Read DPCD receiver capability for DP to DVI converter 1460143 drm: Read DPCD receiver capability for DP to VGA converter 2088d48 drm: Add missing DP downstream port types ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 6/7] igt_kms: Change igt_wait_for_vblank to use helper function.
From: Robert Foss
Change igt_wait_for_vblank() to use kmstest_get_vbl_flag() helper function.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 5ef73c8..bc022c8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2488,11 +2488,13 @@ void igt_crtc_set_background(igt_pipe_t *pipe, uint64_t
background)
void igt_wait_for_vblank(int drm_fd, enum pipe pipe)
{
drmVBlank wait_vbl;
+ uint32_t pipe_id_flag;
memset(&wait_vbl, 0, sizeof(wait_vbl));
+ pipe_id_flag = kmstest_get_vbl_flag(pipe);
- wait_vbl.request.type = pipe << DRM_VBLANK_HIGH_CRTC_SHIFT |
- DRM_VBLANK_RELATIVE;
+ wait_vbl.request.type = DRM_VBLANK_RELATIVE;
+ wait_vbl.request.type |= pipe_id_flag;
wait_vbl.request.sequence = 1;
igt_assert(drmWaitVBlank(drm_fd, &wait_vbl) == 0);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/i915: Generate addressing mode bit from flag in context.
On 15/05/16 18:32, Zhi Wang wrote:
Previously the addressing mode bit in context descriptor is generated from
context PPGTT. As we allow context could be used without PPGTT, and we
still need to know the addressing mode during context submission, a flag
is introduced.
And the addressing mode bit will be generated from this flag.
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c| 9 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ac88b2..7f050a3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -885,6 +885,7 @@ struct intel_context {
bool skip_init_context;
u32 ring_buffer_size;
} engine[I915_NUM_ENGINES];
+ bool use_48bit_addressing_mode;
struct list_head link;
};
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b952e37..b5b0849 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,8 @@ i915_gem_create_context(struct drm_device *dev,
ctx->ppgtt = ppgtt;
} else
ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
+
+ ctx->use_48bit_addressing_mode = USES_FULL_48BIT_PPGTT(dev);
Should be dev_priv, you added it in an earlier patch. Could replace the
one usage of to_i915 in this function with it in that patch as well.
Regards,
Tvrtko
}
trace_i915_context_create(ctx);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3f04784..0a96d4a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -214,7 +214,8 @@ enum {
LEGACY_64B_CONTEXT
};
#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ADDRESSING_MODE(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
+#define GEN8_CTX_ADDRESSING_MODE(ctx) \
+ (ctx->use_48bit_addressing_mode ? \
LEGACY_64B_CONTEXT :\
LEGACY_32B_CONTEXT)
enum {
@@ -281,8 +282,6 @@ logical_ring_init_platform_invariants(struct
intel_engine_cs *engine)
(engine->id == VCS || engine->id ==
VCS2);
engine->ctx_desc_template = GEN8_CTX_VALID;
- engine->ctx_desc_template |= GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
- GEN8_CTX_ADDRESSING_MODE_SHIFT;
if (IS_GEN8(dev_priv))
engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
@@ -325,8 +324,10 @@ intel_lr_context_descriptor_update(struct intel_context
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1engine[engine->id].lrc_vma->node.start + /* bits 12-31 */
- LRC_PPHWSP_PN * PAGE_SIZE;
+ LRC_PPHWSP_PN * PAGE_SIZE;
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-52 */
ctx->engine[engine->id].lrc_desc = desc;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 3/7] lib/igt_kms: Switch to verbose assert.
From: Robert Foss Switch igt_assert to igt_assert_lte to provide more diagnostic information. Signed-off-by: Robert Foss --- lib/igt_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 876f65c..9af9603 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1392,7 +1392,7 @@ void igt_display_init(igt_display_t *display, int drm_fd) pipe->n_planes = n_planes; /* make sure we don't overflow the plane array */ - igt_assert(pipe->n_planes <= IGT_MAX_PLANES); + igt_assert_lte(pipe->n_planes, IGT_MAX_PLANES); } /* -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915/gvt: Fold vGPU active check into inner functions
Thanks for the comments. :)
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Monday, May 16, 2016 3:50 AM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org;
Gordon, David S ; joonas.lahti...@linux.intel.com;
Tian, Kevin ; Lv, Zhiyuan
Subject: Re: [Intel-gfx] [PATCH 02/15] drm/i915/gvt: Fold vGPU active check
into inner functions
Hi,
On 15/05/16 18:32, Zhi Wang wrote:
> Fold vGPU related active check into the inner functions. (Kevin)
>
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
> drivers/gpu/drm/i915/i915_vgpu.c| 10 --
> drivers/gpu/drm/i915/i915_vgpu.h| 2 +-
> 3 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 7eab619..5c02c5a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2737,11 +2737,9 @@ static int i915_gem_setup_global_gtt(struct drm_device
> *dev,
> i915_address_space_init(&ggtt->base, dev_priv);
> ggtt->base.total += PAGE_SIZE;
>
> - if (intel_vgpu_active(dev_priv)) {
> - ret = intel_vgt_balloon(dev);
> - if (ret)
> - return ret;
> - }
> + ret = intel_vgt_balloon(dev);
> + if (ret)
> + return ret;
>
> if (!HAS_LLC(dev))
> ggtt->base.mm.color_adjust = i915_gtt_color_adjust; @@ -2841,8
> +2839,7 @@ void i915_ggtt_cleanup_hw(struct drm_device *dev)
> i915_gem_cleanup_stolen(dev);
>
> if (drm_mm_initialized(&ggtt->base.mm)) {
> - if (intel_vgpu_active(dev_priv))
> - intel_vgt_deballoon();
> + intel_vgt_deballoon(dev);
>
> drm_mm_takedown(&ggtt->base.mm);
> list_del(&ggtt->base.global_link);
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index d5a7a5e..0b76c70 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -101,10 +101,13 @@ static struct _balloon_info_ bl_info;
>* This function is called to deallocate the ballooned-out graphic memory,
> when
>* driver is unloaded or when ballooning fails.
>*/
> -void intel_vgt_deballoon(void)
> +void intel_vgt_deballoon(struct drm_device *dev)
In the spirit of current driver cleanup you should make intel_vgt_balloon and
deballoon take dev_priv. The former does not use dev for anything anyway, just
to get to dev_priv.
> {
> int i;
>
> + if (!intel_vgpu_active(to_i915(dev)))
> + return;
> +
> DRM_DEBUG("VGT deballoon.\n");
>
> for (i = 0; i < 4; i++) {
> @@ -187,6 +190,9 @@ int intel_vgt_balloon(struct drm_device *dev)
> unsigned long unmappable_base, unmappable_size, unmappable_end;
> int ret;
>
> + if (!intel_vgpu_active(to_i915(dev)))
> + return 0;
Even already has the dev_priv local variable.
> +
> mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
> mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
> unmappable_base =
> I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
> @@ -258,6 +264,6 @@ int intel_vgt_balloon(struct drm_device *dev)
>
> err:
> DRM_ERROR("VGT balloon fail\n");
> - intel_vgt_deballoon();
> + intel_vgt_deballoon(dev);
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.h
> b/drivers/gpu/drm/i915/i915_vgpu.h
> index 07e67d5..c0e9569 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.h
> +++ b/drivers/gpu/drm/i915/i915_vgpu.h
> @@ -28,6 +28,6 @@
>
> extern void i915_check_vgpu(struct drm_i915_private *dev_priv);
> extern int intel_vgt_balloon(struct drm_device *dev); -extern void
> intel_vgt_deballoon(void);
> +extern void intel_vgt_deballoon(struct drm_device *dev);
>
> #endif /* _I915_VGPU_H_ */
>
The rest looks good to me.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/21] drm/i915: Assert the dbuf is enabled when disabling DC5/6
From: Ville Syrjälä
Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling.
Let's make sure it has correctly restored the dbuf state to enabled
when we disable the DC states.
Cc: Imre Deak
Suggested-by: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index b70e123f67ca..27cb92c18bb5 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -806,6 +806,15 @@ static bool gen9_dc_off_power_well_enabled(struct
drm_i915_private *dev_priv,
return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
}
+static void skl_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
+{
+ u32 tmp = I915_READ(DBUF_CTL);
+
+ WARN((tmp & (DBUF_POWER_STATE | DBUF_POWER_REQUEST)) !=
+(DBUF_POWER_STATE | DBUF_POWER_REQUEST),
+"Unexpected DBuf power power state (0x%08x)\n", tmp);
+}
+
static void gen9_dc_off_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
@@ -814,6 +823,8 @@ static void gen9_dc_off_power_well_enable(struct
drm_i915_private *dev_priv,
WARN_ON(dev_priv->cdclk_freq !=
dev_priv->display.get_display_clock_speed(dev_priv->dev));
+ skl_assert_dbuf_enabled(dev_priv);
+
if (IS_BROXTON(dev_priv))
broxton_ddi_phy_verify_state(dev_priv);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Introduce execlist context status change notification
On 15/05/16 18:32, Zhi Wang wrote:
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. So GVT-g
has to know the status of the execlist context.
This function is configurable in the context creation service. Currently,
Only GVT-g will create the "status-change-notification" enabled GEM
context.
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c | 23 +++
drivers/gpu/drm/i915/intel_lrc.h | 5 +
3 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7f050a3..1c9e865 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -884,6 +884,8 @@ struct intel_context {
bool initialised;
bool skip_init_context;
u32 ring_buffer_size;
+ bool enable_status_change_notification;
This flag will be per context and not per context-engine, correct? In
which case it would be worth moving it to the context. Would make
execlists_context_status_change cheaper as well.
+ struct atomic_notifier_head status_notifier_head;
} engine[I915_NUM_ENGINES];
bool use_48bit_addressing_mode;
@@ -2403,6 +2405,9 @@ struct drm_i915_gem_request {
/** Execlists context hardware id. */
unsigned ctx_hw_id;
+
+ /** GVT workload **/
+ void *gvt_workload;
Why is this a void *, for what it will be used ? I can't see in this
patch series what will be stored here so asking. Is it only temporary
until further patches?
Also, is it really per-request? I am just wondering since other patches
are mostly concerned about contexts.
};
struct drm_i915_gem_request * __must_check
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0a96d4a..aeaea2e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -415,6 +415,19 @@ static void execlists_submit_requests(struct
drm_i915_gem_request *rq0,
spin_unlock_irq(&dev_priv->uncore.lock);
}
+static inline void execlists_context_status_change(
+ struct drm_i915_gem_request *req,
+ unsigned long status)
+{
+ if (!req->ctx->engine[req->engine->id].
+ enable_status_change_notification)
+ return;
+
+ atomic_notifier_call_chain(
+ &req->ctx->engine[req->engine->id].status_notifier_head,
+ status, req->gvt_workload);
+}
I would really like to see this compiled out when !CONFIG_DRM_I915_GVT.
Otherwise is just adding useless conditionals on submission fast paths.
+
static void execlists_context_unqueue(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
@@ -450,6 +463,11 @@ static void execlists_context_unqueue(struct
intel_engine_cs *engine)
if (unlikely(!req0))
return;
+ execlists_context_status_change(req0, CONTEXT_SCHEDULE_IN);
+
+ if (req1)
+ execlists_context_status_change(req1, CONTEXT_SCHEDULE_IN);
+
if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
/*
* WaIdleLiteRestore: make sure we never cause a lite restore
@@ -488,6 +506,8 @@ execlists_check_remove_request(struct intel_engine_cs
*engine, u32 ctx_id)
if (--head_req->elsp_submitted > 0)
return 0;
+ execlists_context_status_change(head_req, CONTEXT_SCHEDULE_OUT);
+
list_del(&head_req->execlist_link);
i915_gem_request_unreference(head_req);
@@ -2541,6 +2561,9 @@ static int execlists_context_deferred_alloc(struct
intel_context *ctx,
ctx->engine[engine->id].state = ctx_obj;
ctx->engine[engine->id].initialised = engine_initialised(ctx, engine);
+ if (ctx->engine[engine->id].enable_status_change_notification)
+ ATOMIC_INIT_NOTIFIER_HEAD(
+ &ctx->engine[engine->id].status_notifier_head);
return 0;
error_ringbuf:
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 1afba03..98c94ee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -57,6 +57,11 @@
#define GEN8_CSB_READ_PTR(csb_status) \
(((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
+enum {
+ CONTEXT_SCHEDULE_IN = 0,
+ CONTEXT_SCHEDULE_OUT,
+};
+
/* Logical Rings */
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request);
int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/m
Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6
On 06/05/2016 13:18, Gordon, David S wrote: On 06/05/16 10:37, Nick Hoath wrote: On 05/05/2016 16:04, Dave Gordon wrote: On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up to the value stored in the GUC_WOPCM_SIZE register (as the comment above the #define says). Architecturally, this is allowed to be any value greater than (16K+sizeof internal SRAM (64, 128, or 256K)) and less than or equal to GUC_WOPCM_TOP (which is a platform-independent constant), so we normally choose the maximm allowed. Howver on BXT, we need to leave some space at the top for the RC6 image, hence the logic (and comments!) in guc_wopcm_size(). The extra information does not aid anybody as the information is used internally within the GuC. It may help the next person who has to figure out what's gone wrong on some future chip that needs more than 64K for RC6! .Dave. But, I have not actual objection to the patch. Peter. Unfortunately Dave's patch locked my test system on bootup, so I've t-b & r-b'd Peter's. They're equivalent, unless your firmware happens to be between 458752 and 491520 bytes in size (in which case you have a problem anyway). To check, I've run both versions, with debug printing the value chosen (on SKL) and the value that would have been chosen on BXT, and they're identical (and both work). So I think your build had some other problem unrelated to the specific patch. I've no problem with using Peter's patch for now, but it's not just a matter of the comments; there's also the other use(s) of GUC_WOP_(TOP,SIZE_VALUE), with ad-hoc additions or subtractions. So it still needs fixing properly. .Dave. After a rebuild & a retest, Dave's patch works fine. Therefore for "drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM": Tested-by: Nick Hoath Reviewed-by: Nick Hoath ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing PPGTT in context creation
Looks like I can drop this patch without harm. As I will load the root pointer
myself. And there is patch to check if ppgtt == something then populate PDPs,
so under FULL_PPGTT && !NO_PPGTT_CTX it won't load anything. Under !FULL_PPGTT
&& !NO_PPGTT_CTX, it will load aliasing_ppgtt_mm, but then I will load PDPs
myself, so it's also OK.
-Original Message-
From: Wang, Zhi A
Sent: Monday, May 16, 2016 7:16 AM
To: 'Tvrtko Ursulin' ;
intel-gfx@lists.freedesktop.org; Gordon, David S ;
joonas.lahti...@linux.intel.com; Tian, Kevin ; Lv,
Zhiyuan
Subject: RE: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing
PPGTT in context creation
I understand what you say. Let me think about other approach. My requirement is
to do nothing if a context doesn't have a ppgtt, but ctx->ppgtt == NULL means
context is using aliasing ppgtt, so I need to find another way to achieve this.
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Monday, May 16, 2016 6:31 AM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org;
Gordon, David S ; joonas.lahti...@linux.intel.com;
Tian, Kevin ; Lv, Zhiyuan
Subject: Re: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing
PPGTT in context creation
On 15/05/16 18:32, Zhi Wang wrote:
> Currently ctx->ppgtt would only be initialized when full PPGTT is used.
> For aliasing PPGTT mode, ctx->ppgtt will be set when LRC context is
> populated.
>
> This patch moves the assignment into i915_gem_create_context() for
> better code structure.
Hm, it doesn't move the assignment it adds it.
Previously ctx->ppgtt was always NULL when !USES_FULL_PPGTT. Now it will point
to aliasing ppgtt.
Since there are various places in the code which do "if (ctx->ppgtt)"
(more or less) I think you need to explain why those will still work OK.
i915_gem_context_free for example?
Regards,
Tvrtko
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 4 +++-
> drivers/gpu/drm/i915/intel_lrc.c| 3 ---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 2aedd18..21498e5 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -300,6 +300,7 @@ static struct intel_context *
> i915_gem_create_context(struct drm_device *dev,
> struct drm_i915_file_private *file_priv)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> const bool is_global_default_ctx = file_priv == NULL;
> struct intel_context *ctx;
> int ret = 0;
> @@ -337,7 +338,8 @@ i915_gem_create_context(struct drm_device *dev,
> }
>
> ctx->ppgtt = ppgtt;
> - }
> + } else
> + ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
>
> trace_i915_context_create(ctx);
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index db10c96..397fe65 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2286,9 +2286,6 @@ populate_lr_context(struct intel_context *ctx,
> u32 *reg_state;
> int ret;
>
> - if (!ppgtt)
> - ppgtt = dev_priv->mm.aliasing_ppgtt;
> -
> ret = i915_gem_object_set_to_cpu_domain(ctx_obj, true);
> if (ret) {
> DRM_DEBUG_DRIVER("Could not set to CPU domain\n");
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Introduce execlist context status change notification
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Monday, May 16, 2016 7:00 AM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org;
Gordon, David S ; joonas.lahti...@linux.intel.com;
Tian, Kevin ; Lv, Zhiyuan
Subject: Re: [Intel-gfx] [PATCH 11/15] drm/i915: Introduce execlist context
status change notification
On 15/05/16 18:32, Zhi Wang wrote:
> This patch introduces an approach to track the execlist context status
> change.
>
> GVT-g uses GVT context as the "shadow context". The content inside GVT
> context will be copied back to guest after the context is idle. So
> GVT-g has to know the status of the execlist context.
>
> This function is configurable in the context creation service.
> Currently, Only GVT-g will create the "status-change-notification"
> enabled GEM context.
>
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_lrc.c | 23 +++
> drivers/gpu/drm/i915/intel_lrc.h | 5 +
> 3 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 7f050a3..1c9e865 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -884,6 +884,8 @@ struct intel_context {
> bool initialised;
> bool skip_init_context;
> u32 ring_buffer_size;
> + bool enable_status_change_notification;
This flag will be per context and not per context-engine, correct? In which
case it would be worth moving it to the context. Would make
execlists_context_status_change cheaper as well.
OK. Will do.
> + struct atomic_notifier_head status_notifier_head;
> } engine[I915_NUM_ENGINES];
> bool use_48bit_addressing_mode;
>
> @@ -2403,6 +2405,9 @@ struct drm_i915_gem_request {
>
> /** Execlists context hardware id. */
> unsigned ctx_hw_id;
> +
> + /** GVT workload **/
> + void *gvt_workload;
Why is this a void *, for what it will be used ? I can't see in this patch
series what will be stored here so asking. Is it only temporary until further
patches?
Also, is it really per-request? I am just wondering since other patches are
mostly concerned about contexts.
Will remove that according to today discussion.
> };
>
> struct drm_i915_gem_request * __must_check diff --git
> a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 0a96d4a..aeaea2e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -415,6 +415,19 @@ static void execlists_submit_requests(struct
> drm_i915_gem_request *rq0,
> spin_unlock_irq(&dev_priv->uncore.lock);
> }
>
> +static inline void execlists_context_status_change(
> + struct drm_i915_gem_request *req,
> + unsigned long status)
> +{
> + if (!req->ctx->engine[req->engine->id].
> + enable_status_change_notification)
> + return;
> +
> + atomic_notifier_call_chain(
> + &req->ctx->engine[req->engine->id].status_notifier_head,
> + status, req->gvt_workload);
> +}
I would really like to see this compiled out when !CONFIG_DRM_I915_GVT.
Otherwise is just adding useless conditionals on submission fast paths.
Let's do that.
> +
> static void execlists_context_unqueue(struct intel_engine_cs *engine)
> {
> struct drm_i915_gem_request *req0 = NULL, *req1 = NULL; @@ -450,6
> +463,11 @@ static void execlists_context_unqueue(struct intel_engine_cs
> *engine)
> if (unlikely(!req0))
> return;
>
> + execlists_context_status_change(req0, CONTEXT_SCHEDULE_IN);
> +
> + if (req1)
> + execlists_context_status_change(req1, CONTEXT_SCHEDULE_IN);
> +
> if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
> /*
>* WaIdleLiteRestore: make sure we never cause a lite restore
> @@
> -488,6 +506,8 @@ execlists_check_remove_request(struct intel_engine_cs
> *engine, u32 ctx_id)
> if (--head_req->elsp_submitted > 0)
> return 0;
>
> + execlists_context_status_change(head_req, CONTEXT_SCHEDULE_OUT);
> +
> list_del(&head_req->execlist_link);
> i915_gem_request_unreference(head_req);
>
> @@ -2541,6 +2561,9 @@ static int execlists_context_deferred_alloc(struct
> intel_context *ctx,
> ctx->engine[engine->id].state = ctx_obj;
> ctx->engine[engine->id].initialised = engine_initialised(ctx,
> engine);
>
> + if (ctx->engine[engine->id].enable_status_change_notification)
> + ATOMIC_INIT_NOTIFIER_HEAD(
> + &ctx->engine[engine->id].status_notifier_head);
> return 0;
>
> error_ringbuf:
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index 1afba03..98c94ee 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing PPGTT in context creation
I understand what you say. Let me think about other approach. My requirement is
to do nothing if a context doesn't have a ppgtt, but ctx->ppgtt == NULL means
context is using aliasing ppgtt, so I need to find another way to achieve this.
-Original Message-
From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
Sent: Monday, May 16, 2016 6:31 AM
To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org;
Gordon, David S ; joonas.lahti...@linux.intel.com;
Tian, Kevin ; Lv, Zhiyuan
Subject: Re: [Intel-gfx] [PATCH 05/15] drm/i915: Set ctx->ppgtt for aliasing
PPGTT in context creation
On 15/05/16 18:32, Zhi Wang wrote:
> Currently ctx->ppgtt would only be initialized when full PPGTT is used.
> For aliasing PPGTT mode, ctx->ppgtt will be set when LRC context is
> populated.
>
> This patch moves the assignment into i915_gem_create_context() for
> better code structure.
Hm, it doesn't move the assignment it adds it.
Previously ctx->ppgtt was always NULL when !USES_FULL_PPGTT. Now it will point
to aliasing ppgtt.
Since there are various places in the code which do "if (ctx->ppgtt)"
(more or less) I think you need to explain why those will still work OK.
i915_gem_context_free for example?
Regards,
Tvrtko
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 4 +++-
> drivers/gpu/drm/i915/intel_lrc.c| 3 ---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 2aedd18..21498e5 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -300,6 +300,7 @@ static struct intel_context *
> i915_gem_create_context(struct drm_device *dev,
> struct drm_i915_file_private *file_priv)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> const bool is_global_default_ctx = file_priv == NULL;
> struct intel_context *ctx;
> int ret = 0;
> @@ -337,7 +338,8 @@ i915_gem_create_context(struct drm_device *dev,
> }
>
> ctx->ppgtt = ppgtt;
> - }
> + } else
> + ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
>
> trace_i915_context_create(ctx);
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index db10c96..397fe65 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2286,9 +2286,6 @@ populate_lr_context(struct intel_context *ctx,
> u32 *reg_state;
> int ret;
>
> - if (!ppgtt)
> - ppgtt = dev_priv->mm.aliasing_ppgtt;
> -
> ret = i915_gem_object_set_to_cpu_domain(ctx_obj, true);
> if (ret) {
> DRM_DEBUG_DRIVER("Could not set to CPU domain\n");
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Factor out and expose i915_steal_fence()
On Mon, May 16, 2016 at 01:32:52AM +0800, Zhi Wang wrote: > Factor out and expose fence stealing functionality for GVT-g. GVT-g > will use i915_find_fence_reg() to find a free/unpin fence register > and use i915_steal_fence() to steal it. No. This code cannot be exported as is (the code makes presumptions that the caller will carefully control the reference). And there is nothing to tell us what you need it for. -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 i-g-t v2] autotools/: Allow building tests/gem_concurrent_{all, blit}
Trivial. Pushed. On Mon, May 16, 2016 at 01:36:48PM +0300, Marius Vlad wrote: > Introduced by a633ad03c6 (tests: Separate tests with lots of subtests). > > v2: Fix commit typo (Jani Nikula). > > Signed-off-by: Marius Vlad > --- > tests/Makefile.am | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/Makefile.am b/tests/Makefile.am > index 32b9115..c2c2025 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -30,6 +30,7 @@ pkglibexec_PROGRAMS = \ > gem_stress \ > $(TESTS_progs) \ > $(TESTS_progs_M) \ > + $(TESTS_progs_XM) \ > $(NULL) > > dist_pkglibexec_SCRIPTS = \ > -- > 2.8.0.rc3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/dsi: add skip functions for spi and pmic elements
In sequence block v3 these are gracefully skipped anyway, but add the
functions so we can have some debug breadcrumbs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 3e840a526f53..7dd850760c4d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -344,6 +344,20 @@ static const u8 *mipi_exec_i2c(struct intel_dsi
*intel_dsi, const u8 *data)
return data + *(data + 6) + 7;
}
+static const u8 *mipi_exec_spi(struct intel_dsi *intel_dsi, const u8 *data)
+{
+ DRM_DEBUG_KMS("Skipping SPI element execution\n");
+
+ return data + *(data + 5) + 6;
+}
+
+static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
+{
+ DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+
+ return data + 14;
+}
+
typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
const u8 *data);
static const fn_mipi_elem_exec exec_elem[] = {
@@ -351,6 +365,8 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
[MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
+ [MIPI_SEQ_ELEM_SPI] = mipi_exec_spi,
+ [MIPI_SEQ_ELEM_PMIC] = mipi_exec_pmic,
};
/*
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/dsi: don't debug log "missing" sequences
This is not interesting. They are not "missing", they are just not part
of the VBT sequences for the panel.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f122484bedfc..4d05f0bfaea3 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -385,11 +385,8 @@ static void generic_exec_sequence(struct drm_panel *panel,
enum mipi_seq seq_id)
return;
data = dev_priv->vbt.dsi.sequence[seq_id];
- if (!data) {
- DRM_DEBUG_KMS("MIPI sequence %d - %s not available\n",
- seq_id, sequence_name(seq_id));
+ if (!data)
return;
- }
WARN_ON(*data != seq_id);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] drm/i915/dsi: sequence execution tweaks
Run the power/backlight on/off sequences, log about not running tear on/off sequences, add a consistency check, and improve the debug logging. BR, Jani. Jani Nikula (7): drm/i915/dsi: don't debug log "missing" sequences drm/i915/dsi: add debug logging to element execution drm/i915/dsi: add skip functions for spi and pmic elements drm/i915/dsi: run power on/off sequences in panel prepare/unprepare hooks drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks drm/i915/bios: log about presence of DSI sequences we do not run drm/i915/dsi: double check element parsing against size if present drivers/gpu/drm/i915/intel_bios.c | 4 +++ drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 45 ++ 2 files changed, 43 insertions(+), 6 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/dsi: add debug logging to element execution
Just simple breadcrumbs for now. While at it, rename the i2c skip
function.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 4d05f0bfaea3..3e840a526f53 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -126,6 +126,8 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi
*intel_dsi,
u16 len;
enum port port;
+ DRM_DEBUG_KMS("\n");
+
flags = *data++;
type = *data++;
@@ -199,6 +201,8 @@ static const u8 *mipi_exec_delay(struct intel_dsi
*intel_dsi, const u8 *data)
{
u32 delay = *((const u32 *) data);
+ DRM_DEBUG_KMS("\n");
+
usleep_range(delay, delay + 10);
data += 4;
@@ -307,6 +311,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
u8 gpio_source, gpio_index;
bool value;
+ DRM_DEBUG_KMS("\n");
+
if (dev_priv->vbt.dsi.seq_version >= 3)
data++;
@@ -331,8 +337,10 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
return data;
}
-static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8
*data)
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
{
+ DRM_DEBUG_KMS("Skipping I2C element execution\n");
+
return data + *(data + 6) + 7;
}
@@ -342,7 +350,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
- [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
+ [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
};
/*
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index e0337a82a6b4..d078c5765014 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -476,12 +476,14 @@ static int vbt_panel_unprepare(struct drm_panel *panel)
static int vbt_panel_enable(struct drm_panel *panel)
{
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON);
+ generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON);
return 0;
}
static int vbt_panel_disable(struct drm_panel *panel)
{
+ generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF);
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF);
return 0;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/bios: log about presence of DSI sequences we do not run
Leave behind some debugging clues in case some panels don't work
properly.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 8b68c4882fba..8cab24bb5c29 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -991,6 +991,10 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
goto err;
}
+ /* Log about presence of sequences we won't run. */
+ if (seq_id == MIPI_SEQ_TEAR_ON || seq_id == MIPI_SEQ_TEAR_OFF)
+ DRM_DEBUG_KMS("Unsupported sequence %u\n", seq_id);
+
dev_priv->vbt.dsi.sequence[seq_id] = data + index;
if (sequence->version >= 3)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/dsi: double check element parsing against size if present
Be a little paranoid in case the specs change or something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index d078c5765014..30fcb02fce9b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -441,7 +441,15 @@ static void generic_exec_sequence(struct drm_panel *panel,
enum mipi_seq seq_id)
operation_size = *data++;
if (mipi_elem_exec) {
+ const u8 *next = data + operation_size;
+
data = mipi_elem_exec(intel_dsi, data);
+
+ /* Consistency check if we have size. */
+ if (operation_size && data != next) {
+ DRM_ERROR("Inconsistent operation size\n");
+ return;
+ }
} else if (operation_size) {
/* We have size, skip. */
DRM_DEBUG_KMS("Unsupported MIPI operation byte %u\n",
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Factor out and expose i915_steal_fence()
I see. How about merging this function into i915_find_fence_reg()? -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Monday, May 16, 2016 7:58 AM To: Wang, Zhi A Cc: intel-gfx@lists.freedesktop.org; Gordon, David S ; joonas.lahti...@linux.intel.com; Tian, Kevin ; Lv, Zhiyuan Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: Factor out and expose i915_steal_fence() On Mon, May 16, 2016 at 01:32:52AM +0800, Zhi Wang wrote: > Factor out and expose fence stealing functionality for GVT-g. GVT-g > will use i915_find_fence_reg() to find a free/unpin fence register and > use i915_steal_fence() to steal it. No. This code cannot be exported as is (the code makes presumptions that the caller will carefully control the reference). And there is nothing to tell us what you need it for. -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 06/15] drm/i915: Allow the caller to create a intel_context without PPGTT
On Mon, May 16, 2016 at 01:32:44AM +0800, Zhi Wang wrote:
> GVT context will use its own shadow PPGTT, and it doesn't need a
> i915_hw_ppgtt.
>
> This patch adds a "has_ppgtt" param to i915_gem_context(), which
> allows the caller to create a context without PPGTT
>
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 34
> ++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 21498e5..b952e37 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -298,7 +298,8 @@ err_out:
> */
> static struct intel_context *
> i915_gem_create_context(struct drm_device *dev,
> - struct drm_i915_file_private *file_priv)
> + struct drm_i915_file_private *file_priv,
> + bool has_ppgtt)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> const bool is_global_default_ctx = file_priv == NULL;
> @@ -327,19 +328,22 @@ i915_gem_create_context(struct drm_device *dev,
> }
> }
>
> - if (USES_FULL_PPGTT(dev)) {
> - struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
> + if (has_ppgtt) {
> + if (USES_FULL_PPGTT(dev)) {
> + struct i915_hw_ppgtt *ppgtt =
> + i915_ppgtt_create(dev, file_priv);
>
> - if (IS_ERR_OR_NULL(ppgtt)) {
> - DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
> - PTR_ERR(ppgtt));
> - ret = PTR_ERR(ppgtt);
> - goto err_unpin;
> - }
> + if (IS_ERR_OR_NULL(ppgtt)) {
> + DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
> + PTR_ERR(ppgtt));
> + ret = PTR_ERR(ppgtt);
> + goto err_unpin;
> + }
>
> - ctx->ppgtt = ppgtt;
> - } else
> - ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
> + ctx->ppgtt = ppgtt;
> + } else
> + ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
You have to first go through the driver and update the sematics for
ctx->ppgtt == NULL. (Note in some instances you have to use the
ggtt pointer and not the appgtt, just a minor case in execbuf!).
Then tell us how you didn't spot the explosion when trying to use the
aliasing_ppgtt after freeing it.
-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] [PATCH 4/7] drm/i915/dsi: run power on/off sequences in panel prepare/unprepare hooks
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 7dd850760c4d..e0337a82a6b4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -459,6 +459,7 @@ static void generic_exec_sequence(struct drm_panel *panel,
enum mipi_seq seq_id)
static int vbt_panel_prepare(struct drm_panel *panel)
{
generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
+ generic_exec_sequence(panel, MIPI_SEQ_POWER_ON);
generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP);
return 0;
@@ -466,6 +467,7 @@ static int vbt_panel_prepare(struct drm_panel *panel)
static int vbt_panel_unprepare(struct drm_panel *panel)
{
+ generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF);
generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
return 0;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Allow the caller to create a intel_context without PPGTT
Yes. Thanks! Seems there is an assumption if ctx->ppgtt == NULL then go back to
use aliasing ppgtt. I see. I will drop that patch, without that patch we could
also work
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Monday, May 16, 2016 8:13 AM
To: Wang, Zhi A
Cc: intel-gfx@lists.freedesktop.org; Gordon, David S
; joonas.lahti...@linux.intel.com; Tian, Kevin
; Lv, Zhiyuan
Subject: Re: [Intel-gfx] [PATCH 06/15] drm/i915: Allow the caller to create a
intel_context without PPGTT
On Mon, May 16, 2016 at 01:32:44AM +0800, Zhi Wang wrote:
> GVT context will use its own shadow PPGTT, and it doesn't need a
> i915_hw_ppgtt.
>
> This patch adds a "has_ppgtt" param to i915_gem_context(), which
> allows the caller to create a context without PPGTT
>
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 34
> ++---
> 1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 21498e5..b952e37 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -298,7 +298,8 @@ err_out:
> */
> static struct intel_context *
> i915_gem_create_context(struct drm_device *dev,
> - struct drm_i915_file_private *file_priv)
> + struct drm_i915_file_private *file_priv,
> + bool has_ppgtt)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> const bool is_global_default_ctx = file_priv == NULL; @@ -327,19
> +328,22 @@ i915_gem_create_context(struct drm_device *dev,
> }
> }
>
> - if (USES_FULL_PPGTT(dev)) {
> - struct i915_hw_ppgtt *ppgtt = i915_ppgtt_create(dev, file_priv);
> + if (has_ppgtt) {
> + if (USES_FULL_PPGTT(dev)) {
> + struct i915_hw_ppgtt *ppgtt =
> + i915_ppgtt_create(dev, file_priv);
>
> - if (IS_ERR_OR_NULL(ppgtt)) {
> - DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
> - PTR_ERR(ppgtt));
> - ret = PTR_ERR(ppgtt);
> - goto err_unpin;
> - }
> + if (IS_ERR_OR_NULL(ppgtt)) {
> + DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
> + PTR_ERR(ppgtt));
> + ret = PTR_ERR(ppgtt);
> + goto err_unpin;
> + }
>
> - ctx->ppgtt = ppgtt;
> - } else
> - ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
> + ctx->ppgtt = ppgtt;
> + } else
> + ctx->ppgtt = dev_priv->mm.aliasing_ppgtt;
You have to first go through the driver and update the sematics for
ctx->ppgtt == NULL. (Note in some instances you have to use the
ggtt pointer and not the appgtt, just a minor case in execbuf!).
Then tell us how you didn't spot the explosion when trying to use the
aliasing_ppgtt after freeing it.
-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] [PATCH 1/3] drm/i915: refactor i915_gem_object_pin_map()
The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its own subfunction.
The next patch will then insert the new optimisation into the middle of
the now-separated subfunction.
This reorganisation will probably not affect the generated code, as the
compiler will most likely inline it anyway, but it makes the logical
structure a bit clearer and easier to modify.
v2:
Restructure loop-over-pages & error check (Chris Wilson)
v3:
Add page count to debug messages (Chris Wilson)
Convert WARN_ON() to GEM_BUG_ON()
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 59 ++---
1 file changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index aff386e..bbec429 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2398,6 +2398,43 @@ static void i915_gem_object_free_mmap_offset(struct
drm_i915_gem_object *obj)
return 0;
}
+/* The 'mapping' part of i915_gem_object_pin_map() below */
+static void *i915_gem_object_map(const struct drm_i915_gem_object *obj)
+{
+ unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
+ struct sg_table *sgt = obj->pages;
+ struct sg_page_iter sg_iter;
+ struct page **pages;
+ unsigned long i = 0;
+ void *addr = NULL;
+
+ /* A single page can always be kmapped */
+ if (n_pages == 1)
+ return kmap(sg_page(sgt->sgl));
+
+ pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+ if (pages == NULL) {
+ DRM_DEBUG_DRIVER("Failed to get space for %lu pointers\n",
+n_pages);
+ return NULL;
+ }
+
+ for_each_sg_page(sgt->sgl, &sg_iter, sgt->nents, 0)
+ pages[i++] = sg_page_iter_page(&sg_iter);
+
+ /* Check that we have the expected number of pages */
+ GEM_BUG_ON(i != n_pages);
+
+ addr = vmap(pages, n_pages, 0, PAGE_KERNEL);
+ if (addr == NULL)
+ DRM_DEBUG_DRIVER("Failed to vmap %lu pages\n", n_pages);
+
+ drm_free_large(pages);
+
+ return addr;
+}
+
+/* get, pin, and map the pages of the object into kernel space */
void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
{
int ret;
@@ -2411,27 +2448,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object
*obj)
i915_gem_object_pin_pages(obj);
if (obj->mapping == NULL) {
- struct page **pages;
-
- pages = NULL;
- if (obj->base.size == PAGE_SIZE)
- obj->mapping = kmap(sg_page(obj->pages->sgl));
- else
- pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
- sizeof(*pages),
- GFP_TEMPORARY);
- if (pages != NULL) {
- struct sg_page_iter sg_iter;
- int n;
-
- n = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter,
-obj->pages->nents, 0)
- pages[n++] = sg_page_iter_page(&sg_iter);
-
- obj->mapping = vmap(pages, n, 0, PAGE_KERNEL);
- drm_free_large(pages);
- }
+ obj->mapping = i915_gem_object_map(obj);
if (obj->mapping == NULL) {
i915_gem_object_unpin_pages(obj);
return ERR_PTR(-ENOMEM);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: optimise i915_gem_object_map() for small objects
We're using this function for ringbuffers and other "small" objects, so
it's worth avoiding an extra malloc()/free() cycle if the page array is
small enough to put on the stack. Here we've chosen an arbitrary cutoff
of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a
context image (currently up to 22 pages).
v5:
change name of local array [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bbec429..38e4e1e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2404,7 +2404,8 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj)
unsigned long n_pages = obj->base.size >> PAGE_SHIFT;
struct sg_table *sgt = obj->pages;
struct sg_page_iter sg_iter;
- struct page **pages;
+ struct page *stack_pages[32];
+ struct page **pages = stack_pages;
unsigned long i = 0;
void *addr = NULL;
@@ -2412,11 +2413,14 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj)
if (n_pages == 1)
return kmap(sg_page(sgt->sgl));
- pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
- if (pages == NULL) {
- DRM_DEBUG_DRIVER("Failed to get space for %lu pointers\n",
-n_pages);
- return NULL;
+ if (n_pages > ARRAY_SIZE(stack_pages)) {
+ /* Too big for stack -- allocate temporary array instead */
+ pages = drm_malloc_gfp(n_pages, sizeof(*pages), GFP_TEMPORARY);
+ if (pages == NULL) {
+ DRM_DEBUG_DRIVER("Failed to get space for %lu
pointers\n",
+n_pages);
+ return NULL;
+ }
}
for_each_sg_page(sgt->sgl, &sg_iter, sgt->nents, 0)
@@ -2429,7 +2433,8 @@ static void *i915_gem_object_map(const struct
drm_i915_gem_object *obj)
if (addr == NULL)
DRM_DEBUG_DRIVER("Failed to vmap %lu pages\n", n_pages);
- drm_free_large(pages);
+ if (pages != stack_pages)
+ drm_free_large(pages);
return addr;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] Introduce & use new lightweight SGL iterators
The existing for_each_sg_page() iterator is somewhat heavyweight, and is
limiting i915 driver performance in a few benchmarks. So here we
introduce somewhat lighter weight iterators, primarily for use with GEM
objects or other case where we need only deal with whole aligned pages.
Unlike the old iterator, the new iterators use an internal state
structure which is not intended to be accessed by the caller; instead
each takes as a parameter an output variable which is set before each
iteration. This makes them particularly simple to use :)
One of the new iterators provides the caller with the DMA address of
each page in turn; the other provides the 'struct page' pointer required
by many memory management operations.
Various uses of for_each_sg_page() are then converted to the new macros.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.h | 62 +--
drivers/gpu/drm/i915/i915_gem.c | 20 -
drivers/gpu/drm/i915/i915_gem_fence.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 76 -
drivers/gpu/drm/i915/i915_gem_userptr.c | 7 ++-
5 files changed, 116 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72f0b02..c0fc6aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2125,6 +2125,10 @@ struct drm_i915_gem_object_ops {
#define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
(0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+void i915_gem_track_fb(struct drm_i915_gem_object *old,
+ struct drm_i915_gem_object *new,
+ unsigned frontbuffer_bits);
+
struct drm_i915_gem_object {
struct drm_gem_object base;
@@ -2256,9 +2260,61 @@ struct drm_i915_gem_object {
};
#define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
-void i915_gem_track_fb(struct drm_i915_gem_object *old,
- struct drm_i915_gem_object *new,
- unsigned frontbuffer_bits);
+/*
+ * New optimised SGL iterator for i915 GEM objects
+ */
+struct sgt_iter {
+ struct scatterlist *sgp;
+ union {
+ unsigned long pfn;
+ unsigned long dma;
+ } ix;
+ unsigned int curr;
+ unsigned int max;
+};
+
+/* Constructor for new iterator */
+static inline struct sgt_iter
+__sgt_iter(struct scatterlist *sgl, bool dma)
+{
+ struct sgt_iter s = { .sgp = sgl };
+
+ if (sgl) {
+ s.max = s.curr = sgl->offset;
+ s.max += sgl->length;
+ if (dma)
+ s.ix.dma = sg_dma_address(sgl);
+ else
+ s.ix.pfn = page_to_pfn(sg_page(sgl));
+ }
+
+ return s;
+}
+
+/**
+ * for_each_sgt_dma - iterate over the DMA addresses of the given sg_table
+ * @__dmap:DMA address (output)
+ * @__iter:'struct sgt_iter' (iterator state, internal)
+ * @__sgt: sg_table to iterate over (input)
+ */
+#define for_each_sgt_dma(__dmap, __iter, __sgt)
\
+ for ((__iter) = __sgt_iter((__sgt)->sgl, true); \
+((__dmap) = (__iter).ix.dma + (__iter).curr); \
+(((__iter).curr += PAGE_SIZE) < (__iter).max) || \
+ ((__iter) = __sgt_iter(sg_next((__iter).sgp), true), 0))
+
+/**
+ * for_each_sgt_page - iterate over the pages of the given sg_table
+ * @__pp: page pointer (output)
+ * @__iter:'struct sgt_iter' (iterator state, internal)
+ * @__sgt: sg_table to iterate over (input)
+ */
+#define for_each_sgt_page(__pp, __iter, __sgt) \
+ for ((__iter) = __sgt_iter((__sgt)->sgl, false);\
+((__pp) = (__iter).ix.pfn == 0 ? NULL :\
+ pfn_to_page((__iter).ix.pfn + ((__iter).curr >> PAGE_SHIFT)));\
+(((__iter).curr += PAGE_SIZE) < (__iter).max) || \
+ ((__iter) = __sgt_iter(sg_next((__iter).sgp), false), 0))
/**
* Request queue structure.
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 38e4e1e..0fe7e95 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2165,7 +2165,8 @@ static void i915_gem_object_free_mmap_offset(struct
drm_i915_gem_object *obj)
static void
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
{
- struct sg_page_iter sg_iter;
+ struct sgt_iter sgt_iter;
+ struct page *page;
int ret;
BUG_ON(obj->madv == __I915_MADV_PURGED);
@@ -2187,9 +2188,7 @@ static void i915_gem_object_free_mmap_offset(struct
drm_i915_gem_object *obj)
if (obj->madv == I915_MADV_DONTNEED)
obj->dirty = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents, 0) {
- str
Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools
On Mon, 16 May 2016, Dave Gordon wrote:
> On 13/05/16 16:05, Tvrtko Ursulin wrote:
>>
>> On 13/05/16 15:47, Jani Nikula wrote:
>>> On Fri, 13 May 2016, Chris Wilson wrote:
On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote:
>
> On 13/05/16 15:04, Jani Nikula wrote:
>> This is more robust for assignments and comparisons.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index d9d07b70f05c..bb0b6f64000e 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -752,7 +752,7 @@ struct intel_csr {
>> func(has_ddi) sep \
>> func(has_fpga_dbg)
>>
>> -#define DEFINE_FLAG(name) u8 name:1
>> +#define DEFINE_FLAG(name) bool name:1
>> #define SEP_SEMICOLON ;
>>
>> struct intel_device_info {
>>
>
> The churn virus spreads? :)
>
> I tried that but it was negatively impacting the compiler. For some
> reason it increases .text by 2.5k here. Don't see anything obvious,
> would have to look at the code more closely to spot exactly why.
Oh, that's not fun. bool:1 holds such promise for a clear explanation of
the most common form of bitfield.
>>>
>>> Really a bummer, especially since assigning any positive even number to
>>> unsigned int foo:1 will result in 0.
>>
>> That is a pretty strong argument to go for this rather than make sure
>> all places which set them are correct.
>>
>> Reviewed-by: Tvrtko Ursulin
>>
>> Regards,
>> Tvrtko
>
> Unfortunately, the compiler doesn't generate such good code when using
> 'bool' vs. 'u8' for these bitfields.
I've pushed patch 2/2 while the jury seems to be still out for 1/2.
Generally we might prefer bools anyway, but this struct is const in
dev_priv with the idea that this is immutable data, and we override the
const briefly on driver load in intel_device_info_runtime_init().
Checking all usage is not a huge effort, although we might still screw
this up later on...
BR,
Jani.
>
> Firstly, it looks like the compiler DOESN'T combine bool-bitfield tests
> such as "if (IS_A() || IS_B())", whereas it does if they're u8. Example:
>
> With bitfields as 'u8'
>
> if (IS_HASWELL(dev) || IS_BROADWELL(dev))
> 48 8b 57 28 mov0x28(%rdi),%rdx # dev->dev_priv
> 0f b6 52 30 movzbl 0x30(%rdx),%edx # dev_priv->flag byte
> f6 c2 60 test $0x60,%dl# (haswell|broadwell)
> 0f 85 bb 00 00 00 jne12e4 # branch to if-true
>
> else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> 83 e2 18 and$0x18,%edx # test two more flags
> 0f 84 1c 01 00 00 je 134e # skip if neither
> ... code for VLV/CHV ...
> (code for HSW/BDW is out-of-line, at the end of the function)
>
> With bitfields as bools:
>
> 48 8b 57 28 mov0x28(%rdi),%rdx # dev->dev_priv
> 0f b6 52 30 movzbl 0x30(%rdx),%edx # dev_priv->flag byte
> f6 c2 20 test $0x20,%dl# test one flag
> 75 09 jne1241 # jump if true
> f6 c2 40 test $0x40,%dl# test other flag
> 0f 84 b7 00 00 00 je 12f8 # skip if not
> ... code for HSW/BDW ...
> (code for VLV/CHV/other is later)
>
> So that would suggest that the compiler generates more efficient code
> for 'u8' (at least it didn't reload the flag byte even in the 'bool'
> case). Here's another case:
>
> With bitfields as bools:
>
> dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
> HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
> 0f b6 43 30 movzbl 0x30(%rbx),%eax # flags byte
> c0 e8 05 shr$0x5,%al # haswell->bit 0
> 83 e0 01 and$0x1,%eax# leaves bit 0 only
> 3c 01 cmp$0x1,%al # compare to 1u
> 19 c0 sbb%eax,%eax# convert to 0/-1
> 25 00 b0 00 00and$0xb000,%eax # convert to 0/b000
> 05 00 48 06 00add$0x64800,%eax# final result
> 89 83 e8 20 00 00 mov%eax,0x20e8(%rbx)# store it
>
> This is ingenious code, avoiding any branching. Now with 'u8':
>
> 0f b6 43 30 movzbl 0x30(%rbx),%eax
> 83 e0 20 and$0x20,%eax # leaves bit 5 only
> 3c 01 cmp$0x1,%al # compare to 1u
> 19 c0 sbb%eax,%eax# convert to 0/-1
> 25 00 b0 00 00and$0xb000,%eax # etc
> 05 00 48 06 00add$0x64800,%eax
> 89 83 e8 20 00 00 mov%eax,0x20e8(%rbx)
>
> Again it's shorter, because the compiler has been able to extract a
> truth-value without shifting the "haswell" bit down to bit 0 first.
>
> .Dave.
> _
[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/dsi: sequence execution tweaks
== Series Details == Series: drm/i915/dsi: sequence execution tweaks URL : https://patchwork.freedesktop.org/series/7234/ State : failure == Summary == Series 7234v1 drm/i915/dsi: sequence execution tweaks http://patchwork.freedesktop.org/api/1.0/series/7234/revisions/1/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-ivb2-i7-3770) pass -> FAIL (ro-byt-n2820) fail -> PASS (ro-hsw-i3-4010u) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:173 dwarn:0 dfail:0 fail:4 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:151 dwarn:0 dfail:0 fail:2 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:186 dwarn:0 dfail:0 fail:1 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_909/ d381724 drm-intel-nightly: 2016y-05m-16d-12h-14m-04s UTC integration manifest 2075953 drm/i915/dsi: double check element parsing against size if present a158996 drm/i915/bios: log about presence of DSI sequences we do not run f5ee3b8 drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks 5e59831 drm/i915/dsi: run power on/off sequences in panel prepare/unprepare hooks 408b6d6 drm/i915/dsi: add skip functions for spi and pmic elements ff3e4b9 drm/i915/dsi: add debug logging to element execution 39c0e84 drm/i915/dsi: don't debug log "missing" sequences ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915: refactor i915_gem_object_pin_map()
== Series Details == Series: series starting with [1/3] drm/i915: refactor i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/7237/ State : failure == Summary == Series 7237v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/7237/revisions/1/mbox Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ro-ilk1-i5-650) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ro-hsw-i7-4770r) fail -> PASS (ro-hsw-i3-4010u) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-hsw-i7-4770r total:219 pass:193 dwarn:0 dfail:0 fail:1 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_910/ d381724 drm-intel-nightly: 2016y-05m-16d-12h-14m-04s UTC integration manifest 304d9cf Introduce & use new lightweight SGL iterators 60b157a drm/i915: optimise i915_gem_object_map() for small objects bd3b9cc drm/i915: refactor i915_gem_object_pin_map() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter
On 13/05/16 16:31, Tvrtko Ursulin wrote:
On 13/05/16 15:36, Dave Gordon wrote:
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
0 DISABLE don't load/use the GuC
1 BEST EFFORT try to load/use the GuC, fallback if not available
2 REQUIRE must load/use the GuC, else leave the GPU wedged
The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.
v4:
Changed some error-message levels, mostly ERROR->INFO, per
review comments by Tvrtko Ursulin.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c| 1 -
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_params.c | 14 +++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 108
-
5 files changed, 76 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 2a7be71..2bf8743 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4870,7 +4870,6 @@ int i915_gem_init_engines(struct drm_device *dev)
ret = intel_guc_setup(dev);
if (ret) {
DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
This error msg should go as well I think.
Yes, if we reach this we'll have just printed a message in
intel_guc_setup() so we don't really need both.
-ret = -EIO;
goto out;
}
}
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a..916cd67 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
-if (!i915.enable_guc_submission)
+if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
-if (!i915.enable_guc_submission)
+if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
Will the above two do the right thing for the fw_path == NULL case? That
is !HAS_GUC_UCODE && HAS_GUC_SCHED? Looks like load status will bt NONE
in that case, GuC submission will be enabled and suspend and resume
hooks will be skipped?
Maybe fetch and load status should be set to success on such platforms?
I think probably fetch==NONE but load==SUCCESS, in which case the code
above will be correct already. OTOH there aren't actually any such
platforms yet, and intel_guc_setup() doesn't really support this fully;
for instance, we don't know whether the correct behaviour of _setup() on
such a hypothetical platform would be to reset the GuC and just skip the
DMA, or to skip the reset as well. Certainly some of the setup would
still be required.
So for now I've forced GuC submission off for any such platform, so the
code above should be OK for the four possibilities (no GuC, GuC not
loaded, GuC loaded but not used for submission, GuC loaded and in use).
We can revisit this in the event that a firmware-free GuC ever appears!
[snip]
@@ -486,7 +474,6 @@ int intel_guc_setup(struct drm_device *dev)
return 0;
fail:
-DRM_ERROR("GuC firmware load failed, err %d\n", err);
if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_PENDING)
guc_fw->guc_fw_load_status = GUC_FIRMWARE_FAIL;
@@ -494,7 +481,36 @@ int intel_guc_setup(struct drm_device *dev)
i915_guc_submission_disable(dev);
i915_guc_submission_fini(dev);
-return err;
+/*
+ * We've failed to load the firmware :(
+ *
+ * Decide whether to disable GuC submission and fall back to
+ * execlist mode, and whether to hide the error by returning
+ * zero or to return -EIO, which the caller will treat as a
+ * nonfatal error (i.e. it doesn't prevent driver load, but
+ * marks the GPU as wedged until reset).
+ */
+if (i915.enable_guc_loading > 1) {
+ret = -EIO;
+} else if (HAS_GUC_SCHED(dev) && !HAS_GUC_UCODE(dev)) {
+/* This GuC works even without firmware :) */
+return 0;
+} else if (i915.enable_guc_submission > 1) {
+ret = -EIO;
+} else {
+ret = 0;
+}
+
+if (ret == -EIO)
+
[Intel-gfx] [PATCH v5 3/7] drm/i915/guc: add enable_guc_loading parameter
Split the function of "enable_guc_submission" into two separate
options. The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.
In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default) whatever the platform default is
0 DISABLE don't load/use the GuC
1 BEST EFFORT try to load/use the GuC, fallback if not available
2 REQUIRE must load/use the GuC, else leave the GPU wedged
The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.
v4:
Changed some error-message levels, mostly ERROR->INFO, per
review comments by Tvrtko Ursulin.
v5:
Dropped one more error message, disabled GuC submission on
hypothetical firmware-free devices [Tvrtko Ursulin].
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c| 5 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_params.c | 14 +++-
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 108 -
5 files changed, 77 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2cc8c24..1e63744 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4868,11 +4868,8 @@ int i915_gem_init_engines(struct drm_device *dev)
/* We can't enable contexts until all firmware is loaded */
if (HAS_GUC(dev)) {
ret = intel_guc_setup(dev);
- if (ret) {
- DRM_ERROR("Failed to initialize GuC, error %d\n", ret);
- ret = -EIO;
+ if (ret)
goto out;
- }
}
/*
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 169242a..916cd67 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -969,7 +969,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
@@ -995,7 +995,7 @@ int intel_guc_resume(struct drm_device *dev)
struct intel_context *ctx;
u32 data[3];
- if (!i915.enable_guc_submission)
+ if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
return 0;
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 383c076..6a5578c 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_submission = false,
+ .enable_guc_loading = -1,
+ .enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = {
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
+MODULE_PARM_DESC(enable_guc_loading,
+ "Enable GuC firmware loading "
+ "(-1=auto [default], 0=never, 1=if available, 2=required)");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
+MODULE_PARM_DESC(enable_guc_submission,
+ "Enable GuC submission "
+ "(-1=auto, 0=never [default], 1=if available, 2=required)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 65e73dd..1323261 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,8 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+ int enable_guc_loading;
+ int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
int mmio_debug;
@@ -57,7 +59,6 @@ struct i915_params {
bool loa
Re: [Intel-gfx] [PATCH] drm: Remove unused drm_device from drm_gem_object_lookup()
Hi Chris,
On 9 May 2016 at 11:04, Chris Wilson wrote:
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -607,12 +606,8 @@ drm_gem_object_lookup(struct drm_device *dev, struct
> drm_file *filp,
>
> /* Check if we currently have a reference on the object */
> obj = idr_find(&filp->object_idr, handle);
> - if (obj == NULL) {
> - spin_unlock(&filp->table_lock);
> - return NULL;
> - }
> -
> - drm_gem_object_reference(obj);
> + if (obj)
> + drm_gem_object_reference(obj);
>
This hunk looks unrelated to the goal of the patch. Still a nice
cleanup though. Worth splitting out ?
-Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] SKL watermark algorithm updates
These patches from Mahesh address places where our SKL-style watermark programming does not match the current bspec rules, either because the bspec was updated after the original code was written, or because new display features (e.g., plane scaling) were added without corresponding updates to the watermark code. Mahesh wrote these patches a long time ago, but due to other churn in the driver they never made it in. The work here is all orthogonal to the atomic watermark stuff I've been doing lately, but landing atomic watermarks did require major changes to the flow of the code in this series, so these patches have been nearly completely rewritten at this point. You can thank Mahesh for any bugs these fix, but blame me for any new bugs they contain. At the moment I've dropped the final patches here for the arbitrated display bandwidth workaround that was previously part of this series; I'm working on a new method of obtaining the data we need for that workaround that's less fragile than the DMI method previously attempted and will post that workaround separately after this series lands. Cc: Kumar, Mahesh Kumar, Mahesh (3): drm/i915/skl+: calculate ddb minimum allocation (v4) drm/i915/skl+: calculate plane pixel rate (v4) drm/i915/skl+: Use scaling amount for plane data rate calculation (v3) Matt Roper (1): drm/i915: Don't try to calculate relative data rates during hw readout drivers/gpu/drm/i915/intel_pm.c | 166 1 file changed, 136 insertions(+), 30 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/skl+: calculate ddb minimum allocation (v4)
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
v2: optimizations as per Matt's comments.
v3 (by Matt):
- Fix boolean logic for !fb test in skl_ddb_min_alloc()
- Adjust negative tiling format comparisons in skl_ddb_min_alloc() to
improve readability.
v4 (by Matt):
- Rebase onto recent atomic watermark changes
- Slight tweaks to code flow to make the logic more closely match the
description in the bspec.
Cc: matthew.d.ro...@intel.com
Signed-off-by: Kumar, Mahesh
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 62 +
1 file changed, 57 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 95f9bb5..d7165b5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3038,6 +3038,61 @@ skl_get_total_relative_data_rate(struct intel_crtc_state
*intel_cstate)
return total_data_rate;
}
+static uint16_t
+skl_ddb_min_alloc(const struct drm_plane_state *pstate,
+ const int y)
+{
+ struct drm_framebuffer *fb = pstate->fb;
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
+ uint32_t src_w, src_h;
+ uint32_t min_scanlines = 8;
+ uint8_t plane_bpp;
+
+ if (WARN_ON(!fb))
+ return 0;
+
+ /* For packed formats, no y-plane, return 0 */
+ if (y && fb->pixel_format != DRM_FORMAT_NV12)
+ return 0;
+
+ /* For Non Y-tile return 8-blocks */
+ if (fb->modifier[0] != I915_FORMAT_MOD_Y_TILED &&
+ fb->modifier[0] != I915_FORMAT_MOD_Yf_TILED)
+ return 8;
+
+ src_w = drm_rect_width(&intel_pstate->src) >> 16;
+ src_h = drm_rect_height(&intel_pstate->src) >> 16;
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(src_w, src_h);
+
+ /* Halve UV plane width and height for NV12 */
+ if (fb->pixel_format == DRM_FORMAT_NV12 && !y) {
+ src_w /= 2;
+ src_h /= 2;
+ }
+
+ plane_bpp = y ? drm_format_plane_cpp(fb->pixel_format, 0) :
+ drm_format_plane_cpp(fb->pixel_format, 1);
+
+ if (intel_rotation_90_or_270(pstate->rotation)) {
+ switch (plane_bpp) {
+ case 1:
+ min_scanlines = 32;
+ break;
+ case 2:
+ min_scanlines = 16;
+ break;
+ default:
+ WARN(1, "Unsupported pixel depth %u for rotation",
+plane_bpp);
+ min_scanlines = 32;
+ }
+ }
+
+ return DIV_ROUND_UP((4 * src_w * plane_bpp), 512) * min_scanlines/4 + 3;
+}
+
static int
skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct skl_ddb_allocation *ddb /* out */)
@@ -3100,11 +3155,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
continue;
}
- minimum[id] = 8;
- if (pstate->fb->pixel_format == DRM_FORMAT_NV12)
- y_minimum[id] = 8;
- else
- y_minimum[id] = 0;
+ minimum[id] = skl_ddb_min_alloc(pstate, 0);
+ y_minimum[id] = skl_ddb_min_alloc(pstate, 1);
}
for (i = 0; i < PLANE_CURSOR; i++) {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/skl+: calculate plane pixel rate (v4)
From: "Kumar, Mahesh"
Don't use pipe pixel rate for plane pixel rate. Calculate plane pixel according
to formula
adjusted plane_pixel_rate = adjusted pipe_pixel_rate * downscale ammount
downscale amount = max[1, src_h/dst_h] * max[1, src_w/dst_w]
if 90/270 rotation use rotated width & height
v2: use intel_plane_state->visible instead of (fb == NULL) as per Matt's
comment.
v3 (by Matt):
- Keep downscale amount in 16.16 fixed point rather than converting to
decimal fixed point.
- Store adjusted plane pixel rate in plane state instead of the plane
parameters structure that we no longer use.
v4 (by Matt):
- Significant rebasing onto latest atomic watermark work
- Don't bother storing plane pixel rate in state; just calculate it
right before the calls that make use of it.
- Fix downscale calculations to actually use width values when
computing downscale_w rather than copy/pasted height values.
Cc: matthew.d.ro...@intel.com
Signed-off-by: Kumar, Mahesh
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 73 +++--
1 file changed, 70 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d7165b5..5bd885b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -26,6 +26,7 @@
*/
#include
+#include
#include "i915_drv.h"
#include "intel_drv.h"
#include "../../../platform/x86/intel_ips.h"
@@ -2945,6 +2946,46 @@ void skl_ddb_get_hw_state(struct drm_i915_private
*dev_priv,
}
}
+/*
+ * Determines the downscale amount of a plane for the purposes of watermark
calculations.
+ * The bspec defines downscale amount as:
+ *
+ * """
+ * Horizontal down scale amount = maximum[1, Horizontal source size /
+ * Horizontal destination size]
+ * Vertical down scale amount = maximum[1, Vertical source size /
+ * Vertical destination size]
+ * Total down scale amount = Horizontal down scale amount *
+ * Vertical down scale amount
+ * """
+ *
+ * Return value is provided in 16.16 fixed point form to retain fractional
part.
+ * Caller should take care of dividing & rounding off the value.
+ */
+static uint32_t
+skl_plane_downscale_amount(const struct intel_plane_state *pstate)
+{
+ uint32_t downscale_h, downscale_w;
+ uint32_t src_w, src_h, dst_w, dst_h;
+
+ if (WARN_ON(!pstate->visible))
+ return DRM_PLANE_HELPER_NO_SCALING;
+
+ /* n.b., src is 16.16 fixed point, dst is whole integer */
+ src_w = drm_rect_width(&pstate->src);
+ src_h = drm_rect_height(&pstate->src);
+ dst_w = drm_rect_width(&pstate->dst);
+ dst_h = drm_rect_height(&pstate->dst);
+ if (intel_rotation_90_or_270(pstate->base.rotation))
+ swap(dst_w, dst_h);
+
+ downscale_h = max(src_h / dst_h, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
+ downscale_w = max(src_w / dst_w, (uint32_t)DRM_PLANE_HELPER_NO_SCALING);
+
+ /* Provide result in 16.16 fixed point */
+ return (uint64_t)downscale_w * downscale_h >> 16;
+}
+
static unsigned int
skl_plane_relative_data_rate(const struct intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
@@ -3273,6 +3314,30 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
return ret;
}
+static uint32_t skl_adjusted_plane_pixel_rate(const struct intel_crtc_state
*cstate,
+ struct intel_plane_state *pstate)
+{
+ uint64_t adjusted_pixel_rate;
+ uint64_t downscale_amount;
+ uint64_t pixel_rate;
+
+ /* Shouldn't reach here on disabled planes... */
+ if (WARN_ON(!pstate->visible))
+ return 0;
+
+ /*
+* Adjusted plane pixel rate is just the pipe's adjusted pixel rate
+* with additional adjustments for plane-specific scaling.
+*/
+ adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+ downscale_amount = skl_plane_downscale_amount(pstate);
+
+ pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
+ WARN_ON(pixel_rate != clamp_t(uint32_t, pixel_rate, 0, ~0));
+
+ return pixel_rate;
+}
+
static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
struct intel_crtc_state *cstate,
struct intel_plane_state *intel_pstate,
@@ -3291,6 +3356,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t selected_result;
uint8_t cpp;
uint32_t width = 0, height = 0;
+ uint32_t plane_pixel_rate;
if (latency == 0 || !cstate->base.active || !intel_pstate->visible) {
*enabled = false;
@@ -3304,9 +3370,10 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
[Intel-gfx] [PATCH 1/4] drm/i915: Don't try to calculate relative data rates during hw readout
We don't actually read out full plane state during driver startup (only
whether the primary plane is enabled/disabled), so all of the src/dest
rectangles are invalid at this point. However this calculation was
needless anyway since we re-calculate them from scratch on the very
first atomic transaction after boot anyway.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index adb6463..95f9bb5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4042,7 +4042,6 @@ void skl_wm_get_hw_state(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb;
struct drm_crtc *crtc;
- struct intel_crtc *intel_crtc;
skl_ddb_get_hw_state(dev_priv, ddb);
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
@@ -4055,23 +4054,6 @@ void skl_wm_get_hw_state(struct drm_device *dev)
/* Easy/common case; just sanitize DDB now if everything off */
memset(ddb, 0, sizeof(*ddb));
}
-
- /* Calculate plane data rates */
- for_each_intel_crtc(dev, intel_crtc) {
- struct intel_crtc_state *cstate = intel_crtc->config;
- struct intel_plane *intel_plane;
-
- for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
- const struct drm_plane_state *pstate =
- intel_plane->base.state;
- int id = skl_wm_plane_id(intel_plane);
-
- cstate->wm.skl.plane_data_rate[id] =
- skl_plane_relative_data_rate(cstate, pstate, 0);
- cstate->wm.skl.plane_y_data_rate[id] =
- skl_plane_relative_data_rate(cstate, pstate, 1);
- }
- }
}
static void ilk_pipe_wm_get_hw_state(struct drm_crtc *crtc)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/skl+: Use scaling amount for plane data rate calculation (v3)
From: "Kumar, Mahesh"
if downscaling is enabled plane data rate increases according to scaling
amount. take scaling amount under consideration while calculating plane
data rate
v2: Address Matt's comments, where data rate was overridden because of
missing else.
v3 (by Matt):
- Add braces to 'else' branch to match kernel coding style
- Adjust final calculation now that skl_plane_downscale_amount()
returns 16.16 fixed point value instead of a decimal fixed point
Cc: matthew.d.ro...@intel.com
Signed-off-by: Kumar, Mahesh
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5bd885b..4d0088c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2993,6 +2993,7 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
{
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ uint32_t down_scale_amount, data_rate;
uint32_t width = 0, height = 0;
unsigned format = fb ? fb->pixel_format : DRM_FORMAT_XRGB;
@@ -3012,15 +3013,19 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
/* for planar format */
if (format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return width * height *
+ data_rate = width * height *
drm_format_plane_cpp(format, 0);
else/* uv-plane data rate */
- return (width / 2) * (height / 2) *
+ data_rate = (width / 2) * (height / 2) *
drm_format_plane_cpp(format, 1);
+ } else {
+ /* for packed formats */
+ data_rate = width * height * drm_format_plane_cpp(format, 0);
}
- /* for packed formats */
- return width * height * drm_format_plane_cpp(format, 0);
+ down_scale_amount = skl_plane_downscale_amount(intel_pstate);
+
+ return data_rate * down_scale_amount >> 16;
}
/*
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation
This is the userspace component of the Displayport Compliance testing software required for compliance testing of the I915 Display Port driver. This must be running in order to successfully complete Display Port compliance testing. This app and the kernel code that accompanies it has been written to satify the requirements of the Displayport Link CTS 1.2 rev1.1 specification from VESA. Note that this application does not support eDP compliance testing. This utility ahs an automation support for the EDID tests (4.2.2.3 - 4.2.2.6) and Video Pattern generation tests (400.3.3.1) from CTS specification 1.2 Rev 1.1. Currently the video pattern automation has been explicitly disabled until the link training automation is fully supported in the kernel. The Linux DUT running this utility must be in text (console) mode and cannot have any other display manager running. Since this uses sysfs nodes for kernel interaction, this utility should be run as Root. Once this user application is up and running, waiting for test requests, the test appliance software on the windows host can now be used to execute the compliance tests. This app is based on some prior work done in April 2015 (by Todd Previte ) v1: * Reworked gem_mmap/unmap logic so these calls go together (by Marius Vlad) * Cleaned up the setup_drm/restore/close calls so that it happens before the tests, after every test and at exit (by Marius Vlad) Signed-off-by: Marius Vlad Signed-off-by: Todd Previte Signed-off-by: Manasi Navare --- tools/Makefile.sources |1 + tools/intel_dp_compliance.c | 1089 +++ 2 files changed, 1090 insertions(+) create mode 100644 tools/intel_dp_compliance.c diff --git a/tools/Makefile.sources b/tools/Makefile.sources index 5d5958d..3054856 100644 --- a/tools/Makefile.sources +++ b/tools/Makefile.sources @@ -13,6 +13,7 @@ bin_PROGRAMS =\ intel_bios_reader \ intel_display_crc \ intel_display_poller\ + intel_dp_compliance \ intel_dump_decode \ intel_error_decode \ intel_forcewaked\ diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c new file mode 100644 index 000..31996ba --- /dev/null +++ b/tools/intel_dp_compliance.c @@ -0,0 +1,1089 @@ +/* + * Copyright ? 2014-2015 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. + * + * Displayport Compliance Testing Application + * + * This is the userspace component of the Displayport Compliance testing + * software required for compliance testing of the I915 Display Port driver. + * This must be running in order to successfully complete Display Port + * compliance testing. This app and the kernel code that accompanies it has been + * written to satify the requirements of the Displayport Link CTS 1.2 rev1.1 + * specification from VESA. Note that this application does not support eDP + * compliance testing. + * + * Compliance Testing requires several components: + * - A kernel build that contains the patch set for DP compliance support + * Make sure it has the EDID compliance automation patch + * - A Displayport Compliance Testing appliance such as Unigraf-DPR120 + * - This user application + * - A windows host machine to run the DPR test software + * - Root access on the DUT due to the use of sysfs utility + * + * Test Setup: + * It is strongly recommended that the windows host, test appliance and DUT + * be freshly restarted before any testing begins to ensure that any previous + * configurations and settings will not interfere with test process. Refer to + * the test appliance documentation for setup, software installation and + * operation specific to that device. + * + * The Linux DUT must be in text (console) mode and cannot have any other + * dis
Re: [Intel-gfx] [PATCH 03/15] drm/i915: gvt: Introduce the basic architecture of GVT-g
-Original Message- From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] Sent: Monday, May 16, 2016 5:03 AM To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; Gordon, David S ; joonas.lahti...@linux.intel.com; Tian, Kevin ; Lv, Zhiyuan Subject: Re: [Intel-gfx] [PATCH 03/15] drm/i915: gvt: Introduce the basic architecture of GVT-g Hi, Just a few comments from a non-assigned reviewer. On 15/05/16 18:32, Zhi Wang wrote: > This patch introduces the very basic framework of GVT-g device model, > includes basic prototypes, definitions, initialization. > > v3: > Take Joonas' comments: > - Change file name i915_gvt.* to intel_gvt.* > - Move GVT kernel parameter into intel_gvt.c > - Remove redundant debug macros > - Change error handling style > - Add introductions for some stub functions > - Introduce drm/i915_gvt.h. > > Take Kevin's comments: > - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c > > v2: > - Introduce i915_gvt.c. > It's necessary to introduce the stubs between i915 driver and GVT-g > host, as GVT-g components is configurable in kernel config. When > disabled, the stubs here do nothing. > > Take Joonas' comments: > - Replace boolean return value with int. > - Replace customized info/warn/debug macros with DRM macros. > - Document all non-static functions like i915. > - Remove empty and unused functions. > - Replace magic number with marcos. > - Set GVT-g in kernel config to "n" by default. > > Signed-off-by: Zhi Wang > --- > drivers/gpu/drm/i915/Kconfig | 15 +++ > drivers/gpu/drm/i915/Makefile| 5 + > drivers/gpu/drm/i915/gvt/Makefile| 5 + > drivers/gpu/drm/i915/gvt/debug.h | 36 ++ > drivers/gpu/drm/i915/gvt/gvt.c | 209 > +++ > drivers/gpu/drm/i915/gvt/gvt.h | 85 ++ > drivers/gpu/drm/i915/gvt/hypercall.h | 38 +++ > drivers/gpu/drm/i915/gvt/mpt.h | 51 + > drivers/gpu/drm/i915/i915_dma.c | 17 ++- > drivers/gpu/drm/i915/i915_drv.h | 12 ++ > drivers/gpu/drm/i915/intel_gvt.c | 106 ++ > drivers/gpu/drm/i915/intel_gvt.h | 49 > include/drm/i915_gvt.h | 31 ++ > 13 files changed, 655 insertions(+), 4 deletions(-) > create mode 100644 drivers/gpu/drm/i915/gvt/Makefile > create mode 100644 drivers/gpu/drm/i915/gvt/debug.h > create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c > create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h > create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h > create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h > create mode 100644 drivers/gpu/drm/i915/intel_gvt.c > create mode 100644 drivers/gpu/drm/i915/intel_gvt.h > create mode 100644 include/drm/i915_gvt.h > > diff --git a/drivers/gpu/drm/i915/Kconfig > b/drivers/gpu/drm/i915/Kconfig index 29a32b1..782c97c 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -57,6 +57,21 @@ config DRM_I915_USERPTR > > If in doubt, say "Y". > > +config DRM_I915_GVT > +bool "Intel GVT-g host driver" > +depends on DRM_I915 > +default n > +help > + Enabling GVT-g mediated graphics passthrough technique for > +Intel i915 pass-through > + based integrated graphics card. With GVT-g, it's possible to have > one > + integrated i915 device shared by multiple VMs. Performance critical > + opterations such as apperture accesses and ring buffer > + operations operations, aperture > + are pass-throughed to VM, with a minimal set of conflicting > + resources passed-through to the host or hypervisor ? > + (e.g. display settings) mediated by vGT driver. The benefit of vGT > + is on both the performance, given that each VM could directly > operate > + its aperture space and submit commands like running on native, and > + the feature completeness, given that a true GEN hardware is > exposed. > + > menu "drm/i915 Debugging" > depends on DRM_I915 > depends on EXPERT > diff --git a/drivers/gpu/drm/i915/Makefile > b/drivers/gpu/drm/i915/Makefile index 63c4d2b..e48145b 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -103,6 +103,11 @@ i915-y += i915_vgpu.o > # legacy horrors > i915-y += i915_dma.o > > +ifeq ($(CONFIG_DRM_I915_GVT),y) > +i915-y += intel_gvt.o > +include $(src)/gvt/Makefile > +endif > + > obj-$(CONFIG_DRM_I915) += i915.o > > CFLAGS_i915_trace_points.o := -I$(src) diff --git > a/drivers/gpu/drm/i915/gvt/Makefile > b/drivers/gpu/drm/i915/gvt/Makefile > new file mode 100644 > index 000..d0f21a6 > --- /dev/null > +++ b/drivers/gpu/drm/i915/gvt/Makefile > @@ -0,0 +1,5 @@ > +GVT_DIR := gvt > +GVT_SOURCE := gvt.o > + > +ccflags-y += -I$(src) -I$(src)/$(GVT_DIR) -Wall > +i915-y += $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > diff -
[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable GuC submission (rev2)
== Series Details ==
Series: Enable GuC submission (rev2)
URL : https://patchwork.freedesktop.org/series/7153/
State : failure
== Summary ==
Series 7153v2 Enable GuC submission
http://patchwork.freedesktop.org/api/1.0/series/7153/revisions/2/mbox
Test drv_module_reload_basic:
pass -> SKIP (ro-ivb-i7-3770)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass -> FAIL (ro-byt-n2820)
fail -> PASS (ro-hsw-i3-4010u)
ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38
ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13
ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32
ro-bsw-n3050 total:219 pass:174 dwarn:0 dfail:0 fail:3 skip:42
ro-byt-n2820 total:218 pass:173 dwarn:0 dfail:0 fail:4 skip:41
ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25
ro-hsw-i7-4770r total:219 pass:194 dwarn:0 dfail:0 fail:0 skip:25
ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67
ro-ilk1-i5-650 total:214 pass:151 dwarn:0 dfail:0 fail:2 skip:61
ro-ivb-i7-3770 total:219 pass:182 dwarn:0 dfail:0 fail:0 skip:37
ro-ivb2-i7-3770 total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32
ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25
ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41
fi-byt-n2820 failed to connect after reboot
Results at /archive/results/CI_IGT_test/RO_Patchwork_912/
d381724 drm-intel-nightly: 2016y-05m-16d-12h-14m-04s UTC integration manifest
9870d88 drm/i915/guc: change default to using GuC submission if possible
e2ed92b drm/i915/guc: rework guc_add_workqueue_item()
0b04a38 drm/i915/guc: don't spinwait if the GuC's workqueue is full
6cbef76 drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space,
submit}()
1a50673 drm/i915/guc: add enable_guc_loading parameter
4461c44 drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED
1996f53 drm/i915/guc: rename loader entry points
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: warning for SKL watermark algorithm updates
== Series Details == Series: SKL watermark algorithm updates URL : https://patchwork.freedesktop.org/series/7262/ State : warning == Summary == Series 7262v1 SKL watermark algorithm updates http://patchwork.freedesktop.org/api/1.0/series/7262/revisions/1/mbox Test drv_hangman: Subgroup error-state-basic: fail -> PASS (ro-ilk1-i5-650) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-hsw-i3-4010u) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (ro-ivb2-i7-3770) ro-bdw-i5-5250u total:219 pass:181 dwarn:0 dfail:0 fail:0 skip:38 ro-bdw-i7-5557U total:219 pass:206 dwarn:0 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:219 pass:187 dwarn:0 dfail:0 fail:0 skip:32 ro-bsw-n3050 total:219 pass:175 dwarn:0 dfail:0 fail:2 skip:42 ro-byt-n2820 total:218 pass:174 dwarn:0 dfail:0 fail:3 skip:41 ro-hsw-i3-4010u total:218 pass:193 dwarn:0 dfail:0 fail:0 skip:25 ro-ilk-i7-620lm total:219 pass:151 dwarn:0 dfail:0 fail:1 skip:67 ro-ilk1-i5-650 total:214 pass:152 dwarn:0 dfail:0 fail:1 skip:61 ro-ivb-i7-3770 total:219 pass:183 dwarn:0 dfail:0 fail:0 skip:36 ro-ivb2-i7-3770 total:219 pass:186 dwarn:1 dfail:0 fail:0 skip:32 ro-skl-i7-6700hq total:214 pass:189 dwarn:0 dfail:0 fail:0 skip:25 ro-snb-i7-2620M total:219 pass:177 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/RO_Patchwork_913/ d381724 drm-intel-nightly: 2016y-05m-16d-12h-14m-04s UTC integration manifest c0706cc drm/i915/skl+: Use scaling amount for plane data rate calculation (v3) 87857a1 drm/i915/skl+: calculate plane pixel rate (v4) a17643c drm/i915/skl+: calculate ddb minimum allocation (v4) 51cc79c drm/i915: Don't try to calculate relative data rates during hw readout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/7] drm/i915: Check pixel rate for DP to VGA dongle
On Mon, May 16, 2016 at 04:19:33PM +0300, Mika Kahola wrote:
> Prep work to improve DP branch device handling.
>
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The register defines the pixel rate divided by 8 in MP/s.
>
> v2: DPCD read outs and computation moved to drm (Ville, Daniel)
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 3633002..5ec6287 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -201,6 +201,12 @@ intel_dp_mode_valid(struct drm_connector *connector,
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>
> + /* DP to VGA dongle may define max pixel rate in DPCD */
> + if (intel_dp->bd.present &&
> + (intel_dp->bd.type & DP_DS_PORT_TYPE_VGA) &&
> + (intel_dp->bd.dfp.vga.dot_clk > 0))
> + max_dotclk = min(max_dotclk, intel_dp->bd.dfp.vga.dot_clk);
I think this is rendering the helpers a bit pointless if you have to dig
around so much in internals. drm_dp_helper_max_sink_dotclock(), and then
we have a place to put more of that stuff?
-Daniel
> +
> if (is_edp(intel_dp) && fixed_mode) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> return MODE_PANEL;
> @@ -4575,6 +4581,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum intel_display_power_domain power_domain;
> enum irqreturn ret = IRQ_NONE;
> + int err;
>
> if (intel_dig_port->base.type != INTEL_OUTPUT_EDP &&
> intel_dig_port->base.type != INTEL_OUTPUT_HDMI)
> @@ -4599,6 +4606,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> power_domain = intel_display_port_aux_power_domain(intel_encoder);
> intel_display_power_get(dev_priv, power_domain);
>
> + err = drm_dp_bd(&intel_dp->aux, &intel_dp->bd);
> + if (err < 0)
> + DRM_DEBUG_KMS("error reading DPCD[0x80] for DP branch
> device\n");
> +
> if (long_hpd) {
> /* indicate that we need to restart link training */
> intel_dp->train_set_valid = false;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Remove unused drm_device from drm_gem_object_lookup()
On Mon, May 16, 2016 at 11:15:09PM +0100, Emil Velikov wrote:
> Hi Chris,
>
> On 9 May 2016 at 11:04, Chris Wilson wrote:
>
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
>
> > @@ -607,12 +606,8 @@ drm_gem_object_lookup(struct drm_device *dev, struct
> > drm_file *filp,
> >
> > /* Check if we currently have a reference on the object */
> > obj = idr_find(&filp->object_idr, handle);
> > - if (obj == NULL) {
> > - spin_unlock(&filp->table_lock);
> > - return NULL;
> > - }
> > -
> > - drm_gem_object_reference(obj);
> > + if (obj)
> > + drm_gem_object_reference(obj);
> >
> This hunk looks unrelated to the goal of the patch. Still a nice
> cleanup though. Worth splitting out ?
Imo too trivial too require it's own patch, so applied to drm-misc. But
with the kerneldoc updated - 0day should have caught this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
