RE: [PATCH 1/2] device: add dma_params-max_segment_count
Hello,
On Thursday, July 19, 2012 6:24 PM Rob Clark wrote:
From: Rob Clark r...@ti.com
For devices which have constraints about maximum number of segments
in an sglist. For example, a device which could only deal with
contiguous buffers would set max_segment_count to 1.
The initial motivation is for devices sharing buffers via dma-buf,
to allow the buffer exporter to know the constraints of other
devices which have attached to the buffer. The dma_mask and fields
in 'struct device_dma_parameters' tell the exporter everything else
that is needed, except whether the importer has constraints about
maximum number of segments.
Signed-off-by: Rob Clark r...@ti.com
Yea, it is a really good idea to add this to struct device_dma_parameters.
We only need to initialize it to '1' in platform startup code for all
devices relevant to buffer sharing.
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/device.h |1 +
include/linux/dma-mapping.h | 16
2 files changed, 17 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 161d962..3813735 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -568,6 +568,7 @@ struct device_dma_parameters {
* sg limitations.
*/
unsigned int max_segment_size;
+ unsigned int max_segment_count;/* zero for unlimited */
unsigned long segment_boundary_mask;
};
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index dfc099e..f380f79 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -111,6 +111,22 @@ static inline unsigned int dma_set_max_seg_size(struct
device *dev,
return -EIO;
}
+static inline unsigned int dma_get_max_seg_count(struct device *dev)
+{
+ return dev-dma_parms ? dev-dma_parms-max_segment_count : 0;
+}
+
+static inline int dma_set_max_seg_count(struct device *dev,
+ unsigned int count)
+{
+ if (dev-dma_parms) {
+ dev-dma_parms-max_segment_count = count;
+ return 0;
+ } else
+ return -EIO;
+}
+
+
static inline unsigned long dma_get_seg_boundary(struct device *dev)
{
return dev-dma_parms ?
--
1.7.9.5
Best regards
--
Marek Szyprowski
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] vivi: remove pointless video_nr++
On Thu July 19 2012 23:15:42 Ezequiel Garcia wrote: On Thu, Jul 19, 2012 at 6:05 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On Thu, Jul 19, 2012 at 5:45 PM, Hans Verkuil hverk...@xs4all.nl wrote: Remove the pointless video_nr++. It doesn't do anything useful and it has the unexpected side-effect of changing the video_nr module option, so cat /sys/module/vivi/parameters/video_nr gives a different value back then what was specified with modprobe. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c index 1e8c4f3..679e329 100644 --- a/drivers/media/video/vivi.c +++ b/drivers/media/video/vivi.c @@ -1330,9 +1330,6 @@ static int __init vivi_create_instance(int inst) /* Now that everything is fine, let's add it to device list */ list_add_tail(dev-vivi_devlist, vivi_devlist); - if (video_nr != -1) - video_nr++; - v4l2_info(dev-v4l2_dev, V4L2 device registered as %s\n, video_device_node_name(vfd)); return 0; -- Hans, I think you forgot to *also* remove the video_nr module parameter. (and, of course, pass a '-1' to video_register_device) Or maybe not, :-) if you want to be able to force video device number. Some people apparently want to force it. I never understood why, but enough people do it so that we can't remove it. Regards, Hans -- 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: mx2_camera: Add YUYV output format.
On 12 July 2012 10:56, Javier Martin javier.mar...@vista-silicon.com wrote:
Add explicit conversions from UYVY and YUYV to YUYV so that
csicr1 configuration can be set properly for each format.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 40
++
1 file changed, 40 insertions(+)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 0f01e7b..2a33bcb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -337,6 +337,34 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
}
},
{
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC |
PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_SWAP16_EN,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
+ PRP_INTR_CH1FC |
PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
.in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
.out_fmt= V4L2_PIX_FMT_YUV420,
.cfg= {
@@ -1146,6 +1174,18 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
}
}
+ if (code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ formats++;
+ if (xlate) {
+ xlate-host_fmt =
+ soc_mbus_get_fmtdesc(V4L2_MBUS_FMT_YUYV8_2X8);
+ xlate-code = code;
+ dev_dbg(dev, Providing host format %s for sensor
code %d\n,
+ xlate-host_fmt-name, code);
+ xlate++;
+ }
+ }
+
/* Generic pass-trough */
formats++;
if (xlate) {
--
1.7.9.5
Any comments on this one?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
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: mx2_camera: Add YUYV output format.
Hi Javier
On Fri, 20 Jul 2012, javier Martin wrote:
On 12 July 2012 10:56, Javier Martin javier.mar...@vista-silicon.com wrote:
Add explicit conversions from UYVY and YUYV to YUYV so that
csicr1 configuration can be set properly for each format.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 40
++
1 file changed, 40 insertions(+)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 0f01e7b..2a33bcb 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -337,6 +337,34 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
}
},
{
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR
|
+ PRP_INTR_CH1FC |
PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_SWAP16_EN,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUYV,
+ .cfg= {
+ .channel= 1,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH1_OUT_YUV422,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .ch1_pixel = 0x62000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR
|
+ PRP_INTR_CH1FC |
PRP_INTR_LBOVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
.in_fmt = V4L2_MBUS_FMT_YUYV8_2X8,
.out_fmt= V4L2_PIX_FMT_YUV420,
.cfg= {
@@ -1146,6 +1174,18 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
}
}
+ if (code == V4L2_MBUS_FMT_UYVY8_2X8) {
+ formats++;
+ if (xlate) {
+ xlate-host_fmt =
+
soc_mbus_get_fmtdesc(V4L2_MBUS_FMT_YUYV8_2X8);
+ xlate-code = code;
+ dev_dbg(dev, Providing host format %s for sensor
code %d\n,
+ xlate-host_fmt-name, code);
+ xlate++;
+ }
+ }
+
/* Generic pass-trough */
formats++;
if (xlate) {
--
1.7.9.5
Any comments on this one?
Thanks for the reminder, but in this specific case I haven't
forgottne:-) I'm processing my v4l patch queue ATM, will have a closer
look at this and other your patches, will write back if I have any
objections. I hope I won't - I'm leaving for a week-long holiday tomorrow,
so, I hope to push my queue today.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: Supporting 3D formats in V4L2
On Fri July 20 2012 07:23:32 Soby Mathew wrote: Hi Hans, I think your solution is appropriate. I agree to your suggestions. Regarding the 'active space' issue for 3D formats, I was studying the currently the v4l2_bt_timings structure. The Vtotal is calculated for 2D timings as : tot_height = height + vfrontporch + vsync + vbackporch + il_vfrontporch + il_vsync + il_vbackporch In case of 3D, the Vtotal would be dependent on the 3D format. No, as I understand it active_space is just part of the active video. So the timings struct is fine, it's just that the height parameter for e.g. 720p in frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height of the frame that will have to be DMAed from/to the receiver/transmitter. I think the only thing that needs to be done is that the appropriate timings are added to linux/v4l2-dv-timings.h. Regards, Hans For FRAME PACK progressive tot_height = height + active_space + vfrontporch + vsync + vbackporch FRAME PACK interlace tot_height = height + active_space1 + active_space2 + vfrontporch + vsync + vbackporch FIELD_ALTERNATIVE tot_height = height + active_space1 + active_space2 + vfrontporch1 + vfrontporch2+ vsync1 + vsync2 + vbackporch1 + vbackporch2 All the other 3D formats would fall into one of the categories above. Either v4l2_bt_timings structure has to be expanded to accommodate for 3D timings, or a new structure can be defined for the same. Best Regards Soby Mathew On Thu, Jul 19, 2012 at 7:36 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu 19 July 2012 15:41:07 Hans Verkuil wrote: Hi Soby! On Thu 19 July 2012 14:18:13 Soby Mathew wrote: Hi everyone, Currently there is limitation in v4l2 for specifying the 3D formats . In HDMI 1.4 standard, the following 3D formats are specified: I think that this is ideal for adding to enum v4l2_field. I've made some proposals below: 1. FRAME_PACK, V4L2_FIELD_3D_FRAME_PACK (progressive) V4L2_FIELD_3D_FRAME_PACK_TB (interlaced, odd == top comes first) BTW, I'm not really sure at the moment how to handle the 'active space'. I guess the application will have to use the DV_TIMINGS ioctls to discover the vertical blanking size and use that to interpret the captured data. We would also have to add new 3D timings to linux/v4l2-dv-timings.h. Regards, Hans 2. FIELD_ALTERNATIVE, V4L2_FIELD_3D_FIELD_ALTERNATIVE 3. LINE_ALTERNATIVE, V4L2_FIELD_3D_LINE_ALTERNATIVE 4. SIDE BY SIDE FULL, V4L2_FIELD_3D_SBS_FULL 5. SIDE BY SIDE HALF, V4L2_FIELD_3D_SBS_HALF 6. LEFT + DEPTH, V4L2_FIELD_3D_L_DEPTH 7. LEFT + DEPTH + GRAPHICS + GRAPHICS-DEPTH, V4L2_FIELD_3D_L_DEPTH_GFX_DEPTH 8. TOP AND BOTTOM V4L2_FIELD_3D_TAB You would also need defines that describe which field is received for the field alternative mode (it's put in struct v4l2_buffer): V4L2_FIELD_3D_LEFT_TOP V4L2_FIELD_3D_LEFT_BOTTOM V4L2_FIELD_3D_RIGHT_TOP V4L2_FIELD_3D_RIGHT_BOTTOM In addition for some of the formats like Side-by-side-half there are some additional metadata (like type of horizontal sub-sampling) A control seems to be the most appropriate method of exposing the horizontal subsampling. and parallax information which may be required for programming the display processing pipeline properly. This would be a new ioctl, but I think this should only be implemented if someone can actually test it with real hardware. The same is true for the more exotic 3D formats above. It seems SBS is by far the most common format. I am not very sure on how to expose this to the userspace. This is an inherent property of video signal , hence it would be appropriate to have an additional field in v4l_format to specify 3D format. Currently this is a requirement for HDMI 1.4 Rx / Tx but in the future it would be applicable to broadcast sources also. In our implementation we have temporarily defined a Private Control to expose this . Please let me know of your suggestions . I hope this helps! Regards, Hans -- 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 -- 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: [RFC PATCH 19/26] soc_camera: remove V4L2_FL_LOCK_ALL_FOPS
Hi Hans
Thanks for the patch. I guess, you'll want to pull it via your queue. Let
me know if for some reason you'd prefer me to take it.
On Sun, 24 Jun 2012, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Add proper locking to the file operations, allowing for the removal
of the V4L2_FL_LOCK_ALL_FOPS flag.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
drivers/media/video/soc_camera.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 0421bf9..368b6fc 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -507,9 +507,12 @@ static int soc_camera_open(struct file *file)
ici = to_soc_camera_host(icd-parent);
+ if (mutex_lock_interruptible(icd-video_lock))
+ return -ERESTARTSYS;
if (!try_module_get(ici-ops-owner)) {
dev_err(icd-pdev, Couldn't lock capture bus driver.\n);
- return -EINVAL;
+ ret = -EINVAL;
+ goto emodule;
}
icd-use_count++;
@@ -570,6 +573,7 @@ static int soc_camera_open(struct file *file)
}
v4l2_ctrl_handler_setup(icd-ctrl_handler);
}
+ mutex_unlock(icd-video_lock);
file-private_data = icd;
dev_dbg(icd-pdev, camera device open\n);
@@ -590,6 +594,8 @@ epower:
eiciadd:
icd-use_count--;
module_put(ici-ops-owner);
+emodule:
+ mutex_unlock(icd-video_lock);
return ret;
}
@@ -599,6 +605,7 @@ static int soc_camera_close(struct file *file)
struct soc_camera_device *icd = file-private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ mutex_lock(icd-video_lock);
icd-use_count--;
if (!icd-use_count) {
struct soc_camera_link *icl = to_soc_camera_link(icd);
@@ -615,6 +622,7 @@ static int soc_camera_close(struct file *file)
if (icd-streamer == file)
icd-streamer = NULL;
+ mutex_unlock(icd-video_lock);
module_put(ici-ops-owner);
@@ -645,10 +653,13 @@ static int soc_camera_mmap(struct file *file, struct
vm_area_struct *vma)
if (icd-streamer != file)
return -EBUSY;
+ if (mutex_lock_interruptible(icd-video_lock))
+ return -ERESTARTSYS;
if (ici-ops-init_videobuf)
err = videobuf_mmap_mapper(icd-vb_vidq, vma);
else
err = vb2_mmap(icd-vb2_vidq, vma);
+ mutex_unlock(icd-video_lock);
dev_dbg(icd-pdev, vma start=0x%08lx, size=%ld, ret=%d\n,
(unsigned long)vma-vm_start,
@@ -662,16 +673,18 @@ static unsigned int soc_camera_poll(struct file *file,
poll_table *pt)
{
struct soc_camera_device *icd = file-private_data;
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ unsigned res = POLLERR;
if (icd-streamer != file)
- return -EBUSY;
-
- if (ici-ops-init_videobuf list_empty(icd-vb_vidq.stream)) {
- dev_err(icd-pdev, Trying to poll with no queued buffers!\n);
return POLLERR;
- }
- return ici-ops-poll(file, pt);
+ mutex_lock(icd-video_lock);
+ if (ici-ops-init_videobuf list_empty(icd-vb_vidq.stream))
+ dev_err(icd-pdev, Trying to poll with no queued buffers!\n);
+ else
+ res = ici-ops-poll(file, pt);
+ mutex_unlock(icd-video_lock);
+ return res;
}
void soc_camera_lock(struct vb2_queue *vq)
@@ -1432,10 +1445,6 @@ static int video_dev_create(struct soc_camera_device
*icd)
vdev-tvnorms = V4L2_STD_UNKNOWN;
vdev-ctrl_handler = icd-ctrl_handler;
vdev-lock = icd-video_lock;
- /* Locking in file operations other than ioctl should be done
-by the driver, not the V4L2 core.
-This driver needs auditing so that this flag can be removed. */
- set_bit(V4L2_FL_LOCK_ALL_FOPS, vdev-flags);
icd-vdev = vdev;
--
1.7.10
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] media: coda: Add driver for Coda video codec.
On Fri July 20 2012 11:25:05 javier Martin wrote: On 19 July 2012 14:14, Hans Verkuil hverk...@xs4all.nl wrote: Hi Javier, Can you run v4l2-compliance? I have updated it today so that it is able to handle m2m devices. It will find at least one problem since you didn't set bus_info in querycap :-) That's true but in the specification says that If no such information is available the field may simply count the devices controlled by the driver, or contain the empty string (bus_info[0] = 0) [1]. What should I put in there anyway? My device is memory mapped through the AHB bus. Should I just write ahb? v4l2-compliance is often more strict than the spec, and this is one such case. It should be possible to use bus_info as a unique identifier of the device, and an empty string doesn't do that. In platform drivers like this you can just fill in the same value as was placed in the card field. I've put this on the list of API items to discuss during the upcoming V4L2 workshop. Regards, Hans [1] http://v4l2spec.bytesex.org/spec/r13105.htm You will also see that it complains about VIDIOC_G_PARM. That's fixed by applying this patch: http://www.mail-archive.com/linux-media@vger.kernel.org/msg49271.html That patch is part of a patch series that fixes mem2mem_testdev so that v4l2-compliance runs without errors. -- 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: Problems with Asus My Cinema-U3000Hybrid tuner
On 20-07-12 11:01, H. Cristiano Alves Machado wrote: 2012/7/20 Oliver Schinagl oliver+l...@schinagl.nl: I did do see those already. Well if you have never seen it properly work in Linux, there may be a few things to try. The easiest is an older version of ubuntu for example. DIB7000 based devices are supported for quite some time. 10.04 was an LTS release, best start with that one to test. The only other thing I could think of, is that maybe your firmware is different. It currently loads 1.20; Maybe try extracting the firmware from your windows driver and try that first. Other then that, I really have no idea :( Hi Oliver and thanks for the care you've shown up until now! I really appreciate that. I will try to follow your suggestions. I will try to install previous version of ubuntu (10.04 LTS first) and then the second way, adapt windows'. I found that on October 13th 2008 Mauro commited support for the Asus My Cinema U3000 Hybrid. Mauro is currently on vacation so your best bet would have been him. I also see that Albert Comera and Patrick Boettcher signed off on this too, so they should know the details on why it's not working. I've noticed that my PCI DVB-T card works quite some better in kaffeine then in VDR. Also me-tv works reasonably well (when not using a CAM). Try various applications in your testing enviroment, it may be application related. Unfortunately I can not help you anymore then that. I have some doubts about extracting windows drivers and applying them here. How can I go about doing that? If you (or someone else can give some pointers I will try to follow them) Besides I will also look (google) around to see how that can be done. Best regards! -- 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: [RFCv3 PATCH 00/33] Core and vb2 enhancements
Hi Hans On Thu, 28 Jun 2012, Hans Verkuil wrote: Hi all, This is the third version of this patch series. The first version is here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg47558.html Nice to see an owner concept added to the vb2. In soc-camera we're also using a concept of a streamer user. This is the user, that first calls one of data-flow related ioctl()s, like s_fmt(), streamon(), streamoff() and all buffer queue-related operations. I realise that this your patch-set only deals with the buffer queue, but in principle, do you think it would make sense to use such a concept globally? We probably don't want to let other processes mess with any of the above calls as long as one process is actively managing the streaming. Thanks Guennadi Changes since RFCv2: - Rebased to staging/for_v3.6. - Incorporated Laurent's review comments in patch 22: vb2-core: refactor reqbufs/create_bufs. Changes since RFCv1: - Incorporated all review comments from Hans de Goede and Laurent Pinchart (Thanks!) except for splitting off the vb2 helper functions into a separate source. I decided to keep it together with the vb2-core code. - Improved commit messages, added more comments to the code. - The owner filehandle and the queue lock are both moved to struct vb2_queue since these are a property of the queue. - The debug function has a new 'write_only' boolean: some debug functions can only print a subset of the arguments if it is called by an _IOW ioctl. The previous patch series split this up into two functions. Handling the debug function for a write-only ioctl is annoying at the moment: you have to print the arguments before calling the ioctl since the ioctl can overwrite arguments. I am considering changing the op argument to const for such ioctls and see if any driver is actually messing around with the contents of such structs. If we can guarantee that drivers do not change the argument struct, then we can simplify the debug code. - All debugging is now KERN_DEBUG instead of KERN_INFO. I still have one outstanding question: should anyone be able to call mmap() or only the owner of the vb2 queue? Right now anyone can call mmap(). Comments are welcome, but if I don't see any in the next 2-3 days, then I'll make a pull request for this on Sunday. Regards, Hans --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/2] v4l: Add factory register values form S5K4ECGX sensor
Opps, the previous email has a HTML part, so resending. Hi Sylwester Thank for the review. On 19 July 2012 20:40, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi Sangwook, On 07/19/2012 02:14 PM, Sangwook Lee wrote: Add factory default settings for S5K4ECGX sensor registers. I copied them from the reference code of Samsung S.LSI. I'm pretty sure we can do better than that. I've started S5K6AAFX sensor driver development with similar set of write-only register address/value arrays, that stored mainly register default values after the device reset, or were configuring presets that were never used. If you lok at the s5k6aa driver, you'll find only one relatively small array of register values for the analog processing block settings. It's true that I had to reverse engineer a couple of things, but I also had a relatively good datasheet for the sensor. Yes, I already saw analog settings in s5k6aa. Compared to s5k6aa, I couldn't also understand why the sensor has lots of initial values. Is it because s5k4ecgx is slightly more complicated than s5k6aa ? According to comments from the reference code, they do not recommend any changes of these settings. Yes, but it doesn't mean cannot convert, at least part of, those ugly tables into function calls. Yes, the biggest table seems to be one time for boot-up, at least I need to remove one more macro (token) Have you tried to contact Samsung S.LSI for a datasheet that would contain better registers' description ? As you might know, there is a limitation for me to get those information. :-) Instead, if I look into the source code of Google Nexus S which uses s5k4ecgx, https://android.googlesource.com/kernel/samsung.git I can discover that both Google and Samsung are using the same huge table just for initial settings from the sensor booting-up. I added the original author of this sensor driver. Hopes he might add some comments :-) Thanks Sangwook -- Thanks, Sylwester -- 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: [RFCv3 PATCH 00/33] Core and vb2 enhancements
On Fri July 20 2012 11:55:31 Guennadi Liakhovetski wrote: Hi Hans On Thu, 28 Jun 2012, Hans Verkuil wrote: Hi all, This is the third version of this patch series. The first version is here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg47558.html Nice to see an owner concept added to the vb2. In soc-camera we're also using a concept of a streamer user. This is the user, that first calls one of data-flow related ioctl()s, like s_fmt(), streamon(), streamoff() and all buffer queue-related operations. I realise that this your patch-set only deals with the buffer queue, but in principle, do you think it would make sense to use such a concept globally? We probably don't want to let other processes mess with any of the above calls as long as one process is actively managing the streaming. I've thought about that, but decided not to do that. It is often hardware dependent whether certain parameters can be changed while streaming. While it would be chaos if other filehandles can do e.g. DQBUF at the same time, it is often quite OK to make other changes on the fly. For example, using v4l2-ctl to change the frequency while a recording is in progress. In general V4L2 is very permissive and it has the G/S_PRIORITY mechanism to allow apps to really lock down their access. It would be great if soc_camera can switch to using struct v4l2_fh to represent filehandles: that would make it trivial to add prio support and very useful for control events as well. Regards, Hans Thanks Guennadi Changes since RFCv2: - Rebased to staging/for_v3.6. - Incorporated Laurent's review comments in patch 22: vb2-core: refactor reqbufs/create_bufs. Changes since RFCv1: - Incorporated all review comments from Hans de Goede and Laurent Pinchart (Thanks!) except for splitting off the vb2 helper functions into a separate source. I decided to keep it together with the vb2-core code. - Improved commit messages, added more comments to the code. - The owner filehandle and the queue lock are both moved to struct vb2_queue since these are a property of the queue. - The debug function has a new 'write_only' boolean: some debug functions can only print a subset of the arguments if it is called by an _IOW ioctl. The previous patch series split this up into two functions. Handling the debug function for a write-only ioctl is annoying at the moment: you have to print the arguments before calling the ioctl since the ioctl can overwrite arguments. I am considering changing the op argument to const for such ioctls and see if any driver is actually messing around with the contents of such structs. If we can guarantee that drivers do not change the argument struct, then we can simplify the debug code. - All debugging is now KERN_DEBUG instead of KERN_INFO. I still have one outstanding question: should anyone be able to call mmap() or only the owner of the vb2 queue? Right now anyone can call mmap(). Comments are welcome, but if I don't see any in the next 2-3 days, then I'll make a pull request for this on Sunday. Regards, Hans --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFCv3 PATCH 00/33] Core and vb2 enhancements
Hi Guennadi, On Friday 20 July 2012 11:55:31 Guennadi Liakhovetski wrote: On Thu, 28 Jun 2012, Hans Verkuil wrote: Hi all, This is the third version of this patch series. The first version is here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg47558.html Nice to see an owner concept added to the vb2. In soc-camera we're also using a concept of a streamer user. This is the user, that first calls one of data-flow related ioctl()s, like s_fmt(), streamon(), streamoff() and all buffer queue-related operations. I realise that this your patch-set only deals with the buffer queue, but in principle, do you think it would make sense to use such a concept globally? We probably don't want to let other processes mess with any of the above calls as long as one process is actively managing the streaming. I think that's a good idea (the uvcvideo driver implements something similar), but I'm not sure whether the spec currently describes the expected behaviour and relationships between ioctls correctly. That could be a topic for the V4L2 ambiguities discussions during KS. Such a a mechanism should not be imposed on drivers though, as it probably wouldn't cover all use cases (think about mem-to-mem drivers where the format is per file-handle for instance). -- 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
[patch] [media] dib8000: move dereference after check for NULL
My static checker complains that we dereference state inside the call
to fft_to_mode() before checking for NULL. The comments say that it is
possible for state to be NULL so I have moved the dereference after
the check.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/dvb/frontends/dib8000.c
b/drivers/media/dvb/frontends/dib8000.c
index 9ca34f4..1f3bcb5 100644
--- a/drivers/media/dvb/frontends/dib8000.c
+++ b/drivers/media/dvb/frontends/dib8000.c
@@ -2680,12 +2680,14 @@ static int dib8000_tune(struct dvb_frontend *fe)
{
struct dib8000_state *state = fe-demodulator_priv;
int ret = 0;
- u16 lock, value, mode = fft_to_mode(state);
+ u16 lock, value, mode;
// we are already tuned - just resuming from suspend
if (state == NULL)
return -EINVAL;
+ mode = fft_to_mode(state);
+
dib8000_set_bandwidth(fe, state-fe[0]-dtv_property_cache.bandwidth_hz
/ 1000);
dib8000_set_channel(state, 0, 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] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
Hi Javier
Thanks for the patch
On Mon, 9 Jul 2012, javier Martin wrote:
On 9 July 2012 10:07, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:46:03AM +0200, javier Martin wrote:
On 9 July 2012 09:43, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi
clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
Baruch,
could you tell us what are the clocks needed by i.MX25?
I just had a look and the i.MX25 it needs three clocks: ipg, ahb and
peripheral clock. So this is broken anyway and should probably be fixed
seperately, that is:
- provide dummy clocks for the csi clocks on i.MX27
- clk_get ipg, ahb and peripheral clocks on all SoCs
- clk_get emma clocks on i.MX27 only
As said, this is a separate topic, so your original patch should be fine
for now.
Well, sorry, but I don't think I can share this.
1. it touches two areas - arch/ and drivers/ which isnÄt a good thing and
should be avoided wherever possible
2. it addresses several problems: (a) missing name for ahb camera clock,
(b) wrong device and connection names for emma clocks, (c) missing
_(un)prepare suffixes in clock API
3. it makes a possibly broken i.MX25 even more broken
IIUC, mx2-camera is broken on i.MX27 in current next because of wrong
clock entries, right? So, we don't have to be bothered not to break
bisection - it is already broken. Then we can clean up the problems
separately under arch/ and drivers/.
So, would it be possible to split this into 3 parts:
(a) arch - fix clocks
(b) media - fix clocks on i.MX27 _without_ breaking it even further on
i.MX25. If we think i.MX25 support is already broken, let's schedule
its removal and remove properly, or add BROKEN to Kconfig, when built
on i.MX25. In your patch this would mean just adding an else to your
if (cpu_is_mx27()) statement and moving the current clk_get() there
(c) add _(un)prepare.
Since these are fixes, I won't wait too long for these. If you don't
resubmit them today, they'll go in after 3.6-rc1.
Thanks
Guennadi
OK, thanks for your interest.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
On Thu, 12 Jul 2012, Javier Martin wrote: These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin javier.mar...@vista-silicon.com For the ARM tree: Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- arch/arm/plat-mxc/include/mach/mx2_cam.h |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h b/arch/arm/plat-mxc/include/mach/mx2_cam.h index 3c080a3..7ded6f1 100644 --- a/arch/arm/plat-mxc/include/mach/mx2_cam.h +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h @@ -23,7 +23,6 @@ #ifndef __MACH_MX2_CAM_H_ #define __MACH_MX2_CAM_H_ -#define MX2_CAMERA_SWAP16(1 0) #define MX2_CAMERA_EXT_VSYNC (1 1) #define MX2_CAMERA_CCIR (1 2) #define MX2_CAMERA_CCIR_INTERLACE(1 3) @@ -31,7 +30,6 @@ #define MX2_CAMERA_GATED_CLOCK (1 5) #define MX2_CAMERA_INV_DATA (1 6) #define MX2_CAMERA_PCLK_SAMPLE_RISING(1 7) -#define MX2_CAMERA_PACK_DIR_MSB (1 8) /** * struct mx2_camera_platform_data - optional platform data for mx2_camera -- 1.7.9.5 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v3 8/9] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
On Wed, 18 Jul 2012, Laurent Pinchart wrote:
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use soc-camera-aware clients.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c |9 +++
drivers/media/video/mt9m001.c |9 +++
drivers/media/video/mt9m111.c | 52 +-
drivers/media/video/mt9t031.c | 11 +++-
drivers/media/video/mt9t112.c |9 +++
drivers/media/video/mt9v022.c |9 +++
drivers/media/video/ov2640.c |9 +++
drivers/media/video/ov5642.c | 10 +++-
drivers/media/video/ov6650.c |9 +++
drivers/media/video/ov772x.c |9 +++
drivers/media/video/ov9640.c | 10 +++-
drivers/media/video/ov9740.c | 24 ++---
drivers/media/video/rj54n1cb0c.c |9 +++
drivers/media/video/soc_camera.c | 82
+
drivers/media/video/soc_camera_platform.c | 11 -
drivers/media/video/tw9910.c |9 +++
include/media/soc_camera.h| 10
17 files changed, 229 insertions(+), 62 deletions(-)
[snip]
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 7bf21da..6abeae2 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -50,43 +50,30 @@ static LIST_HEAD(hosts);
static LIST_HEAD(devices);
static DEFINE_MUTEX(list_lock); /* Protects the list of hosts */
-static int soc_camera_power_on(struct soc_camera_device *icd,
-struct soc_camera_link *icl)
+int soc_camera_power_on(struct device *dev, struct soc_camera_link *icl)
{
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
int ret = regulator_bulk_enable(icl-num_regulators,
icl-regulators);
if (ret 0) {
- dev_err(icd-pdev, Cannot enable regulators\n);
+ dev_err(dev, Cannot enable regulators\n);
return ret;
}
if (icl-power) {
- ret = icl-power(icd-control, 1);
+ ret = icl-power(dev, 1);
if (ret 0) {
- dev_err(icd-pdev,
+ dev_err(dev,
Platform failed to power-on the camera.\n);
- goto elinkpwr;
+ regulator_bulk_disable(icl-num_regulators,
+icl-regulators);
}
}
- ret = v4l2_subdev_call(sd, core, s_power, 1);
- if (ret 0 ret != -ENOIOCTLCMD ret != -ENODEV)
- goto esdpwr;
-
- return 0;
-
-esdpwr:
- if (icl-power)
- icl-power(icd-control, 0);
-elinkpwr:
- regulator_bulk_disable(icl-num_regulators,
-icl-regulators);
return ret;
}
+EXPORT_SYMBOL(soc_camera_power_on);
-static int soc_camera_power_off(struct soc_camera_device *icd,
- struct soc_camera_link *icl)
+int soc_camera_power_off(struct device *dev, struct soc_camera_link *icl)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
int ret = 0;
Oops... Looks like this part went missing during the merge:
- v4l2_subdev_call(sd, core, s_power, 0);
-
Could you please fix and resend just this patch?
Thanks
Guennadi
@@ -94,14 +81,14 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
err = v4l2_subdev_call(sd, core, s_power, 0);
if (err 0 err != -ENOIOCTLCMD err != -ENODEV) {
- dev_err(icd-pdev, Subdev failed to power-off the camera.\n);
+ dev_err(dev, Subdev failed to power-off the camera.\n);
ret = err;
}
if (icl-power) {
- err = icl-power(icd-control, 0);
+ err = icl-power(dev, 0);
if (err 0) {
- dev_err(icd-pdev,
+ dev_err(dev,
Platform failed to power-off the camera.\n);
ret = ret ? : err;
}
@@ -110,12 +97,37 @@ static int soc_camera_power_off(struct soc_camera_device
*icd,
err = regulator_bulk_disable(icl-num_regulators,
icl-regulators);
if (err 0) {
- dev_err(icd-pdev, Cannot disable regulators\n);
+ dev_err(dev, Cannot disable regulators\n);
ret = ret ? : err;
}
return ret;
}
+EXPORT_SYMBOL(soc_camera_power_off);
+
+static int
Re: [PATCH] [v3] i.MX27: Fix emma-prp clocks in mx2_camera.c
On 20 July 2012 13:19, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
Hi Javier
Thanks for the patch
On Mon, 9 Jul 2012, javier Martin wrote:
On 9 July 2012 10:07, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:46:03AM +0200, javier Martin wrote:
On 9 July 2012 09:43, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Jul 09, 2012 at 09:37:25AM +0200, javier Martin wrote:
On 9 July 2012 09:28, Sascha Hauer s.ha...@pengutronix.de wrote:
On Fri, Jul 06, 2012 at 12:56:02PM +0200, Javier Martin wrote:
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
---
Enable clocks only for i.MX27.
Indeed,
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi)) {
+ dev_err(pdev-dev, Could not get csi
clock\n);
+ err = PTR_ERR(pcdev-clk_csi);
+ goto exit_kfree;
+ }
but why? Now the i.MX25 won't get a clock anymore.
What are the clocks needed by i.MX25? csi only?
By the way, is anybody using this driver with i.MX25?
It seems Baruch (added to Cc) has used it on an i.MX25.
Baruch,
could you tell us what are the clocks needed by i.MX25?
I just had a look and the i.MX25 it needs three clocks: ipg, ahb and
peripheral clock. So this is broken anyway and should probably be fixed
seperately, that is:
- provide dummy clocks for the csi clocks on i.MX27
- clk_get ipg, ahb and peripheral clocks on all SoCs
- clk_get emma clocks on i.MX27 only
As said, this is a separate topic, so your original patch should be fine
for now.
Well, sorry, but I don't think I can share this.
1. it touches two areas - arch/ and drivers/ which isnÄt a good thing and
should be avoided wherever possible
2. it addresses several problems: (a) missing name for ahb camera clock,
(b) wrong device and connection names for emma clocks, (c) missing
_(un)prepare suffixes in clock API
3. it makes a possibly broken i.MX25 even more broken
IIUC, mx2-camera is broken on i.MX27 in current next because of wrong
clock entries, right? So, we don't have to be bothered not to break
bisection - it is already broken. Then we can clean up the problems
separately under arch/ and drivers/.
So, would it be possible to split this into 3 parts:
(a) arch - fix clocks
(b) media - fix clocks on i.MX27 _without_ breaking it even further on
i.MX25. If we think i.MX25 support is already broken, let's schedule
its removal and remove properly, or add BROKEN to Kconfig, when built
on i.MX25. In your patch this would mean just adding an else to your
if (cpu_is_mx27()) statement and moving the current clk_get() there
(c) add _(un)prepare.
Since these are fixes, I won't wait too long for these. If you don't
resubmit them today, they'll go in after 3.6-rc1.
Thanks
Guennadi
OK, thanks for your interest.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
Hi Guennadi,
thanks for your review.
I could agree with some of your reasons for not accepting this patch.
Specially (1) and (2).
As regards of reason (3), i.MX25 has been broken for months and I
refuse that a broken chip that no known board in the mainline uses is
constantly slowing the development process.
Furthermore, I sent v3 of this patch 11 days ago. I know you are a
busy developer but, honestly, it doesn't seem fair that, having sent
the patch with plenty of time I am now given only this little time to
fix it. I'm out of the office right now and I won't come back until
monday. Couldn't you either make an exception and accept the path or
give me until monday in the morning to send the new version?
Alternatively, Sascha, Fabio or any other i.MX27 user could send it
too if they have the time.
Otherwise, as you stated it'll have to wait to 3.6-rc1. So 3.5 will be
broken for i.MX27.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
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 v4] soc-camera: Add and use soc_camera_power_[on|off]() helper functions
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use soc-camera-aware clients.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/imx074.c |9 +++
drivers/media/video/mt9m001.c |9 +++
drivers/media/video/mt9m111.c | 52 -
drivers/media/video/mt9t031.c | 11 +++-
drivers/media/video/mt9t112.c |9 +++
drivers/media/video/mt9v022.c |9 +++
drivers/media/video/ov2640.c |9 +++
drivers/media/video/ov5642.c | 10 ++-
drivers/media/video/ov6650.c |9 +++
drivers/media/video/ov772x.c |9 +++
drivers/media/video/ov9640.c | 10 +++-
drivers/media/video/ov9740.c | 24 ++--
drivers/media/video/rj54n1cb0c.c |9 +++
drivers/media/video/soc_camera.c | 88 -
drivers/media/video/soc_camera_platform.c | 11 +++-
drivers/media/video/tw9910.c |9 +++
include/media/soc_camera.h| 10 +++
17 files changed, 229 insertions(+), 68 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 351e9ba..ade1987 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -268,6 +268,14 @@ static int imx074_g_chip_ident(struct v4l2_subdev *sd,
return 0;
}
+static int imx074_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int imx074_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
@@ -292,6 +300,7 @@ static struct v4l2_subdev_video_ops imx074_subdev_video_ops
= {
static struct v4l2_subdev_core_ops imx074_subdev_core_ops = {
.g_chip_ident = imx074_g_chip_ident,
+ .s_power= imx074_s_power,
};
static struct v4l2_subdev_ops imx074_subdev_ops = {
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 00583f5..cd71230 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -377,6 +377,14 @@ static int mt9m001_s_register(struct v4l2_subdev *sd,
}
#endif
+static int mt9m001_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ return soc_camera_set_power(client-dev, icl, on);
+}
+
static int mt9m001_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
{
struct mt9m001 *mt9m001 = container_of(ctrl-handler,
@@ -566,6 +574,7 @@ static struct v4l2_subdev_core_ops mt9m001_subdev_core_ops
= {
.g_register = mt9m001_g_register,
.s_register = mt9m001_s_register,
#endif
+ .s_power= mt9m001_s_power,
};
static int mt9m001_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 863d722..e555f77 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -831,10 +831,37 @@ static int mt9m111_video_probe(struct i2c_client *client)
return v4l2_ctrl_handler_setup(mt9m111-hdl);
}
+static int mt9m111_power_on(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+ int ret;
+
+ ret = soc_camera_power_on(client-dev, icl);
+ if (ret 0)
+ return ret;
+
+ ret = mt9m111_resume(mt9m111);
+ if (ret 0) {
+ dev_err(client-dev, Failed to resume the sensor: %d\n, ret);
+ soc_camera_power_off(client-dev, icl);
+ }
+
+ return ret;
+}
+
+static void mt9m111_power_off(struct mt9m111 *mt9m111)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9m111-subdev);
+ struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
+
+ mt9m111_suspend(mt9m111);
+ soc_camera_power_off(client-dev, icl);
+}
+
static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
{
struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
int ret = 0;
mutex_lock(mt9m111-power_lock);
@@ -844,23 +871,18 @@ static int mt9m111_s_power(struct v4l2_subdev *sd, int on)
* update the power state.
*/
if (mt9m111-power_count == !on) {
- if (on) {
- ret = mt9m111_resume(mt9m111);
-
[PATCH for 3.6] v4l: fix copy/paste typo in vb2_reqbufs comment
Signed-off-by: Nicolas Thery nicolas.th...@st.com --- diff --git a/drivers/media/video/videobuf2-core.c b/drivers/media/video/videobuf2-core.c index 4e0290a..268c7dd 100644 --- a/drivers/media/video/videobuf2-core.c +++ b/drivers/media/video/videobuf2-core.c @@ -715,8 +715,8 @@ static int __create_bufs(struct vb2_queue *q, struct v4l2_create_buffers *create } /** - * vb2_reqbufs() - Wrapper for __reqbufs() that also verifies the memory and - * type values. + * vb2_create_bufs() - Wrapper for __create_bufs() that also verifies the + * memory and type values. * @q: videobuf2 queue * @create:creation parameters, passed from userspace to vidioc_create_bufs * handler in driver-- 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
Terratec Cinergy XS 0ccd:0042 (em28xx): Tuning Problem Analog
Hi, I have tuning problem for some analog channels with the Terratec Cinergy XS 0ccd:0042. This card is unable to tune into some channels. I have another version of this hardware with the ID's 0ccd:005e. Interestingly, this Hardware-Version tunes without any problems all available channels. Some channels are not found, but this seems to be not really correlated with the frequency, although many of the not found channels are at lower frequencies (PAL-BG, channel-list is europe-west): 0ccd:005e 00cd:0042 E6 (182.25 MHz): ???E6 (182.25 MHz): no station E7 (189.25 MHz): ???E7 (189.25 MHz): no station E8 (196.25 MHz): ???E8 (196.25 MHz): no station E9 (203.25 MHz): ???E9 (203.25 MHz): no station SE6 (140.25 MHz): ???SE6 (140.25 MHz): no station SE7 (147.25 MHz): ???SE7 (147.25 MHz): no station SE8 (154.25 MHz): ???SE8 (154.25 MHz): no station SE9 (161.25 MHz): ???SE9 (161.25 MHz): no station SE10 (168.25 MHz): ???SE10 (168.25 MHz): no station SE11 (231.25 MHz): ???SE11 (231.25 MHz): no station For a complete station-list compare the scantv output attached below. According to http://www.kernel.org/doc/Documentation/video4linux/CARDLIST.tuner I created a parameter file for the proper tuner-setting: cat /etc/modprobe.d/tuner_xc2028.conf tuner=71 But this does not solve the problem. The firmware I use is -rw-r--r-- 1 root root 65K 11. Jul 21:17 /lib/firmware/xc3028-v27.fw The problem occurs both with Fedora 17 and Ubuntu 10.04. What could I try next? Any help is appreciated. Thanks -- Felix Hardware-Version: 0ccd:005e scanning channel list europe-west... E2 ( 48.25 MHz): no station E3 ( 55.25 MHz): no station E4 ( 62.25 MHz): no station S01 ( 69.25 MHz): no station S02 ( 76.25 MHz): no station S03 ( 83.25 MHz): no station E5 (175.25 MHz): no station E6 (182.25 MHz): ??? E7 (189.25 MHz): ??? E8 (196.25 MHz): ??? E9 (203.25 MHz): ??? E10 (210.25 MHz): ??? E11 (217.25 MHz): ??? E12 (224.25 MHz): ??? SE1 (105.25 MHz): no station SE2 (112.25 MHz): no station SE3 (119.25 MHz): no station SE4 (126.25 MHz): no station SE5 (133.25 MHz): no station SE6 (140.25 MHz): ??? SE7 (147.25 MHz): ??? SE8 (154.25 MHz): ??? SE9 (161.25 MHz): ??? SE10 (168.25 MHz): ??? SE11 (231.25 MHz): ??? SE12 (238.25 MHz): ??? SE13 (245.25 MHz): ??? SE14 (252.25 MHz): ??? SE15 (259.25 MHz): ??? SE16 (266.25 MHz): ??? SE17 (273.25 MHz): ??? SE18 (280.25 MHz): ??? SE19 (287.25 MHz): ??? SE20 (294.25 MHz): ??? S21 (303.25 MHz): ??? S22 (311.25 MHz): ??? S23 (319.25 MHz): ??? S24 (327.25 MHz): ??? S25 (335.25 MHz): ??? S26 (343.25 MHz): no station S27 (351.25 MHz): no station S28 (359.25 MHz): no station S29 (367.25 MHz): no station S30 (375.25 MHz): no station S31 (383.25 MHz): no station S32 (391.25 MHz): no station S33 (399.25 MHz): no station S34 (407.25 MHz): no station S35 (415.25 MHz): no station S36 (423.25 MHz): no station S37 (431.25 MHz): no station S38 (439.25 MHz): no station S39 (447.25 MHz): no station S40 (455.25 MHz): no station S41 (463.25 MHz): no station 21 (471.25 MHz): no station 22 (479.25 MHz): ??? 23 (487.25 MHz): ??? 24 (495.25 MHz): ??? 25 (503.25 MHz): ??? 26 (511.25 MHz): ??? (...) Hardware-Version: 0ccd:0042 scanning channel list europe-west... E2 ( 48.25 MHz): no station E3 ( 55.25 MHz): no station E4 ( 62.25 MHz): no station S01 ( 69.25 MHz): no station S02 ( 76.25 MHz): no station S03 ( 83.25 MHz): no station E5 (175.25 MHz): no station E6 (182.25 MHz): no station E7 (189.25 MHz): no station E8 (196.25 MHz): no station E9 (203.25 MHz): no station E10 (210.25 MHz): ??? E11 (217.25 MHz): ??? E12 (224.25 MHz): ??? SE1 (105.25 MHz): no station SE2 (112.25 MHz): no station SE3 (119.25 MHz): no station SE4 (126.25 MHz): no station SE5 (133.25 MHz): no station SE6 (140.25 MHz): no station SE7 (147.25 MHz): no station SE8 (154.25 MHz): no station SE9 (161.25 MHz): no station SE10 (168.25 MHz): no station SE11 (231.25 MHz): no station SE12 (238.25 MHz): ??? SE13 (245.25 MHz): ??? SE14 (252.25 MHz): ??? SE15 (259.25 MHz): ??? SE16 (266.25 MHz): ??? SE17 (273.25 MHz): ??? SE18 (280.25 MHz): ??? SE19 (287.25 MHz): ??? SE20 (294.25 MHz): ??? S21 (303.25 MHz): ??? S22 (311.25 MHz): ??? S23 (319.25 MHz): ??? S24 (327.25 MHz): ??? S25 (335.25 MHz): ??? S26 (343.25 MHz): no station S27 (351.25 MHz): no station S28 (359.25 MHz): no station S29 (367.25 MHz): no station S30 (375.25 MHz): no station S31 (383.25 MHz): no station S32 (391.25 MHz): no station S33 (399.25 MHz): no station S34 (407.25 MHz): no station S35 (415.25 MHz): no station S36 (423.25 MHz): no station S37 (431.25 MHz): no station S38 (439.25 MHz): no station S39 (447.25 MHz): no station S40 (455.25 MHz): no station S41 (463.25 MHz): no station 21 (471.25 MHz): no station 22 (479.25 MHz): ??? 23 (487.25 MHz): ??? 24 (495.25 MHz): ??? 25 (503.25
[PATCH] davinci: vpbe: fix build error when CONFIG_VIDEO_ADV_DEBUG is enabled
From: Lad, Prabhakar prabhakar@ti.com
Fix build error when CONFIG_VIDEO_ADV_DEBUG is enabled,
declare the vpbe_dev variable.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
drivers/media/video/davinci/vpbe_display.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpbe_display.c
b/drivers/media/video/davinci/vpbe_display.c
index f78ccc0..6fe7034 100644
--- a/drivers/media/video/davinci/vpbe_display.c
+++ b/drivers/media/video/davinci/vpbe_display.c
@@ -1517,6 +1517,8 @@ static int vpbe_display_g_register(struct file *file,
void *priv,
struct v4l2_dbg_register *reg)
{
struct v4l2_dbg_match *match = reg-match;
+ struct vpbe_fh *fh = file-private_data;
+ struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
if (match-type = 2) {
v4l2_subdev_call(vpbe_dev-venc,
--
1.7.0.4
--
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 RESEND] davinci: vpbe: fix build error when CONFIG_VIDEO_ADV_DEBUG is enabled
From: Lad, Prabhakar prabhakar@ti.com
Fix build error when CONFIG_VIDEO_ADV_DEBUG is enabled,
declare the vpbe_dev variable.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
Resending the patch since it didn't reach to the
linux-media list.
drivers/media/video/davinci/vpbe_display.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpbe_display.c
b/drivers/media/video/davinci/vpbe_display.c
index f78ccc0..6fe7034 100644
--- a/drivers/media/video/davinci/vpbe_display.c
+++ b/drivers/media/video/davinci/vpbe_display.c
@@ -1517,6 +1517,8 @@ static int vpbe_display_g_register(struct file *file,
void *priv,
struct v4l2_dbg_register *reg)
{
struct v4l2_dbg_match *match = reg-match;
+ struct vpbe_fh *fh = file-private_data;
+ struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev;
if (match-type = 2) {
v4l2_subdev_call(vpbe_dev-venc,
--
1.7.4.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 8/9] ov772x: Compute window size registers at runtime
Hi Laurent
Thanks for the patch
On Wed, 18 Jul 2012, Laurent Pinchart wrote:
Instead of hardcoding register arrays, compute the values at runtime.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 162
+-
1 files changed, 65 insertions(+), 97 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3874dbc..aa2ba9e 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
I'm afraid, I still don't quite agree with your changes to size macros.
This is not a huge deal, but I'd preserve the current (Q)VGA_* naming for
now until we find a better solution. How about this patch merged with yours:
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index a2dde04..76a80b6 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -360,8 +360,12 @@
#define SCAL0_ACTRL 0x08 /* Auto scaling factor control */
#define SCAL1_2_ACTRL 0x04 /* Auto scaling factor control */
-#define OV772X_DEFAULT_WIDTH 640
-#define OV772X_DEFAULT_HEIGHT 480
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QVGA_WIDTH 320
+#define QVGA_HEIGHT240
+#define OV772X_MAX_WIDTH VGA_WIDTH
+#define OV772X_MAX_HEIGHT VGA_HEIGHT
/*
* ID
@@ -488,8 +492,8 @@ static const struct ov772x_win_size ov772x_win_sizes[] = {
.rect = {
.left = 140,
.top = 14,
- .width = 640,
- .height = 480,
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
},
}, {
.name = QVGA,
@@ -497,8 +501,8 @@ static const struct ov772x_win_size ov772x_win_sizes[] = {
.rect = {
.left = 252,
.top = 6,
- .width = 320,
- .height = 240,
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
},
},
};
@@ -858,8 +862,8 @@ static int ov772x_g_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
{
a-c.left = 0;
a-c.top= 0;
- a-c.width = OV772X_DEFAULT_WIDTH;
- a-c.height = OV772X_DEFAULT_HEIGHT;
+ a-c.width = VGA_WIDTH;
+ a-c.height = VGA_HEIGHT;
a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
return 0;
@@ -869,8 +873,8 @@ static int ov772x_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
{
a-bounds.left = 0;
a-bounds.top = 0;
- a-bounds.width = OV772X_DEFAULT_WIDTH;
- a-bounds.height= OV772X_DEFAULT_HEIGHT;
+ a-bounds.width = OV772X_MAX_WIDTH;
+ a-bounds.height= OV772X_MAX_HEIGHT;
a-defrect = a-bounds;
a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
a-pixelaspect.numerator= 1;
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] davinci: vpbe: fix check for s_dv_preset function pointer
From: Lad, Prabhakar prabhakar@ti.com fix check for s_dv_preset function pointer to be NULL. return -EINVAL if function pointer is NULL. Signed-off-by: Lad, Prabhakar prabhakar@ti.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com --- drivers/media/video/davinci/vpbe_display.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/vpbe_display.c b/drivers/media/video/davinci/vpbe_display.c index e106b72..f78ccc0 100644 --- a/drivers/media/video/davinci/vpbe_display.c +++ b/drivers/media/video/davinci/vpbe_display.c @@ -1083,7 +1083,7 @@ vpbe_display_s_dv_preset(struct file *file, void *priv, } /* Set the given standard in the encoder */ - if (NULL != vpbe_dev-ops.s_dv_preset) + if (!vpbe_dev-ops.s_dv_preset) return -EINVAL; ret = vpbe_dev-ops.s_dv_preset(vpbe_dev, preset); -- 1.7.4.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
[PATCH] davinci: vpbe: add build infrastructure for VPBE on dm365 and dm355
From: Manjunath Hadli manjunath.ha...@ti.com add Kconfig and Makefile changes to build VPBE display driver on dm365 and dm355 along with dm644x. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com --- drivers/media/video/davinci/Kconfig | 12 ++-- drivers/media/video/davinci/Makefile |2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 9337b56..7fd125d 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -93,13 +93,13 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. -config VIDEO_DM644X_VPBE - tristate DM644X VPBE HW module - depends on ARCH_DAVINCI_DM644x +config VIDEO_DAVINCI_VPBE + tristate DAVINCI VPBE HW module + depends on ARCH_DAVINCI_DM644x || ARCH_DAVINCI_DM365 || ARCH_DAVINCI_DM355 select VIDEO_VPSS_SYSTEM select VIDEOBUF_DMA_CONTIG help - Enables VPBE modules used for display on a DM644x + Enables VPBE modules used for display on a DM644x, DM365, DM355 SoC. To compile this driver as a module, choose M here: the @@ -108,10 +108,10 @@ config VIDEO_DM644X_VPBE config VIDEO_VPBE_DISPLAY tristate VPBE V4L2 Display driver - depends on ARCH_DAVINCI_DM644x + depends on ARCH_DAVINCI_DM644x || ARCH_DAVINCI_DM365 || ARCH_DAVINCI_DM355 select VIDEO_DM644X_VPBE help - Enables VPBE V4L2 Display driver on a DM644x device + Enables VPBE V4L2 Display driver on a DM644x, DM365, DM355 device To compile this driver as a module, choose M here: the module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index ae7dafb..3057822 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,5 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o -obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_DAVINCI_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o -- 1.7.4.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
[PATCH] davinci: vpss: enable vpss clocks
From: Lad, Prabhakar prabhakar@ti.com
By default the VPSS clocks are only enabled in capture driver.
and display wont work if the capture is not enabled. This
patch adds support to enable the VPSS clocks in VPSS driver.
This way we can enable/disable capture and display and use it
independently.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
---
drivers/media/video/davinci/vpss.c | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 3e5cf27..30283bb 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -25,6 +25,9 @@
#include linux/spinlock.h
#include linux/compiler.h
#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+
#include mach/hardware.h
#include media/davinci/vpss.h
@@ -104,6 +107,10 @@ struct vpss_oper_config {
enum vpss_platform_type platform;
spinlock_t vpss_lock;
struct vpss_hw_ops hw_ops;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
};
static struct vpss_oper_config oper_cfg;
@@ -381,6 +388,29 @@ static int __init vpss_probe(struct platform_device *pdev)
return -ENODEV;
}
+ /* Get and enable Master clock */
+ oper_cfg.mclk = clk_get(pdev-dev, master);
+ if (IS_ERR(oper_cfg.mclk)) {
+ status = PTR_ERR(oper_cfg.mclk);
+ goto fail_getclk;
+ }
+ if (clk_enable(oper_cfg.mclk)) {
+ status = -ENODEV;
+ goto fail_mclk;
+ }
+ if (oper_cfg.platform == DM355 || oper_cfg.platform == DM644X) {
+ /* Get and enable Slave clock */
+ oper_cfg.sclk = clk_get(pdev-dev, slave);
+ if (IS_ERR(oper_cfg.sclk)) {
+ status = PTR_ERR(oper_cfg.sclk);
+ goto fail_mclk;
+ }
+ if (clk_enable(oper_cfg.sclk)) {
+ status = -ENODEV;
+ goto fail_sclk;
+ }
+ }
+
dev_info(pdev-dev, %s vpss probed\n, platform_name);
r1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r1)
@@ -442,6 +472,11 @@ fail2:
iounmap(oper_cfg.vpss_regs_base0);
fail1:
release_mem_region(r1-start, resource_size(r1));
+fail_sclk:
+ clk_put(oper_cfg.sclk);
+fail_mclk:
+ clk_put(oper_cfg.mclk);
+fail_getclk:
return status;
}
@@ -452,6 +487,9 @@ static int __devexit vpss_remove(struct platform_device
*pdev)
iounmap(oper_cfg.vpss_regs_base0);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
release_mem_region(res-start, resource_size(res));
+ clk_put(oper_cfg.mclk);
+ if (oper_cfg.platform == DM355 || oper_cfg.platform == DM644X)
+ clk_put(oper_cfg.sclk);
if (oper_cfg.platform == DM355 || oper_cfg.platform == DM365) {
iounmap(oper_cfg.vpss_regs_base1);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
--
1.7.0.4
--
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 8/9] ov772x: Compute window size registers at runtime
Hi Guennadi,
On Friday 20 July 2012 15:58:25 Guennadi Liakhovetski wrote:
On Wed, 18 Jul 2012, Laurent Pinchart wrote:
Instead of hardcoding register arrays, compute the values at runtime.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/ov772x.c | 162
+- 1 files changed, 65
insertions(+), 97 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 3874dbc..aa2ba9e 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
I'm afraid, I still don't quite agree with your changes to size macros.
This is not a huge deal, but I'd preserve the current (Q)VGA_* naming for
now until we find a better solution. How about this patch merged with yours:
I still like my solution better, but you're the driver maintainer :-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index a2dde04..76a80b6 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -360,8 +360,12 @@
#define SCAL0_ACTRL 0x08 /* Auto scaling factor control */
#define SCAL1_2_ACTRL 0x04 /* Auto scaling factor control */
-#define OV772X_DEFAULT_WIDTH 640
-#define OV772X_DEFAULT_HEIGHT480
+#define VGA_WIDTH640
+#define VGA_HEIGHT 480
+#define QVGA_WIDTH 320
+#define QVGA_HEIGHT 240
+#define OV772X_MAX_WIDTH VGA_WIDTH
+#define OV772X_MAX_HEIGHTVGA_HEIGHT
/*
* ID
@@ -488,8 +492,8 @@ static const struct ov772x_win_size ov772x_win_sizes[] =
{ .rect = {
.left = 140,
.top = 14,
- .width = 640,
- .height = 480,
+ .width = VGA_WIDTH,
+ .height = VGA_HEIGHT,
},
}, {
.name = QVGA,
@@ -497,8 +501,8 @@ static const struct ov772x_win_size ov772x_win_sizes[] =
{ .rect = {
.left = 252,
.top = 6,
- .width = 320,
- .height = 240,
+ .width = QVGA_WIDTH,
+ .height = QVGA_HEIGHT,
},
},
};
@@ -858,8 +862,8 @@ static int ov772x_g_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a) {
a-c.left = 0;
a-c.top= 0;
- a-c.width = OV772X_DEFAULT_WIDTH;
- a-c.height = OV772X_DEFAULT_HEIGHT;
+ a-c.width = VGA_WIDTH;
+ a-c.height = VGA_HEIGHT;
a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
return 0;
@@ -869,8 +873,8 @@ static int ov772x_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a) {
a-bounds.left = 0;
a-bounds.top = 0;
- a-bounds.width = OV772X_DEFAULT_WIDTH;
- a-bounds.height= OV772X_DEFAULT_HEIGHT;
+ a-bounds.width = OV772X_MAX_WIDTH;
+ a-bounds.height= OV772X_MAX_HEIGHT;
a-defrect = a-bounds;
a-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
a-pixelaspect.numerator= 1;
--
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
[PATCH v6 0/2] add dm365 specific media formats
add mediabus formats and pixel formats supported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include- 1: ALAW compressed bayer. 2: UV interleaved without Y (for resizer). 3: YDYU Changes for v6: 1: Fixed a comment from Hans, replaced YUYDYDYV and YVYDYDYU to YUYDYVYD and YVYDYUYD. Changes for v5: 1: Fixed comment from Laurent, moved ALAW format above DPCM format to keep the alphabetically sorted, grouped textual description for ALAW and DPCM compression, as they're mutally exclusive, Changed V4L2_MBUS_FMT_YDYC8_1X16 to V4L2_MBUS_FMT_YDYUYDYV8_1X16. Changes for v4: 1: Rebased the patch set on Sakari's branch (http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.4) mainly because of this patch URL:http://www.spinics.net/lists/linux-media/msg44871.html 2: Fixed comments from Sakari, changed description for UV8, and re-arranged sub-uv8; in Documentation/DocBook/media/v4l/pixfmt.xml file. Changes for v3: 1: Added 4cc code for A-law compressed format as per specified in documentation, http://www.spinics.net/lists/linux-media/msg43890.html Changes for v2: 1: Added entries in subdev-formats.xml for V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8, V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8, V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8, V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8, V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8. 2: Added documentation of ALAW and UV8 pix format. Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++ Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 + Documentation/DocBook/media/v4l/pixfmt.xml |2 + Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- include/linux/videodev2.h |8 + 6 files changed, 358 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml -- 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 v6 1/2] media: add new mediabus format enums for dm365
From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..01b2811 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8 entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry entry0x300b/entry @@ -853,10 +921,16 @@ titlePacked YUV Formats/title paraThose data formats transfer pixel data as
[PATCH v6 2/2] v4l2: add new pixel formats supported on dm365
From: Manjunath Hadli manjunath.ha...@ti.com
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW algorithm,
add V4L2_PIX_FMT_UV8 to represent storage of CbCr data (UV interleaved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |8 +++
4 files changed, 106 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..61cced5
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per color compressed to 8 bits each,
+ using the A-LAW algorithm. Each color component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..c507c1f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only CbCr plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+ pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+ entryCrsubscript30/subscript/entry
+
[PATCH 1/2] s5p-mfc: Fix second memory bank alignment
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
index 08a5cfe..fd62402 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
@@ -78,7 +78,7 @@ int s5p_mfc_alloc_and_load_firmware(struct s5p_mfc_dev *dev)
}
dev-bank1 = s5p_mfc_bitproc_phys;
b_base = vb2_dma_contig_memops.alloc(
- dev-alloc_ctx[MFC_BANK2_ALLOC_CTX], 1
MFC_BANK2_ALIGN_ORDER);
+ dev-alloc_ctx[MFC_BANK2_ALLOC_CTX], 1 MFC_BASE_ALIGN_ORDER);
if (IS_ERR(b_base)) {
vb2_dma_contig_memops.put(s5p_mfc_bitproc_buf);
s5p_mfc_bitproc_phys = 0;
--
1.7.0.4
--
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 2/2] s5p-mfc: support for dmabuf exporting fix
Added select DMA_SHARED_BUFFER to the Kconfig of the MFC. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..33057e4 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1200,6 +1200,7 @@ config VIDEO_SAMSUNG_S5P_JPEG config VIDEO_SAMSUNG_S5P_MFC tristate Samsung S5P MFC 5.1 Video Codec depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + select DMA_SHARED_BUFFER select VIDEOBUF2_DMA_CONTIG default n help -- 1.7.0.4 -- 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
[PULL] soc-camera for 3.6
Hi Mauro This might be a bit more, than what you'd like to see in a single pull request, sorry, but I had very little time during the last development period, so, my reviews were always delayed - sorry to all developers again! I'll try to do better next time. Anyway, here go: The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41: Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44 -0300) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.6 Fabio Estevam (2): video: mx1_camera: Use clk_prepare_enable/clk_disable_unprepare video: mx2_camera: Use clk_prepare_enable/clk_disable_unprepare Guennadi Liakhovetski (1): V4L: soc-camera: add selection API host operations Javier Martin (2): media: mx2_camera: Fix mbus format handling media: mx2_camera: Add YUYV output format. Laurent Pinchart (18): soc-camera: Don't fail at module init time if no device is present soc-camera: Pass the physical device to the power operation ov2640: Don't access the device in the g_mbus_fmt operation ov772x: Don't access the device in the g_mbus_fmt operation tw9910: Don't access the device in the g_mbus_fmt operation soc_camera: Don't call .s_power() during probe soc-camera: Continue the power off sequence if one of the steps fails soc-camera: Add and use soc_camera_power_[on|off]() helper functions soc-camera: Push probe-time power management to drivers ov772x: Fix memory leak in probe error path ov772x: Select the default format at probe time ov772x: Don't fail in s_fmt if the requested format isn't supported ov772x: try_fmt must not default to the current format ov772x: Make to_ov772x convert from v4l2_subdev to ov772x_priv ov772x: Add ov772x_read() and ov772x_write() functions ov772x: Add support for SBGGR10 format ov772x: Compute window size registers at runtime ov772x: Stop sensor readout right after reset drivers/media/video/imx074.c | 30 ++- drivers/media/video/mt9m001.c | 26 ++- drivers/media/video/mt9m111.c | 116 +--- drivers/media/video/mt9t031.c | 48 ++-- drivers/media/video/mt9t112.c | 21 ++- drivers/media/video/mt9v022.c | 14 + drivers/media/video/mx1_camera.c |4 +- drivers/media/video/mx2_camera.c | 79 +- drivers/media/video/ov2640.c | 26 ++- drivers/media/video/ov5642.c | 31 ++- drivers/media/video/ov6650.c | 28 ++- drivers/media/video/ov772x.c | 451 +++-- drivers/media/video/ov9640.c | 27 ++- drivers/media/video/ov9740.c | 47 ++- drivers/media/video/rj54n1cb0c.c | 27 ++- drivers/media/video/soc_camera.c | 169 +++ drivers/media/video/soc_camera_platform.c | 11 +- drivers/media/video/tw9910.c | 29 ++- include/media/soc_camera.h| 12 + 19 files changed, 771 insertions(+), 425 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 2/2] v4l: Add v4l2 subdev driver for S5K4ECGX sensor
Hi Sylwester
Thank you for the great review!
On 19 July 2012 22:40, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote:
Hi Sangwook,
A few review comments for you below...
On 07/19/2012 02:14 PM, Sangwook Lee wrote:
This dirver implements preview mode of the S5K4ECGX sensor.
dirver - driver
OK, I will fix this.
capture (snapshot) operation, face detection are missing now.
Following controls are supported:
contrast/saturation/birghtness/sharpness
birghtness - brightness
ditto
Signed-off-by: Sangwook Leesangwook@linaro.org
---
+ * Driver for s5k4ecgx (5MP Camera) from SAMSUNG
+ * a quarter-inch optical format 1.4 micron 5 megapixel (Mp)
+ * CMOS image sensor, as reffering to s5k6aa.c
I think this should be mentioned after your own copyright notice,
e.g. in form of:
Based on s5k6aa driver,
Copyright (C) 2011, Samsung Electronics Co., Ltd.
ditto
+ *
+ * Copyright (C) 2012, Linaro, Sangwook Leesangwook@linaro.org
+ * Copyright (C) 2012, Insignal Co,. Ltd, Homin
Leesuap...@insignal.co.kr
+ * Copyright (C) 2011, SAMSUNG ELECTRONICS
No need to shout, Samsung Electronics Co., Ltd. would be just enough.
ditto
+#includemedia/v4l2-device.h
+#includemedia/v4l2-subdev.h
+#includemedia/media-entity.h
+#includemedia/v4l2-ctrls.h
+#includemedia/v4l2-mediabus.h
+#includemedia/s5k4ecgx.h
Can we, please, have these sorted alphabetically ?
OK, I will fix this.
+#include s5k4ecgx_regs.h
+
+static int debug;
+module_param(debug, int, 0644);
+
[snip]
+/* General purpose parameters */
+#define REG_USER_BRIGHTNESS 0x722C /* Brigthness */
availble - available
ditto
+#define REG_USER_SHARP1 0x7A28
+#define REG_USER_SHARP2 0x7ADE
+#define REG_USER_SHARP3 0x7B94
+#define REG_USER_SHARP4 0x7C4A
+#define REG_USER_SHARP5 0x7D00
+
+#define LSB(X) (((X) 0xFF))
+#define MSB(Y) (((Y) 8) 0xFF)
Lower case for hex numbers is preferred.
ditto
+
+/*
+ * Preview size lists supported by sensor
+ */
+struct regval_list *pview_size[] = {
+ s5k4ecgx_176_preview,
+ s5k4ecgx_352_preview,
+ s5k4ecgx_640_preview,
+ s5k4ecgx_720_preview,
+};
+
+struct s5k4ecgx_framesize {
+ u32 idx; /* Should indicate index of pview_size */
+ u32 width;
+ u32 height;
+};
+
+/*
+ * TODO: currently only preview is supported and snapshopt(capture)
+ * is not implemented yet
+ */
+static struct s5k4ecgx_framesize p_sets[] = {
p_sets - s5k4ecgx_framesizes ?
Hmm, the structure name needs to be changed properly.
+ {0, 176, 144},
+ {1, 352, 288},
+ {2, 640, 480},
+ {3, 720, 480},
I believe we can do without presets for just the preview operation mode.
This (p_sets[]) is only used to configure preview size dynamically
when _s_fmt is called and then s_stream become on.
Then, the number of registers to configure when device is powered on
should then decrease significantly.
Those presets are meant to speed up switching the device context, e.g.
from preview to capture, but they just slow down initialization, because
you have to configure all presets beforehand.
+};
+
+#define S5K4ECGX_NUM_PREV ARRAY_SIZE(p_sets)
+struct s5k4ecgx_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+};
+
+/* By defaut value, output from sensor will be YUV422 0-255 */
+static const struct s5k4ecgx_pixfmt s5k4ecgx_formats[] = {
+ { V4L2_MBUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_JPEG},
Nit: missing whitespace before }.
Thanks, I will fix this.
+};
+
+struct s5k4ecgx_preset {
+ /* output pixel format and resolution */
+ struct v4l2_mbus_framefmt mbus_fmt;
+ u8 clk_id;
+ u8 index;
+};
+
+struct s5k4ecgx {
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_ctrl_handler handler;
+
+ struct s5k4ecgx_platform_data *pdata;
+ struct s5k4ecgx_preset presets[S5K4ECGX_MAX_PRESETS];
+ struct s5k4ecgx_preset *preset;
+ struct s5k4ecgx_framesize *p_now; /* Current frame size */
+ struct v4l2_fract timeperframe;
+
+ /* protects the struct members below */
+ struct mutex lock;
+ int streaming;
+
+ /* Token for I2C burst write */
+ enum token_type reg_type;
+ u16 reg_addr_high;
+ u16 reg_addr_low;
+
+ /* Platform specific field */
+ int (*set_power)(int);
This need to be replaced with regulator/GPIO API, if possible.
Platform data callbacks cannot be supported on device tree platforms,
hence we really need to avoid such callbacks.
Thanks for reminding me about device tree.
let me update the driver with regulator/GPIO API.
+ int mdelay;
+};
+
+static inline struct s5k4ecgx *to_s5k4ecgx(struct
mx1: compilation broken
Hi all mx1 camera compilation broken in current media-next (git://linuxtv.org/media_tree.git staging/for_v3.6): In file included from linux/drivers/media/video/mx1_camera.c:44: linux/arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8: fatal error: mach/dma-v1.h: No such file or directory sorry, if this is already fixed in a more recent -next snapshot. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
af9015_rc_query
First occurrence of this kind of failure with Cinergy T RC MKII :| 3.4.5-2.fc17.x86_64 0ccd:0097 TerraTec Electronic GmbH Cinergy T RC MKII … kernel: af9015: recv bulk message failed:-71 kernel: af9015: af9015_rc_query: failed:-1 kernel: dvb-usb: error -1 while querying for an remote control event. … Device get stuck, replugging necessary. Causes of overheating!? cheers, poma -- 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/2] dma-buf: add helpers for attacher dma-parms
Fyi, Daniel Vetter had suggested on IRC that it would be cleaner to
have a single helper fxn that most-restrictive union of all attached
device's dma_parms. Really this should include dma_mask and
coherent_dma_mask, I think. But that touches a lot of other places in
the code. If no one objects to the cleanup of moving
dma_mask/coherent_dma_mask into dma_parms, I'll do this first.
So anyways, don't consider this patch yet for inclusion, I'll make an
updated one based on dma_parms..
BR,
-R
On Thu, Jul 19, 2012 at 11:23 AM, Rob Clark rob.cl...@linaro.org wrote:
From: Rob Clark r...@ti.com
Add some helpers to iterate through all attachers and get the most
restrictive segment size/count/boundary.
Signed-off-by: Rob Clark r...@ti.com
---
drivers/base/dma-buf.c | 63
+++
include/linux/dma-buf.h | 19 ++
2 files changed, 82 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 24e88fe..757ee20 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -192,6 +192,69 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
+ * dma_buf_max_seg_size - helper for exporters to get the minimum of
+ * all attached device's max segment size
+ */
+unsigned int dma_buf_max_seg_size(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+ unsigned int max = (unsigned int)-1;
+
+ if (WARN_ON(!dmabuf))
+ return 0;
+
+ mutex_lock(dmabuf-lock);
+ list_for_each_entry(attach, dmabuf-attachments, node)
+ max = min(max, dma_get_max_seg_size(attach-dev));
+ mutex_unlock(dmabuf-lock);
+
+ return max;
+}
+EXPORT_SYMBOL_GPL(dma_buf_max_seg_size);
+
+/**
+ * dma_buf_max_seg_count - helper for exporters to get the minimum of
+ * all attached device's max segment count
+ */
+unsigned int dma_buf_max_seg_count(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+ unsigned int max = (unsigned int)-1;
+
+ if (WARN_ON(!dmabuf))
+ return 0;
+
+ mutex_lock(dmabuf-lock);
+ list_for_each_entry(attach, dmabuf-attachments, node)
+ max = min(max, dma_get_max_seg_count(attach-dev));
+ mutex_unlock(dmabuf-lock);
+
+ return max;
+}
+EXPORT_SYMBOL_GPL(dma_buf_max_seg_count);
+
+/**
+ * dma_buf_get_seg_boundary - helper for exporters to get the most
+ * restrictive segment alignment of all the attached devices
+ */
+unsigned int dma_buf_get_seg_boundary(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach;
+ unsigned int mask = (unsigned int)-1;
+
+ if (WARN_ON(!dmabuf))
+ return 0;
+
+ mutex_lock(dmabuf-lock);
+ list_for_each_entry(attach, dmabuf-attachments, node)
+ mask = dma_get_seg_boundary(attach-dev);
+ mutex_unlock(dmabuf-lock);
+
+ return mask;
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_seg_boundary);
+
+/**
* dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
* calls attach() of dma_buf_ops to allow device-specific attach
functionality
* @dmabuf:[in]buffer to attach device to.
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index eb48f38..9533b9b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -167,6 +167,10 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+unsigned int dma_buf_max_seg_size(struct dma_buf *dmabuf);
+unsigned int dma_buf_max_seg_count(struct dma_buf *dmabuf);
+unsigned int dma_buf_get_seg_boundary(struct dma_buf *dmabuf);
+
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
@@ -220,6 +224,21 @@ static inline void dma_buf_put(struct dma_buf *dmabuf)
return;
}
+static inline unsigned int dma_buf_max_seg_size(struct dma_buf *dmabuf)
+{
+ return 0;
+}
+
+static inline unsigned int dma_buf_max_seg_count(struct dma_buf *dmabuf)
+{
+ return 0;
+}
+
+static inline unsigned int dma_buf_get_seg_boundary(struct dma_buf *dmabuf)
+{
+ return 0;
+}
+
static inline struct sg_table *dma_buf_map_attachment(
struct dma_buf_attachment *attach, enum dma_data_direction write)
{
--
1.7.9.5
--
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 v6 1/2] media: add new mediabus format enums for dm365
Hi Prabhakar, Just one small comment below. On Friday 20 July 2012 20:28:09 Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 - include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) @@ -2415,6 +2553,106 @@ entryusubscript1/subscript/entry entryusubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-YDYUYDYV8-1X16 + entryV4L2_MBUS_FMT_YDYUYDYV8_1X16/entry + entry0x2014/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryysubscript7/subscript/entry + entryysubscript6/subscript/entry + entryysubscript5/subscript/entry + entryysubscript4/subscript/entry + entryysubscript3/subscript/entry + entryysubscript2/subscript/entry + entryysubscript1/subscript/entry + entryysubscript0/subscript/entry + entrydsubscript7/subscript/entry + entrydsubscript6/subscript/entry + entrydsubscript5/subscript/entry + entrydsubscript4/subscript/entry + entrydsubscript3/subscript/entry + entrydsubscript2/subscript/entry + entrydsubscript1/subscript/entry + entrydsubscript0/subscript/entry I would remove the subscripts for all the dummy bits (here and below), as they're dummy. With that change, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com + /row + row + entry/entry + entry/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryysubscript7/subscript/entry + entryysubscript6/subscript/entry + entryysubscript5/subscript/entry + entryysubscript4/subscript/entry + entryysubscript3/subscript/entry + entryysubscript2/subscript/entry + entryysubscript1/subscript/entry + entryysubscript0/subscript/entry + entryusubscript7/subscript/entry + entryusubscript6/subscript/entry + entryusubscript5/subscript/entry + entryusubscript4/subscript/entry + entryusubscript3/subscript/entry + entryusubscript2/subscript/entry + entryusubscript1/subscript/entry + entryusubscript0/subscript/entry + /row + row + entry/entry + entry/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryysubscript7/subscript/entry + entryysubscript6/subscript/entry + entryysubscript5/subscript/entry + entryysubscript4/subscript/entry + entryysubscript3/subscript/entry + entryysubscript2/subscript/entry + entryysubscript1/subscript/entry + entryysubscript0/subscript/entry + entrydsubscript7/subscript/entry + entrydsubscript6/subscript/entry + entrydsubscript5/subscript/entry + entrydsubscript4/subscript/entry + entrydsubscript3/subscript/entry + entrydsubscript2/subscript/entry + entrydsubscript1/subscript/entry + entrydsubscript0/subscript/entry + /row + row + entry/entry + entry/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryysubscript7/subscript/entry + entryysubscript6/subscript/entry + entryysubscript5/subscript/entry + entryysubscript4/subscript/entry + entryysubscript3/subscript/entry + entryysubscript2/subscript/entry + entryysubscript1/subscript/entry + entryysubscript0/subscript/entry + entryvsubscript7/subscript/entry + entryvsubscript6/subscript/entry + entryvsubscript5/subscript/entry + entryvsubscript4/subscript/entry + entryvsubscript3/subscript/entry +
Build Failure: ddbridge-core.o and drxk_hard.o
Hi, I have been building a streaming server at Georgia Tech and I have recently run into a build error using the media_build git repository that I have yet to find a solution for. The drivers built, installed, and worked about a month ago, but with the recent git update it has failed to build. I wasn't able to find the same error in the daily builds and thought I'd ask to see if anyone could point me in the right direction, whether it be a bug in the build files or something on my end. I am running RHEL 6 without any GUI installed and everything is up to date. Server Info: --- Red Hat Enterprise Linux 6 Kernel: 2.6.32-279.1.1.el6.x86_64 GCC Version: 4.4.6 Main Build Error: --- CC [M] /root/downloads/media_build/v4l/ddbridge-core.o /root/downloads/media_build/v4l/ddbridge-core.c: In function 'ddb_class_create': /root/downloads/media_build/v4l/ddbridge-core.c:1502: warning: assignment from incompatible pointer type CC [M] /root/downloads/media_build/v4l/drxd_firm.o CC [M] /root/downloads/media_build/v4l/drxd_hard.o CC [M] /root/downloads/media_build/v4l/drxk_hard.o /root/downloads/media_build/v4l/drxk_hard.c: In function 'drxk_attach': /root/downloads/media_build/v4l/drxk_hard.c:6615: warning: passing argument 5 of 'request_firmware_nowait' makes integer from pointer without a cast include/linux/firmware.h:40: note: expected 'gfp_t' but argument is of type 'struct drxk_state *' /root/downloads/media_build/v4l/drxk_hard.c:6615: error: too few arguments to function 'request_firmware_nowait' make[3]: *** [/root/downloads/media_build/v4l/drxk_hard.o] Error 1 make[2]: *** [_module_/root/downloads/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/kernels/2.6.32-279.el6.x86_64' make[1]: *** [default] Error 2 make[1]: Leaving directory `/root/downloads/media_build/v4l' make: *** [all] Error 2 build failed at ./build line 452. Other Information: Tuning card: Hauppauge WinTV-HVR-2250 (I'm tuning Clear-QAM and NTSC) Device Subsystem ID Multimedia controller [0480]: Philips Semiconductors SAA7164 [1131:7164] (rev 81) Subsystem: Hauppauge computer works Inc. WinTV HVR-2250 [0070:8851] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at df00 (64-bit, non-prefetchable) [size=4M] Memory at df40 (64-bit, non-prefetchable) [size=4M] Capabilities: [40] MSI: Enable- Count=1/16 Maskable- 64bit+ Capabilities: [50] Express Endpoint, MSI 00 Capabilities: [74] Power Management version 3 Capabilities: [7c] Vendor Specific Information ? Capabilities: [100] Vendor Specific Information ? Capabilities: [160] Virtual Channel ? Kernel driver in use: saa7164 Kernel modules: saa7164 Base Board Information Manufacturer: Dell Inc. Product Name: 05XKKK BIOS Information Vendor: Dell Inc. Version: 1.8.2 Release Date: 08/17/2011 Address: 0xF Runtime Size: 64 kB ROM Size: 4096 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported Japanese floppy for Toshiba 1.2 MB is supported (int 13h) 5.25/360 kB floppy services are supported (int 13h) 5.25/1.2 MB floppy services are supported (int 13h) 3.5/720 kB floppy services are supported (int 13h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 1.8 Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: E5 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 30, Stepping 5 Version: Intel(R) Xeon(R) CPU X3480 @ 3.07GHz Voltage: 1.2 V External Clock: 4800 MHz Max Speed: 3600 MHz Current Speed: 3066 MHz Status: Populated, Enabled Upgrade: Socket LGA1366 L1 Cache Handle: 0x0700 L2 Cache Handle: 0x0701 L3 Cache Handle: 0x0702 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 4 Core Enabled: 4 Thread Count: 8 Characteristics: 64-bit capable Dmesg Log for saa7164 Driver:
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:Fri Jul 20 19:00:22 CEST 2012 git hash:931efdf58bd83af8d0578a6cc53421675daf6d41 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification 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
[PATCH][Trivial][resend] Documentation: Add newline at end-of-file to files lacking one
This patch simply adds a newline character at end-of-file to those files in Documentation/ that currently lack one. This is done for a few different reasons: A) It's rather annoying when you do cat some_file.txt that your prompt/cursor ends up at the end of the last line of output rather than on a new line. B) Some tools that process files line-by-line may get confused by the lack of a newline on the last line. C) The \ No newline at end of file line in diffs annoys me for some reason. So, let's just add the missing newline once and for all. Signed-off-by: Jesper Juhl j...@chaosbits.net --- Documentation/ABI/stable/vdso | 2 +- Documentation/ABI/testing/sysfs-block-zram | 2 +- Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg | 2 +- Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 | 2 +- Documentation/arm/Samsung-S3C24XX/H1940.txt| 2 +- Documentation/arm/Samsung-S3C24XX/SMDK2440.txt | 2 +- Documentation/sound/alsa/hdspm.txt | 2 +- Documentation/video4linux/cpia2_overview.txt | 2 +- Documentation/video4linux/stv680.txt | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/ABI/stable/vdso b/Documentation/ABI/stable/vdso index 8a1cbb5..7cdfc28 100644 --- a/Documentation/ABI/stable/vdso +++ b/Documentation/ABI/stable/vdso @@ -24,4 +24,4 @@ though. (As of this writing, this ABI documentation as been confirmed for x86_64. The maintainers of the other vDSO-using architectures should confirm - that it is correct for their architecture.) \ No newline at end of file + that it is correct for their architecture.) diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index c8b3b48..ec93fe3 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -96,4 +96,4 @@ Description: overhead, allocated for this disk. So, allocator space efficiency can be calculated using compr_data_size and this statistic. - Unit: bytes \ No newline at end of file + Unit: bytes diff --git a/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg b/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg index cb830df..70d00df 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg +++ b/Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg @@ -40,4 +40,4 @@ Description: Controls the decimal places on the device. the value of 10 ** n. Assume this field has the value k and has 1 or more decimal places set, to set the mth place (where m is not already set), - change this fields value to k + 10 ** m. \ No newline at end of file + change this fields value to k + 10 ** m. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 index 4a9c545..33e6488 100644 --- a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 +++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 @@ -53,4 +53,4 @@ Description: Documentation/ABI/stable/sysfs-class-backlight. It can be enabled by writing the value stored in /sys/class/backlight/backlight/max_brightness to - /sys/class/backlight/backlight/brightness. \ No newline at end of file + /sys/class/backlight/backlight/brightness. diff --git a/Documentation/arm/Samsung-S3C24XX/H1940.txt b/Documentation/arm/Samsung-S3C24XX/H1940.txt index f4a7b22..b738859 100644 --- a/Documentation/arm/Samsung-S3C24XX/H1940.txt +++ b/Documentation/arm/Samsung-S3C24XX/H1940.txt @@ -37,4 +37,4 @@ Maintainers Thanks to the many others who have also provided support. -(c) 2005 Ben Dooks \ No newline at end of file +(c) 2005 Ben Dooks diff --git a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt index 32e1eae..429390b 100644 --- a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt +++ b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt @@ -53,4 +53,4 @@ Maintainers and to Simtec Electronics for allowing me time to work on this. -(c) 2004 Ben Dooks \ No newline at end of file +(c) 2004 Ben Dooks diff --git a/Documentation/sound/alsa/hdspm.txt b/Documentation/sound/alsa/hdspm.txt index 7a67ff7..7ba3194 100644 --- a/Documentation/sound/alsa/hdspm.txt +++ b/Documentation/sound/alsa/hdspm.txt @@ -359,4 +359,4 @@ Calling Parameter: enable_monitor int array (min = 1, max = 8), Enable Analog Out on Channel 63/64 by default. - note: here the analog output is enabled (but not routed). \ No newline at end of file + note: here the analog output is enabled (but not routed). diff
Re: [PATCH][Trivial][resend] Documentation: Add newline at end-of-file to files lacking one
On Fri, 20 Jul 2012, Jesper Juhl wrote: This patch simply adds a newline character at end-of-file to those files in Documentation/ that currently lack one. This is done for a few different reasons: A) It's rather annoying when you do cat some_file.txt that your prompt/cursor ends up at the end of the last line of output rather than on a new line. B) Some tools that process files line-by-line may get confused by the lack of a newline on the last line. C) The \ No newline at end of file line in diffs annoys me for some reason. So, let's just add the missing newline once and for all. Signed-off-by: Jesper Juhl j...@chaosbits.net Queued for 3.6, thanks Jesper. -- Jiri Kosina SUSE Labs -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Hi Mauro On Tue, 17 Jul 2012, Guennadi Liakhovetski wrote: Hi Mauro On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, but so far it very much looks like I won't be able to do so unfortunately. Things change and sometimes also to the better:-) Looks like I'll be able to attend actually. So, please add me to the list. Thanks Guennadi Thanks! Mauro Mensagem original Assunto: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit Data: Fri, 13 Jul 2012 13:37:08 -0400 De: Theodore Ts'o ty...@mit.edu Para: James Bottomley james.bottom...@hansenpartnership.com CC: ksummit-2012-disc...@lists.linux-foundation.org, linux-kernel linux-ker...@vger.kernel.org On Wed, Jul 11, 2012 at 09:09:15AM +0100, James Bottomley wrote: Hi All, We have set aside the second day of the kernel summit (Tuesday 28 August) as mini-summit day. So far we have only the PCI mini summit on this day, so if you can think of other topics, please send them to the kernel summit discuss list: ksummit-2012-disc...@lists.linux-foundation.org Looking at the available rooms, we think we can run about four or five mini summits. As an added incentive, mini summit organisers get to pick who they invite and all the people they pick will get an automatic invitation to the third day of the kernel summit (but not the core first day) and the evening events. OK, so far I believe I've heard concrete suggestions from identified (or fairly well identified :-) stuckees willing to organize mini-summits for: * ARM * Media * PCI * memcg I may have missed some, so if people could send a message to the discuss list with [MINI-SUMMIT] in the subbject line and the name of the proposed mini-summit, that would be really helpful. Please indicate whether you are volunteering to help organize the proposed mini-summit, or identify someone you think can be volunteered. :-) Things that we will be asking the mini-summit chars to determine, in addition to who should be given invites for Tuesday and Wednesday is an estimate of how much time you need, and a list of sub-topics (and who might lead the sub-topic discussion). We will be asking you to create a fairly well-defined schedule, with 30 and 60 minute slots, so that we can publish a schedule and so that people who might need to hop between mini-summits, have a chance to do so. So please start thinking about how long each of your sub-topics will need to be, and who might be needed for a particular sub-topic's discussion to be successful. There may be a number of developers, with fingers in multiple subsystem, where scheduling may become a bit of a challenge. Thanks!! - Ted ___ Ksummit-2012-discuss mailing list ksummit-2012-disc...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/ksummit-2012-discuss ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
