Re: [PATCH v2] v4l: videobuf: code cleanup.
Mauro Carvalho Chehab wrote: Pawel Osciak wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It is fine for me to send such patch in a series of changes. A pure CodingStyle patch is preferred if you're doing lots of changes, since it is very easy to review those changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an rc cycle, to avoid conflicts with real patches, especially when the change is on a code that use to have lots of changes during a kernel cycle. In the specific case of videobuf, I prefer to merge any changes functional changes at the beginning of a -rc cycle, and after having several tested-by replies with different architectures and boards, as a trouble there will affect almost all drivers. I'm applying this CodingStyle fix to the tree. Better applying it sooner than later. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: videobuf: code cleanup.
Mauro Carvalho Chehab wrote: Pawel Osciak wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It is fine for me to send such patch in a series of changes. A pure CodingStyle patch is preferred if you're doing lots of changes, since it is very easy to review those changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an rc cycle, to avoid conflicts with real patches, especially when the change is on a code that use to have lots of changes during a kernel cycle. In the specific case of videobuf, I prefer to merge any changes functional changes at the beginning of a -rc cycle, and after having several tested-by replies with different architectures and boards, as a trouble there will affect almost all drivers. I'm applying this CodingStyle fix to the tree. Better applying it sooner than later. Hooray! If time permits then I'll start a series of refactoring patches this weekend. I also have similar cleanup patches in my queue for v4l1 drivers that need to be converted to v4l2. I'll post a pull request for that as well during the weekend. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] v4l: videobuf: code cleanup.
Make videobuf pass checkpatch; minor code cleanups.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c| 116 ++---
drivers/media/video/videobuf-dma-sg.c | 276
drivers/media/video/videobuf-vmalloc.c | 112 ++---
include/media/videobuf-core.h | 10 +-
include/media/videobuf-dma-sg.h| 27 ++--
include/media/videobuf-vmalloc.h | 12 +-
6 files changed, 272 insertions(+), 281 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index bb0a1c8..37afb4e 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -24,10 +24,15 @@
#include media/videobuf-core.h
#define MAGIC_BUFFER 0x20070728
-#define MAGIC_CHECK(is, should) do { \
- if (unlikely((is) != (should))) { \
- printk(KERN_ERR magic mismatch: %x (expected %x)\n, is, should); \
- BUG(); } } while (0)
+#define MAGIC_CHECK(is, should)
\
+ do {\
+ if (unlikely((is) != (should))) { \
+ printk(KERN_ERR \
+ magic mismatch: %x (expected %x)\n, \
+ is, should);\
+ BUG(); \
+ } \
+ } while (0)
static int debug;
module_param(debug, int, 0644);
@@ -36,9 +41,11 @@ MODULE_DESCRIPTION(helper module to manage video4linux
buffers);
MODULE_AUTHOR(Mauro Carvalho Chehab mche...@infradead.org);
MODULE_LICENSE(GPL);
-#define dprintk(level, fmt, arg...) do { \
- if (debug = level) \
- printk(KERN_DEBUG vbuf: fmt , ## arg); } while (0)
+#define dprintk(level, fmt, arg...)\
+ do {\
+ if (debug = level) \
+ printk(KERN_DEBUG vbuf: fmt, ## arg);\
+ } while (0)
/* - */
@@ -57,14 +64,14 @@ void *videobuf_alloc(struct videobuf_queue *q)
}
vb = q-int_ops-alloc(q-msize);
-
if (NULL != vb) {
init_waitqueue_head(vb-done);
- vb-magic = MAGIC_BUFFER;
+ vb-magic = MAGIC_BUFFER;
}
return vb;
}
+EXPORT_SYMBOL_GPL(videobuf_alloc);
#define WAITON_CONDITION (vb-state != VIDEOBUF_ACTIVE \
vb-state != VIDEOBUF_QUEUED)
@@ -86,6 +93,7 @@ int videobuf_waiton(struct videobuf_buffer *vb, int
non_blocking, int intr)
return 0;
}
+EXPORT_SYMBOL_GPL(videobuf_waiton);
int videobuf_iolock(struct videobuf_queue *q, struct videobuf_buffer *vb,
struct v4l2_framebuffer *fbuf)
@@ -95,9 +103,10 @@ int videobuf_iolock(struct videobuf_queue *q, struct
videobuf_buffer *vb,
return CALL(q, iolock, q, vb, fbuf);
}
+EXPORT_SYMBOL_GPL(videobuf_iolock);
-void *videobuf_queue_to_vmalloc (struct videobuf_queue *q,
- struct videobuf_buffer *buf)
+void *videobuf_queue_to_vmalloc(struct videobuf_queue *q,
+ struct videobuf_buffer *buf)
{
if (q-int_ops-vmalloc)
return q-int_ops-vmalloc(buf);
@@ -146,6 +155,7 @@ void videobuf_queue_core_init(struct videobuf_queue *q,
init_waitqueue_head(q-wait);
INIT_LIST_HEAD(q-stream);
}
+EXPORT_SYMBOL_GPL(videobuf_queue_core_init);
/* Locking: Only usage in bttv unsafe find way to remove */
int videobuf_queue_is_busy(struct videobuf_queue *q)
@@ -184,6 +194,7 @@ int videobuf_queue_is_busy(struct videobuf_queue *q)
}
return 0;
}
+EXPORT_SYMBOL_GPL(videobuf_queue_is_busy);
/* Locking: Caller holds q-vb_lock */
void videobuf_queue_cancel(struct videobuf_queue *q)
@@ -216,6 +227,7 @@ void videobuf_queue_cancel(struct videobuf_queue *q)
}
INIT_LIST_HEAD(q-stream);
}
+EXPORT_SYMBOL_GPL(videobuf_queue_cancel);
/* - */
@@ -237,6 +249,7 @@ enum v4l2_field videobuf_next_field(struct videobuf_queue
*q)
}
return field;
}
+EXPORT_SYMBOL_GPL(videobuf_next_field);
/* Locking: Caller holds q-vb_lock */
static void videobuf_status(struct videobuf_queue *q, struct v4l2_buffer *b,
@@ -305,8 +318,7 @@ static int __videobuf_mmap_free(struct videobuf_queue *q)
MAGIC_CHECK(q-int_ops-magic,
RE: [PATCH v2] v4l: videobuf: code cleanup.
Hi, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Wednesday, March 17, 2010 8:04 AM To: linux-media@vger.kernel.org Cc: p.osc...@samsung.com; m.szyprow...@samsung.com; kyungmin.p...@samsung.com Subject: [PATCH v2] v4l: videobuf: code cleanup. Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Regards, Sergio snip -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] v4l: videobuf: code cleanup.
Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] v4l: videobuf: code cleanup.
Hi, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Wednesday, March 17, 2010 8:04 AM To: linux-media@vger.kernel.org Cc: p.osc...@samsung.com; m.szyprow...@samsung.com; kyungmin.p...@samsung.com Subject: [PATCH v2] v4l: videobuf: code cleanup. Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) It is true that you shouldn't do this 'just to clean up code'. But in this case we want to do a lot of work on the videobuf framework, and it helps a lot if it is first brought up to date with the coding standards. It's just step one in a much longer process :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] v4l: videobuf: code cleanup.
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 17, 2010 9:26 AM To: Aguirre, Sergio Cc: Pawel Osciak; linux-media@vger.kernel.org; m.szyprow...@samsung.com; kyungmin.p...@samsung.com Subject: RE: [PATCH v2] v4l: videobuf: code cleanup. Hi, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Wednesday, March 17, 2010 8:04 AM To: linux-media@vger.kernel.org Cc: p.osc...@samsung.com; m.szyprow...@samsung.com; kyungmin.p...@samsung.com Subject: [PATCH v2] v4l: videobuf: code cleanup. Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development- process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) It is true that you shouldn't do this 'just to clean up code'. But in this case we want to do a lot of work on the videobuf framework, and it helps a lot if it is first brought up to date with the coding standards. It's just step one in a much longer process :-) Ok, understood. No problem with that at all... I just wanted clarification on this coding policy. :) Regards, Sergio Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] v4l: videobuf: code cleanup.
-Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Wednesday, March 17, 2010 9:29 AM To: Pawel Osciak Cc: Aguirre, Sergio; linux-media@vger.kernel.org; Marek Szyprowski; kyungmin.p...@samsung.com Subject: RE: [PATCH v2] v4l: videobuf: code cleanup. Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development- process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It wasn't my intention to cancel your effort :) Please don't give up because of my comment. As I said, you give up way too easily. There are good reasons for doing a simple straightforward cleanup patch first before tackling all the more complex issues. Let's get this in first, then the future patches will only do the actual functional changes instead of them having to do codingstyle cleanups at the same time. I want to avoid that. Sounds reasonable. I wont say naything more about the topic. I think you guys have cleared it enough for me :) Regards, Sergio Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] v4l: videobuf: code cleanup.
Aguirre, Sergio wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development- process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It wasn't my intention to cancel your effort :) Please don't give up because of my comment. As I said, you give up way too easily. There are good reasons for doing a simple straightforward cleanup patch first before tackling all the more complex issues. Let's get this in first, then the future patches will only do the actual functional changes instead of them having to do codingstyle cleanups at the same time. I want to avoid that. Sounds reasonable. I wont say naything more about the topic. I think you guys have cleared it enough for me :) Come on guys, I really do not give up that easily, I just went on with more important patches. I am just a very agreeable person, that's all :) Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: videobuf: code cleanup.
Pawel Osciak wrote: Aguirre, Sergio wrote: Make videobuf pass checkpatch; minor code cleanups. I thought this kind patches were frowned upon.. http://www.mjmwired.net/kernel/Documentation/development-process/4.Coding#41 But maybe it's acceptable in this case... I'm not an expert on community policies :) Hm, right... I'm not an expert either, but it does seem reasonable. It was just a part of the roadmap we agreed on in Norway, so I simply went ahead with it. Merging with other patches would pollute them so I just posted it separately. I will leave the decision up to Mauro then. I have some more normal patches lined up, so please let me know. I'm guessing we are cancelling the clean-up then though. It is fine for me to send such patch in a series of changes. A pure CodingStyle patch is preferred if you're doing lots of changes, since it is very easy to review those changes. Yet, I generally hold pure CodingStyle changes to happen at the end of an rc cycle, to avoid conflicts with real patches, especially when the change is on a code that use to have lots of changes during a kernel cycle. In the specific case of videobuf, I prefer to merge any changes functional changes at the beginning of a -rc cycle, and after having several tested-by replies with different architectures and boards, as a trouble there will affect almost all drivers. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: videobuf: code cleanup.
On Wednesday 17 March 2010 14:04:21 Pawel Osciak wrote: Make videobuf pass checkpatch; minor code cleanups. Signed-off-by: Pawel Osciak p.osc...@samsung.com Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl It would be really nice if this can be merged soon. With all the work that we want to do on videobuf it makes life easier if it is cleaned up first. I wonder if it is perhaps possible to get this merged for 2.6.34-rc2? That way it will be easier to merge fixes there. Although I think that it is unlikely that we will want to make any videobuf changes for 2.6.34. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] v4l: videobuf: code cleanup.
Hans Verkuil wrote: On Wednesday 17 March 2010 14:04:21 Pawel Osciak wrote: Make videobuf pass checkpatch; minor code cleanups. Signed-off-by: Pawel Osciak p.osc...@samsung.com Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl It would be really nice if this can be merged soon. With all the work that we want to do on videobuf it makes life easier if it is cleaned up first. I wonder if it is perhaps possible to get this merged for 2.6.34-rc2? That way it will be easier to merge fixes there. Although I think that it is unlikely that we will want to make any videobuf changes for 2.6.34. Videobuf changes for 2.6.34? Only if you catch a bug that affect the current drivers and after lots of testing. It seems very unlikely. I don't see any reason to send a pure cleanup patch outside the merge window. So, after review, I'll add it at v4l-dvb.git tree (so, a patch for 2.6.35). -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
