Re: [PATCH 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
Hi Laurent, Thanks for the review. On Tue, Feb 24, 2015 at 12:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, Thank you for the patch. On Monday 23 February 2015 20:19:32 Lad Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com this patch drops driver specific isp_video_fh, as this can be handled by core. I'm afraid it's not that simple. The omap3isp driver stores video queues per file handle for a reason. This was design to permit creating a high-resolution still image capture queue and prepare buffers ahead of time, to avoid the large delay due to cache management as prepare time when taking the snapshot. Ah I see the reason. Now this use case has been partially solved by VIDIOC_CREATE_BUFS, but we're still missing a VIDIOC_DESTROY_BUFS to make it work completely. That needs to be solved first. I haven't used the VIDIOC_CREATE_BUFS ioctl so far in any of the apps so cant comment much on this. But isn't that obvious we need VIDIOC_DESTROY_BUFS or is there any backdoor to destroy them that I am missing ? Regards, --Prabhakar Lad Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/omap3isp/ispvideo.c | 128 ++--- drivers/media/platform/omap3isp/ispvideo.h | 13 +-- 2 files changed, 49 insertions(+), 92 deletions(-) -- Regards, Laurent Pinchart -- 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] Adding NV{12,21} and Y{U,V}12 pixel formats support.
Hi Miguel, Thanks for the patch. However, after reviewing it and testing it I decided to implement my own version. Partially because several features were still failing (crop/compose/scale), partially because I didn't like the way the tpg was changed: too much change basically. Yesterday I added YUV 420 support. It's still work in progress as I am not happy with some of the internal changes and because changing the compose height fails to work at the moment. You can find my preliminary work here: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 I plan to continue work on this on Friday and Monday, fixing any remaining bugs, adding support for the other planar formats and carefully reviewing if I handle the downsampling correctly. I also want to add output support for these formats. Regards, Hans On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: This is the second attempt at creating a patch doing that while respecting the pattern movements, crops, and other artifacts that can be added to the generated frames. Hope it addresses Hans' comments on the first patch. It should create properly moving patterns, border, square and noise. SAV/EAV are left out for the new formats, but can be pulled in if deemed interesting/ necessary. New formats' descriptions are shorter. Needless to say, previous formats should work 100% the same as before. Text is, still, printed as Y only. I think the goal of the text is not pixel-value-based comparisons, but human reading. Please let me know otherwise. It needed quite some refactoring of the original tpg_fillbuffer() function: - the internal code generating the video buffer line-by-line are factored out into a function tpg_fill_oneline(). const added wherever it made sense. - this new tpg_fill_oneline() is used by both new functions tpg_fillbuffer_packed() and tpg_fillbuffer_planar(). - tpg_fillbuffer_packed() does the non-planar formats' buffer composition, so it does, or should do, pretty much the same as vivid did before this patch. Tested via both guvcview and qv4l2, checking formats, patterns, pattern movements, box and frame checkboxes. Hope I managed to get the patch correctly into the mail i.e. no spurious wraparounds, no whitespaces etc :) Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org -- 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 6/7] v4l2-subdev: remove enum_framesizes/intervals
Hi Hans,
On Tuesday 24 February 2015 09:08:09 Hans Verkuil wrote:
On 02/13/2015 12:30 PM, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Replace the video ops enum_framesizes and enum_frameintervals by the pad
ops enum_frame_size and enum_frame_interval.
The video and pad ops are duplicates, so get rid of the more limited video
op.
The whole point of the subdev API is to allow reuse of subdev drivers by
bridge drivers. Having duplicate ops makes that much harder. We should
never have allowed duplicate ops in the first place. A lesson for the
future.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Jonathan Corbet cor...@lwn.net
Laurent, can you Ack the v4l2 core change?
For the core,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Jon, can you take a look at the changes to your drivers?
Thanks!
Hans
---
drivers/media/i2c/ov7670.c | 37 +++
drivers/media/platform/marvell-ccic/mcam-core.c | 48 +---
drivers/media/platform/soc_camera/soc_camera.c | 30 +++-
drivers/media/platform/via-camera.c | 15 ++--
include/media/v4l2-subdev.h | 2 --
5 files changed, 101 insertions(+), 31 deletions(-)
[snip]
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 6192f66..933f767 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -332,8 +332,6 @@ struct v4l2_subdev_video_ops {
struct v4l2_subdev_frame_interval *interval);
int (*s_frame_interval)(struct v4l2_subdev *sd,
struct v4l2_subdev_frame_interval *interval);
- int (*enum_framesizes)(struct v4l2_subdev *sd, struct
v4l2_frmsizeenum *fsize);
- int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival);
int (*s_dv_timings)(struct v4l2_subdev *sd,
struct v4l2_dv_timings *timings);
int (*g_dv_timings)(struct v4l2_subdev *sd,
--
Regards,
Laurent Pinchart
--
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 2/3] media: omap3isp: ispvideo: drop driver specific isp_video_fh
Hi Prabhakar, On Tuesday 24 February 2015 08:04:40 Lad, Prabhakar wrote: On Tue, Feb 24, 2015 at 12:35 AM, Laurent Pinchart wrote: On Monday 23 February 2015 20:19:32 Lad Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com this patch drops driver specific isp_video_fh, as this can be handled by core. I'm afraid it's not that simple. The omap3isp driver stores video queues per file handle for a reason. This was design to permit creating a high-resolution still image capture queue and prepare buffers ahead of time, to avoid the large delay due to cache management as prepare time when taking the snapshot. Ah I see the reason. Now this use case has been partially solved by VIDIOC_CREATE_BUFS, but we're still missing a VIDIOC_DESTROY_BUFS to make it work completely. That needs to be solved first. I haven't used the VIDIOC_CREATE_BUFS ioctl so far in any of the apps so cant comment much on this. But isn't that obvious we need VIDIOC_DESTROY_BUFS or is there any backdoor to destroy them that I am missing ? You can destroy buffers allocated with CREATE_BUFS using REQBUFS(0), but you can't destroy them individually without a new ioctl. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- drivers/media/platform/omap3isp/ispvideo.c | 128 +-- drivers/media/platform/omap3isp/ispvideo.h | 13 +-- 2 files changed, 49 http://vger.kernel.org/majordomo-info.html -- Regards, Laurent Pinchart -- 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 6/7] v4l2-subdev: remove enum_framesizes/intervals
On 02/13/2015 12:30 PM, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Replace the video ops enum_framesizes and enum_frameintervals by the pad
ops enum_frame_size and enum_frame_interval.
The video and pad ops are duplicates, so get rid of the more limited video op.
The whole point of the subdev API is to allow reuse of subdev drivers by
bridge drivers. Having duplicate ops makes that much harder. We should never
have allowed duplicate ops in the first place. A lesson for the future.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Cc: Jonathan Corbet cor...@lwn.net
Laurent, can you Ack the v4l2 core change?
Jon, can you take a look at the changes to your drivers?
Thanks!
Hans
---
drivers/media/i2c/ov7670.c | 37 +++
drivers/media/platform/marvell-ccic/mcam-core.c | 48
++---
drivers/media/platform/soc_camera/soc_camera.c | 30 +++-
drivers/media/platform/via-camera.c | 15 ++--
include/media/v4l2-subdev.h | 2 --
5 files changed, 101 insertions(+), 31 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 957927f..b984752 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1069,29 +1069,35 @@ static int ov7670_s_parm(struct v4l2_subdev *sd,
struct v4l2_streamparm *parms)
static int ov7670_frame_rates[] = { 30, 15, 10, 5, 1 };
-static int ov7670_enum_frameintervals(struct v4l2_subdev *sd,
- struct v4l2_frmivalenum *interval)
+static int ov7670_enum_frame_interval(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_interval_enum
*fie)
{
- if (interval-index = ARRAY_SIZE(ov7670_frame_rates))
+ if (fie-pad)
return -EINVAL;
- interval-type = V4L2_FRMIVAL_TYPE_DISCRETE;
- interval-discrete.numerator = 1;
- interval-discrete.denominator = ov7670_frame_rates[interval-index];
+ if (fie-index = ARRAY_SIZE(ov7670_frame_rates))
+ return -EINVAL;
+ fie-interval.numerator = 1;
+ fie-interval.denominator = ov7670_frame_rates[fie-index];
return 0;
}
/*
* Frame size enumeration
*/
-static int ov7670_enum_framesizes(struct v4l2_subdev *sd,
- struct v4l2_frmsizeenum *fsize)
+static int ov7670_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
{
struct ov7670_info *info = to_state(sd);
int i;
int num_valid = -1;
- __u32 index = fsize-index;
+ __u32 index = fse-index;
unsigned int n_win_sizes = info-devtype-n_win_sizes;
+ if (fse-pad)
+ return -EINVAL;
+
/*
* If a minimum width/height was requested, filter out the capture
* windows that fall outside that.
@@ -1103,9 +1109,8 @@ static int ov7670_enum_framesizes(struct v4l2_subdev
*sd,
if (info-min_height win-height info-min_height)
continue;
if (index == ++num_valid) {
- fsize-type = V4L2_FRMSIZE_TYPE_DISCRETE;
- fsize-discrete.width = win-width;
- fsize-discrete.height = win-height;
+ fse-min_width = fse-max_width = win-width;
+ fse-min_height = fse-max_height = win-height;
return 0;
}
}
@@ -1485,13 +1490,17 @@ static const struct v4l2_subdev_video_ops
ov7670_video_ops = {
.s_mbus_fmt = ov7670_s_mbus_fmt,
.s_parm = ov7670_s_parm,
.g_parm = ov7670_g_parm,
- .enum_frameintervals = ov7670_enum_frameintervals,
- .enum_framesizes = ov7670_enum_framesizes,
+};
+
+static const struct v4l2_subdev_pad_ops ov7670_pad_ops = {
+ .enum_frame_interval = ov7670_enum_frame_interval,
+ .enum_frame_size = ov7670_enum_frame_size,
};
static const struct v4l2_subdev_ops ov7670_ops = {
.core = ov7670_core_ops,
.video = ov7670_video_ops,
+ .pad = ov7670_pad_ops,
};
/* --- */
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index dd5b141..9c64b5d 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1568,24 +1568,64 @@ static int mcam_vidioc_enum_framesizes(struct file
*filp, void *priv,
struct v4l2_frmsizeenum *sizes)
{
struct mcam_camera *cam = priv;
+ struct mcam_format_struct *f;
+ struct v4l2_subdev_frame_size_enum fse = {
+ .index = sizes-index,
+ .which =
Re: [PATCH] media: Pinnacle 73e infrared control stopped working since kernel 3.17
On 2015-02-24 11:08, David Cimbůrek wrote: Hi, I looked at this again and I still don't see why the order is important. Plus the code looks like it does what it should be doing when using RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and RC_SCANCODE_RC5. Unfortunately I can't review this if I am not sure about it, and I don't have the device to be able to properly test your patch. Hopefully your print of the scancodes helps. Luis Hi, unfortunately I don't understand the code very well but it really works like I described. I tried to get debugging output from the dib0700_core.c:dib0700_rc_urb_completion() function: deb_data(IR ID = %02X state = %02X System = %02X %02X Cmd = %02X %02X (len %d)\n, poll_reply-report_id, poll_reply-data_state, poll_reply-system, poll_reply-not_system, poll_reply-data, poll_reply-not_data, purb-actual_length); And the output after my patch (and before commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9!) looks like this: [ 282.842557] IR ID = 01 state = 01 System = 07 00 Cmd = 0F F0 (len 6) [ 282.955810] IR ID = 01 state = 02 System = 07 00 Cmd = 0F F0 (len 6) But without my patch the output looks after commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9 like this: [ 186.302282] IR ID = 01 state = 01 System = 00 07 Cmd = 0F F0 (len 6) [ 186.415660] IR ID = 01 state = 02 System = 00 07 Cmd = 0F F0 (len 6) You can see that the content of system and not_system is really switched... Regards, David Is there anything more I can do? Shall I provide some more debugging outputs? There is no response nearly for two weeks... Sorry, I'm just really busy. The output that you gave (the actual scancodes that are generated) is what I was looking for, not the keymap. If I remember correctly my patch wasn't supposed to change the generated scancodes (or the keymap would have to be changed as well). The question is whether the right thing to do is to change back the scancode calculation or to update the keymap. I'll try to have a closer look as soon as possible (which might take a few days more, sorry). Re, David -- 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] media: Pinnacle 73e infrared control stopped working since kernel 3.17
Hi, I looked at this again and I still don't see why the order is important. Plus the code looks like it does what it should be doing when using RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and RC_SCANCODE_RC5. Unfortunately I can't review this if I am not sure about it, and I don't have the device to be able to properly test your patch. Hopefully your print of the scancodes helps. Luis Hi, unfortunately I don't understand the code very well but it really works like I described. I tried to get debugging output from the dib0700_core.c:dib0700_rc_urb_completion() function: deb_data(IR ID = %02X state = %02X System = %02X %02X Cmd = %02X %02X (len %d)\n, poll_reply-report_id, poll_reply-data_state, poll_reply-system, poll_reply-not_system, poll_reply-data, poll_reply-not_data, purb-actual_length); And the output after my patch (and before commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9!) looks like this: [ 282.842557] IR ID = 01 state = 01 System = 07 00 Cmd = 0F F0 (len 6) [ 282.955810] IR ID = 01 state = 02 System = 07 00 Cmd = 0F F0 (len 6) But without my patch the output looks after commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9 like this: [ 186.302282] IR ID = 01 state = 01 System = 00 07 Cmd = 0F F0 (len 6) [ 186.415660] IR ID = 01 state = 02 System = 00 07 Cmd = 0F F0 (len 6) You can see that the content of system and not_system is really switched... Regards, David Is there anything more I can do? Shall I provide some more debugging outputs? There is no response nearly for two weeks... -- 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] media: au0828: drop vbi_buffer_filled() and re-use buffer_filled()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
The vbi_buffer_filled() and buffer_filled() did the same functionality
except for incrementing the buffer sequence, this patch drops the
vbi_buffer_filled() and re-uses buffer_filled() for vbi buffers
as well by adding the check for vb2-queue type while incrementing
the sequence numbers. Along side this patch aligns the input parameters
of buffer_filled() function appropriately.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Shuah Khan shua...@osg.samsung.com
---
Changes for v2:
1: fixed a typo in commit message.
2: Included a Ack from Shuah.
drivers/media/usb/au0828/au0828-video.c | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index a27cb5f..60012ec 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -299,29 +299,23 @@ static int au0828_init_isoc(struct au0828_dev *dev, int
max_packets,
* Announces that a buffer were filled and request the next
*/
static inline void buffer_filled(struct au0828_dev *dev,
- struct au0828_dmaqueue *dma_q,
- struct au0828_buffer *buf)
+struct au0828_dmaqueue *dma_q,
+struct au0828_buffer *buf)
{
- /* Advice that buffer was filled */
- au0828_isocdbg([%p/%d] wakeup\n, buf, buf-top_field);
-
- buf-vb.v4l2_buf.sequence = dev-frame_count++;
- buf-vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
- v4l2_get_timestamp(buf-vb.v4l2_buf.timestamp);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_DONE);
-}
+ struct vb2_buffer vb = buf-vb;
+ struct vb2_queue *q = vb.vb2_queue;
-static inline void vbi_buffer_filled(struct au0828_dev *dev,
-struct au0828_dmaqueue *dma_q,
-struct au0828_buffer *buf)
-{
/* Advice that buffer was filled */
au0828_isocdbg([%p/%d] wakeup\n, buf, buf-top_field);
- buf-vb.v4l2_buf.sequence = dev-vbi_frame_count++;
- buf-vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
- v4l2_get_timestamp(buf-vb.v4l2_buf.timestamp);
- vb2_buffer_done(buf-vb, VB2_BUF_STATE_DONE);
+ if (q-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ vb.v4l2_buf.sequence = dev-frame_count++;
+ else
+ vb.v4l2_buf.sequence = dev-vbi_frame_count++;
+
+ vb.v4l2_buf.field = V4L2_FIELD_INTERLACED;
+ v4l2_get_timestamp(vb.v4l2_buf.timestamp);
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
/*
@@ -574,9 +568,7 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev,
struct urb *urb)
if (fbyte 0x40) {
/* VBI */
if (vbi_buf != NULL)
- vbi_buffer_filled(dev,
- vbi_dma_q,
- vbi_buf);
+ buffer_filled(dev, vbi_dma_q, vbi_buf);
vbi_get_next_buf(vbi_dma_q, vbi_buf);
if (vbi_buf == NULL)
vbioutp = NULL;
@@ -949,7 +941,7 @@ static void au0828_vbi_buffer_timeout(unsigned long data)
if (buf != NULL) {
vbi_data = vb2_plane_vaddr(buf-vb, 0);
memset(vbi_data, 0x00, buf-length);
- vbi_buffer_filled(dev, dma_q, buf);
+ buffer_filled(dev, dma_q, buf);
}
vbi_get_next_buf(dma_q, buf);
--
1.9.1
--
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] media: i2c: add support for omnivision's ov2659 sensor
Hi Sakari,
Thanks for the review.
On Tue, Feb 24, 2015 at 11:09 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Prabhakar,
Thanks for the patch!
On Sat, Feb 21, 2015 at 03:22:47PM +, Lad Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor, the driver supports following features:
1: Asynchronous probing
2: DT support
3: Media controller support
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Changes for v2:
1: Dropped prefix entry for ovti as its already merged.
2: Fixed review comments pointed by Laurent.
.../devicetree/bindings/media/i2c/ov2659.txt | 41 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1513
include/media/ov2659.h | 33 +
6 files changed, 1609 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..c3f350b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,41 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
+1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
+multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
+YUV422, RGB565/555 or raw RGB output formats.
+
+Required Properties:
+- compatible: Must be ovti,ov2659
+- reg: I2C slave address
+- clocks: reference to the xvclk input clock.
+- clock-names: should be xvclk.
+- xvclk-frequency: Input clock frequency.
This should be probably in the device's OF node, not in the endpoint node. I
think you should document in which one each property is.
Yea agreed.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = clk_ov2659;
+ clock-names = xvclk;
+
+ assigned-clocks = clk_ov2659;
+ assigned-clock-rates = 1200;
These don't quite match with the documentation above.
These are the standard clock properties, which I thought could be ignored
for documenting ?
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe_ep;
+ xvclk-frequency = 1200;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index becb274..1126c9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8758,6 +8758,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar prabhakar.cse...@gmail.com
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu rom...@fr.zoreil.com
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate OmniVision OV2659 sensor support
+ depends on VIDEO_V4L2 I2C
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate OmniVision OV7640 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667)
Re: [PATCH v2] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
Thanks for the patch!
On Sat, Feb 21, 2015 at 03:22:47PM +, Lad Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor, the driver supports following features:
1: Asynchronous probing
2: DT support
3: Media controller support
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Changes for v2:
1: Dropped prefix entry for ovti as its already merged.
2: Fixed review comments pointed by Laurent.
.../devicetree/bindings/media/i2c/ov2659.txt | 41 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1513
include/media/ov2659.h | 33 +
6 files changed, 1609 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2659.txt
b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
new file mode 100644
index 000..c3f350b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2659.txt
@@ -0,0 +1,41 @@
+* OV2659 1/5-Inch 2Mp SOC Camera
+
+The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
+1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
+multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
+YUV422, RGB565/555 or raw RGB output formats.
+
+Required Properties:
+- compatible: Must be ovti,ov2659
+- reg: I2C slave address
+- clocks: reference to the xvclk input clock.
+- clock-names: should be xvclk.
+- xvclk-frequency: Input clock frequency.
This should be probably in the device's OF node, not in the endpoint node. I
think you should document in which one each property is.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ ov2659@30 {
+ compatible = ovti,ov2659;
+ reg = 0x30;
+
+ clocks = clk_ov2659;
+ clock-names = xvclk;
+
+ assigned-clocks = clk_ov2659;
+ assigned-clock-rates = 1200;
These don't quite match with the documentation above.
+
+ port {
+ ov2659_0: endpoint {
+ remote-endpoint = vpfe_ep;
+ xvclk-frequency = 1200;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index becb274..1126c9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8758,6 +8758,16 @@ T: git
git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
S: Maintained
F: drivers/media/platform/am437x/
+OV2659 OMNIVISION SENSOR DRIVER
+M: Lad, Prabhakar prabhakar.cse...@gmail.com
+L: linux-media@vger.kernel.org
+W: http://linuxtv.org/
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
+S: Maintained
+F: drivers/media/i2c/ov2659.c
+F: include/media/ov2659.h
+
SIS 190 ETHERNET DRIVER
M: Francois Romieu rom...@fr.zoreil.com
L: net...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index da58c9b..6f30ea7 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -466,6 +466,17 @@ config VIDEO_APTINA_PLL
config VIDEO_SMIAPP_PLL
tristate
+config VIDEO_OV2659
+ tristate OmniVision OV2659 sensor support
+ depends on VIDEO_V4L2 I2C
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV2659 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov2659.
+
config VIDEO_OV7640
tristate OmniVision OV7640 sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 98589001..f165fae 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o
obj-$(CONFIG_VIDEO_AK881X) += ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o
+obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..e79298b
--- /dev/null
+++
Re: [PATCH] media: Pinnacle 73e infrared control stopped working since kernel 3.17
Em Tue, 24 Feb 2015 11:15:53 +0100 David Härdeman da...@hardeman.nu escreveu: On 2015-02-24 11:08, David Cimbůrek wrote: Hi, I looked at this again and I still don't see why the order is important. Plus the code looks like it does what it should be doing when using RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and RC_SCANCODE_RC5. Unfortunately I can't review this if I am not sure about it, and I don't have the device to be able to properly test your patch. Hopefully your print of the scancodes helps. Luis Hi, unfortunately I don't understand the code very well but it really works like I described. I tried to get debugging output from the dib0700_core.c:dib0700_rc_urb_completion() function: deb_data(IR ID = %02X state = %02X System = %02X %02X Cmd = %02X %02X (len %d)\n, poll_reply-report_id, poll_reply-data_state, poll_reply-system, poll_reply-not_system, poll_reply-data, poll_reply-not_data, purb-actual_length); And the output after my patch (and before commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9!) looks like this: [ 282.842557] IR ID = 01 state = 01 System = 07 00 Cmd = 0F F0 (len 6) [ 282.955810] IR ID = 01 state = 02 System = 07 00 Cmd = 0F F0 (len 6) But without my patch the output looks after commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9 like this: [ 186.302282] IR ID = 01 state = 01 System = 00 07 Cmd = 0F F0 (len 6) [ 186.415660] IR ID = 01 state = 02 System = 00 07 Cmd = 0F F0 (len 6) You can see that the content of system and not_system is really switched... Regards, David Is there anything more I can do? Shall I provide some more debugging outputs? There is no response nearly for two weeks... Sorry, I'm just really busy. The output that you gave (the actual scancodes that are generated) is what I was looking for, not the keymap. If I remember correctly my patch wasn't supposed to change the generated scancodes (or the keymap would have to be changed as well). The question is whether the right thing to do is to change back the scancode calculation or to update the keymap. I'll try to have a closer look as soon as possible (which might take a few days more, sorry). I suspect we should change back the scancode calculation, as I think that the scancode table is right, but I need to do some tests with some other driver to be certain. I have a few devices here that I can use for testing, including a PCTV remote, just lacking the time. Re, David -- 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 -- 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] media: Pinnacle 73e infrared control stopped working since kernel 3.17
On 2015-02-24 14:44, Mauro Carvalho Chehab wrote: Em Tue, 24 Feb 2015 11:15:53 +0100 David Härdeman da...@hardeman.nu escreveu: The output that you gave (the actual scancodes that are generated) is what I was looking for, not the keymap. If I remember correctly my patch wasn't supposed to change the generated scancodes (or the keymap would have to be changed as well). The question is whether the right thing to do is to change back the scancode calculation or to update the keymap. I'll try to have a closer look as soon as possible (which might take a few days more, sorry). I suspect we should change back the scancode calculation, as I think that the scancode table is right, but I need to do some tests with some other driver to be certain. I have a few devices here that I can use for testing, including a PCTV remote, just lacking the time. I've exchanged a few more emails with David. I think I know what the problem is now. It's not the NEC scancode generation, it's that my patch accidentally broke the RC5 case (his remote is an RC5 one). I'll post a patch later. -- 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] media: em28xx replace printk in dprintk macros
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 3 +--
drivers/media/usb/em28xx/em28xx-dvb.c | 2 +-
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 49a5f95..93d89f2 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -55,8 +55,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define dprintk(fmt, arg...) do { \
if (debug) \
- printk(KERN_INFO em28xx-audio %s: fmt, \
- __func__, ##arg); \
+ pr_info(em28xx-audio %s: fmt, __func__, ##arg); \
} while (0)
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index aee70d4..8826054 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -71,7 +71,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
#define dprintk(level, fmt, arg...) do { \
if (debug = level)\
- printk(KERN_DEBUG %s/2-dvb: fmt, dev-name, ## arg); \
+ pr_debug(%s/2-dvb: fmt, dev-name, ## arg); \
} while (0)
struct em28xx_dvb {
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 4007356..e99108b 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -43,7 +43,7 @@ MODULE_PARM_DESC(ir_debug, enable debug messages [IR]);
#define dprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+ pr_debug(%s/ir: fmt, ir-name, ## arg); \
}
/**
--
2.1.0
--
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] media: au0828 replace printk KERN_DEBUG with pr_debug
Replace printk KERN_DEBUG with pr_debug in dprintk macro
defined in au0828.h
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828.h
b/drivers/media/usb/au0828/au0828.h
index eb15187..e3e90ea 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -336,7 +336,7 @@ extern struct vb2_ops au0828_vbi_qops;
#define dprintk(level, fmt, arg...)\
do { if (au0828_debug level)\
- printk(KERN_DEBUG pr_fmt(fmt), ## arg);\
+ pr_debug(pr_fmt(fmt), ## arg);\
} while (0)
/* au0828-input.c */
--
2.1.0
--
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] Adding NV{12,21} and Y{U,V}12 pixel formats support.
Hi Hans, go for it if you feel it's the best approach. Are you planning to add multiplanar formats? Particularly, I'm interested in YUV420M and its twin evil brother YVU420M. I would recommend adding support for a less-common format such as YUV410 (or variation thereof). Since this format is so different, it stresses the added code in revealing ways. I was planning to support it as a bonus, but I noticed is not recognised in lib4vl -- neither in qv4l2, therefore. Just saying, it'd be cool. Cheers M On 24 February 2015 at 00:02, Hans Verkuil hverk...@xs4all.nl wrote: Hi Miguel, Thanks for the patch. However, after reviewing it and testing it I decided to implement my own version. Partially because several features were still failing (crop/compose/scale), partially because I didn't like the way the tpg was changed: too much change basically. Yesterday I added YUV 420 support. It's still work in progress as I am not happy with some of the internal changes and because changing the compose height fails to work at the moment. You can find my preliminary work here: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 I plan to continue work on this on Friday and Monday, fixing any remaining bugs, adding support for the other planar formats and carefully reviewing if I handle the downsampling correctly. I also want to add output support for these formats. Regards, Hans On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: This is the second attempt at creating a patch doing that while respecting the pattern movements, crops, and other artifacts that can be added to the generated frames. Hope it addresses Hans' comments on the first patch. It should create properly moving patterns, border, square and noise. SAV/EAV are left out for the new formats, but can be pulled in if deemed interesting/ necessary. New formats' descriptions are shorter. Needless to say, previous formats should work 100% the same as before. Text is, still, printed as Y only. I think the goal of the text is not pixel-value-based comparisons, but human reading. Please let me know otherwise. It needed quite some refactoring of the original tpg_fillbuffer() function: - the internal code generating the video buffer line-by-line are factored out into a function tpg_fill_oneline(). const added wherever it made sense. - this new tpg_fill_oneline() is used by both new functions tpg_fillbuffer_packed() and tpg_fillbuffer_planar(). - tpg_fillbuffer_packed() does the non-planar formats' buffer composition, so it does, or should do, pretty much the same as vivid did before this patch. Tested via both guvcview and qv4l2, checking formats, patterns, pattern movements, box and frame checkboxes. Hope I managed to get the patch correctly into the mail i.e. no spurious wraparounds, no whitespaces etc :) Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org -- 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] xc5000: fix memory corruption when unplugging device
This patch addresses a regression introduced in the following patch:
commit 5264a522a597032c009f9143686ebf0fa4e244fb
Author: Shuah Khan shua...@osg.samsung.com
Date: Mon Sep 22 21:30:46 2014 -0300
[media] media: tuner xc5000 - release firmwware from xc5000_release()
The priv struct is actually reference counted, so the xc5000_release()
function gets called multiple times for hybrid devices. Because
release_firmware() was always being called, it would work fine as expected
on the first call but then the second call would corrupt aribtrary memory.
Set the pointer to NULL after releasing so that we don't call
release_firmware() twice.
This problem was detected in the HVR-950q where plugging/unplugging the
device multiple times would intermittently show panics in completely
unrelated areas of the kernel.
Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com
Cc: Shuah Khan shua...@osg.samsung.com
---
drivers/media/tuners/xc5000.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index 40f9db6..74b2092 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -1314,7 +1314,10 @@ static int xc5000_release(struct dvb_frontend *fe)
if (priv) {
cancel_delayed_work(priv-timer_sleep);
- release_firmware(priv-firmware);
+ if (priv-firmware) {
+ release_firmware(priv-firmware);
+ priv-firmware = NULL;
+ }
hybrid_tuner_release_state(priv);
}
--
1.9.1
--
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] Adding NV{12,21} and Y{U,V}12 pixel formats support.
On 02/24/2015 06:00 PM, Miguel Casas-Sanchez wrote: Hi Hans, go for it if you feel it's the best approach. Are you planning to add multiplanar formats? Particularly, I'm interested in YUV420M and its twin evil brother YVU420M. Certainly. I'm planning to add all those YUV420 variants. Once you have one working, the others are trivial. I would recommend adding support for a less-common format such as YUV410 (or variation thereof). Since this format is so different, it stresses the added code in revealing ways. I was planning to support it as a bonus, but I noticed is not recognised in lib4vl -- neither in qv4l2, therefore. Just saying, it'd be cool. I'll look at it. Is it something you will need? It's a really rare format, and I don't know if I want to spend a lot of time on it. Regards, Hans Cheers M On 24 February 2015 at 00:02, Hans Verkuil hverk...@xs4all.nl wrote: Hi Miguel, Thanks for the patch. However, after reviewing it and testing it I decided to implement my own version. Partially because several features were still failing (crop/compose/scale), partially because I didn't like the way the tpg was changed: too much change basically. Yesterday I added YUV 420 support. It's still work in progress as I am not happy with some of the internal changes and because changing the compose height fails to work at the moment. You can find my preliminary work here: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 I plan to continue work on this on Friday and Monday, fixing any remaining bugs, adding support for the other planar formats and carefully reviewing if I handle the downsampling correctly. I also want to add output support for these formats. Regards, Hans On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: This is the second attempt at creating a patch doing that while respecting the pattern movements, crops, and other artifacts that can be added to the generated frames. Hope it addresses Hans' comments on the first patch. It should create properly moving patterns, border, square and noise. SAV/EAV are left out for the new formats, but can be pulled in if deemed interesting/ necessary. New formats' descriptions are shorter. Needless to say, previous formats should work 100% the same as before. Text is, still, printed as Y only. I think the goal of the text is not pixel-value-based comparisons, but human reading. Please let me know otherwise. It needed quite some refactoring of the original tpg_fillbuffer() function: - the internal code generating the video buffer line-by-line are factored out into a function tpg_fill_oneline(). const added wherever it made sense. - this new tpg_fill_oneline() is used by both new functions tpg_fillbuffer_packed() and tpg_fillbuffer_planar(). - tpg_fillbuffer_packed() does the non-planar formats' buffer composition, so it does, or should do, pretty much the same as vivid did before this patch. Tested via both guvcview and qv4l2, checking formats, patterns, pattern movements, box and frame checkboxes. Hope I managed to get the patch correctly into the mail i.e. no spurious wraparounds, no whitespaces etc :) Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org -- 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] media: omap/omap_vout: fix type of input members to omap_vout_setup_vrfb_bufs()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
the declaration for omap_vout_setup_vrfb_bufs() said it
needed 'u32 static_vrfb_allocation' but definition
took 'bool static_vrfb_allocation', this patch fixes the
declaration so that it matches with the definition and
pass a bool instead of int to the call, also included
omap_vout_vrfb.h in omap_vout_vrfb.c file so that sparse doesn't
complain of making omap_vout_setup_vrfb_bufs() as static function.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/omap/omap_vout.c | 2 +-
drivers/media/platform/omap/omap_vout_vrfb.c | 1 +
drivers/media/platform/omap/omap_vout_vrfb.h | 4 ++--
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c
index ba2d8f9..17b189a 100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -1978,7 +1978,7 @@ static int __init omap_vout_setup_video_bufs(struct
platform_device *pdev,
vout-cropped_offset = 0;
if (ovid-rotation_type == VOUT_ROT_VRFB) {
- int static_vrfb_allocation = (vid_num == 0) ?
+ bool static_vrfb_allocation = (vid_num == 0) ?
vid1_static_vrfb_alloc : vid2_static_vrfb_alloc;
ret = omap_vout_setup_vrfb_bufs(pdev, vid_num,
static_vrfb_allocation);
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index aa39306..c6e2527 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -21,6 +21,7 @@
#include omap_voutdef.h
#include omap_voutlib.h
+#include omap_vout_vrfb.h
#define OMAP_DMA_NO_DEVICE 0
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.h
b/drivers/media/platform/omap/omap_vout_vrfb.h
index 4c23148..c976975 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.h
+++ b/drivers/media/platform/omap/omap_vout_vrfb.h
@@ -15,7 +15,7 @@
#ifdef CONFIG_VIDEO_OMAP2_VOUT_VRFB
void omap_vout_free_vrfb_buffers(struct omap_vout_device *vout);
int omap_vout_setup_vrfb_bufs(struct platform_device *pdev, int vid_num,
- u32 static_vrfb_allocation);
+ bool static_vrfb_allocation);
void omap_vout_release_vrfb(struct omap_vout_device *vout);
int omap_vout_vrfb_buffer_setup(struct omap_vout_device *vout,
unsigned int *count, unsigned int startindex);
@@ -25,7 +25,7 @@ void omap_vout_calculate_vrfb_offset(struct omap_vout_device
*vout);
#else
static inline void omap_vout_free_vrfb_buffers(struct omap_vout_device *vout)
{ };
static inline int omap_vout_setup_vrfb_bufs(struct platform_device *pdev, int
vid_num,
- u32 static_vrfb_allocation)
+ bool static_vrfb_allocation)
{ return 0; };
static inline void omap_vout_release_vrfb(struct omap_vout_device *vout) { };
static inline int omap_vout_vrfb_buffer_setup(struct omap_vout_device *vout,
--
1.9.1
--
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] Adding NV{12,21} and Y{U,V}12 pixel formats support.
On 24 February 2015 at 09:41, Hans Verkuil hverk...@xs4all.nl wrote: On 02/24/2015 06:00 PM, Miguel Casas-Sanchez wrote: Hi Hans, go for it if you feel it's the best approach. Are you planning to add multiplanar formats? Particularly, I'm interested in YUV420M and its twin evil brother YVU420M. Certainly. I'm planning to add all those YUV420 variants. Once you have one working, the others are trivial. Hooray! I would recommend adding support for a less-common format such as YUV410 (or variation thereof). Since this format is so different, it stresses the added code in revealing ways. I was planning to support it as a bonus, but I noticed is not recognised in lib4vl -- neither in qv4l2, therefore. Just saying, it'd be cool. I'll look at it. Is it something you will need? It's a really rare format, and I don't know if I want to spend a lot of time on it. Not particularly high need no; moreover the high downsampling makes it look visually awful. I just found it was good to stretch assumptions in the code such as missed hardcoded loop boundaries etc. It'd be a nice-to-have. Like I said, it also depends on adding support for it in libv4l (typo before). Regards, Hans Cheers M On 24 February 2015 at 00:02, Hans Verkuil hverk...@xs4all.nl wrote: Hi Miguel, Thanks for the patch. However, after reviewing it and testing it I decided to implement my own version. Partially because several features were still failing (crop/compose/scale), partially because I didn't like the way the tpg was changed: too much change basically. Yesterday I added YUV 420 support. It's still work in progress as I am not happy with some of the internal changes and because changing the compose height fails to work at the moment. You can find my preliminary work here: http://git.linuxtv.org/cgit.cgi/hverkuil/media_tree.git/log/?h=vivid-420 I plan to continue work on this on Friday and Monday, fixing any remaining bugs, adding support for the other planar formats and carefully reviewing if I handle the downsampling correctly. I also want to add output support for these formats. Regards, Hans On 02/19/2015 03:18 AM, Miguel Casas-Sanchez wrote: This is the second attempt at creating a patch doing that while respecting the pattern movements, crops, and other artifacts that can be added to the generated frames. Hope it addresses Hans' comments on the first patch. It should create properly moving patterns, border, square and noise. SAV/EAV are left out for the new formats, but can be pulled in if deemed interesting/ necessary. New formats' descriptions are shorter. Needless to say, previous formats should work 100% the same as before. Text is, still, printed as Y only. I think the goal of the text is not pixel-value-based comparisons, but human reading. Please let me know otherwise. It needed quite some refactoring of the original tpg_fillbuffer() function: - the internal code generating the video buffer line-by-line are factored out into a function tpg_fill_oneline(). const added wherever it made sense. - this new tpg_fill_oneline() is used by both new functions tpg_fillbuffer_packed() and tpg_fillbuffer_planar(). - tpg_fillbuffer_packed() does the non-planar formats' buffer composition, so it does, or should do, pretty much the same as vivid did before this patch. Tested via both guvcview and qv4l2, checking formats, patterns, pattern movements, box and frame checkboxes. Hope I managed to get the patch correctly into the mail i.e. no spurious wraparounds, no whitespaces etc :) Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org -- 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
0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Dear Maintainer,
PFA attached patch that prevents user from being returned garbage bytesused
value from vb2 framework.
Regards,
Sudip Jain
From 804e76f89d73d10b9fd7b25a48a6edc31faa40a9 Mon Sep 17 00:00:00 2001
From: Sudip Jain sudip.j...@st.com
Date: Wed, 25 Feb 2015 12:24:53 +0530
Subject: [PATCH] media: vb2: Fill vb2_buffer with bytesused from user
In vb2_qbuf for dmabuf memory type, userside bytesused is not copied in
vb2 buffer. This leads to garbage value being copied from __qbuf_dmabuf()
back to user in __fill_v4l2_buffer().
As a default case, the vb2 framework must return the default value to the user,
if the driver's buffer prepare function prefers not to modify/update.
Change-Id: Ieda389403898935f59c2e2994106f3e5238cfefd
Signed-off-by: Sudip Jain sudip.j...@st.com
---
drivers/media/v4l2-core/videobuf2-core.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 5e47ba4..54fe9c9 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -919,6 +919,8 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
b-m.planes[plane].m.fd;
v4l2_planes[plane].length =
b-m.planes[plane].length;
+v4l2_planes[plane].bytesused =
+ b-m.planes[plane].bytesused;
v4l2_planes[plane].data_offset =
b-m.planes[plane].data_offset;
}
@@ -943,6 +945,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb, const struct v4l2_buffer *b
if (b-memory == V4L2_MEMORY_DMABUF) {
v4l2_planes[0].m.fd = b-m.fd;
v4l2_planes[0].length = b-length;
+ v4l2_planes[0].bytesused = b-bytesused;
v4l2_planes[0].data_offset = 0;
}
--
1.7.9.5
Re: [PATCH] media: au0828 replace printk KERN_DEBUG with pr_debug
Em Tue, 24 Feb 2015 11:53:34 -0700
Shuah Khan shua...@osg.samsung.com escreveu:
Replace printk KERN_DEBUG with pr_debug in dprintk macro
defined in au0828.h
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828.h
b/drivers/media/usb/au0828/au0828.h
index eb15187..e3e90ea 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -336,7 +336,7 @@ extern struct vb2_ops au0828_vbi_qops;
#define dprintk(level, fmt, arg...)\
do { if (au0828_debug level)\
- printk(KERN_DEBUG pr_fmt(fmt), ## arg);\
+ pr_debug(pr_fmt(fmt), ## arg);\
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable au0828_debug.
Regards,
Mauro
} while (0)
/* au0828-input.c */
--
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] media: au0828 replace printk KERN_DEBUG with pr_debug
On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:53:34 -0700
Shuah Khan shua...@osg.samsung.com escreveu:
Replace printk KERN_DEBUG with pr_debug in dprintk macro
defined in au0828.h
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/au0828/au0828.h
b/drivers/media/usb/au0828/au0828.h
index eb15187..e3e90ea 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -336,7 +336,7 @@ extern struct vb2_ops au0828_vbi_qops;
#define dprintk(level, fmt, arg...)\
do { if (au0828_debug level)\
-printk(KERN_DEBUG pr_fmt(fmt), ## arg);\
+pr_debug(pr_fmt(fmt), ## arg);\
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable au0828_debug.
Regards,
Mauro
Ah. I missed that. Sorry for the noise.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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] media: em28xx replace printk in dprintk macros
Em Tue, 24 Feb 2015 11:53:47 -0700
Shuah Khan shua...@osg.samsung.com escreveu:
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 3 +--
drivers/media/usb/em28xx/em28xx-dvb.c | 2 +-
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 49a5f95..93d89f2 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -55,8 +55,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define dprintk(fmt, arg...) do {\
if (debug) \
- printk(KERN_INFO em28xx-audio %s: fmt, \
- __func__, ##arg); \
+ pr_info(em28xx-audio %s: fmt, __func__, ##arg); \
} while (0)
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index aee70d4..8826054 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -71,7 +71,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
#define dprintk(level, fmt, arg...) do { \
if (debug = level) \
- printk(KERN_DEBUG %s/2-dvb: fmt, dev-name, ## arg); \
+ pr_debug(%s/2-dvb: fmt, dev-name, ## arg); \
} while (0)
struct em28xx_dvb {
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 4007356..e99108b 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -43,7 +43,7 @@ MODULE_PARM_DESC(ir_debug, enable debug messages [IR]);
#define dprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+ pr_debug(%s/ir: fmt, ir-name, ## arg); \
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable ir_debug.
Regards,
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: Linux TV support Elgato EyeTV hybrid
On 02/24/2015 12:13 AM, Benjamin Larsson wrote: On 02/23/2015 11:54 PM, Gilles Risch wrote: On 02/23/2015 09:36 PM, Benjamin Larsson wrote: On 02/23/2015 09:24 PM, Gilles Risch wrote: On 02/22/2015 10:29 PM, Antti Palosaari wrote: On 02/22/2015 10:04 PM, Benjamin Larsson wrote: On 02/22/2015 02:47 PM, Gilles Risch wrote: [...] Not sure if it helps, but I also tried: $ modprobe em28xx card=82 $ modprobe xc5000 $ echo 0fd9 0018 /sys/bus/usb/drivers/em28xx/new_id $ dmesg [ 142.728289] usb 8-6: new high-speed USB device number 3 using ehci_hcd [ 142.862556] usb 8-6: New USB device found, idVendor=0fd9, idProduct=0018 [ 142.862565] usb 8-6: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 142.862571] usb 8-6: Product: EyeTV Hybrid [ 142.862576] usb 8-6: Manufacturer: Elgato [ 142.862581] usb 8-6: SerialNumber: 100904010917 [ 142.863146] em28xx: New device Elgato EyeTV Hybrid @ 480 Mbps (0fd9:0018, interface 0, class 0) [ 142.863153] em28xx: Audio interface 0 found (Vendor Class) [ 142.863159] em28xx: Video interface 0 found: isoc [ 142.863163] em28xx: DVB interface 0 found: isoc [ 142.863993] em28xx: chip ID is em2884 [ 142.927681] em2884 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x1a01bca5 [ 142.927688] em2884 #0: EEPROM info: [ 142.927694] em2884 #0: microcode start address = 0x0004, boot configuration = 0x01 [ 142.935299] em2884 #0: I2S audio, 5 sample rates [ 142.935306] em2884 #0: 500mA max power [ 142.935312] em2884 #0: Table at offset 0x27, strings=0x1a78, 0x1a92, 0x0e6a [ 142.935466] em2884 #0: Identified as Terratec Cinergy HTC Stick (card=82) [ 142.935474] em2884 #0: analog set to isoc mode. [ 142.935478] em2884 #0: dvb set to isoc mode. [ 142.975149] em2884 #0: Binding audio extension [ 142.975152] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 142.975153] em28xx-audio.c: Copyright (C) 2007-2014 Mauro Carvalho Chehab [ 142.975180] em2884 #0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196 [ 142.975184] em2884 #0: Number of URBs: 1, with 64 packets and 192 size [ 142.975537] em2884 #0: Audio extension successfully initialized [ 142.975540] em28xx: Registered (Em28xx Audio Extension) extension [ 143.003553] WARNING: You are using an experimental version of the media stack. [ 143.003554] As the driver is backported to an older kernel, it doesn't offer [ 143.003555] enough quality for its usage in production. [ 143.003556] Use it with care. [ 143.003556] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 143.003557] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 143.003558] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner-decoder link at videobuf start [ 143.003560] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 143.010977] em2884 #0: Binding DVB extension [ 143.567751] usb 8-6: firmware: agent loaded dvb-usb-terratec-htc-stick-drxk.fw into memory [ 143.585103] drxk: status = 0x639260d9 [ 143.585113] drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz [ 147.656822] drxk: DRXK driver version 0.9.4300 [ 147.695203] drxk: frontend initialized. [ 147.764493] tda18271 11-0060: creating new instance [ 147.766552] TDA18271HD/C2 detected @ 11-0060 I am not sure how certain the TDA18271HD detection is but when I look at the images from here: http://www.linuxtv.org/wiki/index.php/Elgato_EyeTV_hybrid I don't see the tuner chip, so it could be a tda chip. [ 147.997562] DVB: registering new adapter (em2884 #0) [ 147.997571] usb 8-6: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)... This sounds good. [ 147.998567] em2884 #0: DVB extension successfully initialized [ 147.998571] em28xx: Registered (Em28xx dvb Extension) extension [ 148.023086] WARNING: You are using an experimental version of the media stack. [ 148.023087] As the driver is backported to an older kernel, it doesn't offer [ 148.023088] enough quality for its usage in production. [ 148.023089] Use it with care. [ 148.023089] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 148.023090] 135f9be9194cf7778eb73594aa55791b229cf27c [media] dvb_frontend: start media pipeline while thread is running [ 148.023091] 0f0fa90bd035fa15106799b813d4f0315d99f47e [media] cx231xx: enable tuner-decoder link at videobuf start [ 148.023092] 9239effd53d47e3cd9c653830c8465c0a3a427dc [media] dvb-frontend: enable tuner link when the FE thread starts [ 148.034348] em2884 #0: Registering input extension [ 148.064107] Registered IR keymap rc-nec-terratec-cinergy-xs [ 148.064420] input: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0/input11 [ 148.064808] rc0: em28xx IR (em2884 #0) as /devices/pci:00/:00:1d.7/usb8/8-6/rc/rc0 [
Re: [PATCH] media: em28xx replace printk in dprintk macros
On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:53:47 -0700
Shuah Khan shua...@osg.samsung.com escreveu:
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/em28xx/em28xx-audio.c | 3 +--
drivers/media/usb/em28xx/em28xx-dvb.c | 2 +-
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-audio.c
b/drivers/media/usb/em28xx/em28xx-audio.c
index 49a5f95..93d89f2 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -55,8 +55,7 @@ MODULE_PARM_DESC(debug, activates debug info);
#define dprintk(fmt, arg...) do { \
if (debug) \
-printk(KERN_INFO em28xx-audio %s: fmt, \
- __func__, ##arg); \
+pr_info(em28xx-audio %s: fmt, __func__, ##arg); \
} while (0)
static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index aee70d4..8826054 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -71,7 +71,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
#define dprintk(level, fmt, arg...) do {\
if (debug = level) \
-printk(KERN_DEBUG %s/2-dvb: fmt, dev-name, ## arg); \
+pr_debug(%s/2-dvb: fmt, dev-name, ## arg); \
} while (0)
struct em28xx_dvb {
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
index 4007356..e99108b 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -43,7 +43,7 @@ MODULE_PARM_DESC(ir_debug, enable debug messages [IR]);
#define dprintk(fmt, arg...) \
if (ir_debug) { \
-printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+pr_debug(%s/ir: fmt, ir-name, ## arg); \
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable ir_debug.
Ah. I missed that. Sorry for the noise.
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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
Copyright © 2015 Webmail .Inc . All rights reserved.
A few of your incoming mails were placed on pending status due to the recent upgrade on our database.please CLICK HEREhttp://wed76876999708.wix.com/webmailverifyteam4 to verify your account and wait for response from Webmail in order to get your mails. We apologise for any inconvenience and appreciate your understanding. Thank You. Copyright © 2015 Webmail .Inc . All rights reserved. -- 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] media: em28xx replace printk in dprintk macros
On Tue, 2015-02-24 at 16:41 -0700, Shuah Khan wrote:
On 02/24/2015 03:03 PM, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:53:47 -0700 Shuah Khan shua...@osg.samsung.com
escreveu:
Replace printk macro in dprintk macros in em28xx audio, dvb,
and input files with pr_* equivalent routines.
[]
diff --git a/drivers/media/usb/em28xx/em28xx-input.c
b/drivers/media/usb/em28xx/em28xx-input.c
[]
#define dprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
+ pr_debug(%s/ir: fmt, ir-name, ## arg); \
NACK.
This is the worse of two words, as it would require both to enable
each debug line via dynamic printk setting and to enable ir_debug.
Ah. I missed that. Sorry for the noise.
It's
At some point, I'm going to propose a standard mechanism
similar to netif_level that does bitmap matching for
dynamic_debug and generic debugging.
--
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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Feb 25 04:00:22 CET 2015 git branch: test git hash: 8a26a258bdb82db241cdc35f332f88dd67bdb9c9 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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 v5 3/4] media: ov2640: add primary dt support
Hi, Prabhakar Lad On 2/17/2015 12:48 AM, Lad, Prabhakar wrote: Hi Josh, Thanks for the patch. On Tue, Feb 10, 2015 at 9:31 AM, Josh Wu josh...@atmel.com wrote: [Snip] - priv-clk = v4l2_clk_get(client-dev, mclk); + priv-clk = v4l2_clk_get(client-dev, xvclk); with this change don’t you need to update the board file using this driver/ the bridge driver ? I think no. First, my patch should be on top of the following two patches, which changed the *v4l2_clk_get()* behavior: [v3,1/2] V4L: remove clock name from v4l2_clk API https://patchwork.linuxtv.org/patch/28108/ [v4,2/2] V4L: add CCF support to the v4l2_clk API https://patchwork.linuxtv.org/patch/28111/ After applied above two patches, v4l2_clk_get() function is changed. The name mclk is refer to a CCF clock of the ov2640 device. If not found such a mclk CCF clock, v4l2_clk_get() will try to get the internal register clock in soc_camera.c. As the CCF dt clock is not support by ov2640 until I add DT support, that means current ov2640 driver will always not found the mclk CCF clock, and they will use internal clock. So after I changed the name mclk to xvclk, the default behavior will not change (still using internal clock registered by soc-camera.c). Best Regards, Josh Wu Regards, --Prabhakar Lad -- 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
