drm/i915: avoid "may be used uninitialized" warnings

drm/i915: avoid "may be used uninitialized" warnings

[Sreedhar Donelli]

[-- Attachment #1.1: Type: text/plain, Size: 1143 bytes --]

 HI All,
 
compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
please find the attachment for patch file.

I have taken this issue from below link

https://lkml.org/lkml/2017/1/16/89



Thanks & Regards
 Sreedhar Donelli
 Tata Consultancy Services
 Ph:-   +91 8019039399
 Cell:- +91 8019039399
 Mailto: sreedhar.donelli@tcs.com
 Website: http://www.tcs.com
 ____________________________________________
 Experience certainty.	IT Services
 			Business Solutions
 			Consulting
 ____________________________________________
 
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you



[-- Attachment #1.2: Type: text/html, Size: 1699 bytes --]

[-- Attachment #2: drm-i915-avoid-may-be-used-uninitialised-errors.patch --]
[-- Type: application/octet-stream, Size: 2544 bytes --]

diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c
--- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 18:18:56.564887392 +0530
+++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 19:18:50.524978315 +0530
@@ -2364,7 +2364,7 @@
 	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
 	struct sgt_iter sgt_iter;
 	gen8_pte_t __iomem *gtt_entries;
-	gen8_pte_t gtt_entry;
+	gen8_pte_t gtt_entry = I915_NULL_PTE;
 	dma_addr_t addr;
 	int rpm_atomic_seq;
 	int i = 0;
@@ -2385,8 +2385,10 @@
 	 * of NUMA access patterns. Therefore, even with the way we assume
 	 * hardware should work, we must keep this posting read for paranoia.
 	 */
-	if (i != 0)
+	if (i != 0){
+		gen8_pte_t last_gtt_entry = readq(&gtt_entries[i-1]);
 		WARN_ON(readq(&gtt_entries[i-1]) != gtt_entry);
+	}
 
 	/* This next bit makes the above posting read even more important. We
 	 * want to flush the TLBs only after we're certain all the PTE updates
@@ -2439,7 +2441,7 @@
 	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
 	struct sgt_iter sgt_iter;
 	gen6_pte_t __iomem *gtt_entries;
-	gen6_pte_t gtt_entry;
+	gen6_pte_t gtt_entry = I915_NULL_PTE;
 	dma_addr_t addr;
 	int rpm_atomic_seq;
 	int i = 0;
@@ -2453,14 +2455,17 @@
 		iowrite32(gtt_entry, &gtt_entries[i++]);
 	}
 
-	/* XXX: This serves as a posting read to make sure that the PTE has
+	/* 
+	 * XXX: This serves as a posting read to make sure that the PTE has
 	 * actually been updated. There is some concern that even though
 	 * registers and PTEs are within the same BAR that they are potentially
 	 * of NUMA access patterns. Therefore, even with the way we assume
 	 * hardware should work, we must keep this posting read for paranoia.
 	 */
-	if (i != 0)
+	if (i != 0) {
+		gen8_pte_t last_gtt_entry = readl(&gtt_entries[i-1]);
 		WARN_ON(readl(&gtt_entries[i-1]) != gtt_entry);
+	}
 
 	/* This next bit makes the above posting read even more important. We
 	 * want to flush the TLBs only after we're certain all the PTE updates
diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h
--- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 18:18:56.564887392 +0530
+++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 19:19:57.196980002 +0530
@@ -54,6 +54,7 @@
 #define GEN6_PTE_UNCACHED		(1 << 1)
 #define GEN6_PTE_VALID			(1 << 0)
 
+#define	I915_NULL_PTE			0
 #define I915_PTES(pte_len)		(PAGE_SIZE / (pte_len))
 #define I915_PTE_MASK(pte_len)		(I915_PTES(pte_len) - 1)
 #define I915_PDES			512

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: drm/i915: avoid "may be used uninitialized" warnings

[Jani Nikula]

On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.donelli@tcs.com> wrote:
> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
> please find the attachment for patch file.

There are several issues with this contribution. Please learn to use git
send-email to send your patches. Don't attach them. You need to write a
proper commit message. That commit message needs to include a
Signed-off-by tag. You absolutely can't have a disclaimer about
confidential/privileged with the patch. See
Documentation/process/submitting-patches.rst.

On the content, there are no issues in the code, the compiler just seems
unable to figure it out. If we were to "fix" this, for sure we don't
need the superfluous changes included in this patch.

BR,
Jani.

>
> I have taken this issue from below link
>
> https://lkml.org/lkml/2017/1/16/89
>
>
>
> Thanks & Regards
>  Sreedhar Donelli
>  Tata Consultancy Services
>  Ph:-   +91 8019039399
>  Cell:- +91 8019039399
>  Mailto: sreedhar.donelli@tcs.com
>  Website: http://www.tcs.com
>  ____________________________________________
>  Experience certainty.	IT Services
>  			Business Solutions
>  			Consulting
>  ____________________________________________
>  
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you
>
>
> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c
> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 18:18:56.564887392 +0530
> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 19:18:50.524978315 +0530
> @@ -2364,7 +2364,7 @@
>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>  	struct sgt_iter sgt_iter;
>  	gen8_pte_t __iomem *gtt_entries;
> -	gen8_pte_t gtt_entry;
> +	gen8_pte_t gtt_entry = I915_NULL_PTE;
>  	dma_addr_t addr;
>  	int rpm_atomic_seq;
>  	int i = 0;
> @@ -2385,8 +2385,10 @@
>  	 * of NUMA access patterns. Therefore, even with the way we assume
>  	 * hardware should work, we must keep this posting read for paranoia.
>  	 */
> -	if (i != 0)
> +	if (i != 0){
> +		gen8_pte_t last_gtt_entry = readq(&gtt_entries[i-1]);
>  		WARN_ON(readq(&gtt_entries[i-1]) != gtt_entry);
> +	}
>  
>  	/* This next bit makes the above posting read even more important. We
>  	 * want to flush the TLBs only after we're certain all the PTE updates
> @@ -2439,7 +2441,7 @@
>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>  	struct sgt_iter sgt_iter;
>  	gen6_pte_t __iomem *gtt_entries;
> -	gen6_pte_t gtt_entry;
> +	gen6_pte_t gtt_entry = I915_NULL_PTE;
>  	dma_addr_t addr;
>  	int rpm_atomic_seq;
>  	int i = 0;
> @@ -2453,14 +2455,17 @@
>  		iowrite32(gtt_entry, &gtt_entries[i++]);
>  	}
>  
> -	/* XXX: This serves as a posting read to make sure that the PTE has
> +	/* 
> +	 * XXX: This serves as a posting read to make sure that the PTE has
>  	 * actually been updated. There is some concern that even though
>  	 * registers and PTEs are within the same BAR that they are potentially
>  	 * of NUMA access patterns. Therefore, even with the way we assume
>  	 * hardware should work, we must keep this posting read for paranoia.
>  	 */
> -	if (i != 0)
> +	if (i != 0) {
> +		gen8_pte_t last_gtt_entry = readl(&gtt_entries[i-1]);
>  		WARN_ON(readl(&gtt_entries[i-1]) != gtt_entry);
> +	}
>  
>  	/* This next bit makes the above posting read even more important. We
>  	 * want to flush the TLBs only after we're certain all the PTE updates
> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h
> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 18:18:56.564887392 +0530
> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 19:19:57.196980002 +0530
> @@ -54,6 +54,7 @@
>  #define GEN6_PTE_UNCACHED		(1 << 1)
>  #define GEN6_PTE_VALID			(1 << 0)
>  
> +#define	I915_NULL_PTE			0
>  #define I915_PTES(pte_len)		(PAGE_SIZE / (pte_len))
>  #define I915_PTE_MASK(pte_len)		(I915_PTES(pte_len) - 1)
>  #define I915_PDES			512

-- 
Jani Nikula, Intel Open Source Technology Center

Re: drm/i915: avoid "may be used uninitialized" warnings

[Jani Nikula]

On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.donelli@tcs.com> wrote:
> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
> please find the attachment for patch file.

There are several issues with this contribution. Please learn to use git
send-email to send your patches. Don't attach them. You need to write a
proper commit message. That commit message needs to include a
Signed-off-by tag. You absolutely can't have a disclaimer about
confidential/privileged with the patch. See
Documentation/process/submitting-patches.rst.

On the content, there are no issues in the code, the compiler just seems
unable to figure it out. If we were to "fix" this, for sure we don't
need the superfluous changes included in this patch.

BR,
Jani.

>
> I have taken this issue from below link
>
> https://lkml.org/lkml/2017/1/16/89
>
>
>
> Thanks & Regards
>  Sreedhar Donelli
>  Tata Consultancy Services
>  Ph:-   +91 8019039399
>  Cell:- +91 8019039399
>  Mailto: sreedhar.donelli@tcs.com
>  Website: http://www.tcs.com
>  ____________________________________________
>  Experience certainty.	IT Services
>  			Business Solutions
>  			Consulting
>  ____________________________________________
>  
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you
>
>
> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c
> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 18:18:56.564887392 +0530
> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 19:18:50.524978315 +0530
> @@ -2364,7 +2364,7 @@
>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>  	struct sgt_iter sgt_iter;
>  	gen8_pte_t __iomem *gtt_entries;
> -	gen8_pte_t gtt_entry;
> +	gen8_pte_t gtt_entry = I915_NULL_PTE;
>  	dma_addr_t addr;
>  	int rpm_atomic_seq;
>  	int i = 0;
> @@ -2385,8 +2385,10 @@
>  	 * of NUMA access patterns. Therefore, even with the way we assume
>  	 * hardware should work, we must keep this posting read for paranoia.
>  	 */
> -	if (i != 0)
> +	if (i != 0){
> +		gen8_pte_t last_gtt_entry = readq(&gtt_entries[i-1]);
>  		WARN_ON(readq(&gtt_entries[i-1]) != gtt_entry);
> +	}
>  
>  	/* This next bit makes the above posting read even more important. We
>  	 * want to flush the TLBs only after we're certain all the PTE updates
> @@ -2439,7 +2441,7 @@
>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>  	struct sgt_iter sgt_iter;
>  	gen6_pte_t __iomem *gtt_entries;
> -	gen6_pte_t gtt_entry;
> +	gen6_pte_t gtt_entry = I915_NULL_PTE;
>  	dma_addr_t addr;
>  	int rpm_atomic_seq;
>  	int i = 0;
> @@ -2453,14 +2455,17 @@
>  		iowrite32(gtt_entry, &gtt_entries[i++]);
>  	}
>  
> -	/* XXX: This serves as a posting read to make sure that the PTE has
> +	/* 
> +	 * XXX: This serves as a posting read to make sure that the PTE has
>  	 * actually been updated. There is some concern that even though
>  	 * registers and PTEs are within the same BAR that they are potentially
>  	 * of NUMA access patterns. Therefore, even with the way we assume
>  	 * hardware should work, we must keep this posting read for paranoia.
>  	 */
> -	if (i != 0)
> +	if (i != 0) {
> +		gen8_pte_t last_gtt_entry = readl(&gtt_entries[i-1]);
>  		WARN_ON(readl(&gtt_entries[i-1]) != gtt_entry);
> +	}
>  
>  	/* This next bit makes the above posting read even more important. We
>  	 * want to flush the TLBs only after we're certain all the PTE updates
> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h
> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 18:18:56.564887392 +0530
> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 19:19:57.196980002 +0530
> @@ -54,6 +54,7 @@
>  #define GEN6_PTE_UNCACHED		(1 << 1)
>  #define GEN6_PTE_VALID			(1 << 0)
>  
> +#define	I915_NULL_PTE			0
>  #define I915_PTES(pte_len)		(PAGE_SIZE / (pte_len))
>  #define I915_PTE_MASK(pte_len)		(I915_PTES(pte_len) - 1)
>  #define I915_PDES			512

-- 
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: drm/i915: avoid "may be used uninitialized" warnings

[Jani Nikula]

On Wed, 18 Jan 2017, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.donelli@tcs.com> wrote:
>> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
>> please find the attachment for patch file.
>
> There are several issues with this contribution. Please learn to use git
> send-email to send your patches. Don't attach them. You need to write a
> proper commit message. That commit message needs to include a
> Signed-off-by tag. You absolutely can't have a disclaimer about
> confidential/privileged with the patch. See
> Documentation/process/submitting-patches.rst.
>
> On the content, there are no issues in the code, the compiler just seems
> unable to figure it out. If we were to "fix" this, for sure we don't
> need the superfluous changes included in this patch.

This came out less polite than I intended. Apologies.

Please do pay attention to the submitting-patches.rst document when
contributing.

BR,
Jani.

>>
>> I have taken this issue from below link
>>
>> https://lkml.org/lkml/2017/1/16/89
>>
>>
>>
>> Thanks & Regards
>>  Sreedhar Donelli
>>  Tata Consultancy Services
>>  Ph:-   +91 8019039399
>>  Cell:- +91 8019039399
>>  Mailto: sreedhar.donelli@tcs.com
>>  Website: http://www.tcs.com
>>  ____________________________________________
>>  Experience certainty.	IT Services
>>  			Business Solutions
>>  			Consulting
>>  ____________________________________________
>>  
>> =====-----=====-----=====
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain 
>> confidential or privileged information. If you are 
>> not the intended recipient, any dissemination, use, 
>> review, distribution, printing or copying of the 
>> information contained in this e-mail message 
>> and/or attachments to it are strictly prohibited. If 
>> you have received this communication in error, 
>> please notify us by reply e-mail or telephone and 
>> immediately and permanently delete the message 
>> and any attachments. Thank you
>>
>>
>> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c
>> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 18:18:56.564887392 +0530
>> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 19:18:50.524978315 +0530
>> @@ -2364,7 +2364,7 @@
>>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>>  	struct sgt_iter sgt_iter;
>>  	gen8_pte_t __iomem *gtt_entries;
>> -	gen8_pte_t gtt_entry;
>> +	gen8_pte_t gtt_entry = I915_NULL_PTE;
>>  	dma_addr_t addr;
>>  	int rpm_atomic_seq;
>>  	int i = 0;
>> @@ -2385,8 +2385,10 @@
>>  	 * of NUMA access patterns. Therefore, even with the way we assume
>>  	 * hardware should work, we must keep this posting read for paranoia.
>>  	 */
>> -	if (i != 0)
>> +	if (i != 0){
>> +		gen8_pte_t last_gtt_entry = readq(&gtt_entries[i-1]);
>>  		WARN_ON(readq(&gtt_entries[i-1]) != gtt_entry);
>> +	}
>>  
>>  	/* This next bit makes the above posting read even more important. We
>>  	 * want to flush the TLBs only after we're certain all the PTE updates
>> @@ -2439,7 +2441,7 @@
>>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>>  	struct sgt_iter sgt_iter;
>>  	gen6_pte_t __iomem *gtt_entries;
>> -	gen6_pte_t gtt_entry;
>> +	gen6_pte_t gtt_entry = I915_NULL_PTE;
>>  	dma_addr_t addr;
>>  	int rpm_atomic_seq;
>>  	int i = 0;
>> @@ -2453,14 +2455,17 @@
>>  		iowrite32(gtt_entry, &gtt_entries[i++]);
>>  	}
>>  
>> -	/* XXX: This serves as a posting read to make sure that the PTE has
>> +	/* 
>> +	 * XXX: This serves as a posting read to make sure that the PTE has
>>  	 * actually been updated. There is some concern that even though
>>  	 * registers and PTEs are within the same BAR that they are potentially
>>  	 * of NUMA access patterns. Therefore, even with the way we assume
>>  	 * hardware should work, we must keep this posting read for paranoia.
>>  	 */
>> -	if (i != 0)
>> +	if (i != 0) {
>> +		gen8_pte_t last_gtt_entry = readl(&gtt_entries[i-1]);
>>  		WARN_ON(readl(&gtt_entries[i-1]) != gtt_entry);
>> +	}
>>  
>>  	/* This next bit makes the above posting read even more important. We
>>  	 * want to flush the TLBs only after we're certain all the PTE updates
>> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h
>> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 18:18:56.564887392 +0530
>> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 19:19:57.196980002 +0530
>> @@ -54,6 +54,7 @@
>>  #define GEN6_PTE_UNCACHED		(1 << 1)
>>  #define GEN6_PTE_VALID			(1 << 0)
>>  
>> +#define	I915_NULL_PTE			0
>>  #define I915_PTES(pte_len)		(PAGE_SIZE / (pte_len))
>>  #define I915_PTE_MASK(pte_len)		(I915_PTES(pte_len) - 1)
>>  #define I915_PDES			512

-- 
Jani Nikula, Intel Open Source Technology Center

Re: drm/i915: avoid "may be used uninitialized" warnings

[Jani Nikula]

On Wed, 18 Jan 2017, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.donelli@tcs.com> wrote:
>> compilation issue on kernel-4.10-rc4 is resolved and i created a patch file.
>> please find the attachment for patch file.
>
> There are several issues with this contribution. Please learn to use git
> send-email to send your patches. Don't attach them. You need to write a
> proper commit message. That commit message needs to include a
> Signed-off-by tag. You absolutely can't have a disclaimer about
> confidential/privileged with the patch. See
> Documentation/process/submitting-patches.rst.
>
> On the content, there are no issues in the code, the compiler just seems
> unable to figure it out. If we were to "fix" this, for sure we don't
> need the superfluous changes included in this patch.

This came out less polite than I intended. Apologies.

Please do pay attention to the submitting-patches.rst document when
contributing.

BR,
Jani.

>>
>> I have taken this issue from below link
>>
>> https://lkml.org/lkml/2017/1/16/89
>>
>>
>>
>> Thanks & Regards
>>  Sreedhar Donelli
>>  Tata Consultancy Services
>>  Ph:-   +91 8019039399
>>  Cell:- +91 8019039399
>>  Mailto: sreedhar.donelli@tcs.com
>>  Website: http://www.tcs.com
>>  ____________________________________________
>>  Experience certainty.	IT Services
>>  			Business Solutions
>>  			Consulting
>>  ____________________________________________
>>  
>> =====-----=====-----=====
>> Notice: The information contained in this e-mail
>> message and/or attachments to it may contain 
>> confidential or privileged information. If you are 
>> not the intended recipient, any dissemination, use, 
>> review, distribution, printing or copying of the 
>> information contained in this e-mail message 
>> and/or attachments to it are strictly prohibited. If 
>> you have received this communication in error, 
>> please notify us by reply e-mail or telephone and 
>> immediately and permanently delete the message 
>> and any attachments. Thank you
>>
>>
>> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c
>> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 18:18:56.564887392 +0530
>> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.c	2017-01-17 19:18:50.524978315 +0530
>> @@ -2364,7 +2364,7 @@
>>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>>  	struct sgt_iter sgt_iter;
>>  	gen8_pte_t __iomem *gtt_entries;
>> -	gen8_pte_t gtt_entry;
>> +	gen8_pte_t gtt_entry = I915_NULL_PTE;
>>  	dma_addr_t addr;
>>  	int rpm_atomic_seq;
>>  	int i = 0;
>> @@ -2385,8 +2385,10 @@
>>  	 * of NUMA access patterns. Therefore, even with the way we assume
>>  	 * hardware should work, we must keep this posting read for paranoia.
>>  	 */
>> -	if (i != 0)
>> +	if (i != 0){
>> +		gen8_pte_t last_gtt_entry = readq(&gtt_entries[i-1]);
>>  		WARN_ON(readq(&gtt_entries[i-1]) != gtt_entry);
>> +	}
>>  
>>  	/* This next bit makes the above posting read even more important. We
>>  	 * want to flush the TLBs only after we're certain all the PTE updates
>> @@ -2439,7 +2441,7 @@
>>  	struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
>>  	struct sgt_iter sgt_iter;
>>  	gen6_pte_t __iomem *gtt_entries;
>> -	gen6_pte_t gtt_entry;
>> +	gen6_pte_t gtt_entry = I915_NULL_PTE;
>>  	dma_addr_t addr;
>>  	int rpm_atomic_seq;
>>  	int i = 0;
>> @@ -2453,14 +2455,17 @@
>>  		iowrite32(gtt_entry, &gtt_entries[i++]);
>>  	}
>>  
>> -	/* XXX: This serves as a posting read to make sure that the PTE has
>> +	/* 
>> +	 * XXX: This serves as a posting read to make sure that the PTE has
>>  	 * actually been updated. There is some concern that even though
>>  	 * registers and PTEs are within the same BAR that they are potentially
>>  	 * of NUMA access patterns. Therefore, even with the way we assume
>>  	 * hardware should work, we must keep this posting read for paranoia.
>>  	 */
>> -	if (i != 0)
>> +	if (i != 0) {
>> +		gen8_pte_t last_gtt_entry = readl(&gtt_entries[i-1]);
>>  		WARN_ON(readl(&gtt_entries[i-1]) != gtt_entry);
>> +	}
>>  
>>  	/* This next bit makes the above posting read even more important. We
>>  	 * want to flush the TLBs only after we're certain all the PTE updates
>> diff -uNr a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h
>> --- a/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 18:18:56.564887392 +0530
>> +++ b/linux/drivers/gpu/drm/i915/i915_gem_gtt.h	2017-01-17 19:19:57.196980002 +0530
>> @@ -54,6 +54,7 @@
>>  #define GEN6_PTE_UNCACHED		(1 << 1)
>>  #define GEN6_PTE_VALID			(1 << 0)
>>  
>> +#define	I915_NULL_PTE			0
>>  #define I915_PTES(pte_len)		(PAGE_SIZE / (pte_len))
>>  #define I915_PTE_MASK(pte_len)		(I915_PTES(pte_len) - 1)
>>  #define I915_PDES			512

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel