Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Wednesday, April 06, 2011 18:19:18 Guennadi Liakhovetski wrote:
On Tue, 5 Apr 2011, Hans Verkuil wrote:
On Tuesday, April 05, 2011 14:21:03 Laurent Pinchart wrote:
On Friday 01 April 2011 10:13:02 Guennadi Liakhovetski wrote:
[snip]
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -1937,6 +1957,10 @@ struct v4l2_dbg_chip_ident {
#defineVIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #defineVIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91,
struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_DESTROY_BUFS_IOWR('V', 93, struct v4l2_buffer_span)
+#define VIDIOC_SUBMIT_BUF _IOW('V', 94, int)
+
In case we later need to pass other information (such as flags) to
VIDIOC_SUBMIT_BUF, you should use a structure instead of an int.
I would just pass struct v4l2_buffer to this ioctl, just like QBUF/DQBUF do.
As I said, I didn't like this very much, because it involves redundant
data, but if we want to call .buf_prepare() from it, then we need
v4l2_buffer...
I don't see a problem with this. Applications already *have* the v4l2_buffer
after all. It's not as if they have to fill that structure just for this call.
Furthermore, you need all that data anyway because you need to do the same
checks that vb2_qbuf does.
Regarding DESTROY_BUFS: perhaps we should just skip this for now and wait for
the first use-case. That way we don't need to care about holes. I don't like
artificial restrictions like 'no holes'. If someone has a good use-case for
selectively destroying buffers, then we need to look at this again.
Regards,
Hans
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Wednesday, April 06, 2011 18:19:18 Guennadi Liakhovetski wrote:
On Tue, 5 Apr 2011, Hans Verkuil wrote:
On Tuesday, April 05, 2011 14:21:03 Laurent Pinchart wrote:
On Friday 01 April 2011 10:13:02 Guennadi Liakhovetski wrote:
[snip]
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -1937,6 +1957,10 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91,
struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_DESTROY_BUFS _IOWR('V', 93, struct v4l2_buffer_span)
+#define VIDIOC_SUBMIT_BUF _IOW('V', 94, int)
+
In case we later need to pass other information (such as flags) to
VIDIOC_SUBMIT_BUF, you should use a structure instead of an int.
I would just pass struct v4l2_buffer to this ioctl, just like QBUF/DQBUF
do.
As I said, I didn't like this very much, because it involves redundant
data, but if we want to call .buf_prepare() from it, then we need
v4l2_buffer...
I don't see a problem with this. Applications already *have* the v4l2_buffer
after all. It's not as if they have to fill that structure just for this call.
Furthermore, you need all that data anyway because you need to do the same
checks that vb2_qbuf does.
Regarding DESTROY_BUFS: perhaps we should just skip this for now and wait for
the first use-case. That way we don't need to care about holes. I don't like
artificial restrictions like 'no holes'. If someone has a good use-case for
selectively destroying buffers, then we need to look at this again.
Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) /
close()?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Wednesday, April 06, 2011 18:19:18 Guennadi Liakhovetski wrote:
On Tue, 5 Apr 2011, Hans Verkuil wrote:
On Tuesday, April 05, 2011 14:21:03 Laurent Pinchart wrote:
On Friday 01 April 2011 10:13:02 Guennadi Liakhovetski wrote:
[snip]
* I O C T L C O D E S F O R V I D E O D E V I C E S
*
@@ -1937,6 +1957,10 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91,
struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_DESTROY_BUFS _IOWR('V', 93, struct
v4l2_buffer_span)
+#define VIDIOC_SUBMIT_BUF_IOW('V', 94, int)
+
In case we later need to pass other information (such as flags) to
VIDIOC_SUBMIT_BUF, you should use a structure instead of an int.
I would just pass struct v4l2_buffer to this ioctl, just like
QBUF/DQBUF do.
As I said, I didn't like this very much, because it involves redundant
data, but if we want to call .buf_prepare() from it, then we need
v4l2_buffer...
I don't see a problem with this. Applications already *have* the
v4l2_buffer
after all. It's not as if they have to fill that structure just for this
call.
Furthermore, you need all that data anyway because you need to do the
same
checks that vb2_qbuf does.
Regarding DESTROY_BUFS: perhaps we should just skip this for now and
wait for
the first use-case. That way we don't need to care about holes. I don't
like
artificial restrictions like 'no holes'. If someone has a good use-case
for
selectively destroying buffers, then we need to look at this again.
Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) /
close()?
Yes.
Hans
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
On Wed, Apr 06, 2011 at 11:38:54AM -0700, Greg KH wrote: On Wed, Apr 06, 2011 at 11:25:57AM -0700, Andres Salomon wrote: We've been faced with the problem of being able to pass both MFD related data and a platform_data pointer to some of those drivers. Squeezing the MFD bits in the sub driver platform_data pointer doesn't work for drivers that know nothing about MFDs. It also adds an additional dependency on the MFD API to all MFD sub drivers. That prevents any of those drivers to eventually be used as plain platform device drivers. Then they shouldn't be plain platform drivers, that should only be reserved for drivers that are the lowest type. Just make them MFD devices and go from there. The problem is of mixing plain platform devices and MFD devices. Then don't do that. From my perspective, MFD devices are little more than a bag of platform_devices, with the MFD layer provides infrastructure for managing it. It isn't that there are 'plain' platform device and 'mfd' devices. There are only platform_devices, but some of the drivers use additional data stored in a struct mfd. Personally, I'm not thrilled with the approach of using struct mfd, or more specifically making it available to drivers, but on the ugly scale it isn't very high. However, the changes on how struct mfd is passed that were merged in 2.6.39 were actively dangerous and are going to be reverted. Yet a method is still needed to pass the struct mfd in a safe way. I don't have a problem with adding the mfd pointer to struct platform_device, even if it should just be a stop gap to something better. Independently, I have been experimenting with typesafe methods for attaching data to devices which may very well be the long term approach, but for the short term I see no problem with adding the mfd pointer, particularly because it is by far safer than any of the other immediately available options. g. -- 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 07/19] timberdale: mfd_cell is now implicitly available to drivers
Hi, On Wed, Apr 06, 2011 at 03:09:00PM -0700, Greg KH wrote: On Wed, Apr 06, 2011 at 09:59:02PM +0300, Felipe Balbi wrote: Hi, On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote: What is a MFD cell pointer and why is it needed in struct device? An MFD cell is an MFD instantiated device. MFD (Multi Function Device) drivers instantiate platform devices. Those devices drivers sometimes need a platform data pointer, sometimes an MFD specific pointer, and sometimes both. Also, some of those drivers have been implemented as MFD sub drivers, while others know nothing about MFD and just expect a plain platform_data pointer. That sounds like a bug in those drivers, why not fix them to properly pass in the correct pointer? Because they're drivers for generic IPs, not MFD ones. By forcing them to use MFD specific structure and APIs, we make it more difficult for platform code to instantiate them. I agree. What I do on those cases is to have a simple platform_device for the core IP driver and use platform_device_id tables to do runtime checks of the small differences. If one platform X doesn't use a platform_bus, it uses e.g. PCI, then you make a PCI bridge which allocates a platform_device with the correct name and adds that to the driver model. See [1] (for the core driver) and [2] (for a PCI bridge driver) for an example of what I'm talking about. Yes, thanks for providing a real example, this is the best way to handle this. no problem. ps: that's the driver for the USB3 controller which will come on OMAP5. Driver being validate on a pre-silicon platform right now :-D In a few weeks I'll send the driver for integration. -- balbi -- 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] V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG
Since commit 379fa5d ([media] V4L: mx3_camera: convert to videobuf2) mx3_camera uses videobuf2, but that commit didn't upgrade the select resulting in the following build failure: drivers/built-in.o: In function `mx3_camera_init_videobuf': clkdev.c:(.text+0x86580): undefined reference to `vb2_dma_contig_memops' drivers/built-in.o: In function `mx3_camera_probe': clkdev.c:(.devinit.text+0x3548): undefined reference to `vb2_dma_contig_init_ctx' clkdev.c:(.devinit.text+0x3578): undefined reference to `vb2_dma_contig_cleanup_ctx' drivers/built-in.o: In function `mx3_camera_remove': clkdev.c:(.devexit.text+0x674): undefined reference to `vb2_dma_contig_cleanup_ctx' make[2]: *** [.tmp_vmlinux1] Error 1 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Hello, does someone has a hint how to fix gcc not to believe the undefined references to be in clkdev.c? Best regards Uwe drivers/media/video/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4498b94..00f51dd 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -875,7 +875,7 @@ config MX3_VIDEO config VIDEO_MX3 tristate i.MX3x Camera Sensor Interface driver depends on VIDEO_DEV MX3_IPU SOC_CAMERA - select VIDEOBUF_DMA_CONTIG + select VIDEOBUF2_DMA_CONTIG select MX3_VIDEO ---help--- This is a v4l2 driver for the i.MX3x Camera Sensor Interface -- 1.7.2.3 -- 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/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Wednesday, April 06, 2011 18:19:18 Guennadi Liakhovetski wrote:
On Tue, 5 Apr 2011, Hans Verkuil wrote:
On Tuesday, April 05, 2011 14:21:03 Laurent Pinchart wrote:
On Friday 01 April 2011 10:13:02 Guennadi Liakhovetski wrote:
[snip]
*I O C T L C O D E S F O R V I D E O D E V I C E
S
*
@@ -1937,6 +1957,10 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91,
struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS_IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_DESTROY_BUFS _IOWR('V', 93, struct
v4l2_buffer_span)
+#define VIDIOC_SUBMIT_BUF _IOW('V', 94, int)
+
In case we later need to pass other information (such as flags) to
VIDIOC_SUBMIT_BUF, you should use a structure instead of an int.
I would just pass struct v4l2_buffer to this ioctl, just like
QBUF/DQBUF do.
As I said, I didn't like this very much, because it involves redundant
data, but if we want to call .buf_prepare() from it, then we need
v4l2_buffer...
I don't see a problem with this. Applications already *have* the
v4l2_buffer
after all. It's not as if they have to fill that structure just for this
call.
Furthermore, you need all that data anyway because you need to do the
same
checks that vb2_qbuf does.
Regarding DESTROY_BUFS: perhaps we should just skip this for now and
wait for
the first use-case. That way we don't need to care about holes. I don't
like
artificial restrictions like 'no holes'. If someone has a good use-case
for
selectively destroying buffers, then we need to look at this again.
Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) /
close()?
Yes.
Ok, how about this: I remove the ioctl definition and struct
v4l2_ioctl_ops callback for it, but I keep the span struct and the vb2
implementation - in case we need it later? The vb2_destroy_bufs() will be
used to implement freeing the queue as a particular case of freeing some
buffers.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
On Thursday, April 07, 2011 10:53:32 Guennadi Liakhovetski wrote:
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Thu, 7 Apr 2011, Hans Verkuil wrote:
On Wednesday, April 06, 2011 18:19:18 Guennadi Liakhovetski wrote:
On Tue, 5 Apr 2011, Hans Verkuil wrote:
On Tuesday, April 05, 2011 14:21:03 Laurent Pinchart wrote:
On Friday 01 April 2011 10:13:02 Guennadi Liakhovetski wrote:
[snip]
* I O C T L C O D E S F O R V I D E O D E V I C E
S
*
@@ -1937,6 +1957,10 @@ struct v4l2_dbg_chip_ident {
#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct
v4l2_event_subscription) #define VIDIOC_UNSUBSCRIBE_EVENT
_IOW('V', 91,
struct v4l2_event_subscription)
+#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct
v4l2_create_buffers)
+#define VIDIOC_DESTROY_BUFS _IOWR('V', 93, struct
v4l2_buffer_span)
+#define VIDIOC_SUBMIT_BUF_IOW('V', 94, int)
+
In case we later need to pass other information (such as flags)
to
VIDIOC_SUBMIT_BUF, you should use a structure instead of an int.
I would just pass struct v4l2_buffer to this ioctl, just like
QBUF/DQBUF do.
As I said, I didn't like this very much, because it involves
redundant
data, but if we want to call .buf_prepare() from it, then we need
v4l2_buffer...
I don't see a problem with this. Applications already *have* the
v4l2_buffer
after all. It's not as if they have to fill that structure just for
this
call.
Furthermore, you need all that data anyway because you need to do the
same
checks that vb2_qbuf does.
Regarding DESTROY_BUFS: perhaps we should just skip this for now and
wait for
the first use-case. That way we don't need to care about holes. I don't
like
artificial restrictions like 'no holes'. If someone has a good use-case
for
selectively destroying buffers, then we need to look at this again.
Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) /
close()?
Yes.
Ok, how about this: I remove the ioctl definition and struct
v4l2_ioctl_ops callback for it, but I keep the span struct and the vb2
implementation - in case we need it later? The vb2_destroy_bufs() will be
used to implement freeing the queue as a particular case of freeing some
buffers.
I wouldn't do that. Just keep the code clean and the patch as small as
possible. Having unused/unnecessary code is bad practice.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
Hi Hans, On Thursday 07 April 2011 09:50:13 Hans Verkuil wrote: On Thu, 7 Apr 2011, Hans Verkuil wrote: [snip] Regarding DESTROY_BUFS: perhaps we should just skip this for now and wait for the first use-case. That way we don't need to care about holes. I don't like artificial restrictions like 'no holes'. If someone has a good use-case for selectively destroying buffers, then we need to look at this again. Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) / close()? Yes. I don't really like that as it would mix CREATE and REQBUFS calls. Applications should either use the old API (REQBUFS) or the new one, but not mix both. The fact that freeing arbitrary spans of buffers gives us uneasy feelings might be a sign that the CREATE/DESTROY API is not mature enough. I'd rather try to solve the issue now instead of postponing it for later and discover that our CREATE API should have been different. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management
Hi Hans, On Thursday 07 April 2011 09:50:13 Hans Verkuil wrote: On Thu, 7 Apr 2011, Hans Verkuil wrote: [snip] Regarding DESTROY_BUFS: perhaps we should just skip this for now and wait for the first use-case. That way we don't need to care about holes. I don't like artificial restrictions like 'no holes'. If someone has a good use-case for selectively destroying buffers, then we need to look at this again. Sorry, skip what? skip the ioctl completely and rely on REQBUFS(0) / close()? Yes. I don't really like that as it would mix CREATE and REQBUFS calls. Applications should either use the old API (REQBUFS) or the new one, but not mix both. That's a completely unnecessary limitation. And from the point of view of vb2 it shouldn't even matter. The fact that freeing arbitrary spans of buffers gives us uneasy feelings might be a sign that the CREATE/DESTROY API is not mature enough. I'd rather try to solve the issue now instead of postponing it for later and discover that our CREATE API should have been different. What gives me an uneasy feeling is prohibiting freeing arbitrary spans of buffers. I rather choose not to implement the DESTROY ioctl instead of implementing a limited version of it, also because we do not have proper use cases yet. But I have no problems with the CREATE/DESTROY API as such. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mt9v022: fix pixel clock
On Wed, 6 Apr 2011, Teresa Gámez wrote: Measurements show that the setup of the pixel clock is not correct. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. Doesn't seem correct to me. The mt9v022 datasheet says: quote Invert pixel clock. When set, LINE_VALID, FRAME_VALID, and DOUT is set up to the rising edge of pixel clock, PIXCLK. When clear, they are set up to the falling edge of PIXCLK. /quote and this works for present mt9v022 configurations, which include at least two boards: PXA270-based arch/arm/mach-pxa/pcm990-baseboard.c and i.MX31 based arch/arm/mach-mx3/mach-pcm037.c. If this is different for your board, maybe you have to set the SOCAM_SENSOR_INVERT_PCLK flag in your struct soc_camera_link instance. Thanks Guennadi Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mt9m111: fix pixel clock
On Wed, 6 Apr 2011, Teresa Gámez wrote:
This camera driver supports only rising edge, which is the default
setting of the device. The function mt9m111_setup_pixfmt() overwrites
this setting. So the driver actually uses falling edge.
This patch corrects that.
Ok, this does indeed look like a bug in the driver. But this is not the
best way to fix the problem. We should extend the driver to properly
implement both pclk polarities _and_ adjust PXA270 boards, using this
chip: mioa701, ezx (twice), em-x270.
Thanks
Guennadi
Signed-off-by: Teresa Gámez t.ga...@phytec.de
---
drivers/media/video/mt9m111.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index 53fa2a7..4040a96 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -315,10 +315,20 @@ static int mt9m111_setup_rect(struct i2c_client *client,
static int mt9m111_setup_pixfmt(struct i2c_client *client, u16 outfmt)
{
int ret;
+ u16 mask = MT9M111_OUTFMT_PROCESSED_BAYER | MT9M111_OUTFMT_RGB |
+ MT9M111_OUTFMT_BYPASS_IFP | MT9M111_OUTFMT_SWAP_RGB_EVEN |
+ MT9M111_OUTFMT_RGB565 | MT9M111_OUTFMT_RGB555 |
+ MT9M111_OUTFMT_SWAP_YCbCr_Cb_Cr |
+ MT9M111_OUTFMT_SWAP_YCbCr_C_Y;
- ret = reg_write(OUTPUT_FORMAT_CTRL2_A, outfmt);
+ ret = reg_clear(OUTPUT_FORMAT_CTRL2_A, mask);
if (!ret)
- ret = reg_write(OUTPUT_FORMAT_CTRL2_B, outfmt);
+ ret = reg_set(OUTPUT_FORMAT_CTRL2_A, outfmt);
+ if (!ret)
+ ret = reg_clear(OUTPUT_FORMAT_CTRL2_B, mask);
+ if (!ret)
+ ret = reg_set(OUTPUT_FORMAT_CTRL2_B, outfmt);
+
return ret;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
---
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: v4l: Buffer pools
Hi Laurent On Fri, 1 Apr 2011, Laurent Pinchart wrote: [snip] - Cache management (ISP and DSS) Cache needs to be synchronized between userspace applications, kernel space and hardware. Synchronizing the cache is an expensive operation and should be avoided when possible. Userspace applications don't need to select memory mapping cache attributes, but should be able to either handle cache synchronization explicitly, or override the drivers' default behaviour. So, what cache attributes are currently used by the driver? Presumably, it is some cacheable variant? And which way should the application be able to override the driver's behaviour? One of these overrides would probably be skip cache invalidate (input) / flush (output), right? Anything else? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v16 01/13] davinci vpbe: V4L2 display driver for DM644X SoC
Hi Manjunath,
On Saturday 02 April 2011 11:40:49 Manjunath Hadli wrote:
This is the display driver for Texas Instruments's DM644X family
SoC. This patch contains the main implementation of the driver with the
V4L2 interface. The driver implements the streaming model with
support for both kernel allocated buffers and user pointers. It also
implements all of the necessary IOCTLs necessary and supported by the
video display device.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
[snip]
diff --git a/drivers/media/video/davinci/vpbe_display.c
b/drivers/media/video/davinci/vpbe_display.c new file mode 100644
index 000..dde5f8a
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_display.c
@@ -0,0 +1,2085 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
That looks suspicious, do you really need to include linux/fs.h ?
+#include linux/interrupt.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/irq.h
+#include linux/mm.h
+#include linux/mutex.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include asm/pgtable.h
+#include mach/cputype.h
+
+#include media/v4l2-dev.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include media/davinci/vpbe_display.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpbe_osd.h
+#include vpbe_venc_regs.h
+
+#define VPBE_DISPLAY_DRIVER vpbe-v4l2
+
+static int debug;
+static u32 video2_numbuffers = 3;
+static u32 video3_numbuffers = 3;
Why is the number of buffers set by a module parameter ? It should be
negotiated dynamically with REQBUFS.
+#define VPBE_DISPLAY_SD_BUF_SIZE (720*576*2)
+#define VPBE_DEFAULT_NUM_BUFS 3
+
+static u32 video2_bufsize = VPBE_DISPLAY_SD_BUF_SIZE;
+static u32 video3_bufsize = VPBE_DISPLAY_SD_BUF_SIZE;
Those two variables are assigned but never read. You either forgot to read
them, or to remove them.
+module_param(video2_numbuffers, uint, S_IRUGO);
+module_param(video3_numbuffers, uint, S_IRUGO);
+module_param(video2_bufsize, uint, S_IRUGO);
+module_param(video3_bufsize, uint, S_IRUGO);
+module_param(debug, int, 0644);
+
+static struct buf_config_params display_buf_config_params = {
+ .min_numbuffers = VPBE_DEFAULT_NUM_BUFS,
+ .numbuffers[0] = VPBE_DEFAULT_NUM_BUFS,
+ .numbuffers[1] = VPBE_DEFAULT_NUM_BUFS,
+ .min_bufsize[0] = VPBE_DISPLAY_SD_BUF_SIZE,
+ .min_bufsize[1] = VPBE_DISPLAY_SD_BUF_SIZE,
+ .layer_bufsize[0] = VPBE_DISPLAY_SD_BUF_SIZE,
+ .layer_bufsize[1] = VPBE_DISPLAY_SD_BUF_SIZE,
+};
This also looks like something that shouldn't be hardcoded.
+static struct vpbe_device *vpbe_dev;
+static struct osd_state *osd_device;
No such global variables please. Pass the pointers around between functions
instead.
+static int vpbe_display_nr[] = { 2, 3 };
Is there a reason to register video devices with a specific number ?
video_register_device() doesn't guarantee, that the requested number will be
used, so it looks a bit pointless to me.
+static struct v4l2_capability vpbe_display_videocap = {
+ .driver = VPBE_DISPLAY_DRIVER,
+ .bus_info = platform,
+ .version = VPBE_DISPLAY_VERSION_CODE,
+ .capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING,
+};
Please fill v4l2_capability dynamically in vpbe_display_querycap() instead of
using a global variable.
+static u8 layer_first_int[VPBE_DISPLAY_MAX_DEVICES];
This belongs to your vpbe_display_obj object, not to a global variable.
+static int venc_is_second_field()
+{
+ int ret = 0;
+ int val;
+ ret = v4l2_subdev_call(vpbe_dev-venc,
+core,
+ioctl,
+VENC_GET_FLD,
+val);
+ if (ret 0) {
+ v4l2_err(vpbe_dev-v4l2_dev,
+ Error in getting Field ID 0\n);
+ }
+ return val;
+}
+
+/*
+ * vpbe_display_isr()
+ * ISR function. It changes status of the displayed buffer, takes next
buffer + * from the queue and sets its address in VPBE registers
+ */
+static void
Re: [PATCH 1/2] mt9v022: fix pixel clock
Hello Guennadi, Sorry for the first mail... 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? I have tested this with a pcm038 but I will also make meassurements with the pcm037. Teresa Am Donnerstag, den 07.04.2011, 13:08 +0200 schrieb Guennadi Liakhovetski: On Wed, 6 Apr 2011, Teresa Gámez wrote: Measurements show that the setup of the pixel clock is not correct. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. Doesn't seem correct to me. The mt9v022 datasheet says: quote Invert pixel clock. When set, LINE_VALID, FRAME_VALID, and DOUT is set up to the rising edge of pixel clock, PIXCLK. When clear, they are set up to the falling edge of PIXCLK. /quote and this works for present mt9v022 configurations, which include at least two boards: PXA270-based arch/arm/mach-pxa/pcm990-baseboard.c and i.MX31 based arch/arm/mach-mx3/mach-pcm037.c. If this is different for your board, maybe you have to set the SOCAM_SENSOR_INVERT_PCLK flag in your struct soc_camera_link instance. Thanks Guennadi Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
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. 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. Teresa Guennadi Liakhovetski g.liakhovet...@gmx.de schrieb am 07.04.2011 13:08:11: Von: Guennadi Liakhovetski g.liakhovet...@gmx.de An: Teresa Gámez t.ga...@phytec.de Kopie: linux-media@vger.kernel.org Datum: 07.04.2011 13:08 Betreff: Re: [PATCH 1/2] mt9v022: fix pixel clock On Wed, 6 Apr 2011, Teresa Gámez wrote: Measurements show that the setup of the pixel clock is not correct. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. Doesn't seem correct to me. The mt9v022 datasheet says: quote Invert pixel clock. When set, LINE_VALID, FRAME_VALID, and DOUT is set up to the rising edge of pixel clock, PIXCLK. When clear, they are set up to the falling edge of PIXCLK. /quote and this works for present mt9v022 configurations, which include at least two boards: PXA270-based arch/arm/mach-pxa/pcm990-baseboard.c and i.MX31 based arch/arm/mach-mx3/mach-pcm037.c. If this is different for your board, maybe you have to set the SOCAM_SENSOR_INVERT_PCLK flag in your struct soc_camera_link instance. Thanks Guennadi Signed-off-by: Teresa Gámez t.ga...@phytec.de --- drivers/media/video/mt9v022.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 6a784c8..dec2a69 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -228,7 +228,7 @@ static int mt9v022_set_bus_param(struct soc_camera_device *icd, flags = soc_camera_apply_sensor_flags(icl, flags); - if (flags SOCAM_PCLK_SAMPLE_RISING) + if (flags SOCAM_PCLK_SAMPLE_FALLING) pixclk |= 0x10; if (!(flags SOCAM_HSYNC_ACTIVE_HIGH)) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
On Thu, Apr 07, 2011 at 03:40:23PM +0200, Samuel Ortiz wrote:
Hi Felipe,
On Wed, Apr 06, 2011 at 09:59:02PM +0300, Felipe Balbi wrote:
Hi,
On Wed, Apr 06, 2011 at 08:47:34PM +0200, Samuel Ortiz wrote:
What is a MFD cell pointer and why is it needed in struct device?
An MFD cell is an MFD instantiated device.
MFD (Multi Function Device) drivers instantiate platform devices.
Those
devices drivers sometimes need a platform data pointer, sometimes an
MFD
specific pointer, and sometimes both. Also, some of those drivers
have been
implemented as MFD sub drivers, while others know nothing about MFD
and just
expect a plain platform_data pointer.
That sounds like a bug in those drivers, why not fix them to properly
pass in the correct pointer?
Because they're drivers for generic IPs, not MFD ones. By forcing them to
use
MFD specific structure and APIs, we make it more difficult for platform
code
to instantiate them.
I agree. What I do on those cases is to have a simple platform_device
for the core IP driver and use platform_device_id tables to do runtime
checks of the small differences. If one platform X doesn't use a
platform_bus, it uses e.g. PCI, then you make a PCI bridge which
allocates a platform_device with the correct name and adds that to the
driver model.
I see, thanks.
Below is a patch for the Xilinx SPI example. Although this would fix the
issue, we'd still have to do that on device per device basis. I had a similar
solution where MFD drivers would set a flag for sub drivers that don't need
any of the MFD bits. In that case the MFD core code would just forward the
platform data, instead of embedding it through an MFD cell.
platform_data is already a fiddly bit where you don't know what
structure type platform_data points at; it is implicitly known and
easy to get wrong. This solution makes me *very* nervous
because it would become even easier to get a mismatch on the
platform_data pointer type.
g.
Cheers,
Samuel.
---
drivers/mfd/timberdale.c |8
drivers/spi/xilinx_spi.c | 19 ++-
include/linux/mfd/core.h |3 +++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 94c6c8a..c9220ce 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -416,7 +416,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -476,7 +476,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -526,7 +526,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -570,7 +570,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index c69c6f2..3287b84 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -471,7 +471,11 @@ static int __devinit xilinx_spi_probe(struct
platform_device *dev)
struct spi_master *master;
u8 i;
- pdata = mfd_get_data(dev);
+ if (platform_get_device_id(dev)
+ platform_get_device_id(dev)-driver_data MFD_PLATFORM_DEVICE)
+ pdata = mfd_get_data(dev);
+ else
+ pdata = dev-dev.platform_data;
if (pdata) {
num_cs = pdata-num_chipselect;
little_endian = pdata-little_endian;
@@ -530,6 +534,18 @@ static int __devexit xilinx_spi_remove(struct
platform_device *dev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform: XILINX_SPI_NAME);
+static
Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
On Thu, Apr 07, 2011 at 07:35:15AM -0700, Grant Likely wrote:
Below is a patch for the Xilinx SPI example. Although this would fix the
issue, we'd still have to do that on device per device basis. I had a
similar
solution where MFD drivers would set a flag for sub drivers that don't need
any of the MFD bits. In that case the MFD core code would just forward the
platform data, instead of embedding it through an MFD cell.
platform_data is already a fiddly bit where you don't know what
structure type platform_data points at; it is implicitly known and
easy to get wrong. This solution makes me *very* nervous
because it would become even easier to get a mismatch on the
platform_data pointer type.
How would that be more error prone than say a board file instantiating a
platform device after having set the platform_data pointer to point to an
implicitely know structure reference ?
Cheers,
Samuel.
P.S.: Would you be ok with something like the patch below ?
---
drivers/mfd/timberdale.c |8
drivers/spi/xilinx_spi.c | 19 ++-
include/linux/mfd/core.h |3 +++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 94c6c8a..c9220ce 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -416,7 +416,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -476,7 +476,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -526,7 +526,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -570,7 +570,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index c69c6f2..3287b84 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -471,7 +471,11 @@ static int __devinit xilinx_spi_probe(struct
platform_device *dev)
struct spi_master *master;
u8 i;
- pdata = mfd_get_data(dev);
+ if (platform_get_device_id(dev)
+ platform_get_device_id(dev)-driver_data MFD_PLATFORM_DEVICE)
+ pdata = mfd_get_data(dev);
+ else
+ pdata = dev-dev.platform_data;
if (pdata) {
num_cs = pdata-num_chipselect;
little_endian = pdata-little_endian;
@@ -530,6 +534,18 @@ static int __devexit xilinx_spi_remove(struct
platform_device *dev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform: XILINX_SPI_NAME);
+static const struct platform_device_id xilinx_spi_id_table[] = {
+ {
+ .name = XILINX_SPI_NAME,
+ },
+ {
+ .name = mfd_xilinx_spi,
+ .driver_data = MFD_PLATFORM_DEVICE,
+ },
+ { }, /* Terminating Entry */
+};
+MODULE_DEVICE_TABLE(platform, xilinx_spi_id_table);
+
static struct platform_driver xilinx_spi_driver = {
.probe = xilinx_spi_probe,
.remove = __devexit_p(xilinx_spi_remove),
@@ -538,6 +554,7 @@ static struct platform_driver xilinx_spi_driver = {
.owner = THIS_MODULE,
.of_match_table = xilinx_spi_of_match,
},
+ .id_table = xilinx_spi_id_table,
};
static int __init xilinx_spi_pltfm_init(void)
diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index ad1b19a..13f31f4 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -89,6 +89,9 @@ static inline const struct mfd_cell *mfd_get_cell(struct
platform_device *pdev)
return pdev-dev.platform_data;
}
+/* */
+#define MFD_PLATFORM_DEVICE BIT(0)
+
[PATCH 1/2] Add Y10B, a 10 bpp bit-packed greyscale format.
Add a 10 bits per pixel greyscale format in a bit-packed array representation,
naming it Y10B. Such pixel format is supplied for instance by the Kinect
sensor device.
Cc: Steven Toth st...@kernellabs.com
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Documentation/DocBook/media-entities.tmpl |1 +
Documentation/DocBook/v4l/pixfmt-y10b.xml | 43 +
Documentation/DocBook/v4l/pixfmt.xml |1 +
Documentation/DocBook/v4l/videodev2.h.xml |3 ++
include/linux/videodev2.h |3 ++
5 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-y10b.xml
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index 5d259c6..2dead20 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -294,6 +294,7 @@
!ENTITY sub-srggb10 SYSTEM v4l/pixfmt-srggb10.xml
!ENTITY sub-srggb8 SYSTEM v4l/pixfmt-srggb8.xml
!ENTITY sub-y10 SYSTEM v4l/pixfmt-y10.xml
+!ENTITY sub-y10b SYSTEM v4l/pixfmt-y10b.xml
!ENTITY sub-pixfmt SYSTEM v4l/pixfmt.xml
!ENTITY sub-cropcap SYSTEM v4l/vidioc-cropcap.xml
!ENTITY sub-dbg-g-register SYSTEM v4l/vidioc-dbg-g-register.xml
diff --git a/Documentation/DocBook/v4l/pixfmt-y10b.xml
b/Documentation/DocBook/v4l/pixfmt-y10b.xml
new file mode 100644
index 000..adb0ad8
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y10b.xml
@@ -0,0 +1,43 @@
+refentry id=V4L2-PIX-FMT-Y10BPACK
+ refmeta
+refentrytitleV4L2_PIX_FMT_Y10BPACK ('Y10B')/refentrytitle
+manvol;
+ /refmeta
+ refnamediv
+refnameconstantV4L2_PIX_FMT_Y10BPACK/constant/refname
+refpurposeGrey-scale image as a bit-packed array/refpurpose
+ /refnamediv
+ refsect1
+titleDescription/title
+
+paraThis is a packed grey-scale image format with a depth of 10 bits per
+ pixel. Pixels are stored in a bit-packed array of 10bit bits per pixel,
+ with no padding between them and with the most significant bits coming
+ first from the left./para
+
+example
+ titleconstantV4L2_PIX_FMT_Y10BPACK/constant 4 pixel data stream
taking 5 bytes/title
+
+ formalpara
+ titleBit-packed representation/title
+ parapixels cross the byte boundary and have a ratio of 5 bytes for
each 4
+ pixels.
+ informaltable frame=all
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entryY'subscript00[9:2]/subscript/entry
+
entryY'subscript00[1:0]/subscriptY'subscript01[9:4]/subscript/entry
+
entryY'subscript01[3:0]/subscriptY'subscript02[9:6]/subscript/entry
+
entryY'subscript02[5:0]/subscriptY'subscript03[9:8]/subscript/entry
+ entryY'subscript03[7:0]/subscript/entry
+ /row
+ /tbody
+ /tgroup
+ /informaltable
+ /para
+ /formalpara
+/example
+ /refsect1
+/refentry
diff --git a/Documentation/DocBook/v4l/pixfmt.xml
b/Documentation/DocBook/v4l/pixfmt.xml
index c6fdcbb..2e824a3 100644
--- a/Documentation/DocBook/v4l/pixfmt.xml
+++ b/Documentation/DocBook/v4l/pixfmt.xml
@@ -696,6 +696,7 @@ information./para
sub-packed-yuv;
sub-grey;
sub-y10;
+sub-y10b;
sub-y16;
sub-yuyv;
sub-uyvy;
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..937acf5 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -311,6 +311,9 @@ struct link
linkend=v4l2-pix-formatv4l2_pix_format/link {
#define link linkend=V4L2-PIX-FMT-Y10V4L2_PIX_FMT_Y10/link
v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */
#define link linkend=V4L2-PIX-FMT-Y16V4L2_PIX_FMT_Y16/link
v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */
+/* Grey bit-packed formats */
+#define link linkend=V4L2-PIX-FMT-Y10BPACKV4L2_PIX_FMT_Y10BPACK/link
v4l2_fourcc('Y', '1', '0', 'B') /* 10 Greyscale bit-packed */
+
/* Palette formats */
#define link linkend=V4L2-PIX-FMT-PAL8V4L2_PIX_FMT_PAL8/link
v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..38575ae 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -310,6 +310,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
+/* Grey bit-packed formats */
+#define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10
Greyscale bit-packed */
+
/* Palette formats */
#define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit
palette */
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the
[PATCH 0/2] Add a GSPCA subdriver for the Microsoft Kinect sensor
Hi, This patchset adds support for using the Kinect[1] sensor device as a regular Webcam or as a IR camera. [1] http://en.wikipedia.org/wiki/Kinect The first patch adds a new Y10B pixelformat used to expose the raw IR data the sensor can provide, the second patch adds a gspca subdriver for the Kinect sensor. There was some positive feedback about calling the new format Y10B from Hans Verkuil, Mauro Carvalho Chehab and Guennadi Liakhovetski. Any comment is appreciated. Thanks, Antonio Antonio Ospite (2): Add Y10B, a 10 bpp bit-packed greyscale format. gspca: add a subdriver for the Microsoft Kinect sensor device Documentation/DocBook/media-entities.tmpl |1 + Documentation/DocBook/v4l/pixfmt-y10b.xml | 43 +++ Documentation/DocBook/v4l/pixfmt.xml |1 + Documentation/DocBook/v4l/videodev2.h.xml |3 + drivers/media/video/gspca/Kconfig |9 + drivers/media/video/gspca/Makefile|2 + drivers/media/video/gspca/kinect.c| 427 + include/linux/videodev2.h |3 + 8 files changed, 489 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/v4l/pixfmt-y10b.xml create mode 100644 drivers/media/video/gspca/kinect.c -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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] gspca: add a subdriver for the Microsoft Kinect sensor device
The Kinect sensor is a device used by Microsoft for its Kinect project,
which is a system for controller-less Human-Computer interaction
targeted for Xbox 360.
In the Kinect device, RGBD data is captured from two distinct sensors: a
regular RGB sensor and a monochrome sensor which, with the aid of a IR
structured light, captures what is finally exposed as a depth map; so
what we have is basically a Structured-light 3D scanner.
The Kinect gspca subdriver just supports the video stream for now,
exposing the output from the RGB sensor or the unprocessed output from
the monochrome sensor; it does not deal with the processed depth stream
yet, but it allows using the sensor as a Webcam or as an IR camera (an
external source of IR light might be needed for this use).
The low level implementation is based on code from the OpenKinect
project (http://openkinect.org).
Cc: Steven Toth st...@kernellabs.com
Cc: OpenKinect openkin...@googlegroups.com
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
drivers/media/video/gspca/Kconfig |9 +
drivers/media/video/gspca/Makefile |2 +
drivers/media/video/gspca/kinect.c | 427
3 files changed, 438 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/gspca/kinect.c
diff --git a/drivers/media/video/gspca/Kconfig
b/drivers/media/video/gspca/Kconfig
index eb04e8b..34ae2c2 100644
--- a/drivers/media/video/gspca/Kconfig
+++ b/drivers/media/video/gspca/Kconfig
@@ -77,6 +77,15 @@ config USB_GSPCA_JEILINJ
To compile this driver as a module, choose M here: the
module will be called gspca_jeilinj.
+config USB_GSPCA_KINECT
+ tristate Kinect sensor device USB Camera Driver
+ depends on VIDEO_V4L2 USB_GSPCA
+ help
+ Say Y here if you want support for the Microsoft Kinect sensor device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gspca_kinect.
+
config USB_GSPCA_KONICA
tristate Konica USB Camera V4L2 driver
depends on VIDEO_V4L2 USB_GSPCA
diff --git a/drivers/media/video/gspca/Makefile
b/drivers/media/video/gspca/Makefile
index 855fbc8..802fbe1 100644
--- a/drivers/media/video/gspca/Makefile
+++ b/drivers/media/video/gspca/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_USB_GSPCA_CPIA1)+= gspca_cpia1.o
obj-$(CONFIG_USB_GSPCA_ETOMS)+= gspca_etoms.o
obj-$(CONFIG_USB_GSPCA_FINEPIX) += gspca_finepix.o
obj-$(CONFIG_USB_GSPCA_JEILINJ) += gspca_jeilinj.o
+obj-$(CONFIG_USB_GSPCA_KINECT) += gspca_kinect.o
obj-$(CONFIG_USB_GSPCA_KONICA) += gspca_konica.o
obj-$(CONFIG_USB_GSPCA_MARS) += gspca_mars.o
obj-$(CONFIG_USB_GSPCA_MR97310A) += gspca_mr97310a.o
@@ -46,6 +47,7 @@ gspca_cpia1-objs:= cpia1.o
gspca_etoms-objs:= etoms.o
gspca_finepix-objs := finepix.o
gspca_jeilinj-objs := jeilinj.o
+gspca_kinect-objs := kinect.o
gspca_konica-objs := konica.o
gspca_mars-objs := mars.o
gspca_mr97310a-objs := mr97310a.o
diff --git a/drivers/media/video/gspca/kinect.c
b/drivers/media/video/gspca/kinect.c
new file mode 100644
index 000..f85e746
--- /dev/null
+++ b/drivers/media/video/gspca/kinect.c
@@ -0,0 +1,427 @@
+/*
+ * kinect sensor device camera, gspca driver
+ *
+ * Copyright (C) 2011 Antonio Ospite osp...@studenti.unina.it
+ *
+ * Based on the OpenKinect project and libfreenect
+ * http://openkinect.org/wiki/Init_Analysis
+ *
+ * Special thanks to Steven Toth and kernellabs.com for sponsoring a Kinect
+ * sensor device which I tested the driver on.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#define MODULE_NAME kinect
+
+#include gspca.h
+
+#define CTRL_TIMEOUT 500
+
+MODULE_AUTHOR(Antonio Ospite osp...@studenti.unina.it);
+MODULE_DESCRIPTION(GSPCA/Kinect Sensor Device USB Camera Driver);
+MODULE_LICENSE(GPL);
+
+#ifdef DEBUG
+int gspca_debug = D_ERR | D_PROBE | D_CONF | D_STREAM | D_FRAM | D_PACK |
+ D_USBI | D_USBO | D_V4L2;
+#endif
+
+struct pkt_hdr {
+ uint8_t magic[2];
+ uint8_t pad;
+ uint8_t flag;
+ uint8_t unk1;
+ uint8_t seq;
+ uint8_t unk2;
+ uint8_t unk3;
+ uint32_t timestamp;
+};
+
+struct cam_hdr {
+ uint8_t magic[2];
+ uint16_t len;
+ uint16_t cmd;
+ uint16_t tag;
+};
+
+/* specific webcam descriptor */
+struct sd {
+
[PATCH] libv4lconvert-priv.h: indent with tabs, not spaces
Indent wrapped lines with tabs, just like it is done for the other functions in the same file. Signed-off-by: Antonio Ospite osp...@studenti.unina.it --- lib/libv4lconvert/libv4lconvert-priv.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/libv4lconvert/libv4lconvert-priv.h b/lib/libv4lconvert/libv4lconvert-priv.h index 30d1cfe..84c706e 100644 --- a/lib/libv4lconvert/libv4lconvert-priv.h +++ b/lib/libv4lconvert/libv4lconvert-priv.h @@ -131,7 +131,7 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest, int width, int height); void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest, -const struct v4l2_format *src_fmt); + const struct v4l2_format *src_fmt); void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest, int width, int height); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC, PATCH] libv4lconvert: Add support for Y10B grey format (V4L2_PIX_FMT_Y10BPACK)
Y10B is a 10 bits per pixel greyscale format in a bit-packed array
representation. Such pixel format is supplied for instance by the Kinect
sensor device.
Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Hi,
this is a very first attempt about supporting Y10B in libv4lconvert, the
doubts I have are about the conversion routines which need to unpack a frame
before doing the actual pixelformat conversion, and maybe this can be handled
in some conversion layer in libv4l.
I don't know libv4l yet, so I am asking for advice providing some code to
discuss on; looking at the last hunk of the patch: can I allocate a temporary
buffer only once per device (and not per frame as I am horribly doing now) and
reuse it in the conversion routines? Or is the unpacking better be done even
before conversion, feeding the conversion routines with already unpacked
buffers?
Thanks,
Antonio Ospite
http://ao2.it
include/linux/videodev2.h |3 +
lib/libv4lconvert/libv4lconvert-priv.h |6 +++
lib/libv4lconvert/libv4lconvert.c | 20
lib/libv4lconvert/rgbyuv.c | 76
4 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 51788a6..559d5f3 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -289,6 +289,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale
*/
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale
*/
+/* Grey bit-packed formats */
+#define V4L2_PIX_FMT_Y10BPACKv4l2_fourcc('Y', '1', '0', 'B') /* 10
Greyscale bit-packed */
+
/* Palette formats */
#define V4L2_PIX_FMT_PAL8v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit
palette */
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 84c706e..470a869 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -133,6 +133,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_y10b_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_y10b_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt);
+
void v4lconvert_rgb565_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index e4863fd..631d912 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -48,6 +48,7 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[]
= {
{ V4L2_PIX_FMT_YVYU, 0 },
{ V4L2_PIX_FMT_UYVY, 0 },
{ V4L2_PIX_FMT_RGB565, 0 },
+ { V4L2_PIX_FMT_Y10BPACK, 0 },
{ V4L2_PIX_FMT_SN9C20X_I420, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SBGGR8, V4LCONVERT_NEEDS_CONVERSION },
{ V4L2_PIX_FMT_SGBRG8, V4LCONVERT_NEEDS_CONVERSION },
@@ -862,6 +863,25 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
result = -1;
}
break;
+
+ case V4L2_PIX_FMT_Y10BPACK:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y10b_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y10b_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size (width * height * 10 / 8)) {
+ V4LCONVERT_ERR(short y10b data frame\n);
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_RGB565:
switch (dest_pix_fmt) {
case V4L2_PIX_FMT_RGB24:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index 2ee7e58..23fe8f3 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -603,3 +603,79 @@ void v4lconvert_grey_to_yuv420(const unsigned char *src,
unsigned char *dest,
/* Clear U/V */
memset(dest, 0x80, src_fmt-fmt.pix.width * src_fmt-fmt.pix.height /
2);
}
+
+#include stdint.h
+#include stdlib.h
+/* Unpack buffer of (vw bit) data into padded 16bit buffer. */
+static inline void convert_packed_to_16bit(uint8_t *raw, uint16_t *unpacked,
int vw, int unpacked_len)
+{
+ int mask = (1 vw) - 1;
+ uint32_t buffer = 0;
+ int bitsIn = 0;
+ while
[PULL] V4L and soc-camera fixes for 2.6.39
Hi Mauro The following changes since commit 6221f222c0ebf1acdf7abcf927178f40e1a65e2a: Linux 2.6.39-rc2 (2011-04-05 18:30:43 -0700) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 2.6.39-rc1-fixes Guennadi Liakhovetski (8): V4L: fix videobuf2 to correctly identify allocation failures V4L: fix an error message V4L: fix a macro definition V4L: soc-camera: fix a recent multi-camera breakage on sh-mobile V4L: imx074: return a meaningful error code instead of -1 V4L: soc-camera: don't dereference I2C client after it has been removed V4L: sh_mobile_csi2: fix module reloading V4L: sh_mobile_ceu_camera: fix typos in documentation Documentation/video4linux/sh_mobile_ceu_camera.txt |6 +++--- drivers/media/video/imx074.c |2 +- drivers/media/video/sh_mobile_ceu_camera.c | 10 +- drivers/media/video/sh_mobile_csi2.c | 11 +-- drivers/media/video/soc_camera.c |7 +-- drivers/media/video/videobuf2-core.c |2 +- drivers/media/video/videobuf2-dma-contig.c |2 +- include/media/v4l2-device.h|2 +- 8 files changed, 26 insertions(+), 16 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
On Mon, Apr 4, 2011 at 8:04 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Mon, Apr 04, 2011 at 12:03:15PM +0200, Samuel Ortiz wrote:
diff --git a/include/linux/platform_device.h
b/include/linux/platform_device.h
index d96db98..734d254 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -14,6 +14,8 @@
#include linux/device.h
#include linux/mod_devicetable.h
+struct mfd_cell;
+
struct platform_device {
const char * name;
int id;
@@ -23,6 +25,9 @@ struct platform_device {
const struct platform_device_id *id_entry;
+ /* MFD cell pointer */
+ struct mfd_cell *mfd_cell;
+
Move this down to by the of_node pointer. May as well collect all the
supplemental data about the device in the same place.
So, okay. wow. I have *no* idea what I was smoking at this point in
time. The of_node pointer is in struct device which is definitely not
the place to put the mfd_cell pointer (and you probably though I was
crazy when I suggested it). Greg was totally right to complain about
moving it into struct device. Sorry for causing trouble.
Move it back into struct platform_device and you should be good. I
just talked to greg, and there should be any issues with locating it
there.
g.
--
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: [PULL] V4L and soc-camera fixes for 2.6.39
ehem, let's try again (forgot one more patch): The following changes since commit 6221f222c0ebf1acdf7abcf927178f40e1a65e2a: Linux 2.6.39-rc2 (2011-04-05 18:30:43 -0700) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 2.6.39-rc1-fixes Guennadi Liakhovetski (8): V4L: fix videobuf2 to correctly identify allocation failures V4L: fix an error message V4L: fix a macro definition V4L: soc-camera: fix a recent multi-camera breakage on sh-mobile V4L: imx074: return a meaningful error code instead of -1 V4L: soc-camera: don't dereference I2C client after it has been removed V4L: sh_mobile_csi2: fix module reloading V4L: sh_mobile_ceu_camera: fix typos in documentation Uwe Kleine-König (1): V4L: mx3_camera: select VIDEOBUF2_DMA_CONTIG instead of VIDEOBUF_DMA_CONTIG Documentation/video4linux/sh_mobile_ceu_camera.txt |6 +++--- drivers/media/video/Kconfig|2 +- drivers/media/video/imx074.c |2 +- drivers/media/video/sh_mobile_ceu_camera.c | 10 +- drivers/media/video/sh_mobile_csi2.c | 11 +-- drivers/media/video/soc_camera.c |7 +-- drivers/media/video/videobuf2-core.c |2 +- drivers/media/video/videobuf2-dma-contig.c |2 +- include/media/v4l2-device.h|2 +- 9 files changed, 27 insertions(+), 17 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Add v4l2 subdev driver for S5P MIPI-CSI receivers
Hello, the following is a v4l2 subdev driver for MIPI-CSI2 receivers available in S5PVx10 and EXYNOS4 SoCs. The MIPI-CSIS module (MIPI CSI Slave) works closely with the FIMC IP, i.e. it is its frontend for the MIPI CSI serial bus. Other than that the following patch set moves the s5p-fimc driver under Video Capture Devices in kconfig and adds a V4L2_MBUS_FMT_JPEG_1X8 media bus format. To follow are patches converting s5p-fimc to the pad ops and adding a media device for precisely managing all available FIMC and MIPI CSIS entities and image sensors. However this still needs a bit of work. As usual, review comments are welcome! Changes since v1: - added runtime PM support - conversion to the pad ops The patch series contains: [PATCH 1/3] v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format [PATCH 2/3] v4l: Move S5P FIMC driver into Video Capture Devices [PATCH 3/3] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI Receiver -- 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
[PATCH 2/3] v4l: Move S5P FIMC driver into Video Capture Devices
s5p-fimc now also implements a camera capture video node so move it under the Video capture devices Kconfig menu. Also update the entry to reflect the driver's coverage of EXYNOS4 SoCs. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4498b94..492f2ef 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -927,6 +927,14 @@ config VIDEO_MX2 This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor Interface +config VIDEO_SAMSUNG_S5P_FIMC + tristate S5P and EXYNOS4 camera host interface driver + depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + ---help--- + This is a v4l2 driver for the S5P and EXYNOS4 camera host interface + and video postprocessor. # # USB Multimedia device configuration @@ -1022,13 +1030,4 @@ config VIDEO_MEM2MEM_TESTDEV This is a virtual test device for the memory-to-memory driver framework. -config VIDEO_SAMSUNG_S5P_FIMC - tristate Samsung S5P FIMC (video postprocessor) driver - depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P - select VIDEOBUF2_DMA_CONTIG - select V4L2_MEM2MEM_DEV - help - This is a v4l2 driver for the S5P camera interface - (video postprocessor) - endif # V4L_MEM2MEM_DRIVERS -- 1.7.4.3 -- 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/3] v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format
Add V4L2_MBUS_FMT_JPEG_1X8 format and the corresponding Docbook
documentation.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/v4l/subdev-formats.xml | 46 ++
include/linux/v4l2-mediabus.h|3 ++
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml
b/Documentation/DocBook/v4l/subdev-formats.xml
index 7041127..df2d7d3 100644
--- a/Documentation/DocBook/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
@@ -2463,5 +2463,51 @@
/tgroup
/table
/section
+
+section
+ titleJPEG Compressed Formats/title
+
+ paraThose data formats consist of an ordered sequence of 8-bit bytes
+ obtained from JPEG compression process. Additionally to the
+ constant_JPEG/constant prefix the format code is made of
+ the following information.
+ itemizedlist
+ listitemThe number of bus samples per entropy encoded
byte./listitem
+ listitemThe bus width./listitem
+ /itemizedlist
+
+ paraFor instance, for a JPEG baseline process and an 8-bit bus width
+ the format will be named constantV4L2_MBUS_FMT_JPEG_1X8/constant.
+ /para
+ /para
+
+ paraThe following table lists existing JPEG compressed formats./para
+
+ table pgwide=0 frame=none id=v4l2-mbus-pixelcode-jpeg
+ titleJPEG Formats/title
+ tgroup cols=3
+ colspec colname=id align=left /
+ colspec colname=code align=left/
+ colspec colname=remarks align=left/
+ thead
+ row
+ entryIdentifier/entry
+ entryCode/entry
+ entryRemarks/entry
+ /row
+ /thead
+ tbody valign=top
+ row id=V4L2-MBUS-FMT-JPEG-1X8
+ entryV4L2_MBUS_FMT_JPEG_1X8/entry
+ entry0x4001/entry
+ entryBesides of its usage for the parallel bus this format is
+ recommended for transmission of JPEG data over MIPI CSI bus
+ using the User Defined 8-bit Data types.
+ /entry
+ /row
+ /tbody
+ /tgroup
+ /table
+/section
/section
/section
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 7054a7a..15d6cda 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -86,6 +86,9 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+
+ /* JPEG compressed formats - next is 0x4002 */
+ V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
};
/**
--
1.7.4.3
--
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 3/3] 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 corresponding PHYs are
controlled through the platform data callback. 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
---
drivers/media/video/Kconfig |6 +
drivers/media/video/s5p-fimc/Makefile|2 +
drivers/media/video/s5p-fimc/mipi-csis.c | 746 ++
drivers/media/video/s5p-fimc/mipi-csis.h | 18 +
4 files changed, 772 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 492f2ef..018ce88 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -936,6 +936,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
+ ---help---
+ This is a v4l2 driver for the S5P/EXYNOS4 MIPI-CSI Receivers
+
#
# 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..9502b94
--- /dev/null
+++ b/drivers/media/video/s5p-fimc/mipi-csis.c
@@ -0,0 +1,746 @@
+/*
+ * 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/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/clk.h
+#include linux/irq.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/delay.h
+#include linux/memory.h
+#include linux/regulator/consumer.h
+#include linux/pm_runtime.h
+#include plat/mipi_csis.h
+
+#include linux/videodev2.h
+#include media/v4l2-subdev.h
+#include mipi-csis.h
+
+static int debug = 10;
+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
+#define CSIS_MAX_PIX_HEIGHT0x
+
+enum {
+ CSIS_CLK_MUX,
+ CSIS_CLK_GATE,
+};
+
+static char *csi_clock_name[] = {
+ [CSIS_CLK_MUX] = sclk_csis,
+ [CSIS_CLK_GATE] = csis,
+};
+#define NUM_CSIS_CLOCKSARRAY_SIZE(csi_clock_name)
+
+enum {
+ ST_POWERED = 1,
+ ST_STREAMING= 2,
+ ST_SUSPENDED= 4,
+ ST_CLK_ON = 8,
+};
+
+struct csis_state {
+ struct mutex lock;
+ struct media_pad pads[CSIS_PADS_NUM];
+ struct v4l2_subdev sd;
+ struct platform_device *pdev;
+ struct resource *regs_res;
+ void __iomem *regs;
+ struct clk
V4L/DVB (13598): videobuf_dma_contig_user_get() for non-aligned offsets
Hi all, I have a question about the following videobuf_dma_contig_user_get() fix to 2.6.33: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/videobuf-dma-contig.c;h=22c01097e8a821f95c04ae9d8ae9432623381d46;hp=d25f28461da1fcaac4b5d74ad8d6cac65e286b4f;hb=31bedfa5068936b15a388842be1d03cdd1bdfb07;hpb=0d94e29459d372b6c5dda964a8b35a8d40050ca7 By including offset into the calculation of mem-size, doesn't that impact the correctness of the sequent bound checking? if ((vb-baddr + mem-size) vma-vm_end) goto out_up; Perhaps the fix should have been accompanied by the following change to the above lines to avoid double counting of the non-align offset? if (PAGE_ALIGN(vb-baddr + vb-size) vma-vm_end) goto out_up; Thanks, William Huang -- 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:Thu Apr 7 19:00:20 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: ERRORS 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: ERRORS 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers
On Thu, Apr 07, 2011 at 05:03:23PM +0200, Samuel Ortiz wrote:
On Thu, Apr 07, 2011 at 07:35:15AM -0700, Grant Likely wrote:
Below is a patch for the Xilinx SPI example. Although this would fix the
issue, we'd still have to do that on device per device basis. I had a
similar
solution where MFD drivers would set a flag for sub drivers that don't
need
any of the MFD bits. In that case the MFD core code would just forward the
platform data, instead of embedding it through an MFD cell.
platform_data is already a fiddly bit where you don't know what
structure type platform_data points at; it is implicitly known and
easy to get wrong. This solution makes me *very* nervous
because it would become even easier to get a mismatch on the
platform_data pointer type.
How would that be more error prone than say a board file instantiating a
platform device after having set the platform_data pointer to point to an
implicitely know structure reference ?
Yes, platform_data is already troublesome, but at least current
convention is a 1:1 relationship between driver and platform_data
type. I still hate it and want something better, but it is what we
have. The problem with what having a different platform_data pointer
depending on the instantiation means that it adds yet another level of
decision that needs to be made and is very easy to get wrong.
So, yes, platform_data is bad. I don't want to see it get any worse.
Cheers,
Samuel.
P.S.: Would you be ok with something like the patch below ?
Not really because it requires the driver to make the correct decision
about the platform_data type depending on the driver name. It is easy
to get wrong and the compiler cannot help you catch it.
I've talked with Greg, and adding the mfd_cell pointer to
platform_device will be okay in the short term. In the long term I'm
looking at creating a better way of attaching type-safe data to
devices that will pretty much eliminate this issue.
---
drivers/mfd/timberdale.c |8
drivers/spi/xilinx_spi.c | 19 ++-
include/linux/mfd/core.h |3 +++
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 94c6c8a..c9220ce 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -416,7 +416,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -476,7 +476,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -526,7 +526,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
@@ -570,7 +570,7 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.mfd_data = timberdale_radio_platform_data,
},
{
- .name = xilinx_spi,
+ .name = mfd_xilinx_spi,
.num_resources = ARRAY_SIZE(timberdale_spi_resources),
.resources = timberdale_spi_resources,
.mfd_data = timberdale_xspi_platform_data,
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index c69c6f2..3287b84 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -471,7 +471,11 @@ static int __devinit xilinx_spi_probe(struct
platform_device *dev)
struct spi_master *master;
u8 i;
- pdata = mfd_get_data(dev);
+ if (platform_get_device_id(dev)
+ platform_get_device_id(dev)-driver_data MFD_PLATFORM_DEVICE)
+ pdata = mfd_get_data(dev);
+ else
+ pdata = dev-dev.platform_data;
if (pdata) {
num_cs = pdata-num_chipselect;
little_endian = pdata-little_endian;
@@ -530,6 +534,18 @@ static int __devexit xilinx_spi_remove(struct
platform_device *dev)
/* work with hotplug and coldplug */
MODULE_ALIAS(platform: XILINX_SPI_NAME);
+static const struct platform_device_id xilinx_spi_id_table[] = {
+ {
+ .name = XILINX_SPI_NAME,
+ },
[PATCH][media] cx23885: Don't leak firmware in cx23885_card_setup()
We leak the memory allocated to 'fw' (the firmware) when the variable goes out of scope. Fix the leak by calling release_firmware(fw) before 'fw' goes out of scope. Signed-off-by: Jesper Juhl j...@chaosbits.net --- cx23885-cards.c |1 + 1 file changed, 1 insertion(+) compile tested only. diff --git a/drivers/media/video/cx23885/cx23885-cards.c b/drivers/media/video/cx23885/cx23885-cards.c index ea88722..2354336 100644 --- a/drivers/media/video/cx23885/cx23885-cards.c +++ b/drivers/media/video/cx23885/cx23885-cards.c @@ -1399,6 +1399,7 @@ void cx23885_card_setup(struct cx23885_dev *dev) else altera_init(netup_config, fw); + release_firmware(fw); break; } } -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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] DVB, DiB9000: Fix leak in dib9000_attach()
If the second memory allocation in dib9000_attach() fails, we'll leak the
memory allocated by the first.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
dib9000.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
compile tested only...
diff --git a/drivers/media/dvb/frontends/dib9000.c
b/drivers/media/dvb/frontends/dib9000.c
index 9151876..b25ef2b 100644
--- a/drivers/media/dvb/frontends/dib9000.c
+++ b/drivers/media/dvb/frontends/dib9000.c
@@ -2255,8 +2255,10 @@ struct dvb_frontend *dib9000_attach(struct i2c_adapter
*i2c_adap, u8 i2c_addr, c
if (st == NULL)
return NULL;
fe = kzalloc(sizeof(struct dvb_frontend), GFP_KERNEL);
- if (fe == NULL)
+ if (fe == NULL) {
+ kfree(st);
return NULL;
+ }
memcpy(st-chip.d9.cfg, cfg, sizeof(struct dib9000_config));
st-i2c.i2c_adap = i2c_adap;
--
Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
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:Thu Apr 7 20:09:52 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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][media] DVB, USB, lmedm04: Fix firmware mem leak in lme_firmware_switch()
Don't leak 'fw' in
drivers/media/dvb/dvb-usb/lmedm04.c::lme_firmware_switch() by failing to
call release_firmware().
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
lmedm04.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
compile tested only
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index cd26e7c..d7cc625 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -799,7 +799,7 @@ static int lme_firmware_switch(struct usb_device *udev, int
cold)
if (cold) {
info(FRM Changing to %s firmware, fw_lme);
lme_coldreset(udev);
- return -ENODEV;
+ ret = -ENODEV;
}
release_firmware(fw);
--
Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] DVB, USB, lmedm04: Fix firmware mem leak in lme_firmware_switch()
On Thu, 2011-04-07 at 21:46 +0200, Jesper Juhl wrote:
Don't leak 'fw' in
drivers/media/dvb/dvb-usb/lmedm04.c::lme_firmware_switch() by failing to
call release_firmware().
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
lmedm04.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
compile tested only
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index cd26e7c..d7cc625 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -799,7 +799,7 @@ static int lme_firmware_switch(struct usb_device *udev,
int cold)
if (cold) {
info(FRM Changing to %s firmware, fw_lme);
lme_coldreset(udev);
- return -ENODEV;
+ ret = -ENODEV;
}
release_firmware(fw);
This has already been fixed in this commit
http://git.linuxtv.org/media_tree.git?a=commit;h=b328817a2a391d1e879c4252cd3f11a352d3f3bc
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] DVB, USB, lmedm04: Fix firmware mem leak in lme_firmware_switch()
On Thu, 7 Apr 2011, Malcolm Priestley wrote:
On Thu, 2011-04-07 at 21:46 +0200, Jesper Juhl wrote:
Don't leak 'fw' in
drivers/media/dvb/dvb-usb/lmedm04.c::lme_firmware_switch() by failing to
call release_firmware().
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
lmedm04.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
compile tested only
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index cd26e7c..d7cc625 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -799,7 +799,7 @@ static int lme_firmware_switch(struct usb_device *udev,
int cold)
if (cold) {
info(FRM Changing to %s firmware, fw_lme);
lme_coldreset(udev);
- return -ENODEV;
+ ret = -ENODEV;
}
release_firmware(fw);
This has already been fixed in this commit
http://git.linuxtv.org/media_tree.git?a=commit;h=b328817a2a391d1e879c4252cd3f11a352d3f3bc
I see. Thanks. I was not aware of that.
--
Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
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: CXD2820 PCTV nanoStick T2 290e bringup
Hello Steve at all, Here it is, feel free to test: http://git.linuxtv.org/anttip/media_tree.git?a=shortlog;h=refs/heads/pctv_290e Now I *need* help for adding proper DVB-T2 support for the API. I added fe_delivery_system_t SYS_DVBT2, but there is no app knowing that yet. Since there is also module param to set DVB-T2 frequencies. For example here is DVB-T2 transmission on channels 570 MHz and 586 MHz. You can just type: echo 570,586 /sys/module/cxd2820r/parameters/dvbt2_freq as root, or load driver module following way: modprobe cxd2820r dvbt2_freq=570,586 for the same. Also em28xx driver MFE needs review and comments, since I am not sure about its correctness. Antti On 02/27/2011 09:49 PM, Steve Kerrison wrote: Hello everyone, I've done some work on bringup of this device in Linux, and now have a stub for the CXD2820 demod that includes the capability to pass I2C commands through to the tuner that sits behind it. The focus was on bringup, not compatibility with linux-media or Linus' coding guidelines, but hopefully it's not so horrendous that it makes you want to cry. This isn't a formal patch submission, but anyone with an interest is welcome to read more and grab the patch here: http://stevekerrison.com/290e/index.html#20110227 taking heed of the warnings and advice where necessary :) Only I2C passthrough is supported - none of the other demodulator or frontend functions work, and it doesn't detach properly. I'd like to know what the best approach would be for me to allow others to contribute to this if they so wish? Many thanks, -- http://palosaari.fi/ -- 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
Prof 7500 demod crashing after many tunes
I wrote a scan program that steps through all the frequencies in a given range and tries to tune them in a for loop. This is my first C program so be nice, http://chinesebob.net/dvb/blindscan-s2/blindscan-s2-201104070153.tgz I'm using it with my Prof 7500, which uses the dvb-usb-dw2102 and stv0900 modules, this way I can use the blindscan algo and do a blind scan for all transponders in a satellite to find the symbol rates. A problem I'm having now is that after something like 60 tuning attempts the demod crashes and I cannot tune anything else unless I reset power on the tuning device, this is a usb device. Resetting the usb bus and removing/readding the drivers doesn't help. This happens on any version of s2-liplianin I've tried from 3 months ago to current. The current version of s2-liplianin tunes much faster but, that just means it will crash faster when I try my tuning loop. Please let me know what kind of debugging I should do and what I should post to the list that would be helpful to figure this out. When it's in this state I get a constant DEMOD LOCK OK, and it thinks it has 100% signal, is there some way to force the demod to think it is not locking, or force reset the demod somehow without resetting power to the device? -- 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
