Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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: OMAP3 isp single-shot
Hi Laurent, On Friday 25 March 2011 14:10:28 Daniel Lundborg wrote: On Thursday 24 March 2011 11:26:01 Daniel Lundborg wrote: [snip] I can see on the oscilloscope that the sensor is sending something when I trigger it, but no picture is received.. something is a bit vague, can you check the hsync/vsync signals and make sure they're identical in both modes ? I have now tested this and I can say that I am having problems triggering the sensor. I wrongly thought I was triggering the sensor with my other driver correctly, but that was not the case. What I want is to put the Omap ISP to generate a signal (CAM_WEN) to make the camera sensor take a picture. That's not possible. The cam_wen signal is an input to the ISP. The ISP Timing Control module can generate pulses on the cam_shutter, cam_strobe and cam_global_reset signals only. I meant the CAM_WEN pin that should be set as CAM_SHUTTER.. :) What you could do is configure the cam_wen pin as a GPIO and control it using the GPIO framework (either in kernelspace or userspace). In my working mt9v034 driver which is using kernel 2.6.31-rc7 with the patches from http://gitorious.org/omap3camera/mainline/commits/slave I set the ISP to this on power on: isp_reg_and_or(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0x9a1b63ff, 0x98036000); // Set CAM_GLOBAL_RESET pin as output, enable shutter, set DIVC = 216 What ISP driver version are you using ? isp_reg_and_or has been replaced by isp_reg_clr_set a very long time ago. You should really upgrade. That's what I was trying to do :) isp_reg_and(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_DELAY, 0xfe00); // Set no shutter delay isp_reg_and_or(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_SHUT_LENGTH, 0xfe00, 0x03e8); // Set shutter signal length to 1000 (= 1000 * 1/216MHz * 216 = 1 ms) isp_reg_and_or(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_GRESET_LENGTH, 0xfe00, 0x03e8); // Set shutter signal length to 1000 (= 1000 * 1/216MHz * 216 = 1 ms) isp_reg_and(isp_ccdc_dev, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_LSC_CONFIG, ~ISPCCDC_LSC_ENABLE); // Make sure you disable LSC And when I want to take a picture I do: isp_reg_or(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0x00e0); // Enable shutter (SHUTEN bit = 1) isp_reg_or(vdev-cam-isp, OMAP3_ISP_IOMEM_MAIN, ISP_TCTRL_CTRL, 0x2000); // Start generation of CAM_GLOBAL_RESET signal (GRESETEN bit = 1) When I try to do this in the newer driver I manage to generate a pulse on the CAM_WEN pin, but no VSYNC, HSYNC or data is transmitted. I fail to see how that code can generate a pulse on the cam_wen signal. It should only control the cam_shutter, cam_strobe and cam_global_shutter pins. Am I missing something? Is your sensor correctly configured ? Is there a publicly available datasheet for the MT9V034 ? I found where I was misconfiguring the sensor. I missed setting a bit in the CHIP_CONTROL register. So now my driver is running. :) This is how I set the sensor in shutter mode now: // Set chip to shutter mode temp = mt9v034_read(client, MT9V034_CHIP_CONTROL); temp = 0x0198 | (temp 0xfeff); ret = mt9v034_write(client, MT9V034_CHIP_CONTROL, temp); Thank you, /Daniel -- 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.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Hi, On 04/12/2011 08:28 AM, Guennadi Liakhovetski wrote: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. Im not sure whether this is the case. Doesn't bytesperline refer only to the data layout in memory buffer written by the DMA? i.e. does padding really makes sens for JPEG files? 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) You might want to use v4l2_buffer::bytesused to inform user space about the actual size of the captured frame, which would be set before a buffer is dequeued from the driver. The size of JPEG file will depend on the content, so IMHO you could not use v4l2_pix_fmt::sizeimage in such way. thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? I the S5P FIMC driver I used to set sizeimage to some arbitrary value, (it's not yet in mainline kernel), e.g. sizeimage = width * height * C, where C = 1 bytesperline = width. However it would be useful to make the C coefficient dependent on JPEG compression quality, not to make the image buffer unnecessary large. I thought about creating a separate control class for JPEG but the quality control was so far everything I would need to put in this class. It's on my to do list to figure out what controls set would cover the standard. Regards, -- Sylwester Nawrocki 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 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
2011/4/12 Kassey Lee kassey1...@gmail.com: Hi, Guennadi; for sizeimage , I agree with you. that we can overwrite it after a frame is done. for byteperline: on Marvell soc. it needs to know the bytesperline before receive frame from sensor. what we did now is hardcode in host driver for bytesperline. since different sensors have different timing for JPEG, and bytesperline is different. while soc_mbus_bytes_per_line does not support JPEG. So, we want that host driver can get byteperline from sensor driver (sub dev) before transfer a frame for JPEG format. a way to do this: soc_mbus_bytes_per_line return 0 for JPEG, and host driver will try another API to get bytesperline for JPEG from sensor driver. the effort is new API or reused other API. Is that reasonable ? 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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 -- 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: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Hans,
Hans Verkuil wrote:
[clip]
diff --git a/drivers/media/video/v4l2-fh.c
b/drivers/media/video/v4l2-fh.c
index 8635011..c6aef84 100644
--- a/drivers/media/video/v4l2-fh.c
+++ b/drivers/media/video/v4l2-fh.c
@@ -93,10 +93,8 @@ void v4l2_fh_exit(struct v4l2_fh *fh)
{
if (fh-vdev == NULL)
return;
-
- fh-vdev = NULL;
-
v4l2_event_free(fh);
+ fh-vdev = NULL;
This looks like a bugfix.
But it isn't :-)
v4l2_event_free didn't use fh-vdev in the past, but now it does so the
order had to be swapped.
Ok.
}
EXPORT_SYMBOL_GPL(v4l2_fh_exit);
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 92d2fdd..f7238c1 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1787,6 +1787,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_ALL 0
#define V4L2_EVENT_VSYNC 1
#define V4L2_EVENT_EOS 2
+#define V4L2_EVENT_CTRL_CH_VALUE 3
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1795,21 +1796,33 @@ struct v4l2_event_vsync {
__u8 field;
} __attribute__ ((packed));
+/* Payload for V4L2_EVENT_CTRL_CH_VALUE */
+struct v4l2_event_ctrl_ch_value {
+ __u32 type;
type is enum v4l2_ctrl_type in struct v4l2_ctrl and struct v4l2_queryctrl.
Yes, but enum's are frowned upon these days in the public API.
Agreed.
+ union {
+ __s32 value;
+ __s64 value64;
+ };
+} __attribute__ ((packed));
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
+ struct v4l2_event_ctrl_ch_value ctrl_ch_value;
__u8data[64];
} u;
__u32 pending;
__u32 sequence;
struct timespec timestamp;
- __u32 reserved[9];
+ __u32 id;
id is valid only for control related events. Shouldn't it be part of the
control related structures instead, or another union for control related
event types? E.g.
struct {
enum v4l2_ctrl_type id;
union {
struct v4l2_event_ctrl_ch_value ch_value;
};
} ctrl;
The problem with making this dependent of the type is that the core event
code would have to have a switch on the event type when it comes to
matching identifiers. By making it a core field it doesn't have to do
this. Also, this makes it available for use by private events as well.
It is important to keep the send-event core code as fast as possible since
it can be called from interrupt context.
So this is by design.
I understand your point, and agree with it. There would be a few places
in the v4l2-event.c that one would have to know if the event is
control-related or not.
As the id field is handled in the v4l2-event.c the way it is, it must be
zero when the event is not a control-related one. This makes it
impossible to use it for other purposes, at least for now.
What about renaming the field to ctrl_id? Or do you think we could have
other use for the field outside the scope of the control-related events?
The benefit of the current name is still that it does not suggest
anything on the implementation.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
On Tue, 12 Apr 2011, Kassey Lee wrote: 2011/4/12 Kassey Lee kassey1...@gmail.com: Hi, Guennadi; for sizeimage , I agree with you. that we can overwrite it after a frame is done. for byteperline: on Marvell soc. it needs to know the bytesperline before receive frame from sensor. what we did now is hardcode in host driver for bytesperline. since different sensors have different timing for JPEG, and bytesperline is different. while soc_mbus_bytes_per_line does not support JPEG. So, we want that host driver can get byteperline from sensor driver (sub dev) before transfer a frame for JPEG format. a way to do this: soc_mbus_bytes_per_line return 0 for JPEG, and host driver will try another API to get bytesperline for JPEG from sensor driver. the effort is new API or reused other API. Is that reasonable ? If you mean this your patch http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31323/match= then I've queued it for 2.6.40. Thanks Guennadi 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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 --- 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
Re: [PATCH 2.6.39] soc_camera: OMAP1: fix missing bytesperline and sizeimage initialization
Yes, thank you very much! 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: On Tue, 12 Apr 2011, Kassey Lee wrote: 2011/4/12 Kassey Lee kassey1...@gmail.com: Hi, Guennadi; for sizeimage , I agree with you. that we can overwrite it after a frame is done. for byteperline: on Marvell soc. it needs to know the bytesperline before receive frame from sensor. what we did now is hardcode in host driver for bytesperline. since different sensors have different timing for JPEG, and bytesperline is different. while soc_mbus_bytes_per_line does not support JPEG. So, we want that host driver can get byteperline from sensor driver (sub dev) before transfer a frame for JPEG format. a way to do this: soc_mbus_bytes_per_line return 0 for JPEG, and host driver will try another API to get bytesperline for JPEG from sensor driver. the effort is new API or reused other API. Is that reasonable ? If you mean this your patch http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31323/match= then I've queued it for 2.6.40. Thanks Guennadi 2011/4/12 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi On Tue, 12 Apr 2011, Kassey Lee wrote: hi, Guennadi: a lot of sensors support JPEG output. 1) bytesperline is defined by sensor timing. 2) and sizeimage is unknow for jpeg. how about for JPEG 1) host driver gets bytesperline from sensor driver. 2) sizeimage refilled by host driver after dma transfer done( a frame is received) thanks. How is this done currently on other V4L2 drivers? To transfer a frame you usually first do at least one of S_FMT and G_FMT, at which time you already have to report sizeimage to the user - before any transfer has taken place. Currently with soc-camera it is already possible to override sizeimage and bytesperline from the host driver. Just set them to whatever you need in your try_fmt and they will be kept. Not sure how you want to do that, if you need to first read in a frame - do you want to perform some dummy frame transfer? You might not even have any buffers queued yet, so, it has to be a read without writing to RAM. Don't such compressed formats just put a value in sizeimage, that is a calculated maximum size? Thanks Guennadi 2011/4/11 Guennadi Liakhovetski g.liakhovet...@gmx.de: Hi Janusz On Sat, 9 Apr 2011, Janusz Krzysztofik wrote: Since commit 0e4c180d3e2cc11e248f29d4c604b6194739d05a, bytesperline and sizeimage memebers of v4l2_pix_format structure have no longer been calculated inside soc_camera_g_fmt_vid_cap(), but rather passed via soc_camera_device structure from a host driver callback invoked by soc_camera_set_fmt(). OMAP1 camera host driver has never been providing these parameters, so it no longer works correctly. Fix it by adding suitable assignments to omap1_cam_set_fmt(). Thanks for the patch, but now it looks like many soc-camera host drivers are re-implementing this very same calculation in different parts of their code - in try_fmt, set_fmt, get_fmt. Why don't we unify them all, implement this centrally in soc_camera.c and remove all those calculations? Could you cook up a patch or maybe several patches - for soc_camera.c and all drivers? Thanks Guennadi Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- drivers/media/video/omap1_camera.c | 6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.39-rc2/drivers/media/video/omap1_camera.c.orig 2011-04-06 14:30:37.0 +0200 +++ linux-2.6.39-rc2/drivers/media/video/omap1_camera.c 2011-04-09 00:16:36.0 +0200 @@ -1292,6 +1292,12 @@ static int omap1_cam_set_fmt(struct soc_ pix-colorspace = mf.colorspace; icd-current_fmt = xlate; + pix-bytesperline = soc_mbus_bytes_per_line(pix-width, + xlate-host_fmt); + if (pix-bytesperline 0) + return pix-bytesperline; + pix-sizeimage = pix-height * pix-bytesperline; + return 0; } --- 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 --- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer
Re: [PATCH 0/2] V4L: Extended crop/compose API, ver2
Hi Hans, Tomasz,
On Monday 11 April 2011 12:42:10 Tomasz Stanislawski wrote:
Hans Verkuil wrote:
On Wednesday, April 06, 2011 10:44:17 Tomasz Stanislawski wrote:
Hello everyone,
This patch-set introduces new ioctls to V4L2 API. The new method for
configuration of cropping and composition is presented.
This is the second version of extcrop RFC. It was enriched with new
features like additional hint flags, and a support for auxiliary
crop/compose rectangles.
There is some confusion in understanding of a cropping in current
version of V4L2. For CAPTURE devices cropping refers to choosing only a
part of input data stream and processing it and storing it in a memory
buffer. The buffer is fully filled by data. It is not possible to
choose only a part of a buffer for being updated by hardware.
In case of OUTPUT devices, the whole content of a buffer is passed by
hardware to output display. Cropping means selecting only a part of an
output display/signal. It is not possible to choose only a part for a
memory buffer to be processed.
The overmentioned flaws in cropping API were discussed in post:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/
28945
A solution was proposed during brainstorming session in Warsaw.
1. Data structures.
The structure v4l2_crop used by current API lacks any place for further
extensions. Therefore new structure is proposed.
struct v4l2_selection {
u32 type;
u32 target;
struct v4l2_rect r;
u32 flags;
u32 reserved[9];
};
Where,
type- type of buffer queue: V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_BUF_TYPE_VIDEO_OUTPUT, etc.
target - choose one of cropping/composing rectangles
r - selection rectangle
flags - control over coordinates adjustments
reserved - place for further extensions, adjust struct size to 64 bytes
At first, the distinction between cropping and composing was stated. The
cropping operation means choosing only part of input data bounding it by
a cropping rectangle. All other data must be discarded. On the other
hand, composing means pasting processed data into rectangular part of
data sink. The sink may be output device, user buffer, etc.
2. Crop/Compose ioctl.
Four new ioctls would be added to V4L2.
Name
VIDIOC_S_EXTCROP - set cropping rectangle on an input of a device
Synopsis
int ioctl(fd, VIDIOC_S_EXTCROP, struct v4l2_selection *s)
Description:
The ioctl is used to configure:
- for input devices, a part of input data that is processed in hardware
- for output devices, a part of a data buffer to be passed to hardware
Drivers may adjust a cropping area. The adjustment can be controlled
by v4l2_selection::flags. Please refer to Hints section.
- an adjusted crop rectangle is returned in v4l2_selection::r
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
ERANGE - failed to find a rectangle that satisfy all constraints
EINVAL - incorrect buffer type, incorrect target, cropping not
supported
-
Name
VIDIOC_G_EXTCROP - get cropping rectangle on an input of a device
Synopsis
int ioctl(fd, VIDIOC_G_EXTCROP, struct v4l2_selection *s)
Description:
The ioctl is used to query:
- for input devices, a part of input data that is processed in hardware
Other crop rectangles might be examined using this ioctl.
Please refer to Targets section.
- for output devices, a part of data buffer to be passed to hardware
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
EINVAL - incorrect buffer type, incorrect target, cropping not
supported
-
Name
VIDIOC_S_COMPOSE - set destination rectangle on an output of a device
Synopsis
int ioctl(fd, VIDIOC_S_COMPOSE, struct v4l2_selection *s)
Description:
The ioctl is used to configure:
- for input devices, a part of a data buffer that is filled by hardware
- for output devices, a area on output device where image is inserted
Drivers may adjust a composing area. The adjustment can be controlled
by v4l2_selection::flags. Please refer to Hints section.
- an adjusted composing rectangle is returned in v4l2_selection::r
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
ERANGE - failed to find a rectangle that satisfy all constraints
EINVAL - incorrect buffer type, incorrect target, composing not
supported
[PATCH v3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers
Add the subdev driver for the MIPI CSIS units available in S5P and Exynos4 SoC series. This driver supports both CSIS0 and CSIS1 MIPI-CSI2 receivers. The driver requires Runtime PM to be enabled for proper operation. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Hello, this is a third version of the subdev driver for MIPI-CSI2 receivers available in S5PVx10 and EXYNOS4 SoCs. The MIPI CSIS module is a MIPI-CSI bus frontend of the FIMC IP. Changes since v1: - added runtime PM support - conversion to the pad ops Changes since v2: - added reference counting in s_stream op to allow the mipi-csi subdev to be shared by multiple FIMC instances - added support for TRY format in pad get_fmt op - added pm_runtime* calls in s_stream op to avoid a need for explicit s_power(1) call - corrected locking around the pad ops, minor bug fixes Comments are welcome! Regards, Sylwester Nawrocki Samsung Poland RD Center --- drivers/media/video/Kconfig |6 + drivers/media/video/s5p-fimc/Makefile|2 + drivers/media/video/s5p-fimc/mipi-csis.c | 756 ++ drivers/media/video/s5p-fimc/mipi-csis.h | 19 + 4 files changed, 783 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.c create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 55caa73..fd0bd68 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -955,6 +955,12 @@ config VIDEO_SAMSUNG_S5P_FIMC This is a v4l2 driver for the S5P and EXYNOS4 camera host interface and video postprocessor. +config VIDEO_S5P_MIPI_CSIS + tristate S5P and EXYNOS4 MIPI CSI Receiver driver + depends on VIDEO_V4L2 VIDEO_SAMSUNG_S5P_FIMC MEDIA_CONTROLLER + ---help--- + This is a v4l2 driver for the S5P/EXYNOS4 MIPI-CSI Receiver. + # # USB Multimedia device configuration # diff --git a/drivers/media/video/s5p-fimc/Makefile b/drivers/media/video/s5p-fimc/Makefile index 7ea1b14..72207de 100644 --- a/drivers/media/video/s5p-fimc/Makefile +++ b/drivers/media/video/s5p-fimc/Makefile @@ -1,3 +1,5 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) := s5p-fimc.o s5p-fimc-y := fimc-core.o fimc-reg.o fimc-capture.o + +obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += mipi-csis.o diff --git a/drivers/media/video/s5p-fimc/mipi-csis.c b/drivers/media/video/s5p-fimc/mipi-csis.c new file mode 100644 index 000..10e083e --- /dev/null +++ b/drivers/media/video/s5p-fimc/mipi-csis.c @@ -0,0 +1,756 @@ +/* + * Samsung S5P SoC series MIPI-CSI receiver driver + * + * Copyright (C) 2011 Samsung Electronics Co., Ltd. + * Contact: Sylwester Nawrocki, s.nawro...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + + +#include linux/clk.h +#include linux/delay.h +#include linux/device.h +#include linux/errno.h +#include linux/interrupt.h +#include linux/io.h +#include linux/irq.h +#include linux/kernel.h +#include linux/memory.h +#include linux/module.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/regulator/consumer.h +#include linux/slab.h +#include linux/spinlock.h +#include linux/videodev2.h +#include media/v4l2-subdev.h +#include plat/mipi_csis.h +#include mipi-csis.h + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, Debug level (0-1)); + +/* Register map definition */ + +/* CSIS global control */ +#define S5P_CSIS_CTRL 0x00 +#define S5P_CSIS_CTRL_DPDN_DEFAULT (0 31) +#define S5P_CSIS_CTRL_DPDN_SWAP(1 31) +#define S5P_CSIS_CTRL_ALIGN_32BIT (1 20) +#define S5P_CSIS_CTRL_UPDATE_SHADOW(1 16) +#define S5P_CSIS_CTRL_WCLK_EXTCLK (1 8) +#define S5P_CSIS_CTRL_RESET(1 4) +#define S5P_CSIS_CTRL_ENABLE (1 0) + +/* D-PHY control */ +#define S5P_CSIS_DPHYCTRL 0x04 +#define S5P_CSIS_DPHYCTRL_HSS_MASK (0x1f 27) +#define S5P_CSIS_DPHYCTRL_ENABLE (0x1f 0) + +#define S5P_CSIS_CONFIG0x08 +#define S5P_CSIS_CFG_FMT_YCBCR422_8BIT (0x1e 2) +#define S5P_CSIS_CFG_FMT_RAW8 (0x2a 2) +#define S5P_CSIS_CFG_FMT_RAW10 (0x2b 2) +#define S5P_CSIS_CFG_FMT_RAW12 (0x2c 2) +/* User defined formats, x = 1...4 */ +#define S5P_CSIS_CFG_FMT_USER(x) ((0x30 + x - 1) 2) +#define S5P_CSIS_CFG_FMT_MASK (0x3f 2) +#define S5P_CSIS_CFG_NR_LANE_MASK 3 + +/* Interrupt mask. */ +#define S5P_CSIS_INTMSK0x10 +#define S5P_CSIS_INTMSK_EN_ALL 0xf03f +#define S5P_CSIS_INTSRC0x14 + +/* Pixel resolution */ +#define S5P_CSIS_RESOL 0x2c +#define CSIS_MAX_PIX_WIDTH 0x
Prolink PixelView PlayTV D235U (DVB-T USB)
Hello, Is there any way to find out whether the Prolink PixelView PlayTV D235U DVB-T USB device is supported in Linux? http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices only has the Prolink Pixelview SBTVD; according to the Prolink website that is the D231U model. I wonder if these use the same chipset. -- Yours, Mikhail Ramendik Unless explicitly stated, all opinions in my mail are my own and do not reflect the views of any organization -- 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: fsl_viu: fix bug in streamon routine
Currently video capturing using streaming I/O method
doesn't work if capturing to overlay buffer took place
before.
When enabling the stream we have to check the overlay
enable driver flag and reset it so that the interrupt
handler won't execute the overlay interrupt path after
enabling DMA in streamon routine. Otherwise the capture
interrupt won't be handled correctly causing non working
VIDIOC_DQBUF ioctl.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
drivers/media/video/fsl-viu.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
index 031af16..4b2bba8 100644
--- a/drivers/media/video/fsl-viu.c
+++ b/drivers/media/video/fsl-viu.c
@@ -911,12 +911,16 @@ static int vidioc_dqbuf(struct file *file, void *priv,
struct v4l2_buffer *p)
static int vidioc_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
{
struct viu_fh *fh = priv;
+ struct viu_dev *dev = fh-dev;
if (fh-type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
if (fh-type != i)
return -EINVAL;
+ if (dev-ovenable)
+ dev-ovenable = 0;
+
viu_start_dma(fh-dev);
return videobuf_streamon(fh-vb_vidq);
--
1.7.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: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Am Freitag, den 08.04.2011, 15:27 +0200 schrieb Teresa Gamez: Hello Guennadi, Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi Liakhovetski: Hello Teresa On Thu, 7 Apr 2011, Teresa Gamez wrote: Hello Guennadi, the datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? Hm, yeah, looks like a typical example of a copy-paste datasheet to me:-( And now we don't know which of the two is actually supposed to be true. As for set up vs. valid - not sure, whether there is indeed a difference between them. To me set up _TO_ the rising edge is a short way to set set up to be valid at the rising edge, however, I might be wrong. Can you tell me in more detail what and where (at the sensor board or on the baseboard) you measured and what it looked like? I think, Figure 7 and the description below it are interesting. From that diagram I would indeed say indeed the DOUT pins are valid and should be sampled at the rising edge by default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING means, that the data should be sampled at the rising of pclkm, i.e., it is valid there. I meassured the outgoing pins from the baseboard to the camera board and checked the PCLK and D0 to see at which point the data is valid. I have also checked the quality of the image. All tests where made with sensor_type=color My results for pcm038 are with following register settings: mx2_camera 0x0 CSICR1: 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ugly image, wrong colors) Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx2_camera 0x0 CSICR1 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Now changed the PCLK of the mx2_camera: mx2_camera 0x0 CSICR1 0x10020b90 - falling edge mt9v022 0x74 PIXCLK_FV_LV0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) So, yes, if your measurements agree with figure 7 from the datasheet, we shall assume, that the driver implements the pclk polarity wrongly. But the fix should be more extensive, than what you've submitted: if we invert driver's behaviour, we should also invert board configuration of all driver users: pcm990 and pcm037. Or we have to test them and verify, that the inverted pclk polarity doesn't megatively affect the image quality, or maybe even improves it. Thanks Guennadi I have tested this with a pcm038 but I will also make meassurements with the pcm037. Same results with the pcm037: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV:0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ulgy image, looks like b/w with pixel errors) Set SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Additionally set MX3_CAMERA_PCP of the mx3_camera flags mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV:0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) Removed SOCAM_SENSOR_INVERT_PCLK flag for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: risging edge (ugly image, looks like the first one) I have noticed that on our pcm037 BSP the SOCAM_SENSOR_INVERT_PCLK flag for the camera was set to fix this issue. I will continue this test on the pcm990. Got the same result with the pcm990: pxa_camera 0x5010 CICR4: 0x00880001 - rising edge (0 22) mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (1 4) (which I think is falling edge) meassured: falling edge (some pixel have wrong colors) --- Now set the SOCAM_SENSOR_INVERT_PCLK for mt9v022: pxa_camera 0x5010 CICR4: 0x00880001 - rising edge (0 22) mt9v022 0x74 PIXCLK_FV_LV: 0x - falling edge (0 4) (which I think is rising edge) meassured: rising edge (image is
Re: [PATCH] tm6000: fix vbuf may be used uninitialized (Dmitri please read)
On 4/11/11, Jarod Wilson ja...@wilsonet.com wrote: So I was just circling back around on this one, and took some time to read the actual code and the radio support addition. After doing so, I don't see why the patch I proposed wouldn't do. The buffer is only manipulated if !dev-radio or if vbuf is non-NULL (the memcpy call). If its initialized to NULL, it only gets used exactly as it did before 8aff8ba9 when !dev-radio, and if its not been used or its NULL following manipulations protected by !dev-radio, it doesn't get copied. What is the real bug I am missing there? (Or did I already miss a patch posted to linux-media addressing it?) My laptop was stolen so I can't review code for the next couple weeks. I remember that I thought your patch looked correct, but I was hoping that Dmitri would Ack it. regards, dan carpenter -- 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: [PATCHES] Misc. trivial fixes
On 04/12/2011 04:10 AM, Robby Workman wrote: --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = /usr/share/man Why did you hardcode /usr instead of keeping $(PREFIX)/share/man? Regards, Andreas -- 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
RFQ3133:P/N: cxd2820 Q-ty: 10000 pcs
If you reply to this e-mail, please don't change the subject line content!!! Thank you in advance. Dear Sales, We are looking for the following: P/N: cxd2820 Q-ty: 1 pcs pls advise your best price. Pls advise the approximate shipping weight and delivery time. I appreciate your feedback. Sincerely, Gintare. UAB EURASIA LT Titnago str. 14,LT-02300 Vilnius, Lithuania Tel.: +370 (5) 205 84 00 E-mail: m...@iseurasia.com Web: http://www.iseurasia.com/ Co. Reg. No. : 300656274 VAT Reg. No.: LT13032613 == -- 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] v4l: Don't register media entities for subdev device nodes
Laurent Pinchart wrote:
Subdevs already have their own entity, don't register as second one when
registering the subdev device node.
Thanks for the patch!
Acked-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/v4l2-dev.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 498e674..6dc7196 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -389,7 +389,8 @@ static int v4l2_open(struct inode *inode, struct file
*filp)
video_get(vdev);
mutex_unlock(videodev_lock);
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev) {
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV) {
entity = media_entity_get(vdev-entity);
if (!entity) {
ret = -EBUSY;
@@ -415,7 +416,8 @@ err:
/* decrease the refcount in case of an error */
if (ret) {
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_entity_put(entity);
#endif
video_put(vdev);
@@ -437,7 +439,8 @@ static int v4l2_release(struct inode *inode, struct file
*filp)
mutex_unlock(vdev-lock);
}
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_entity_put(vdev-entity);
#endif
/* decrease the refcount unconditionally since the release()
@@ -686,7 +689,8 @@ int __video_register_device(struct video_device *vdev,
int type, int nr,
#if defined(CONFIG_MEDIA_CONTROLLER)
/* Part 5: Register the entity. */
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev) {
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV) {
vdev-entity.type = MEDIA_ENT_T_DEVNODE_V4L;
vdev-entity.name = vdev-name;
vdev-entity.v4l.major = VIDEO_MAJOR;
@@ -733,7 +737,8 @@ void video_unregister_device(struct video_device *vdev)
return;
#if defined(CONFIG_MEDIA_CONTROLLER)
- if (vdev-v4l2_dev vdev-v4l2_dev-mdev)
+ if (vdev-v4l2_dev vdev-v4l2_dev-mdev
+ vdev-vfl_type != VFL_TYPE_SUBDEV)
media_device_unregister_entity(vdev-entity);
#endif
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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
[GIT PULL FOR 2.6.39] MC, V4L2 and OMAP3 ISP fixes
Hi Mauro,
The following changes since commit 28df73703e738d8ae7a958350f74b08b2e9fe9ed:
[media] xc5000: Improve it to work better with 6MHz-spaced channels
(2011-03-28 15:49:28 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.git omap3isp-next-omap3isp
Those changes are either bug fixes (MC, V4L2 and OMAP3 ISP) or small
enhancements to the OMAP3 ISP driver ('omap3isp: ccdc: support Y10/12, 8-bit
bayer fmts' and 'omap3isp: lane shifter support'). The later won't cause any
regression, as the OMAP3 ISP driver will appear in 2.6.39 for the first time.
David Cohen (1):
omap3isp: stat: update struct ispstat_generic_config's comments
Laurent Pinchart (8):
media: Use correct ioctl name in MEDIA_IOC_SETUP_LINK documentation
omap3isp: resizer: Center the crop rectangle
omap3isp: resizer: Use 4-tap mode equations when the ratio is = 512
media: Properly handle link flags in link setup, link notify callback
omap3isp: isp: Reset the ISP when the pipeline can't be stopped
omap3isp: Don't increment node entity use count when poweron fails
v4l: Don't register media entities for subdev device nodes
omap3isp: queue: Don't corrupt buf-npages when get_user_pages() fails
Michael Jones (5):
omap3isp: Fix trivial typos
v4l: add V4L2_PIX_FMT_Y12 format
media: add missing 8-bit bayer formats and Y12
omap3isp: ccdc: support Y10/12, 8-bit bayer fmts
omap3isp: lane shifter support
Sakari Ailus (1):
omap3isp: resizer: Improved resizer rsz factor formula
Stanimir Varbanov (1):
omap3isp: Use isp xclk defines
Documentation/DocBook/media-entities.tmpl |1 +
Documentation/DocBook/v4l/media-ioc-setup-link.xml |2 +-
Documentation/DocBook/v4l/pixfmt-y12.xml | 79 ++
Documentation/DocBook/v4l/pixfmt.xml |1 +
Documentation/DocBook/v4l/subdev-formats.xml | 59 +++
drivers/media/media-entity.c |8 +-
drivers/media/video/omap3isp/isp.c | 38 +--
drivers/media/video/omap3isp/isp.h | 12 +-
drivers/media/video/omap3isp/ispccdc.c | 37 ++--
drivers/media/video/omap3isp/isppreview.c |2 +-
drivers/media/video/omap3isp/ispqueue.c|6 +-
drivers/media/video/omap3isp/ispresizer.c | 75 +++---
drivers/media/video/omap3isp/ispstat.h |6 +-
drivers/media/video/omap3isp/ispvideo.c| 108 ---
drivers/media/video/omap3isp/ispvideo.h|3 +
drivers/media/video/v4l2-dev.c | 15 ++-
include/linux/v4l2-mediabus.h |7 +-
include/linux/videodev2.h |1 +
18 files changed, 390 insertions(+), 70 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-y12.xml
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv1 PATCH 4/9] v4l2-ctrls: add per-control events.
Hi Hans,
Hans Verkuil wrote:
+ union {
+ __s32 value;
+ __s64 value64;
+ };
+} __attribute__ ((packed));
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
+ struct v4l2_event_ctrl_ch_value ctrl_ch_value;
__u8data[64];
} u;
__u32 pending;
__u32 sequence;
struct timespec timestamp;
- __u32 reserved[9];
+ __u32 id;
id is valid only for control related events. Shouldn't it be part of
the
control related structures instead, or another union for control
related
event types? E.g.
struct {
enum v4l2_ctrl_type id;
union {
struct v4l2_event_ctrl_ch_value ch_value;
};
} ctrl;
The problem with making this dependent of the type is that the core
event
code would have to have a switch on the event type when it comes to
matching identifiers. By making it a core field it doesn't have to do
this. Also, this makes it available for use by private events as well.
It is important to keep the send-event core code as fast as possible
since
it can be called from interrupt context.
So this is by design.
I understand your point, and agree with it. There would be a few places
in the v4l2-event.c that one would have to know if the event is
control-related or not.
As the id field is handled in the v4l2-event.c the way it is, it must be
zero when the event is not a control-related one. This makes it
impossible to use it for other purposes, at least for now.
What about renaming the field to ctrl_id? Or do you think we could have
other use for the field outside the scope of the control-related events?
I believe so, yes. For example per-input or per-output events (where id
refers to the input/output index) or per-pad events (where id refers to
the pad id). In general, the id field can be used as an object identifier.
If there are no 'objects' related to the event, then it has to be 0 as you
said.
Regards,
Hans
The benefit of the current name is still that it does not suggest
anything on the implementation.
Cheers,
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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
--
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: [PATCHES] Misc. trivial fixes
On Tue, 12 Apr 2011, Andreas Oberritter wrote: On 04/12/2011 04:10 AM, Robby Workman wrote: --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = /usr/share/man Why did you hardcode /usr instead of keeping $(PREFIX)/share/man? Eek. I'd like to say that I sent the wrong patch, but alas, I simply had a thinko. See attached (better) patch :-) -RWFrom 6ef4a1fecee242be9658528ef7663845d9bd6bc6 Mon Sep 17 00:00:00 2001 From: Robby Workman rwork...@slackware.com Date: Tue, 12 Apr 2011 09:26:57 -0500 Subject: [PATCH] Allow override of manpage installation directory This creates MANDIR in Make.rules and keeps the preexisting default of $(PREFIX)/share/man, but allows packagers to easily override via e.g. make MANDIR=/usr/man --- Make.rules |1 + utils/keytable/Makefile |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Make.rules b/Make.rules index 0bb2eb8..875828a 100644 --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = $(PREFIX)/share/man # These ones should not be overriden from the cmdline diff --git a/utils/keytable/Makefile b/utils/keytable/Makefile index 29a6ac4..e093280 100644 --- a/utils/keytable/Makefile +++ b/utils/keytable/Makefile @@ -39,7 +39,7 @@ install: $(TARGETS) install -m 644 -p rc_keymaps/* $(DESTDIR)/etc/rc_keymaps install -m 755 -d $(DESTDIR)/lib/udev/rules.d install -m 644 -p 70-infrared.rules $(DESTDIR)/lib/udev/rules.d - install -m 755 -d $(DESTDIR)$(PREFIX)/share/man/man1 - install -m 644 -p ir-keytable.1 $(DESTDIR)$(PREFIX)/share/man/man1 + install -m 755 -d $(DESTDIR)$(MANDIR)/man1 + install -m 644 -p ir-keytable.1 $(DESTDIR)$(MANDIR)/man1 include ../../Make.rules -- 1.7.4.4
Re: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
napisał(a):
Please find below a refreshed patch, which should be based on
mainline commit:
Hi,
This version works for me, and fixes the regression.
Ok, Thanks for testing.
Guennadi,
It's up to you if you want to take your patch or mine. I guess I just wanted
to be more complete in my patch, but strictly speaking about a regression
fix (And based on what the current popular apps do), both do the job.
This was just my proposal :).
Regards,
Sergio
Thanks,
Janusz
From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00
2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate
.sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a
possibility to calculate .sizeimage and .bytesperline pixel format
fields internally, however, some drivers relied on the core
calculating these values for them, following a default algorithm.
This patch restores the default calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 48
+ 1 files changed, 42
insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long
soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ + ((x) 24) 0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd,
pix-pixelformat);
+ if (!xlate)
+ return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+ pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file
*file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return ici-ops-try_fmt(icd, f);
+ return soc_camera_try_fmt(icd, f);
}
static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct
soc_camera_device *icd)
icd-user_formats = NULL;
}
-#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16)
0xff, \ - ((x) 24) 0xff
-
/* Called with .vb_lock held, or from the first open(2), see comment
there */ static int soc_camera_set_fmt(struct soc_camera_device
*icd, struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct
soc_camera_device *icd, pixfmtstr(pix-pixelformat), pix-width,
pix-height);
/* We always call try_fmt() before set_fmt() or set_crop() */
- ret = ici-ops-try_fmt(icd, f);
+ ret = soc_camera_try_fmt(icd, f);
if (ret 0)
return ret;
--
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 0/2] V4L: Extended crop/compose API, ver2
Hi Laurent,
Thank you for your comments.
Hi Hans, Tomasz,
On Monday 11 April 2011 12:42:10 Tomasz Stanislawski wrote:
Hans Verkuil wrote:
On Wednesday, April 06, 2011 10:44:17 Tomasz Stanislawski wrote:
Hello everyone,
This patch-set introduces new ioctls to V4L2 API. The new method for
configuration of cropping and composition is presented.
[snip]
3. Hints
The v4l2_selection::flags field is used to give a driver a hint about
coordinate adjustments. Below one can find the proposition of
adjustment flags. The syntax is V4L2_SEL_{name}_{LE/GE}, where {name}
refer to a field in struct v4l2_rect. Two additional properties exist
'right' and 'bottom'. The refer to respectively: left + width, and top
+ height. The LE is abbreviation from lesser or equal. It prevents
the driver form increasing a parameter. In similar fashion GE means
greater or equal and it disallows decreasing. Combining LE and GE
flags prevents the driver from any adjustments of parameters. In such
a manner, setting flags field to zero would give a driver a free hand
in coordinate adjustment.
#define V4L2_SEL_WIDTH_GE 0x0001
#define V4L2_SEL_WIDTH_LE 0x0002
#define V4L2_SEL_HEIGHT_GE 0x0004
#define V4L2_SEL_HEIGHT_LE 0x0008
#define V4L2_SEL_LEFT_GE 0x0010
#define V4L2_SEL_LEFT_LE 0x0020
#define V4L2_SEL_TOP_GE0x0040
#define V4L2_SEL_TOP_LE0x0080
#define V4L2_SEL_RIGHT_GE 0x0100
#define V4L2_SEL_RIGHT_LE 0x0200
#define V4L2_SEL_BOTTOM_GE 0x0400
#define V4L2_SEL_BOTTOM_LE 0x0800
#define V4L2_SEL_WIDTH_FIXED 0x0003
#define V4L2_SEL_HEIGHT_FIXED 0x000c
#define V4L2_SEL_LEFT_FIXED0x0030
#define V4L2_SEL_TOP_FIXED 0x00c0
#define V4L2_SEL_RIGHT_FIXED 0x0300
#define V4L2_SEL_BOTTOM_FIXED 0x0c00
#define V4L2_SEL_FIXED 0x0fff
The hint flags may be useful in a following scenario. There is a
sensor
with a face detection functionality. An application receives
information about a position of a face on sensor array. Assume
that the
camera pipeline is capable of an image scaling. The application is
capable of obtaining a location of a face using V4L2 controls. The
task
it to grab only part of image that contains a face, and store it to a
framebuffer at a fixed window. Therefore following constrains have to
be satisfied:
- the rectangle that contains a face must lay inside cropping area
- hardware is allowed only to access area inside window on the
framebuffer
Both constraints could be satisfied with two ioctl calls.
- VIDIOC_EXTCROP with flags field equal to
V4L2_SEL_TOP_LE | V4L2_SEL_LEFT_LE |
V4L2_SEL_RIGHT_GE | V4L2_SEL_BOTTOM_GE.
- VIDIOC_COMPOSE with flags field equal to
V4L2_SEL_TOP_FIXED | V4L2_SEL_LEFT_FIXED |
V4L2_SEL_WIDTH_LE | V4L2_SEL_HEIGHT_LE
Feel free to add a new flag if necessary.
While this is very flexible, I am a bit concerned about the complexity
this would introduce in a driver. I think I would want to see this
actually implemented in a driver first. I suspect that some utility
functions are probably needed.
I'm very concerned about that as well. Without hints, computing the
OMAP3 ISP
resizer configuration parameters in the driver is already very
complex. With
hints it would become even worse, close to impossible. I know that I
won't
have a month to spend on the implementation.
I think we will need a new helper function in V4L2 kernel API in order
to reduce complexity introduced by hints. This function would contain
typical business logic used to adjust cropping rectangle. It would use
structures similar
to struct v4l2_frmsizeenum to specify available ranges of rectangles'
sizes and offsets. The function would
also take hints flags and a rectangle provided by userspace. It would
return an adjusted rectangle.
Moreover, we will need a additional function in form:
u32 v4l2_rect_verify_constraints(struct v4l2_rect *desired, struct
v4l2_rect *proposed);
that checks which constraints are satisfied by 'proposed' rectangle
relative to 'desired' rectangle.
If returned hints have a zero bit that is set in user hints then EINVAL
is returned. Additionally, if
ioctl was called in TRY mode then v4l2_selection::r is substituted with
a rectangle proposed by a driver.
Other solution would be introduction of an ioctl similar to
VIDIOC_ENUM_FRAMESIZES but dedicated for cropping/composing. This way a
business logic could be partially exported to a userspace.
I will try to prepare an RFC about it.
Do you have any suggestions?
Please look below for comments about S_FMT stuff.
4. Targets
The cropping/composing subsystem may use auxiliary rectangles
other than
a normal cropping rectangle. The field v4l2_selection::target is used
to choose the rectangle. This functionality was added to simulate
VIDIOC_CROPCAP ioctl. All cropcap fields except pixel aspect are
Re: cx231xx: add support for Kworld..
On Apr 11, 2011, at 6:57 PM, Márcio Alves wrote: patch to cx231xx: add support for Kworld UB430 Signed-off-by: Márcio A Alves fr...@gmail.com diff -upr ../new_build2/linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h --- ../new_build2/linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-02-28 01:45:23.0 -0300 +++ linux//drivers/media/dvb/dvb-usb/dvb-usb-ids.h2011-04-11 14:23:31.836858001 -0300 @@ -125,6 +125,7 @@ #define USB_PID_GRANDTEC_DVBT_USB_COLD 0x0fa0 #define USB_PID_GRANDTEC_DVBT_USB_WARM 0x0fa1 #define USB_PID_INTEL_CE9500 0x9500 +#define USB_PID_KWORLD_UB430 0xe424 #define USB_PID_KWORLD_399U 0xe399 #define USB_PID_KWORLD_399U_20xe400 #define USB_PID_KWORLD_395U 0xe396 That addition does nothing, since cx231xx-*.c don't include that header. Its only for use by drivers under dvb-usb/. Just leave this out. ... diff -upr ../new_build2/linux//drivers/media/video/cx231xx/cx231xx.h linux//drivers/media/video/cx231xx/cx231xx.h --- ../new_build2/linux//drivers/media/video/cx231xx/cx231xx.h 2011-03-11 13:25:49.0 -0300 +++ linux//drivers/media/video/cx231xx/cx231xx.h 2011-04-11 14:20:30.616858003 -0300 @@ -64,7 +64,8 @@ #define CX231XX_BOARD_HAUPPAUGE_EXETER 8 #define CX231XX_BOARD_HAUPPAUGE_USBLIVE2 9 #define CX231XX_BOARD_PV_PLAYTV_USB_HYBRID 10 -#define CX231XX_BOARD_PV_XCAPTURE_USB 11 +#define CX231XX_BOARD_KWORLD_UB430_USB_HYBRID 11 +#define CX231XX_BOARD_PV_XCAPTURE_USB 12 /* Limits minimum and default number of buffers */ #define CX231XX_MIN_BUF 4 You should add to the end of the list, as device 12, not move an already existing device. Those two minor nits aside, the patch looks sane. -- Jarod Wilson ja...@wilsonet.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
Genius webcam problem on ARM
Hello, I have problem with UVC webcam. It's Genius Facecam 1000. I would like to use it with mjpg-streamer. Before this model, I had Facecam 1320, but it wasn't mjpeg capable, so mjpg-streamer had to do jpeg compresion and it was quite slow. Facecam 1000 can provide mjpg stream by itself and it works great on x86, but it doesn't work on ARM. To exclude problem in mjpg-streamer I compiled v4l capture example (http://v4l2spec.bytesex.org/spec-single/v4l2.html#CAPTURE-EXAMPLE) and it's same - works on x86 a not on ARM. On embedded platform I'm using AT91SAM9260 (Olimex kit L9260) which has USB2.0, but only full-speed - is it problem? I don't think so - previous webcam works great. On x86 I use kernel 2.6.35 and glibc. On ARM there is kernel 2.6.33.7.2-rt30 and uClibc. v4l example fails with this error: VIDIOC_STREAMON error 5, Input/output error webcam is detected correctly: [ 2042.10] usb 1-1: new full speed USB device using at91_ohci and address 3 [ 2042.29] usb 1-1: New USB device found, idVendor=0458, idProduct=707e [ 2042.29] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2042.31] usb 1-1: Product: FaceCam 1000 [ 2042.32] usb 1-1: Manufacturer: KYE SYSTEMS CORP. [ 2042.40] uvcvideo: Found UVC 1.00 device FaceCam 1000 (0458:707e) [ 2042.46] input: FaceCam 1000 as /devices/platform/at91_ohci/usb1/1-1/1-1:1.0/input/input1 Thanks for any advice! Best regards Zdenek Materna -- 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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
Dnia wtorek 12 kwiecień 2011 o 17:39:35 Aguirre, Sergio napisał(a): On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio napisał(a): Please find below a refreshed patch, which should be based on mainline commit: Hi, This version works for me, and fixes the regression. Ok, Thanks for testing. I forgot to mention: the patch didn't apply cleanly, I had to unwrap a few lines manually, so you may want to resend it unwrapped. Thanks, Janusz -- 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] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
2011/4/12 Janusz Krzysztofik jkrzy...@tis.icnet.pl:
Dnia wtorek 12 kwiecień 2011 o 17:39:35 Aguirre, Sergio napisał(a):
On Mon, Apr 11, 2011 at 4:52 PM, Janusz Krzysztofik
jkrzy...@tis.icnet.pl wrote:
Dnia poniedziałek 11 kwiecień 2011 o 22:05:35 Aguirre, Sergio
napisał(a):
Please find below a refreshed patch, which should be based on
mainline commit:
Hi,
This version works for me, and fixes the regression.
Ok, Thanks for testing.
I forgot to mention: the patch didn't apply cleanly, I had to unwrap a
few lines manually, so you may want to resend it unwrapped.
Hmm,
I think that's a problem with my mail servers :/
Anyways, I'm attaching it now. Hopefully that's unwrapped.
Regards,
Sergio
Thanks,
Janusz
From f767059c12c755ebe79c4b74de17c23a257007c7 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre saagui...@ti.com
Date: Mon, 11 Apr 2011 11:14:33 -0500
Subject: [PATCH] V4L: soc-camera: regression fix: calculate .sizeimage in soc_camera.c
A recent patch has given individual soc-camera host drivers a possibility
to calculate .sizeimage and .bytesperline pixel format fields internally,
however, some drivers relied on the core calculating these values for
them, following a default algorithm. This patch restores the default
calculation for such drivers.
Based on initial patch by Guennadi Liakhovetski, found here:
http://www.spinics.net/lists/linux-media/msg31282.html
Except that this covers try_fmt aswell.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c | 48 +
1 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 4628448..dcc6623 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -136,11 +136,50 @@ unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
+#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16) 0xff, \
+ ((x) 24) 0xff
+
+static int soc_camera_try_fmt(struct soc_camera_device *icd,
+ struct v4l2_format *f)
+{
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct v4l2_pix_format *pix = f-fmt.pix;
+ int ret;
+
+ dev_dbg(icd-dev, TRY_FMT(%c%c%c%c, %ux%u)\n,
+ pixfmtstr(pix-pixelformat), pix-width, pix-height);
+
+ pix-bytesperline = 0;
+ pix-sizeimage = 0;
+
+ ret = ici-ops-try_fmt(icd, f);
+ if (ret 0)
+ return ret;
+
+ if (!pix-sizeimage) {
+ if (!pix-bytesperline) {
+ const struct soc_camera_format_xlate *xlate;
+
+ xlate = soc_camera_xlate_by_fourcc(icd, pix-pixelformat);
+ if (!xlate)
+return -EINVAL;
+
+ ret = soc_mbus_bytes_per_line(pix-width,
+ xlate-host_fmt);
+ if (ret 0)
+pix-bytesperline = ret;
+ }
+ if (pix-bytesperline)
+ pix-sizeimage = pix-bytesperline * pix-height;
+ }
+
+ return 0;
+}
+
static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct soc_camera_device *icd = file-private_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
WARN_ON(priv != file-private_data);
@@ -149,7 +188,7 @@ static int soc_camera_try_fmt_vid_cap(struct file *file, void *priv,
return -EINVAL;
/* limit format to hardware capabilities */
- return ici-ops-try_fmt(icd, f);
+ return soc_camera_try_fmt(icd, f);
}
static int soc_camera_enum_input(struct file *file, void *priv,
@@ -362,9 +401,6 @@ static void soc_camera_free_user_formats(struct soc_camera_device *icd)
icd-user_formats = NULL;
}
-#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16) 0xff, \
- ((x) 24) 0xff
-
/* Called with .vb_lock held, or from the first open(2), see comment there */
static int soc_camera_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
@@ -377,7 +413,7 @@ static int soc_camera_set_fmt(struct soc_camera_device *icd,
pixfmtstr(pix-pixelformat), pix-width, pix-height);
/* We always call try_fmt() before set_fmt() or set_crop() */
- ret = ici-ops-try_fmt(icd, f);
+ ret = soc_camera_try_fmt(icd, f);
if (ret 0)
return ret;
--
1.7.0.4
Re: Genius webcam problem on ARM
Hello again, now I discovered, that it's possible to change module parameters even if they are compiled in kernel... So I did: echo 2 /sys/module/uvcvideo/parameters/quirks And v4l example now ends like this: VIDIOC_S_FMT error 28, No space left on device Error No space left indicates problem with USB bandwidth? How can I solve it? I tried to change resolution in v4l example from 640x480 to 160x120 but it didn't help. Dne 12. dubna 2011 18:37 Zdeněk Materna zdenek.mate...@gmail.com napsal(a): Hello, I have problem with UVC webcam. It's Genius Facecam 1000. I would like to use it with mjpg-streamer. Before this model, I had Facecam 1320, but it wasn't mjpeg capable, so mjpg-streamer had to do jpeg compresion and it was quite slow. Facecam 1000 can provide mjpg stream by itself and it works great on x86, but it doesn't work on ARM. To exclude problem in mjpg-streamer I compiled v4l capture example (http://v4l2spec.bytesex.org/spec-single/v4l2.html#CAPTURE-EXAMPLE) and it's same - works on x86 a not on ARM. On embedded platform I'm using AT91SAM9260 (Olimex kit L9260) which has USB2.0, but only full-speed - is it problem? I don't think so - previous webcam works great. On x86 I use kernel 2.6.35 and glibc. On ARM there is kernel 2.6.33.7.2-rt30 and uClibc. v4l example fails with this error: VIDIOC_STREAMON error 5, Input/output error webcam is detected correctly: [ 2042.10] usb 1-1: new full speed USB device using at91_ohci and address 3 [ 2042.29] usb 1-1: New USB device found, idVendor=0458, idProduct=707e [ 2042.29] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2042.31] usb 1-1: Product: FaceCam 1000 [ 2042.32] usb 1-1: Manufacturer: KYE SYSTEMS CORP. [ 2042.40] uvcvideo: Found UVC 1.00 device FaceCam 1000 (0458:707e) [ 2042.46] input: FaceCam 1000 as /devices/platform/at91_ohci/usb1/1-1/1-1:1.0/input/input1 Thanks for any advice! Best regards Zdenek Materna -- 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: Genius webcam problem on ARM
Hello, I'm sorry for another mail. It works with quirks 128 and uncompressed YUV format. Is there any way how to use compressed MJPEG? Should I try compile never uvcvideo driver? Dne 12. dubna 2011 18:55 Zdeněk Materna zdenek.mate...@gmail.com napsal(a): Hello again, now I discovered, that it's possible to change module parameters even if they are compiled in kernel... So I did: echo 2 /sys/module/uvcvideo/parameters/quirks And v4l example now ends like this: VIDIOC_S_FMT error 28, No space left on device Error No space left indicates problem with USB bandwidth? How can I solve it? I tried to change resolution in v4l example from 640x480 to 160x120 but it didn't help. Dne 12. dubna 2011 18:37 Zdeněk Materna zdenek.mate...@gmail.com napsal(a): Hello, I have problem with UVC webcam. It's Genius Facecam 1000. I would like to use it with mjpg-streamer. Before this model, I had Facecam 1320, but it wasn't mjpeg capable, so mjpg-streamer had to do jpeg compresion and it was quite slow. Facecam 1000 can provide mjpg stream by itself and it works great on x86, but it doesn't work on ARM. To exclude problem in mjpg-streamer I compiled v4l capture example (http://v4l2spec.bytesex.org/spec-single/v4l2.html#CAPTURE-EXAMPLE) and it's same - works on x86 a not on ARM. On embedded platform I'm using AT91SAM9260 (Olimex kit L9260) which has USB2.0, but only full-speed - is it problem? I don't think so - previous webcam works great. On x86 I use kernel 2.6.35 and glibc. On ARM there is kernel 2.6.33.7.2-rt30 and uClibc. v4l example fails with this error: VIDIOC_STREAMON error 5, Input/output error webcam is detected correctly: [ 2042.10] usb 1-1: new full speed USB device using at91_ohci and address 3 [ 2042.29] usb 1-1: New USB device found, idVendor=0458, idProduct=707e [ 2042.29] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2042.31] usb 1-1: Product: FaceCam 1000 [ 2042.32] usb 1-1: Manufacturer: KYE SYSTEMS CORP. [ 2042.40] uvcvideo: Found UVC 1.00 device FaceCam 1000 (0458:707e) [ 2042.46] input: FaceCam 1000 as /devices/platform/at91_ohci/usb1/1-1/1-1:1.0/input/input1 Thanks for any advice! Best regards Zdenek Materna -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Apr 12 19:00:30 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 v2] tm6000: fix vbuf may be used uninitialized
In commit 8aff8ba95155df, most of the manipulations to vbuf inside copy_streams were gated on if !dev-radio, but one place that touches vbuf lays outside those gates -- a memcpy of vbuf isn't NULL. If we initialize vbuf to NULL, that memcpy will never happen in the case where we do have dev-radio, and otherwise, in the !dev-radio case, the code behaves exactly like it did prior to 8aff8ba95155df. While we're at it, also fix an incorrectly indented closing brace for one of the sections touching vbuf that is conditional on !dev-radio. v2: add a detailed commit log and fix that brace CC: Dan Carpenter erro...@gmail.com CC: Dmitri Belimov d.beli...@gmail.com CC: de...@driverdev.osuosl.org Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/staging/tm6000/tm6000-video.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-video.c b/drivers/staging/tm6000/tm6000-video.c index c80a316..8b971a0 100644 --- a/drivers/staging/tm6000/tm6000-video.c +++ b/drivers/staging/tm6000/tm6000-video.c @@ -228,7 +228,7 @@ static int copy_streams(u8 *data, unsigned long len, unsigned long header = 0; int rc = 0; unsigned int cmd, cpysize, pktsize, size, field, block, line, pos = 0; - struct tm6000_buffer *vbuf; + struct tm6000_buffer *vbuf = NULL; char *voutp = NULL; unsigned int linewidth; @@ -318,7 +318,7 @@ static int copy_streams(u8 *data, unsigned long len, if (pos + size vbuf-vb.size) cmd = TM6000_URB_MSG_ERR; dev-isoc_ctl.vfield = field; - } + } break; case TM6000_URB_MSG_VBI: break; -- 1.7.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: [RFC] V4L2 API for flash devices
Here are two more use-cases for flash that might help inform the API design. Sakari encouraged me to post these. The person writing this is Andrew Adams, but I'm sending this from Sung Hee's account, because I only just subscribed to linux-media and can't immediately figure out how to reply to messages from before I subscribed. Sung Hee and I are both grad students at Stanford who work on FCam (http://fcam.garage.maemo.org/) Second-curtain-sync: Sometimes you want to fire the flash at the end of a long exposure time. It's usually a way to depict motion. Here's an example: http://www.flickr.com/photos/latitudes/133206615/. This only really applies to xenon flashes because you can't get a crisp image out of a longer duration LED flash. Even then it's somewhat problematic on rolling-shutter sensors but still possible provided you don't mind a slight shear to the crisp part of the image. From an API perspective, it requires you to be able to specify a trigger time at some number of microseconds into the exposure. On the N900 we did this with a real-time thread. Triggering external hardware: This use-case is a little weirder, but it has the same API requirement. Some photographic setups require you to synchronize some piece of hardware with the exposure (e.g. an oscilloscope, or an external slave flash). On embedded devices this is generally difficult. If you can at least fire the flash at a precise delay into the exposure, you can attach a photodiode to it, and use the flash+photodiode as an opto-isolator to trigger your external hardware. So we're in favor of having user-settable flash duration, and also user-settable trigger times (with reference to the start of the exposure time). I'm guessing that in a SMIA++ driver the trigger time would actually be a control on the sensor device, but it seemed relevant to bring up while you guys were talking about the flash API. - Andrew On Mon, Mar 28, 2011 at 5:55 AM, Sakari Ailus sakari.ai...@maxwell.research.nokia.com wrote: Hi, This is a proposal for an interface for controlling flash devices on the V4L2/v4l2_subdev APIs. My plan is to use the interface in the ADP1653 driver, the flash controller used in the Nokia N900. Comments and questions are very, very welcome! Scope = This RFC is focused mostly on the ADP1653 [1] and similar chips [2, 3] which provides following functionality. [2, 3] mostly differ on the available faults --- for example, there are faults also for the indicator LED. - High power LED output (flash or torch modes) - Low power indicator LED output (a.k.a. privacy light) - Programmable flash timeout - Software and hardware strobe - Fault detection - Overvoltage - Overtemperature - Short circuit - Timeout - Programmable current (both high-power and indicator LEDs) If anyone else is aware of hardware which significantly differs from these and does not get served well under the proposed interface, please tell about it. This RFC does NOT address the synchronisation of the flash to a given frame since this task is typically performed by the sensor through a strobe signal. The host does not have enough information for this --- exact timing information on the exposure of the sensor pixel array. In this case the flash synchronisation is visible to the flash controller as the hardware strobe originating from the sensor. Flash synchronisation requires 1) flash control capability from the sensor including a strobe output, 2) strobe input in the flash controller, 3) (optionally) ability to program sensor parameters at given frame, such as flash strobe, and 4) ability to read back metadata produced by the sensor related to a given frame. This should include whether the frame is exposed with flash, i.e. the sensor's flash strobe output. Since we have little examples of both in terms of hardware support, which is in practice required, it was decided to postpone the interface specification for now. [6] Xenon flash controllers exist but I don't have a specific example of those. Typically the interface is quite simple. Gpio pins for charge and strobe. The length of the strobe signal determines the strength of the flash pulse. The strobe is controlled by the sensor as for LED flash if it is hardware based. Known use cases === The use case listed below concentrate on using a flash in a mobile device, for example in a mobile phone. The use cases could be somewhat different in devices the primary use of which is camera. Unsynchronised LED flash (software strobe) -- Unsynchronised LED flash is controlled directly by the host as the sensor. The flash must be enabled by the host before the exposure of the image starts and disabled once it ends. The host is fully responsible for the timing of the flash. Example of such device: Nokia N900. Synchronised LED flash (hardware strobe)
[RFC PATCH] input: add KEY_IMAGES specifically for AL Image Browser
Many media center remotes have buttons intended for jumping straight to
one type of media browser or another -- commonly, images/photos/pictures,
audio/music, television, and movies. At present, remotes with an images
or photos or pictures button use any number of different keycodes which
sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA is
used in a lot of webcams, and typically means take a picture now.
KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
might be the closest fit here, if you think photo slide show, but it
may well be more intended for run application in full-screen
presentation mode or to launch something like magicpoint, I dunno.
And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
Image Browser, the meaning of which I think is crystal-clear. I believe
AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
by KEY_VIDEO, so I'm also adding appropriate comments next to those
keys.
I have follow-on patches for drivers/hid/hid-input.c and for
drivers/media/rc/* that make use of this new key, if its deemed
appropriate for addition. To make it simpler to merge the additional
patches, it would be nice if this could sneak into 2.6.39, and the
rest can then get queued up for 2.6.40, avoiding any multi-tree
integration headaches.
CC: Dmitry Torokhov dmitry.torok...@gmail.com
CC: Jiri Kosina jkos...@suse.cz
CC: Linux Media linux-media@vger.kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
include/linux/input.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index e428382..be082e9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -553,8 +553,8 @@ struct input_keymap_entry {
#define KEY_DVD0x185 /* Media Select DVD */
#define KEY_AUX0x186
#define KEY_MP30x187
-#define KEY_AUDIO 0x188
-#define KEY_VIDEO 0x189
+#define KEY_AUDIO 0x188 /* AL Audio Browser */
+#define KEY_VIDEO 0x189 /* AL Movie Browser */
#define KEY_DIRECTORY 0x18a
#define KEY_LIST 0x18b
#define KEY_MEMO 0x18c /* Media Select Messages */
@@ -605,6 +605,7 @@ struct input_keymap_entry {
#define KEY_MEDIA_REPEAT 0x1b7 /* Consumer - transport control */
#define KEY_10CHANNELSUP0x1b8 /* 10 channels up (10+) */
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
+#define KEY_IMAGES 0x1ba /* AL Image Browser */
#define KEY_DEL_EOL0x1c0
#define KEY_DEL_EOS0x1c1
--
1.7.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 0/2] [media] nuvoton-cir: support more hardware variants
There are some additional Nuvoton LPC Super I/O chips that report the PNP device ID the nuvoton-cir driver binds to, and we *should* be able to support them all. This gets us closer... Jarod Wilson (2): [media] rc/nuvoton-cir: only warn about unknown chips [media] rc/nuvoton-cir: enable CIR on w83667hg chip variant drivers/media/rc/nuvoton-cir.c | 51 +-- drivers/media/rc/nuvoton-cir.h | 13 -- 2 files changed, 53 insertions(+), 11 deletions(-) -- 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 1/2] [media] rc/nuvoton-cir: only warn about unknown chips
There are additional chip IDs that report a PNP ID of NTN0530, which we
were refusing to load on. Instead, lets just warn if we encounter an
unknown chip, as there's a chance it will work just fine.
Also, expand the list of known hardware to include both an earlier and a
later generation chip that this driver should function with. Douglas has
an older w83667hg variant, that with a touch more work, will be
supported by this driver, and Lutz has a newer w83677hg variant that
works without any further modifications to the driver.
Reported-by: Douglas Clowes dclow...@optusnet.com.au
Reported-by: Lutz Sammer john...@gmx.net
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/nuvoton-cir.c | 40
drivers/media/rc/nuvoton-cir.h | 10 +++---
2 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index d4d6449..bc5c1e2 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -37,8 +37,6 @@
#include nuvoton-cir.h
-static char *chip_id = w836x7hg;
-
/* write val to config reg */
static inline void nvt_cr_write(struct nvt_dev *nvt, u8 val, u8 reg)
{
@@ -233,6 +231,8 @@ static int nvt_hw_detect(struct nvt_dev *nvt)
unsigned long flags;
u8 chip_major, chip_minor;
int ret = 0;
+ char chip_id[12];
+ bool chip_unknown = false;
nvt_efm_enable(nvt);
@@ -246,15 +246,39 @@ static int nvt_hw_detect(struct nvt_dev *nvt)
}
chip_minor = nvt_cr_read(nvt, CR_CHIP_ID_LO);
- nvt_dbg(%s: chip id: 0x%02x 0x%02x, chip_id, chip_major, chip_minor);
- if (chip_major != CHIP_ID_HIGH ||
- (chip_minor != CHIP_ID_LOW chip_minor != CHIP_ID_LOW2)) {
- nvt_pr(KERN_ERR, %s: unsupported chip, id: 0x%02x 0x%02x,
- chip_id, chip_major, chip_minor);
- ret = -ENODEV;
+ /* these are the known working chip revisions... */
+ switch (chip_major) {
+ case CHIP_ID_HIGH_667:
+ strcpy(chip_id, w83667hg\0);
+ if (chip_minor != CHIP_ID_LOW_667)
+ chip_unknown = true;
+ break;
+ case CHIP_ID_HIGH_677B:
+ strcpy(chip_id, w83677hg\0);
+ if (chip_minor != CHIP_ID_LOW_677B2
+ chip_minor != CHIP_ID_LOW_677B3)
+ chip_unknown = true;
+ break;
+ case CHIP_ID_HIGH_677C:
+ strcpy(chip_id, w83677hg-c\0);
+ if (chip_minor != CHIP_ID_LOW_677C)
+ chip_unknown = true;
+ break;
+ default:
+ strcpy(chip_id, w836x7hg\0);
+ chip_unknown = true;
+ break;
}
+ /* warn, but still let the driver load, if we don't know this chip */
+ if (chip_unknown)
+ nvt_pr(KERN_WARNING, %s: unknown chip, id: 0x%02x 0x%02x,
+ it may not work..., chip_id, chip_major, chip_minor);
+ else
+ nvt_dbg(%s: chip id: 0x%02x 0x%02x,
+ chip_id, chip_major, chip_minor);
+
nvt_efm_disable(nvt);
spin_lock_irqsave(nvt-nvt_lock, flags);
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index 048135e..cc8cee3 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -330,9 +330,13 @@ struct nvt_dev {
#define EFER_EFM_DISABLE 0xaa
/* Chip IDs found in CR_CHIP_ID_{HI,LO} */
-#define CHIP_ID_HIGH 0xb4
-#define CHIP_ID_LOW0x72
-#define CHIP_ID_LOW2 0x73
+#define CHIP_ID_HIGH_667 0xa5
+#define CHIP_ID_HIGH_677B 0xb4
+#define CHIP_ID_HIGH_677C 0xc3
+#define CHIP_ID_LOW_6670x13
+#define CHIP_ID_LOW_677B2 0x72
+#define CHIP_ID_LOW_677B3 0x73
+#define CHIP_ID_LOW_677C 0x33
/* Config regs we need to care about */
#define CR_SOFTWARE_RESET 0x02
--
1.7.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 2/2] [media] rc/nuvoton-cir: enable CIR on w83667hg chip variant
Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The already-supported w83677hg hardware has CIR
enabled out of the box, and the relevant bits of register 0x2c have a
completely different meaning, so we only poke them on the 667.
Reported-by: Douglas Clowes dclow...@optusnet.com.au
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/nuvoton-cir.c | 11 +++
drivers/media/rc/nuvoton-cir.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index bc5c1e2..4ebda1c 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -299,6 +299,17 @@ static void nvt_cir_ldev_init(struct nvt_dev *nvt)
val |= (OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB);
nvt_cr_write(nvt, val, CR_OUTPUT_PIN_SEL);
+ /*
+* multifunction pin selection, on w83677hg, these are fan headers
+* config bits we don't need to touch, but on w83667hg, the two high
+* bits must be set to 10 to enable the CIR function
+*/
+ val = nvt_cr_read(nvt, CR_MULTIFUNC_PIN_SEL);
+ val = MULTIFUNC_PIN_SEL_MASK;
+ val |= MULTIFUNC_ENABLE_CIR;
+ if (nvt-chip_major == CHIP_ID_HIGH_667)
+ nvt_cr_write(nvt, val, CR_MULTIFUNC_PIN_SEL);
+
/* Select CIR logical device and enable */
nvt_select_logical_dev(nvt, LOGICAL_DEV_CIR);
nvt_cr_write(nvt, LOGICAL_DEV_ENABLE, CR_LOGICAL_DEV_EN);
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index cc8cee3..41b3545 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -345,6 +345,7 @@ struct nvt_dev {
#define CR_CHIP_ID_LO 0x21
#define CR_DEV_POWER_DOWN 0x22 /* bit 2 is CIR power, default power on */
#define CR_OUTPUT_PIN_SEL 0x27
+#define CR_MULTIFUNC_PIN_SEL 0x2c
#define CR_LOGICAL_DEV_EN 0x30 /* valid for all logical devices */
/* next three regs valid for both the CIR and CIR_WAKE logical devices */
#define CR_CIR_BASE_ADDR_HI0x60
@@ -369,8 +370,10 @@ struct nvt_dev {
#define PME_INTR_CIR_PASS_BIT 0x08
#define OUTPUT_PIN_SEL_MASK0xbc
+#define MULTIFUNC_PIN_SEL_MASK 0xbf
#define OUTPUT_ENABLE_CIR 0x01 /* Pin95=CIRRX, Pin96=CIRTX1 */
#define OUTPUT_ENABLE_CIRWB0x40 /* enable wide-band sensor */
+#define MULTIFUNC_ENABLE_CIR 0x80 /* Pin75 and Pin76 on w83667hg */
/* MCE CIR signal length, related on sample period */
--
1.7.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: [RFC PATCH] input: add KEY_IMAGES specifically for AL Image Browser
Jarod Wilson ja...@redhat.com wrote:
Many media center remotes have buttons intended for jumping straight to
one type of media browser or another -- commonly,
images/photos/pictures,
audio/music, television, and movies. At present, remotes with an images
or photos or pictures button use any number of different keycodes which
sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite
right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA is
used in a lot of webcams, and typically means take a picture now.
KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
might be the closest fit here, if you think photo slide show, but it
may well be more intended for run application in full-screen
presentation mode or to launch something like magicpoint, I dunno.
And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
Image Browser, the meaning of which I think is crystal-clear. I believe
AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
by KEY_VIDEO, so I'm also adding appropriate comments next to those
keys.
I have follow-on patches for drivers/hid/hid-input.c and for
drivers/media/rc/* that make use of this new key, if its deemed
appropriate for addition. To make it simpler to merge the additional
patches, it would be nice if this could sneak into 2.6.39, and the
rest can then get queued up for 2.6.40, avoiding any multi-tree
integration headaches.
CC: Dmitry Torokhov dmitry.torok...@gmail.com
CC: Jiri Kosina jkos...@suse.cz
CC: Linux Media linux-media@vger.kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
include/linux/input.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index e428382..be082e9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -553,8 +553,8 @@ struct input_keymap_entry {
#define KEY_DVD 0x185 /* Media Select DVD */
#define KEY_AUX 0x186
#define KEY_MP3 0x187
-#define KEY_AUDIO 0x188
-#define KEY_VIDEO 0x189
+#define KEY_AUDIO 0x188 /* AL Audio Browser */
+#define KEY_VIDEO 0x189 /* AL Movie Browser */
#define KEY_DIRECTORY 0x18a
#define KEY_LIST 0x18b
#define KEY_MEMO 0x18c /* Media Select Messages */
@@ -605,6 +605,7 @@ struct input_keymap_entry {
#define KEY_MEDIA_REPEAT 0x1b7 /* Consumer - transport control */
#define KEY_10CHANNELSUP0x1b8 /* 10 channels up (10+) */
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
+#define KEY_IMAGES0x1ba /* AL Image Browser */
#define KEY_DEL_EOL 0x1c0
#define KEY_DEL_EOS 0x1c1
--
1.7.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
Maybe Launch instead of AL in the comments. It took me a while to figure
out AL even with the email context.
Regards,
Andy
--
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] input: add KEY_IMAGES specifically for AL Image Browser
Andy Walls wrote:
Jarod Wilsonja...@redhat.com wrote:
Many media center remotes have buttons intended for jumping straight to
one type of media browser or another -- commonly,
images/photos/pictures,
audio/music, television, and movies. At present, remotes with an images
or photos or pictures button use any number of different keycodes which
sort of maybe fit. I've seen at least KEY_MEDIA, KEY_CAMERA,
KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those seem quite
right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA is
used in a lot of webcams, and typically means take a picture now.
KEY_GRAPHICSEDITOR implies an editor, not a browser. KEY_PRESENTATION
might be the closest fit here, if you think photo slide show, but it
may well be more intended for run application in full-screen
presentation mode or to launch something like magicpoint, I dunno.
And thus, I'd like to have a KEY_IMAGES, which matches the HID Usage AL
Image Browser, the meaning of which I think is crystal-clear. I believe
AL Audio Browser is already covered by KEY_AUDIO, and AL Movie Browser
by KEY_VIDEO, so I'm also adding appropriate comments next to those
keys.
I have follow-on patches for drivers/hid/hid-input.c and for
drivers/media/rc/* that make use of this new key, if its deemed
appropriate for addition. To make it simpler to merge the additional
patches, it would be nice if this could sneak into 2.6.39, and the
rest can then get queued up for 2.6.40, avoiding any multi-tree
integration headaches.
CC: Dmitry Torokhovdmitry.torok...@gmail.com
CC: Jiri Kosinajkos...@suse.cz
CC: Linux Medialinux-media@vger.kernel.org
Signed-off-by: Jarod Wilsonja...@redhat.com
---
include/linux/input.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index e428382..be082e9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -553,8 +553,8 @@ struct input_keymap_entry {
#define KEY_DVD 0x185 /* Media Select DVD */
#define KEY_AUX 0x186
#define KEY_MP3 0x187
-#define KEY_AUDIO 0x188
-#define KEY_VIDEO 0x189
+#define KEY_AUDIO 0x188 /* AL Audio Browser */
+#define KEY_VIDEO 0x189 /* AL Movie Browser */
#define KEY_DIRECTORY 0x18a
#define KEY_LIST0x18b
#define KEY_MEMO0x18c /* Media Select Messages */
@@ -605,6 +605,7 @@ struct input_keymap_entry {
#define KEY_MEDIA_REPEAT0x1b7 /* Consumer - transport control */
#define KEY_10CHANNELSUP0x1b8 /* 10 channels up (10+) */
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
+#define KEY_IMAGES 0x1ba /* AL Image Browser */
#define KEY_DEL_EOL 0x1c0
#define KEY_DEL_EOS 0x1c1
--
1.7.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
Maybe Launch instead of AL in the comments. It took me a while to figure
out AL even with the email context.
Ah, yes, that's an HID Usage Table-ism, short for Application Launch.
The comment text is taken straight from the HUT's Usage Name column, on
page 80 of HUT v1.12, and matches a fair number of other comments in
input.h. It wasn't until I started reading the HUT doc that many of the
comments next to keys actually started making sense... :)
So I'm fine with either AL or Launch, but if we opt for the latter,
it might be good to change the rest of the comments to match.
--
Jarod Wilson
ja...@redhat.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 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used
for obtaining page frame number passed to remap_pfn_range()
(commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig
stopped working on my ARM based board. The ARM architecture maintainer,
Russell King, confirmed that using something like
virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be
broken on other architectures as well. The author of the change, Jiri
Slaby, also confirmed that his code may not work on all architectures.
The patch tries to solve this regression by using
virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic
virt_to_phys(mem-vaddr). I think this should work even if those
translations would occure inaccurate for DMA addresses, since possible
errors introduced by both translations, performed in opposite
directions, should compensate.
Tested on ARM OMAP1 based Amstrad Delta board.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1 - v2 changes:
- drop dma_mmap_coherent() path, it may not work correctly for device
memory preallocated with dma_declare_coherent_memory().
drivers/media/video/videobuf-dma-contig.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- git/drivers/media/video/videobuf-dma-contig.c.orig 2011-04-09
00:38:45.0 +0200
+++ git/drivers/media/video/videobuf-dma-contig.c 2011-04-12
22:36:44.0 +0200
@@ -300,8 +300,8 @@ static int __videobuf_mmap_mapper(struct
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
retval = remap_pfn_range(vma, vma-vm_start,
-PFN_DOWN(virt_to_phys(mem-vaddr)),
-size, vma-vm_page_prot);
+ PFN_DOWN(virt_to_phys(bus_to_virt(mem-dma_handle))),
+ size, vma-vm_page_prot);
if (retval) {
dev_err(q-dev, mmap: remap failed with error %d. , retval);
dma_free_coherent(q-dev, mem-size,
--
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] input: add KEY_IMAGES specifically for AL Image Browser
On Tuesday, April 12, 2011 02:00:53 PM Jarod Wilson wrote:
Andy Walls wrote:
Jarod Wilsonja...@redhat.com wrote:
Many media center remotes have buttons intended for jumping straight
to one type of media browser or another -- commonly,
images/photos/pictures,
audio/music, television, and movies. At present, remotes with an
images or photos or pictures button use any number of different
keycodes which sort of maybe fit. I've seen at least KEY_MEDIA,
KEY_CAMERA, KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those
seem quite right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA
is used in a lot of webcams, and typically means take a picture
now. KEY_GRAPHICSEDITOR implies an editor, not a browser.
KEY_PRESENTATION might be the closest fit here, if you think photo
slide show, but it may well be more intended for run application
in full-screen presentation mode or to launch something like
magicpoint, I dunno. And thus, I'd like to have a KEY_IMAGES, which
matches the HID Usage AL Image Browser, the meaning of which I think
is crystal-clear. I believe AL Audio Browser is already covered by
KEY_AUDIO, and AL Movie Browser by KEY_VIDEO, so I'm also adding
appropriate comments next to those keys.
I have follow-on patches for drivers/hid/hid-input.c and for
drivers/media/rc/* that make use of this new key, if its deemed
appropriate for addition. To make it simpler to merge the additional
patches, it would be nice if this could sneak into 2.6.39, and the
rest can then get queued up for 2.6.40, avoiding any multi-tree
integration headaches.
CC: Dmitry Torokhovdmitry.torok...@gmail.com
CC: Jiri Kosinajkos...@suse.cz
CC: Linux Medialinux-media@vger.kernel.org
Signed-off-by: Jarod Wilsonja...@redhat.com
---
include/linux/input.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index e428382..be082e9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -553,8 +553,8 @@ struct input_keymap_entry {
#define KEY_DVD0x185 /* Media Select DVD */
#define KEY_AUX0x186
#define KEY_MP30x187
-#define KEY_AUDIO 0x188
-#define KEY_VIDEO 0x189
+#define KEY_AUDIO 0x188 /* AL Audio Browser */
+#define KEY_VIDEO 0x189 /* AL Movie Browser */
#define KEY_DIRECTORY 0x18a
#define KEY_LIST 0x18b
#define KEY_MEMO 0x18c /* Media Select Messages */
@@ -605,6 +605,7 @@ struct input_keymap_entry {
#define KEY_MEDIA_REPEAT 0x1b7 /* Consumer - transport control */
#define KEY_10CHANNELSUP0x1b8 /* 10 channels up (10+) */
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
+#define KEY_IMAGES0x1ba /* AL Image Browser */
#define KEY_DEL_EOL0x1c0
#define KEY_DEL_EOS0x1c1
--
1.7.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
Maybe Launch instead of AL in the comments. It took me a while to
figure out AL even with the email context.
Ah, yes, that's an HID Usage Table-ism, short for Application Launch.
The comment text is taken straight from the HUT's Usage Name column, on
page 80 of HUT v1.12, and matches a fair number of other comments in
input.h. It wasn't until I started reading the HUT doc that many of the
comments next to keys actually started making sense... :)
So I'm fine with either AL or Launch, but if we opt for the latter,
it might be good to change the rest of the comments to match.
Somewhere above in input.h we have:
/*
* Keys and buttons
*
* Most of the keys/buttons are modeled after USB HUT 1.12
* (see http://www.usb.org/developers/hidpage).
* Abbreviations in the comments:
* AC - Application Control
* AL - Application Launch Button
* SC - System Control
*/
Thanks.
--
Dmitry
--
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] input: add KEY_IMAGES specifically for AL Image Browser
Dmitry Torokhov wrote:
On Tuesday, April 12, 2011 02:00:53 PM Jarod Wilson wrote:
Andy Walls wrote:
Jarod Wilsonja...@redhat.com wrote:
Many media center remotes have buttons intended for jumping straight
to one type of media browser or another -- commonly,
images/photos/pictures,
audio/music, television, and movies. At present, remotes with an
images or photos or pictures button use any number of different
keycodes which sort of maybe fit. I've seen at least KEY_MEDIA,
KEY_CAMERA, KEY_GRAPHICSEDITOR and KEY_PRESENTATION. None of those
seem quite right.
In my mind, KEY_MEDIA should be something more like a media center
application launcher (and I'd like to standardize on that for things
like the windows media center button on the mce remotes). KEY_CAMERA
is used in a lot of webcams, and typically means take a picture
now. KEY_GRAPHICSEDITOR implies an editor, not a browser.
KEY_PRESENTATION might be the closest fit here, if you think photo
slide show, but it may well be more intended for run application
in full-screen presentation mode or to launch something like
magicpoint, I dunno. And thus, I'd like to have a KEY_IMAGES, which
matches the HID Usage AL Image Browser, the meaning of which I think
is crystal-clear. I believe AL Audio Browser is already covered by
KEY_AUDIO, and AL Movie Browser by KEY_VIDEO, so I'm also adding
appropriate comments next to those keys.
I have follow-on patches for drivers/hid/hid-input.c and for
drivers/media/rc/* that make use of this new key, if its deemed
appropriate for addition. To make it simpler to merge the additional
patches, it would be nice if this could sneak into 2.6.39, and the
rest can then get queued up for 2.6.40, avoiding any multi-tree
integration headaches.
CC: Dmitry Torokhovdmitry.torok...@gmail.com
CC: Jiri Kosinajkos...@suse.cz
CC: Linux Medialinux-media@vger.kernel.org
Signed-off-by: Jarod Wilsonja...@redhat.com
---
include/linux/input.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index e428382..be082e9 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -553,8 +553,8 @@ struct input_keymap_entry {
#define KEY_DVD 0x185 /* Media Select DVD */
#define KEY_AUX 0x186
#define KEY_MP3 0x187
-#define KEY_AUDIO 0x188
-#define KEY_VIDEO 0x189
+#define KEY_AUDIO 0x188 /* AL Audio Browser */
+#define KEY_VIDEO 0x189 /* AL Movie Browser */
#define KEY_DIRECTORY 0x18a
#define KEY_LIST0x18b
#define KEY_MEMO0x18c /* Media Select Messages */
@@ -605,6 +605,7 @@ struct input_keymap_entry {
#define KEY_MEDIA_REPEAT0x1b7 /* Consumer - transport control */
#define KEY_10CHANNELSUP0x1b8 /* 10 channels up (10+) */
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
+#define KEY_IMAGES 0x1ba /* AL Image Browser */
#define KEY_DEL_EOL 0x1c0
#define KEY_DEL_EOS 0x1c1
--
1.7.1
Maybe Launch instead of AL in the comments. It took me a while to
figure out AL even with the email context.
Ah, yes, that's an HID Usage Table-ism, short for Application Launch.
The comment text is taken straight from the HUT's Usage Name column, on
page 80 of HUT v1.12, and matches a fair number of other comments in
input.h. It wasn't until I started reading the HUT doc that many of the
comments next to keys actually started making sense... :)
So I'm fine with either AL or Launch, but if we opt for the latter,
it might be good to change the rest of the comments to match.
Somewhere above in input.h we have:
/*
* Keys and buttons
*
* Most of the keys/buttons are modeled after USB HUT 1.12
* (see http://www.usb.org/developers/hidpage).
* Abbreviations in the comments:
* AC - Application Control
* AL - Application Launch Button
* SC - System Control
*/
Thanks.
D'oh. Okay, yeah, I have vague recollections of seeing that before, and
its probably what got me looking at the USB HUT in the first place...
Apologies for the implication the maintainer hadn't documented it. ;)
So, with that in mind, I think just AL is indeed appropriate.
--
Jarod Wilson
ja...@redhat.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 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). Who says that DMA handles are bus addresses in the strictest sense? DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it. What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it. Hence why ARM only implements it. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). -- 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
em28xx: idVendor=eb1a, idProduct=e301
Hi, I've made tests with my board: Model: Kaiomy TVnPC U2 http://www.kaiomy.com/products_feat.aspx?id=56 idVendor=eb1a, idProduct=e301 uname -r 2.6.35.12-88.fc14.i686.PAE -- 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: em28xx: idVendor=eb1a, idProduct=e301
Hi, port20031 wrote: Hi, I've made tests with my board: Model: Kaiomy TVnPC U2 http://www.kaiomy.com/products_feat.aspx?id=56 idVendor=eb1a, idProduct=e301 uname -r 2.6.35.12-88.fc14.i686.PAE What happened? You can share the dmesg as well. Cheers Douglas -- 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.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue, 12 Apr 2011, Russell King - ARM Linux wrote: On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). Who says that DMA handles are bus addresses in the strictest sense? DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it. What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it. Hence why ARM only implements it. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). I do not know how this fits into the present discussion. Perhaps everyone who reads the above message is well aware of what is below. If so my comment below is superfluous. But just in case things are otherwise it might save someone a bit of trouble in trying to write something which will work everywhere: If one is speaking here of architecture problems, there is the additional problem that some ARM systems might have not two PCI buses, but instead no PCI bus at all. Theodore Kilgore -- 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
[soc_camera] Dynamic crop window change while streaming (Zoom case)?
Hi Guennadi,
I was wondering what's the stand on allowing soc_camera host drivers to have
internal scalers...
It looks possible, but however I see one important blocker for being able to
change window rectangle while streaming (for example, when attempting to do
zoom in/out during streaming). See here:
in soc_camera.c::soc_camera_s_crop()
...
/* If get_crop fails, we'll let host and / or client drivers decide */
ret = ici-ops-get_crop(icd, current_crop);
/* Prohibit window size change with initialised buffers */
if (ret 0) {
dev_err(icd-dev,
S_CROP denied: getting current crop failed\n);
} else if (icd-vb_vidq.bufs[0]
(a-c.width != current_crop.c.width ||
a-c.height != current_crop.c.height)) {
dev_err(icd-dev,
S_CROP denied: queue initialised and sizes differ\n);
ret = -EBUSY;
} else {
ret = ici-ops-set_crop(icd, a);
}
...
Now, I don't want to move just yet to a Media Controller implementation in my
omap4 camera driver, since I don't intend yet to exploit the full HW, which
is easly 2x more complicated than omap3. But I want to start with a simplistic
driver which Pandaboard community can take (which don't need any advanced
features, just being able to receive frames.) and i just want to know how
complicated is to just offer the scaler functionality still.
Regards,
Sergio
--
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 dvb-apps] Avoid buffer overflow with UTF-8 32-bit strings
As Winfried handygewinnsp...@gmx.de pointed, me UTF-8 can have up to 32 bits. Also, someone might want to convert data to UCS-4, So, the buffer need to have 4 bytes per char, to be safe. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/util/scan/scan.c b/util/scan/scan.c --- a/util/scan/scan.c +++ b/util/scan/scan.c @@ -884,7 +884,7 @@ static void descriptorcpy(char **dest, c * Destination length should be bigger. As the worse case seems to * use 3 chars for one code, use it for destlen */ - destlen = len * 3; + destlen = len * 4; *dest = malloc(destlen + 1); /* Remove special chars */ -- 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 dvb-utils] Use ISO6937 instead of ISO-6937
Altrough iconv seems to recognize also ISO-6937, and scan uses its own table
for it, as iconv --list shows it as ISO6937, use the name provided by
iconv. Thanks to Winfried handygewinnsp...@gmx.de to point this issue to
me.
While here, improve the help message for the -C parameter, and show the
default charset at the help message.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/util/scan/scan.c b/util/scan/scan.c
--- a/util/scan/scan.c
+++ b/util/scan/scan.c
@@ -69,7 +69,7 @@ static int vdr_version = 3;
static struct lnb_types_st lnb_type;
static int unique_anon_services;
-char *default_charset = ISO-6937;
+char *default_charset = ISO6937;
char *output_charset;
#define CS_OPTIONS //TRANSLIT
@@ -559,7 +559,7 @@ struct charset_conv {
unsigned char data[3];
};
-/* This table is the Latin 00 table. Basically ISO-6937 + Euro sign */
+/* This table is the Latin 00 table. Basically ISO6937 + Euro sign */
struct charset_conv en300468_latin_00_to_utf8[256] = {
[0x00] = { 1, {0x00, } },
[0x01] = { 1, {0x01, } },
@@ -725,7 +725,7 @@ struct charset_conv en300468_latin_00_to
[0xa1] = { 2, {0xc2, 0xa1, } },
[0xa2] = { 2, {0xc2, 0xa2, } },
[0xa3] = { 2, {0xc2, 0xa3, } },
- [0xa4] = { 3, { 0xe2, 0x82, 0xac,} }, /* Euro sign. Addition
over the ISO-6937 standard */
+ [0xa4] = { 3, { 0xe2, 0x82, 0xac,} }, /* Euro sign. Addition
over the ISO6937 standard */
[0xa5] = { 2, {0xc2, 0xa5, } },
[0xa6] = { 0, {} },
[0xa7] = { 2, {0xc2, 0xa7, } },
@@ -836,7 +836,6 @@ static void descriptorcpy(char **dest, c
if (*src 0x20) {
switch (*src) {
- case 0x00: type = ISO-6937; break;
case 0x01: type = ISO-8859-5;break;
case 0x02: type = ISO-8859-6;break;
case 0x03: type = ISO-8859-7;break;
@@ -888,7 +887,7 @@ static void descriptorcpy(char **dest, c
*dest = malloc(destlen + 1);
/* Remove special chars */
- if (!strncasecmp(type, ISO-8859, 8) || !strcasecmp(type, ISO-6937))
{
+ if (!strncasecmp(type, ISO-8859, 8) || !strcasecmp(type, ISO6937)) {
/*
* Handles the ISO/IEC 10646 1-byte control codes
* (EN 300 468 v1.11.1 Table A.1)
@@ -924,7 +923,7 @@ static void descriptorcpy(char **dest, c
s = src;
p = *dest;
- if (!strcasecmp(type, ISO-6937)) {
+ if (!strcasecmp(type, ISO6937)) {
unsigned char *p1, *p2;
/* Convert charset to UTF-8 using Code table 00 - Latin */
@@ -2512,7 +2511,8 @@ static const char *usage = \n
(but only PAT and PMT) (applies for ATSC only)\n
-A Ncheck for ATSC 1=Terrestrial [default], 2=Cable or
3=both\n
-U Uniquely name unknown services\n
- -C cs Override default charset for service name/provider
(default = ISO-6937)\n
+ -C cs Override default charset for service name/provider\n
+ when no charset is provided (default = %s)\n
-D cs Output charset (default = %s)\n
Supported charsets by -C/-D parameters can be obtained via 'iconv -l'
command\n;
@@ -2526,7 +2526,7 @@ bad_usage(char *pname, int problem)
switch (problem) {
default:
case 0:
- fprintf (stderr, usage, pname, output_charset);
+ fprintf (stderr, usage, pname, default_charset, output_charset);
break;
case 1:
i = 0;
@@ -2542,7 +2542,7 @@ bad_usage(char *pname, int problem)
break;
case 2:
show_existing_tuning_data_files();
- fprintf (stderr, usage, pname);
+ fprintf (stderr, usage, pname, default_charset, output_charset);
}
}
@@ -2556,11 +2556,6 @@ int main (int argc, char **argv)
const char *initial = NULL;
char *charset;
- if (argc = 1) {
- bad_usage(argv[0], 2);
- return -1;
- }
-
/*
* Get the environment charset, and use it as the default
* output charset. In thesis, using nl_langinfo should be
@@ -2581,6 +2576,11 @@ int main (int argc, char **argv)
} else
output_charset = nl_langinfo(CODESET);
+ if (argc = 1) {
+ bad_usage(argv[0], 2);
+ return -1;
+ }
+
/* start with default lnb type */
lnb_type = *lnb_enum(0);
while ((opt = getopt(argc, argv,
5cnpa:f:d:s:o:x:e:t:i:l:vquPA:UC:D:)) != -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 dvb-apps] Allow LANG/LC_TYPE with @ symbol
According to IEEE Std 1003.1[1], the common way to specify LANG/LC_TYPE
is:
language[_territory][.codeset]
However, a variant may also be used, like:
[language[_territory][.codeset][@modifier]]
Change the logic to allow getting the charset also with the extended
syntax.
[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
Thanks to Winfield handygewinnsp...@gmx.de for pointing it to me.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/util/scan/scan.c b/util/scan/scan.c
--- a/util/scan/scan.c
+++ b/util/scan/scan.c
@@ -2565,12 +2565,13 @@ int main (int argc, char **argv)
if ((charset = getenv(LC_ALL)) ||
(charset = getenv(LC_CTYPE)) ||
(charset = getenv (LANG))) {
- while (*charset != '.' *charset)
- charset++;
- if (*charset == '.')
- charset++;
- if (*charset)
- output_charset = charset;
+ char *p = strchr(charset, '.');
+ if (p) {
+ p++;
+ p = strtok(p, @);
+ }
+ if (p)
+ output_charset = p;
else
output_charset = nl_langinfo(CODESET);
} else
--
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
