* Patch
@ 2013-11-22 16:35 Arthur Schwalbenberg
2013-11-22 17:36 ` Patch Levente Kurusa
0 siblings, 1 reply; 7+ messages in thread
From: Arthur Schwalbenberg @ 2013-11-22 16:35 UTC (permalink / raw)
To: Daniel Vetter, David Airlie, intel-gfx, dri-devel, linux-kernel,
Arthur Schwalbenberg
From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001
From: Arthur Schwalbenberg <aschwal@hotmail.com>
Date: Thu, 21 Nov 2013 19:42:44 -0500
Subject: [PATCH] Staging: Fixed compilar warnings and coding style
issues in i915_debugfs.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is a patch fixing both a compilar warning:
‘val’ may be used uninitialized in this function
and various coding style issues which include line length
warnings and a few errors as defined by 'checkpatch.pl' tool
Signed-off-by: Arthur Schwalbenberg <aschwal@hotmail.com>
---
drivers/gpu/drm/i915/i915_debugfs.c | 75 ++++++++++++++++++++---------------
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ed45a9..01135d4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2008 Intel Corporation
+ * Copyright © 2008 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -87,8 +87,8 @@ static int i915_capabilities(struct seq_file *m, void
*data)
seq_printf(m, "gen: %d\n", info->gen);
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev));
-#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x))
-#define SEP_SEMICOLON ;
+#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x));
+#define SEP_SEMICOLON
DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG, SEP_SEMICOLON);
#undef PRINT_FLAG
#undef SEP_SEMICOLON
@@ -144,7 +144,7 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
if (obj->pin_count)
seq_printf(m, " (pinned x %d)", obj->pin_count);
if (obj->pin_display)
- seq_printf(m, " (display)");
+ seq_puts(m, " (display)");
if (obj->fence_reg != I915_FENCE_REG_NONE)
seq_printf(m, " (fence: %d)", obj->fence_reg);
list_for_each_entry(vma, &obj->vma_list, vma_link) {
@@ -210,9 +210,9 @@ static int i915_gem_object_list_info(struct seq_file
*m, void *data)
total_obj_size = total_gtt_size = count = 0;
list_for_each_entry(vma, head, mm_list) {
- seq_printf(m, " ");
+ seq_puts(m, " ");
describe_obj(m, vma->obj);
- seq_printf(m, "\n");
+ seq_puts(m, "\n");
total_obj_size += vma->obj->base.size;
total_gtt_size += vma->node.size;
count++;
@@ -333,7 +333,7 @@ static int per_file_stats(int id, void *ptr, void *data)
} \
} while (0)
-static int i915_gem_object_info(struct seq_file *m, void* data)
+static int i915_gem_object_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
@@ -460,6 +460,7 @@ static int i915_gem_gtt_info(struct seq_file *m,
void *data)
static int i915_gem_pageflip_info(struct seq_file *m, void *data)
{
+ struct drm_i915_gem_object *obj = NULL;
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
unsigned long flags;
@@ -487,19 +488,22 @@ static int i915_gem_pageflip_info(struct seq_file
*m, void *data)
seq_puts(m, "Stall check enabled, ");
else
seq_puts(m, "Stall check waiting for page flip ioctl, ");
- seq_printf(m, "%d prepares\n", atomic_read(&work->pending));
+
+ seq_printf(m, "%d prepares\n",
+ atomic_read(&work->pending));
if (work->old_fb_obj) {
- struct drm_i915_gem_object *obj = work->old_fb_obj;
+ obj = work->old_fb_obj;
if (obj)
seq_printf(m, "Old framebuffer gtt_offset 0x%08lx\n",
- i915_gem_obj_ggtt_offset(obj));
+ i915_gem_obj_ggtt_offset(obj));
}
if (work->pending_flip_obj) {
- struct drm_i915_gem_object *obj = work->pending_flip_obj;
+ obj = work->pending_flip_obj;
if (obj)
- seq_printf(m, "New framebuffer gtt_offset 0x%08lx\n",
- i915_gem_obj_ggtt_offset(obj));
+ seq_printf(m,
+ "New framebuffer gtt_offset 0x%08lx\n",
+ i915_gem_obj_ggtt_offset(obj));
}
}
spin_unlock_irqrestore(&dev->event_lock, flags);
@@ -530,9 +534,8 @@ static int i915_gem_request_info(struct seq_file *m,
void *data)
list_for_each_entry(gem_request,
&ring->request_list,
list) {
- seq_printf(m, " %d @ %d\n",
- gem_request->seqno,
- (int) (jiffies - gem_request->emitted_jiffies));
+ seq_printf(m, " %d @ %d\n", gem_request->seqno,
+ (int) (jiffies - gem_request->emitted_jiffies));
}
count++;
}
@@ -909,7 +912,9 @@ static int i915_rstdby_delays(struct seq_file *m,
void *unused)
mutex_unlock(&dev->struct_mutex);
- seq_printf(m, "w/ctx: %d, w/o ctx: %d\n", (crstanddelay >> 8) & 0x3f,
(crstanddelay & 0x3f));
+ seq_printf(m, "w/ctx: %d, w/o ctx: %d\n",
+ (crstanddelay >> 8) & 0x3f,
+ (crstanddelay & 0x3f));
return 0;
}
@@ -929,10 +934,11 @@ static int i915_cur_delayinfo(struct seq_file *m,
void *unused)
seq_printf(m, "Requested P-state: %d\n", (rgvswctl >> 8) & 0xf);
seq_printf(m, "Requested VID: %d\n", rgvswctl & 0x3f);
- seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK) >>
- MEMSTAT_VID_SHIFT);
+ seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK)
+ >> MEMSTAT_VID_SHIFT);
seq_printf(m, "Current P-state: %d\n",
- (rgvstat & MEMSTAT_PSTATE_MASK) >> MEMSTAT_PSTATE_SHIFT);
+ (rgvstat & MEMSTAT_PSTATE_MASK) >>
+ MEMSTAT_PSTATE_SHIFT);
} else if ((IS_GEN6(dev) || IS_GEN7(dev)) && !IS_VALLEYVIEW(dev)) {
u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
u32 rp_state_limits = I915_READ(GEN6_RP_STATE_LIMITS);
@@ -1173,13 +1179,13 @@ static int gen6_drpc_info(struct seq_file *m)
spin_unlock_irq(&dev_priv->uncore.lock);
if (forcewake_count) {
- seq_puts(m, "RC information inaccurate because somebody "
- "holds a forcewake reference \n");
+ seq_puts(m, "RC information inaccurate because somebody holds a
forcewake reference\n");
} else {
/* NB: we cannot use forcewake, else we read the wrong values */
while (count++ < 50 && (I915_READ_NOTRACE(FORCEWAKE_ACK) & 1))
udelay(10);
- seq_printf(m, "RC information accurate: %s\n", yesno(count < 51));
+ seq_printf(m, "RC information accurate: %s\n",
+ yesno(count < 51));
}
gt_core_status = readl(dev_priv->regs + GEN6_GT_CORE_STATUS);
@@ -1549,7 +1555,8 @@ static int i915_context_status(struct seq_file *m,
void *unused)
describe_ctx(m, ctx);
for_each_ring(ring, dev_priv, i)
if (ring->default_context == ctx)
- seq_printf(m, "(default context %s) ", ring->name);
+ seq_printf(m, "(default context %s) ",
+ ring->name);
describe_obj(m, ctx->obj);
seq_putc(m, '\n');
@@ -1683,10 +1690,15 @@ static void gen6_ppgtt_info(struct seq_file *m,
struct drm_device *dev)
for_each_ring(ring, dev_priv, i) {
seq_printf(m, "%s\n", ring->name);
if (INTEL_INFO(dev)->gen == 7)
- seq_printf(m, "GFX_MODE: 0x%08x\n", I915_READ(RING_MODE_GEN7(ring)));
- seq_printf(m, "PP_DIR_BASE: 0x%08x\n", I915_READ(RING_PP_DIR_BASE(ring)));
- seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n",
I915_READ(RING_PP_DIR_BASE_READ(ring)));
- seq_printf(m, "PP_DIR_DCLV: 0x%08x\n", I915_READ(RING_PP_DIR_DCLV(ring)));
+ seq_printf(m, "GFX_MODE: 0x%08x\n",
+ I915_READ(RING_MODE_GEN7(ring)));
+
+ seq_printf(m, "PP_DIR_BASE: 0x%08x\n",
+ I915_READ(RING_PP_DIR_BASE(ring)));
+ seq_printf(m, "PP_DIR_BASE_READ: 0x%08x\n",
+ I915_READ(RING_PP_DIR_BASE_READ(ring)));
+ seq_printf(m, "PP_DIR_DCLV: 0x%08x\n",
+ I915_READ(RING_PP_DIR_DCLV(ring)));
}
if (dev_priv->mm.aliasing_ppgtt) {
struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
@@ -2347,7 +2359,7 @@ static int pipe_crc_set_source(struct drm_device
*dev, enum pipe pipe,
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
- u32 val;
+ u32 val = 0;
int ret;
if (pipe_crc->source == source)
@@ -2362,7 +2374,7 @@ static int pipe_crc_set_source(struct drm_device
*dev, enum pipe pipe,
else if (INTEL_INFO(dev)->gen < 5)
ret = i9xx_pipe_crc_ctl_reg(dev, pipe, &source, &val);
else if (IS_VALLEYVIEW(dev))
- ret = vlv_pipe_crc_ctl_reg(dev,pipe, &source, &val);
+ ret = vlv_pipe_crc_ctl_reg(dev, pipe, &source, &val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(&source, &val);
else
@@ -3046,7 +3058,8 @@ static const struct drm_info_list
i915_debugfs_list[] = {
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pinned", i915_gem_gtt_info, 0, (void *) PINNED_LIST},
{"i915_gem_active", i915_gem_object_list_info, 0, (void *) ACTIVE_LIST},
- {"i915_gem_inactive", i915_gem_object_list_info, 0, (void *)
INACTIVE_LIST},
+ {"i915_gem_inactive", i915_gem_object_list_info, 0,
+ (void *) INACTIVE_LIST},
{"i915_gem_stolen", i915_gem_stolen_list_info },
{"i915_gem_pageflip", i915_gem_pageflip_info, 0},
{"i915_gem_request", i915_gem_request_info, 0},
--
1.7.9.5
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Patch
2013-11-22 16:35 Patch Arthur Schwalbenberg
@ 2013-11-22 17:36 ` Levente Kurusa
2013-11-25 8:58 ` Patch Daniel Vetter
0 siblings, 1 reply; 7+ messages in thread
From: Levente Kurusa @ 2013-11-22 17:36 UTC (permalink / raw)
To: Arthur Schwalbenberg, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, linux-kernel, Arthur Schwalbenberg
2013-11-22 17:35, Arthur Schwalbenberg:
>
> From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001
> From: Arthur Schwalbenberg <aschwal@hotmail.com>
> Date: Thu, 21 Nov 2013 19:42:44 -0500
> Subject: [PATCH] Staging: Fixed compilar warnings and coding style
> issues in i915_debugfs.c
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This is a patch fixing both a compilar warning:
> ‘val’ may be used uninitialized in this function
> and various coding style issues which include line length
> warnings and a few errors as defined by 'checkpatch.pl' tool
>
> Signed-off-by: Arthur Schwalbenberg <aschwal@hotmail.com>
Hi,
When you break 80+ lines into two lines, you should also
indent the newly created line so that it shows that it is a part of something.
I as well don't think it is worth splitting lines that are 84 characters long into
two lines, that just doesn't make sense.
Also, your patch seems (atleast to me) a 'bit' whitespace damaged.
--
Regards,
Levente Kurusa
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Patch
2013-11-22 17:36 ` Patch Levente Kurusa
@ 2013-11-25 8:58 ` Daniel Vetter
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Vetter @ 2013-11-25 8:58 UTC (permalink / raw)
To: Levente Kurusa
Cc: Arthur Schwalbenberg, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, linux-kernel, Arthur Schwalbenberg
On Fri, Nov 22, 2013 at 06:36:48PM +0100, Levente Kurusa wrote:
> 2013-11-22 17:35, Arthur Schwalbenberg:
> >
> > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001
> > From: Arthur Schwalbenberg <aschwal@hotmail.com>
> > Date: Thu, 21 Nov 2013 19:42:44 -0500
> > Subject: [PATCH] Staging: Fixed compilar warnings and coding style
> > issues in i915_debugfs.c
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > This is a patch fixing both a compilar warning:
> > ‘val’ may be used uninitialized in this function
> > and various coding style issues which include line length
> > warnings and a few errors as defined by 'checkpatch.pl' tool
> >
> > Signed-off-by: Arthur Schwalbenberg <aschwal@hotmail.com>
>
> Hi,
>
> When you break 80+ lines into two lines, you should also
> indent the newly created line so that it shows that it is a part of something.
> I as well don't think it is worth splitting lines that are 84 characters long into
> two lines, that just doesn't make sense.
>
> Also, your patch seems (atleast to me) a 'bit' whitespace damaged.
Also, please don't smash different changes into the same patch. Especially
pure whitespace changes _must_ be separate from actual code changes.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 7+ messages in thread
* patch
@ 2010-05-04 16:48 Kristoffer Ericson
0 siblings, 0 replies; 7+ messages in thread
From: Kristoffer Ericson @ 2010-05-04 16:48 UTC (permalink / raw)
To: jeff; +Cc: linux-kernel
Hey,
did you get my patch concerning those hash changes? Havent gotten any reply.
Best wishes
Kristoffer
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: patch
2002-11-18 23:20 ` patch Rik van Riel
@ 2002-11-19 7:33 ` Duncan Sands
0 siblings, 0 replies; 7+ messages in thread
From: Duncan Sands @ 2002-11-19 7:33 UTC (permalink / raw)
To: Rik van Riel, deepak; +Cc: linux-kernel
On Tuesday 19 November 2002 00:20, Rik van Riel wrote:
> On Mon, 18 Nov 2002, deepak wrote:
> > how do i uninstall a patch
>
> $ man patch
> ...
> -R or --reverse
> Assume that this patch was created with the old and new
> files swapped. (Yes, I'm afraid that does happen occa
> sionally, human nature being what it is.) patch
> attempts to swap each hunk around before applying it.
> Rejects come out in the swapped format. The -R option
> ...
>
> Next time you should read the man page yourself ;)
Come on, be fair. This text is pretty obscure. If you didn't know so
already, would you understand from it that -R undoes a patch?
Duncan.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: patch
2002-11-18 23:07 patch deepak
@ 2002-11-18 23:20 ` Rik van Riel
2002-11-19 7:33 ` patch Duncan Sands
0 siblings, 1 reply; 7+ messages in thread
From: Rik van Riel @ 2002-11-18 23:20 UTC (permalink / raw)
To: deepak; +Cc: linux-kernel
On Mon, 18 Nov 2002, deepak wrote:
> how do i uninstall a patch
$ man patch
...
-R or --reverse
Assume that this patch was created with the old and new
files swapped. (Yes, I'm afraid that does happen occa
sionally, human nature being what it is.) patch
attempts to swap each hunk around before applying it.
Rejects come out in the swapped format. The -R option
...
Next time you should read the man page yourself ;)
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://guru.conectiva.com/
Current spamtrap: <a href=mailto:"october@surriel.com">october@surriel.com</a>
^ permalink raw reply [flat|nested] 7+ messages in thread
* patch
@ 2002-11-18 23:07 deepak
2002-11-18 23:20 ` patch Rik van Riel
0 siblings, 1 reply; 7+ messages in thread
From: deepak @ 2002-11-18 23:07 UTC (permalink / raw)
To: linux-kernel
how do i uninstall a patch
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-11-25 8:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-22 16:35 Patch Arthur Schwalbenberg
2013-11-22 17:36 ` Patch Levente Kurusa
2013-11-25 8:58 ` Patch Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2010-05-04 16:48 patch Kristoffer Ericson
2002-11-18 23:07 patch deepak
2002-11-18 23:20 ` patch Rik van Riel
2002-11-19 7:33 ` patch Duncan Sands
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).