[Intel-gfx] drm/i915: avoid "may be used uninitialized" warnings
Jani Nikula
jani.nikula at linux.intel.com
Wed Jan 18 12:30:06 UTC 2017
On Wed, 18 Jan 2017, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> On Wed, 18 Jan 2017, Sreedhar Donelli <sreedhar.donelli at 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 at 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(>t_entries[i-1]);
>> WARN_ON(readq(>t_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, >t_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(>t_entries[i-1]);
>> WARN_ON(readl(>t_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
More information about the Intel-gfx
mailing list