Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
> Changing this could break em28xx that might be expecting it > to be set to composite1. On a quick look, the code there seems to be > doing the right thing: during the probe procedure, it explicitly > calls s_routing, in order to initialize the device input to the > first input type found at the cards structure. So, this patch > is likely harmless. > > Yet, why do you need to change it? Any bridge driver that uses it should > be doing the same: at initialization, it should set the input to a > value that it is compatible with the way the device is wired, and not > to assume a particular arrangement. What I'm trying to do with these patches and my previous one related to mx2_camera, is to be able to use mx2_camera host driver with tvp5150 video decoder. I'm not sure how mx2_camera could be aware that the sensor or decoder attached to it needs s_routing function to be called with a certain parameter without making it too board specific. The only solution I could think of was assuming that if s_routing function was not called at all, the enabled input in tvp5150 would be the default COMPOSITE0 as it is specified in the datasheet. However, If you or anyone suggests a cleaner approach I'm totally open. But still, changing default value of the selected input in tvp5150 probe function is a bit dirty IMHO. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
> The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to > tvp5150, in order to set the pipelines there. This sounds like a sensible solution I will work on that soon. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: tvp5150 Fix default input selection.
On 15 December 2011 13:01, javier Martin wrote: >> The mx2_camera needs some code to forward calls to S_INPUT/S_ROUTING to >> tvp5150, in order to set the pipelines there. > > This sounds like a sensible solution I will work on that soon. > Hi Mauro, regarding this subject it seems soc-camera assumes the attached sensor has only one input: input 0. This means I am not able to forward S_INPUT/S_ROUTING as you suggested: http://lxr.linux.no/#linux+v3.1.5/drivers/media/video/soc_camera.c#L213 This trick is clearly a loss of functionality because it restricts sensors to output 0, but it should work since the subsystem can assume a sensor whose inputs have not been configured has input 0 as the one selected. However, this trick in the tvp5150 which selects input 1 (instead of 0) as the default input is breaking that assumption. The solution could be either apply my patch to set input 0 (COMPOSITE0) as default or swap input numbers so that COMPOSITE1 input is input 0. Personally I find my approach more convenient since it matches with the default behavior expected in the datasheet. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: tvp5150: Add mbus_fmt callbacks.
These callbacks allow a host video driver
to poll video formats supported by tvp5150.
---
Changes since v1:
Fix standard handling in tvp5150_mbus_fmt()
Signed-off-by: Javier Martin
---
drivers/media/video/tvp5150.c | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val & 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder->norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder->norm;
+
+ f->width = 720;
+ if (std & V4L2_STD_525_60)
+ f->height = 480;
+ else
+ f->height = 576;
+
+ f->code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f->field = V4L2_FIELD_SEQ_TB;
+ f->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
+ f->height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops
= {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
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
Trying to figure out reasons for lost pictures in UVC driver.
Hi, we are testing a logitech Webcam M/N: V-U0012 in the UVC tree (commit ef7728797039bb6a20f22cc2d96ef72d9338cba0). It is configured at 25fps, VGA. We've observed that the following debugging message appears sometimes "Frame complete (FID bit toggled).". Whenever this happens a v4l2 frame is lost (i.e. one sequence number has been skipped). Is this behavior expected? What could we do to avoid frame loss? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L: soc-camera: provide support for S_INPUT.
Some v4l-subdevs such as tvp5150 have multiple
inputs. This patch allows the user of a soc-camera
device to select between them.
Signed-off-by: Javier Martin
---
drivers/media/video/soc_camera.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index b72580c..1cea1a9 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -235,10 +235,10 @@ static int soc_camera_g_input(struct file *file, void
*priv, unsigned int *i)
static int soc_camera_s_input(struct file *file, void *priv, unsigned int i)
{
- if (i > 0)
- return -EINVAL;
+ struct soc_camera_device *icd = file->private_data;
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- return 0;
+ return v4l2_subdev_call(sd, video, s_routing, i, 0, 0);
}
static int soc_camera_s_std(struct file *file, void *priv, v4l2_std_id *a)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On 16 December 2011 09:34, Scott Jiang wrote:
> 2011/12/16 Javier Martin :
>> Some v4l-subdevs such as tvp5150 have multiple
>> inputs. This patch allows the user of a soc-camera
>> device to select between them.
>>
>> Signed-off-by: Javier Martin
>> ---
>> drivers/media/video/soc_camera.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/video/soc_camera.c
>> b/drivers/media/video/soc_camera.c
>> index b72580c..1cea1a9 100644
>> --- a/drivers/media/video/soc_camera.c
>> +++ b/drivers/media/video/soc_camera.c
>> @@ -235,10 +235,10 @@ static int soc_camera_g_input(struct file *file, void
>> *priv, unsigned int *i)
>>
>> static int soc_camera_s_input(struct file *file, void *priv, unsigned int i)
>> {
>> - if (i > 0)
>> - return -EINVAL;
> should it check max input?
>
>> + struct soc_camera_device *icd = file->private_data;
>> + struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
>>
>> - return 0;
>> + return v4l2_subdev_call(sd, video, s_routing, i, 0, 0);
>> }
>>
> why must output be zero?
Current behavior of soc-camera is not touching output at all, but
s_routing() callback enforces to select both input and output values.
The more neutral value I could think of for output is 0. Of course any
other suggestions are welcome.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On 16 December 2011 09:47, Guennadi Liakhovetski wrote: > Hi Javier > > On Fri, 16 Dec 2011, Javier Martin wrote: > >> Some v4l-subdevs such as tvp5150 have multiple >> inputs. This patch allows the user of a soc-camera >> device to select between them. > > Sure, we can support it. But I've got a couple of remarks: > > First question: you probably also want to patch soc_camera_g_input() and > soc_camera_enum_input(). But no, I do not know how. The video subdevice > operations do not seem to provide a way to query subdevice routing > capabilities, so, I've got no idea how we're supposed to support > enum_input(). There is a g_input_status() method, but I'm not sure about > its semantics. Would it return an error like -EINVAL on an unsupported > index? I would gladly implement also eum_input() and get_input() but I can't test it since my device does not support "g_input_status" callback but only "s_routing". > Secondly, I would prefer to keep the current behaviour per default. I.e., > if the subdevice doesn't implement routing- / input-related operations, we > should act as before - assume input 0 and return success. Sure, it seems reasonable. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On 16 December 2011 10:36, Scott Jiang wrote: >>> How about this implementation? I know it's not for soc, but I post it >>> to give my idea. >>> Bridge knows the layout, so it doesn't need to query the subdevice. >> >> Where from? AFAIU, we are talking here about subdevice inputs, right? In >> this case about various inputs of the TV decoder. How shall the bridge >> driver know about that? > > I have asked this question before. Laurent reply me: > >> >> ENUMINPUT as defined by V4L2 enumerates input connectors available on >> >> the board. Which inputs the board designer hooked up is something that >> >> only the top-level V4L driver will know. Subdevices do not have that >> >> information, so enuminputs is not applicable there. >> >> >> >> Of course, subdevices do have input pins and output pins, but these are >> >> assumed to be fixed. With the s_routing ops the top level driver selects >> >> which input and output pins are active. Enumeration of those inputs and >> >> outputs wouldn't gain you anything as far as I can tell since the >> >> subdevice simply does not know which inputs/outputs are actually hooked >> >> up. It's the top level driver that has that information (usually passed >> >> in through board/card info structures). But AFAIK, soc-camera does not support passing such kind of information. Neither any of the host camera drivers currently available expect that kind of data. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
Hi, thank you for your comments. Let me try to summarize the conclusions we've agreed here: 1.- soc-camera can support S_INPUT as long as I provide backwards compatibility in case subdev does not support s_routing (i.e. I must resend my patch returning input 0 in case s_routing is not supported). 2.- Board specific code must tell the subdevice which inputs are really connected and how through platform data. Is that OK? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On 19 December 2011 11:41, Guennadi Liakhovetski wrote: > On Mon, 19 Dec 2011, Laurent Pinchart wrote: > >> Hi Guennadi, >> >> On Monday 19 December 2011 11:13:58 Guennadi Liakhovetski wrote: >> > On Mon, 19 Dec 2011, Laurent Pinchart wrote: >> > > On Monday 19 December 2011 09:09:34 Guennadi Liakhovetski wrote: >> > > > On Mon, 19 Dec 2011, Laurent Pinchart wrote: >> > > > > On Friday 16 December 2011 10:50:21 Guennadi Liakhovetski wrote: >> > > > > > On Fri, 16 Dec 2011, Scott Jiang wrote: >> > > > > > > >> How about this implementation? I know it's not for soc, but I >> > > > > > > >> post it to give my idea. >> > > > > > > >> Bridge knows the layout, so it doesn't need to query the >> > > > > > > >> subdevice. >> > > > > > > > >> > > > > > > > Where from? AFAIU, we are talking here about subdevice inputs, >> > > > > > > > right? In this case about various inputs of the TV decoder. How >> > > > > > > > shall the bridge driver know about that? >> > > > > > > >> > > > > > > I have asked this question before. Laurent reply me: >> > > > > > > > >> ENUMINPUT as defined by V4L2 enumerates input connectors >> > > > > > > > >> available on the board. Which inputs the board designer >> > > > > > > > >> hooked up is something that only the top-level V4L driver >> > > > > > > > >> will know. Subdevices do not have that information, so >> > > > > > > > >> enuminputs is not applicable there. >> > > > > > > > >> >> > > > > > > > >> Of course, subdevices do have input pins and output pins, >> > > > > > > > >> but these are assumed to be fixed. With the s_routing ops >> > > > > > > > >> the top level driver selects which input and output pins >> > > > > > > > >> are active. Enumeration of those inputs and outputs >> > > > > > > > >> wouldn't gain you anything as far as I can tell since the >> > > > > > > > >> subdevice simply does not know which inputs/outputs are >> > > > > > > > >> actually hooked up. It's the top level driver that has that >> > > > > > > > >> information (usually passed in through board/card info >> > > > > > > > >> structures). >> > > > > > >> > > > > > Laurent, right, I now remember reading this discussion before. But >> > > > > > I'm not sure I completely agree:-) Yes, you're right - the board >> > > > > > decides which pins are routed to which connectors. And it has to >> > > > > > provide this information to the driver in its platform data. But - >> > > > > > I think, this information should be provided not to the bridge >> > > > > > driver, but to respective subdevice drivers, because only they >> > > > > > know what exactly those interfaces are good for and how to report >> > > > > > them to the bridge or the user, if we decide to also export this >> > > > > > information over the subdevice user-space API. >> > > > > > >> > > > > > So, I would say, the board has to tell the subdevice driver: yes, >> > > > > > your inputs 0 and 1 are routed to external connectors. On input 1 >> > > > > > I've put a pullup, it is connected to connector of type X over a >> > > > > > circuit Y, clocked from your output Z, if the driver needs to know >> > > > > > all that. And the subdev driver will just tell the bridge only >> > > > > > what that one needs to know - number of inputs and their >> > > > > > capabilities. >> > > > > >> > > > > That sounds reasonable. >> > > > >> > > > Good, this would mean, we need additional subdevice operations along >> > > > the lines of enum_input and enum_output, and maybe also g_input and >> > > > g_output? >> > > >> > > What about implementing pad support in the subdevice ? Input enumeration >> > > could then be performed without a subdev operation. >> > >> > soc-camera doesn't support pad operations yet. >> >> soc-camera doesn't support enum_input yet either, so you need to implement >> something anyway ;-) >> >> You wouldn't need to call a pad operation here, you would just need to >> iterate >> through the pads provided by the subdev. > > tvp5150 doesn't implement it either yet. So, I would say, it is a better > solution ATM to fix this functionality independent of the pad-level API. I agree, I cannot contribute to implement pad-level API stuff since I can't test it with tvp5150. Would you accept a patch implementing only S_INPUT? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to figure out reasons for lost pictures in UVC driver.
On 19 December 2011 01:19, Laurent Pinchart wrote: > Hi Javier, > > On Thursday 15 December 2011 17:02:47 javier Martin wrote: >> Hi, >> we are testing a logitech Webcam M/N: V-U0012 in the UVC tree (commit >> ef7728797039bb6a20f22cc2d96ef72d9338cba0). >> It is configured at 25fps, VGA. >> >> We've observed that the following debugging message appears sometimes >> "Frame complete (FID bit toggled).". Whenever this happens a v4l2 >> frame is lost (i.e. one sequence number has been skipped). >> >> Is this behavior expected? What could we do to avoid frame loss? > > Could you check the frame intervals to see if a frame is really lost, or if > the driver erroneously reports frame loss ? Hi Laurent, sequence number in the v4l2 buffer returned is one step bigger than expected, however the timestamp difference with the previous buffer is 40ms which is what it is expected at 25fps. So, sequence number indicates a buffer has been lost but timestamp does not. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
On 19 December 2011 11:58, Guennadi Liakhovetski wrote: > On Mon, 19 Dec 2011, javier Martin wrote: > >> On 19 December 2011 11:41, Guennadi Liakhovetski >> wrote: >> > On Mon, 19 Dec 2011, Laurent Pinchart wrote: >> > >> >> Hi Guennadi, >> >> >> >> On Monday 19 December 2011 11:13:58 Guennadi Liakhovetski wrote: >> >> > On Mon, 19 Dec 2011, Laurent Pinchart wrote: >> >> > > On Monday 19 December 2011 09:09:34 Guennadi Liakhovetski wrote: >> >> > > > On Mon, 19 Dec 2011, Laurent Pinchart wrote: >> >> > > > > On Friday 16 December 2011 10:50:21 Guennadi Liakhovetski wrote: >> >> > > > > > On Fri, 16 Dec 2011, Scott Jiang wrote: >> >> > > > > > > >> How about this implementation? I know it's not for soc, >> >> > > > > > > >> but I >> >> > > > > > > >> post it to give my idea. >> >> > > > > > > >> Bridge knows the layout, so it doesn't need to query the >> >> > > > > > > >> subdevice. >> >> > > > > > > > >> >> > > > > > > > Where from? AFAIU, we are talking here about subdevice >> >> > > > > > > > inputs, >> >> > > > > > > > right? In this case about various inputs of the TV decoder. >> >> > > > > > > > How >> >> > > > > > > > shall the bridge driver know about that? >> >> > > > > > > >> >> > > > > > > I have asked this question before. Laurent reply me: >> >> > > > > > > > >> ENUMINPUT as defined by V4L2 enumerates input connectors >> >> > > > > > > > >> available on the board. Which inputs the board designer >> >> > > > > > > > >> hooked up is something that only the top-level V4L driver >> >> > > > > > > > >> will know. Subdevices do not have that information, so >> >> > > > > > > > >> enuminputs is not applicable there. >> >> > > > > > > > >> >> >> > > > > > > > >> Of course, subdevices do have input pins and output pins, >> >> > > > > > > > >> but these are assumed to be fixed. With the s_routing ops >> >> > > > > > > > >> the top level driver selects which input and output pins >> >> > > > > > > > >> are active. Enumeration of those inputs and outputs >> >> > > > > > > > >> wouldn't gain you anything as far as I can tell since the >> >> > > > > > > > >> subdevice simply does not know which inputs/outputs are >> >> > > > > > > > >> actually hooked up. It's the top level driver that has >> >> > > > > > > > >> that >> >> > > > > > > > >> information (usually passed in through board/card info >> >> > > > > > > > >> structures). >> >> > > > > > >> >> > > > > > Laurent, right, I now remember reading this discussion before. >> >> > > > > > But >> >> > > > > > I'm not sure I completely agree:-) Yes, you're right - the board >> >> > > > > > decides which pins are routed to which connectors. And it has to >> >> > > > > > provide this information to the driver in its platform data. >> >> > > > > > But - >> >> > > > > > I think, this information should be provided not to the bridge >> >> > > > > > driver, but to respective subdevice drivers, because only they >> >> > > > > > know what exactly those interfaces are good for and how to >> >> > > > > > report >> >> > > > > > them to the bridge or the user, if we decide to also export this >> >> > > > > > information over the subdevice user-space API. >> >> > > > > > >> >> > > > > > So, I would say, the board has to tell the subdevice driver: >> >> > > > > > yes, >> >> >
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
>> I agree that input enumeration is needed, but I really think this should be >> handled through pads, no with a new subdev operation. I don't like the idea >> of >> introducing a new operation that will already be deprecated from the very >> beginning. >> >> Implementing this through pads isn't difficult. You don't need to implement >> any pad operation in the tvp5150 driver. All you need to do is setup an array >> of pads at probe time with information provided through platform data. soc- >> camera should then just access the pads array and implement enum_input >> internally. > > Ok, this might indeed be simple enough. Javier, could you give it a try? All right, as soon as I have some time I'll go for that approach. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to figure out reasons for lost pictures in UVC driver.
On 19 December 2011 12:59, Laurent Pinchart wrote: > Hi Javier, > > On Monday 19 December 2011 12:01:34 javier Martin wrote: >> On 19 December 2011 01:19, Laurent Pinchart wrote: >> > On Thursday 15 December 2011 17:02:47 javier Martin wrote: >> >> Hi, >> >> we are testing a logitech Webcam M/N: V-U0012 in the UVC tree (commit >> >> ef7728797039bb6a20f22cc2d96ef72d9338cba0). >> >> It is configured at 25fps, VGA. >> >> >> >> We've observed that the following debugging message appears sometimes >> >> "Frame complete (FID bit toggled).". Whenever this happens a v4l2 >> >> frame is lost (i.e. one sequence number has been skipped). >> >> >> >> Is this behavior expected? What could we do to avoid frame loss? >> > >> > Could you check the frame intervals to see if a frame is really lost, or >> > if the driver erroneously reports frame loss ? >> >> Hi Laurent, >> sequence number in the v4l2 buffer returned is one step bigger than >> expected, however the timestamp difference with the previous buffer is >> 40ms which is what it is expected at 25fps. >> So, sequence number indicates a buffer has been lost but timestamp does >> not. > > Could you please test the following patch ? > > From e6d21947277ad7875e41a90d387db8a1160368b6 Mon Sep 17 00:00:00 2001 > From: Laurent Pinchart > Date: Mon, 19 Dec 2011 12:54:20 +0100 > Subject: [PATCH] uvcvideo: Toggle the stored FID bit when detecting a new > frame > > The FID bit is used to detect the start of a new frame by comparing the > value sent by the device with the last value stored in the driver. When > a new frame is detected this way the last value isn't updated, which > leads to the frame sequence being incremented twice. Fix this by > toggling the stored FID bit correctly. > > Signed-off-by: Laurent Pinchart > --- > drivers/media/video/uvc/uvc_video.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/uvc/uvc_video.c > b/drivers/media/video/uvc/uvc_video.c > index c7e69b8..f61c36b 100644 > --- a/drivers/media/video/uvc/uvc_video.c > +++ b/drivers/media/video/uvc/uvc_video.c > @@ -1031,6 +1031,7 @@ static int uvc_video_decode_start(struct uvc_streaming > *stream, > uvc_trace(UVC_TRACE_FRAME, "Frame complete (FID bit " > "toggled).\n"); > buf->state = UVC_BUF_STATE_READY; > + stream->last_fid = fid; > return -EAGAIN; > } > > -- > Regards, > > Laurent Pinchart Hi Laurent, after applying the patch we keep on losing frames, sometimes a great amount of them. And timestamps are still wrong. For instance, the following case shows a current timestamp being lesser than the previous: Lost 40 frames during acquisition. Total 40 pictures lost Previous timestamp: 902 s, 818241 us. Current timestamp: 902 s, 145941 us. Every time those kind of issues appear we get the following message from the kernel: "Dropping payload (out of sync)." -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media i.MX27 camera: add support for YUV420 format.
Hi, are there any comments on this? May I suppose you agree and it will be applied? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MEM2MEM devices: how to handle sequence number?
Hi,
we have a processing chain composed of three v4l2 devices:
- ---
--
| v4l2 source || v4l2 fixer | | v4l2 encoder |
| (capture) |-->| (mem2mem)| >| (mem2mem) |
>
|___||| ||
"v4l2 source" generates consecutive sequence numbers so that we can
detect whether a frame has been lost or not.
"v4l2 fixer" and "v4l2 encoder" cannot lose frames because they don't
interact with an external sensor.
How should "v4l2 fixer" and "v4l2 encoder" behave regarding frame
sequence number? Should they just copy the sequence number from the
input buffer to the output buffer or should they maintain their own
count for the CAPTURE queue?
If the former option is chosen we should apply a patch like the
following so that the sequence number of the input buffer is passed to
the videobuf2 layer:
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 1250662..7d8a88b 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1127,6 +1127,7 @@ int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
*/
list_add_tail(&vb->queued_entry, &q->queued_list);
vb->state = VB2_BUF_STATE_QUEUED;
+ vb->v4l2_buf.sequence = b->sequence;
/*
* If already streaming, give the buffer to driver for processing.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media i.MX27 camera: Fix field_count handling.
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c |5 -
drivers/media/video/mx2_emmaprp.c | 29 ++---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev->csicr1, pcdev->base_csi + CSICR1);
pcdev->icd = icd;
+ pcdev->frame_count = 0;
dev_info(icd->parent, "Camera driver attached to camera %d\n",
icd->devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(&vb->queue);
vb->state = state;
do_gettimeofday(&vb->ts);
- vb->field_count++;
+ vb->field_count = pcdev->frame_count * 2;
+ pcdev->frame_count++;
wake_up(&vb->done);
}
diff --git a/drivers/media/video/mx2_emmaprp.c
b/drivers/media/video/mx2_emmaprp.c
index 607b73f..fb87665 100644
--- a/drivers/media/video/mx2_emmaprp.c
+++ b/drivers/media/video/mx2_emmaprp.c
@@ -16,6 +16,7 @@
* Free Software Foundation; either version 2 of the
* License, or (at your option) any later version
*/
+
#include
#include
#include
@@ -35,7 +36,7 @@ MODULE_AUTHOR("Javier Martin
dev;
+ struct dma_chan *chan = pcdev->dma_chan;
if ((v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) > 0)
&& (v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) > 0)
- && (atomic_read(&pcdev->busy) == 0))
+ && (dma_async_memcpy_complete(chan, ctx->cookie, NULL, NULL) == 0))
return 1;
dprintk(pcdev, "Task not ready to run\n");
@@ -290,10 +292,8 @@ static void emmaprp_unlock(void *priv)
static void emmaprp_dma_callback(void *data)
{
struct emmaprp_dev *pcdev = (struct emmaprp_dev *)data;
- struct dma_chan *chan = pcdev->dma_chan;
struct vb2_buffer *src_vb, *dst_vb;
struct emmaprp_ctx *curr_ctx;
- enum dma_status status;
unsigned long flags;
curr_ctx = v4l2_m2m_get_curr_priv(pcdev->m2m_dev);
@@ -306,26 +306,18 @@ static void emmaprp_dma_callback(void *data)
if (curr_ctx->aborting)
goto irq_ok;
- status = dma_async_memcpy_complete(chan, curr_ctx->cookie, NULL, NULL);
- if (status != DMA_SUCCESS) {
- v4l2_warn(&pcdev->v4l2_dev,
- "DMA got completion callback but status is \'%s\'\n",
- status == DMA_ERROR ? "error" : "in progress");
- goto irq_ok;
- }
-
src_vb = v4l2_m2m_src_buf_remove(curr_ctx->m2m_ctx);
dst_vb = v4l2_m2m_dst_buf_remove(curr_ctx->m2m_ctx);
dst_vb->v4l2_buf.sequence = src_vb->v4l2_buf.sequence;
-
+printk("%s: dstbuf sequence =%d, srcbuf sequence = %d\n", __func__,
dst_vb->v4l2_buf.sequence, src_vb->v4l2_buf.sequence);
spin_lock_irqsave(&pcdev->irqlock, flags);
v4l2_m2m_buf_done(src_vb, VB2_BUF_STATE_DONE);
v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_DONE);
spin_unlock_irqrestore(&pcdev->irqlock, flags);
irq_ok:
- atomic_set(&pcdev->busy, 0);
v4l2_m2m_job_finish(pcdev->m2m_dev, curr_ctx->m2m_ctx);
+printk("DMA IRQ\n");
}
static void emmaprp_device_run(void *priv)
@@ -342,7 +334,6 @@ static void emmaprp_device_run(void *priv)
unsigned int d_size, s_size;
dma_addr_t p_in, p_out;
enum dma_ctrl_flags flags;
- dma_cookie_t cookie;
atomic_set(&ctx->dev->busy, 1);
@@ -382,12 +373,12 @@ static void emmaprp_device_run(void *priv)
}
tx->callback = emmaprp_dma_callback;
tx->callback_param = pcdev;
- cookie = tx->tx_submit(tx);
- ctx->cookie = cookie;
- if (dma_submit_error(cookie)) {
+ ctx->cookie = tx->tx_submit(tx);
+
+ if (dma_submit_error(ctx->cookie)) {
v4l2_warn(&pcdev->v4l2_dev,
"DMA submit error %d with src=0x%x dst=0x%x
len=0x%x\n",
-
Re: [PATCH] media i.MX27 camera: Fix field_count handling.
Argh,
sorry, there is a file here that souldn't be included.
I'll resend it again.
On 22 December 2011 16:05, Javier Martin
wrote:
> To properly detect frame loss the driver must keep
> track of a frame_count.
>
> Furthermore, field_count use was erroneous because
> in progressive format this must be incremented twice.
>
> Signed-off-by: Javier Martin
> ---
> drivers/media/video/mx2_camera.c | 5 -
> drivers/media/video/mx2_emmaprp.c | 29 ++---
> 2 files changed, 14 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/video/mx2_camera.c
> b/drivers/media/video/mx2_camera.c
> index ea1f4dc..ca76dd2 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -255,6 +255,7 @@ struct mx2_camera_dev {
> dma_addr_t discard_buffer_dma;
> size_t discard_size;
> struct mx2_fmt_cfg *emma_prp;
> + u32 frame_count;
> };
>
> /* buffer for one video frame */
> @@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
> *icd)
> writel(pcdev->csicr1, pcdev->base_csi + CSICR1);
>
> pcdev->icd = icd;
> + pcdev->frame_count = 0;
>
> dev_info(icd->parent, "Camera driver attached to camera %d\n",
> icd->devnum);
> @@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
> mx2_camera_dev *pcdev,
> list_del(&vb->queue);
> vb->state = state;
> do_gettimeofday(&vb->ts);
> - vb->field_count++;
> + vb->field_count = pcdev->frame_count * 2;
> + pcdev->frame_count++;
>
> wake_up(&vb->done);
> }
> diff --git a/drivers/media/video/mx2_emmaprp.c
> b/drivers/media/video/mx2_emmaprp.c
> index 607b73f..fb87665 100644
> --- a/drivers/media/video/mx2_emmaprp.c
> +++ b/drivers/media/video/mx2_emmaprp.c
> @@ -16,6 +16,7 @@
> * Free Software Foundation; either version 2 of the
> * License, or (at your option) any later version
> */
> +
> #include
> #include
> #include
> @@ -35,7 +36,7 @@ MODULE_AUTHOR("Javier Martin
> MODULE_LICENSE("GPL");
> MODULE_VERSION("0.0.1");
>
> -static bool debug;
> +static bool debug = true;
> module_param(debug, bool, 0644);
>
> #define MIN_W 32
> @@ -250,10 +251,11 @@ static int emmaprp_job_ready(void *priv)
> {
> struct emmaprp_ctx *ctx = priv;
> struct emmaprp_dev *pcdev = ctx->dev;
> + struct dma_chan *chan = pcdev->dma_chan;
>
> if ((v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) > 0)
> && (v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) > 0)
> - && (atomic_read(&pcdev->busy) == 0))
> + && (dma_async_memcpy_complete(chan, ctx->cookie, NULL, NULL) ==
> 0))
> return 1;
>
> dprintk(pcdev, "Task not ready to run\n");
> @@ -290,10 +292,8 @@ static void emmaprp_unlock(void *priv)
> static void emmaprp_dma_callback(void *data)
> {
> struct emmaprp_dev *pcdev = (struct emmaprp_dev *)data;
> - struct dma_chan *chan = pcdev->dma_chan;
> struct vb2_buffer *src_vb, *dst_vb;
> struct emmaprp_ctx *curr_ctx;
> - enum dma_status status;
> unsigned long flags;
>
> curr_ctx = v4l2_m2m_get_curr_priv(pcdev->m2m_dev);
> @@ -306,26 +306,18 @@ static void emmaprp_dma_callback(void *data)
> if (curr_ctx->aborting)
> goto irq_ok;
>
> - status = dma_async_memcpy_complete(chan, curr_ctx->cookie, NULL,
> NULL);
> - if (status != DMA_SUCCESS) {
> - v4l2_warn(&pcdev->v4l2_dev,
> - "DMA got completion callback but status is
> \'%s\'\n",
> - status == DMA_ERROR ? "error" : "in progress");
> - goto irq_ok;
> - }
> -
> src_vb = v4l2_m2m_src_buf_remove(curr_ctx->m2m_ctx);
> dst_vb = v4l2_m2m_dst_buf_remove(curr_ctx->m2m_ctx);
> dst_vb->v4l2_buf.sequence = src_vb->v4l2_buf.sequence;
> -
> +printk("%s: dstbuf sequence =%d, srcbuf sequence = %d\n", __func__,
> dst_vb->v4l2_buf.sequence, src_vb->v4l2_buf.sequence);
> spin_lock_irqsave(&pcdev->irqlock, flags);
> v4l2_m2m_buf_done(src_vb, VB2_BUF_STATE_DONE);
> v4l2_m2m_buf_done(dst_vb, VB2_BUF_STATE_DONE);
> spin_unlock_irqrestore(&pcdev->irqlock,
[PATCH v2] media i.MX27 camera: Fix field_count handling.
To properly detect frame loss the driver must keep
track of a frame_count.
Furthermore, field_count use was erroneous because
in progressive format this must be incremented twice.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ea1f4dc..ca76dd2 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -255,6 +255,7 @@ struct mx2_camera_dev {
dma_addr_t discard_buffer_dma;
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
+ u32 frame_count;
};
/* buffer for one video frame */
@@ -368,6 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev->csicr1, pcdev->base_csi + CSICR1);
pcdev->icd = icd;
+ pcdev->frame_count = 0;
dev_info(icd->parent, "Camera driver attached to camera %d\n",
icd->devnum);
@@ -1211,7 +1213,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del(&vb->queue);
vb->state = state;
do_gettimeofday(&vb->ts);
- vb->field_count++;
+ vb->field_count = pcdev->frame_count * 2;
+ pcdev->frame_count++;
wake_up(&vb->done);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media i.MX27 camera: Fix field_count handling.
Hi Guennadi,
thank you for your comments.
On 23 December 2011 00:17, Guennadi Liakhovetski wrote:
> On Thu, 22 Dec 2011, Javier Martin wrote:
>
>> To properly detect frame loss the driver must keep
>> track of a frame_count.
>>
>> Furthermore, field_count use was erroneous because
>> in progressive format this must be incremented twice.
>
> Hm, sorry, why this? I just looked at vivi.c - the version before
> videobuf2 conversion - and it seems to only increment the count by one.
If you look at the videobuf-core code you'll notice that the value
assigned to v4l2_buf sequence field is (field_count >> 1):
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/videobuf-core.c#L370
Since mx2_camera driver only supports video formats which are either
progressive or provide both fields in the same buffer, this
"field_count" must be incremented twice so that the final sequence
number is OK.
>>
>> Signed-off-by: Javier Martin
>> ---
>> drivers/media/video/mx2_camera.c | 5 -
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/mx2_camera.c
>> b/drivers/media/video/mx2_camera.c
>> index ea1f4dc..ca76dd2 100644
>> --- a/drivers/media/video/mx2_camera.c
>> +++ b/drivers/media/video/mx2_camera.c
>> @@ -255,6 +255,7 @@ struct mx2_camera_dev {
>> dma_addr_t discard_buffer_dma;
>> size_t discard_size;
>> struct mx2_fmt_cfg *emma_prp;
>> + u32 frame_count;
>
> The rule I usually follow, when choosing variable type is the following:
> does it really have to be fixed bit-width? The positive reply is pretty
> rare, it comes mostly if (a) the variable is used to store values read
> from or written to some (fixed-width) hardware registers, or (b) the
> variable belongs to a fixed ABI, that has to be the same on different
> (32-bit, 64-bit) systems, like (arguably) ioctl()s, data, transferred over
> the network or stored on a medium (filesystems,...). This doesn't seem to
> be the case here, so, I would just use an (unsigned) int.
Thanks for the tip. I hadn't thought of it that way. I just saw that
v4l2_buf.sequence was a __u32 and I thought it was convenient to use
the same type for this variable which is closely related to it
Anyway, let me send a second version of the patch since I've just
noticed this one doesn't reflect lost frames in the field_count field.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] media i.MX27 camera: Fix field_count handling.
On 23 December 2011 10:07, Guennadi Liakhovetski wrote: > On Fri, 23 Dec 2011, javier Martin wrote: > >> Hi Guennadi, >> thank you for your comments. >> >> On 23 December 2011 00:17, Guennadi Liakhovetski >> wrote: >> > On Thu, 22 Dec 2011, Javier Martin wrote: >> > >> >> To properly detect frame loss the driver must keep >> >> track of a frame_count. >> >> >> >> Furthermore, field_count use was erroneous because >> >> in progressive format this must be incremented twice. >> > >> > Hm, sorry, why this? I just looked at vivi.c - the version before >> > videobuf2 conversion - and it seems to only increment the count by one. >> >> If you look at the videobuf-core code you'll notice that the value >> assigned to v4l2_buf sequence field is (field_count >> 1): > > Right, i.e., field-count / 2. So, it really only counts _frames_, not > fields, doesn't it? > Yes, v4l2_buf sequence field counts _frames_ but field_count counts _fields_, that's why I increment field-count twice in my driver. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] soc-camera for 3.3
Hi Guennadi, On 29 December 2011 09:38, Guennadi Liakhovetski wrote: > Hi Mauro > > Please pull a couple of soc-camera patches for 3.3. This is going to be a > _much_ quieter pull, than the previous one:-) I didn't have time to > continue the work on the soc-camera Media Controller conversion, so, that > will have to wait at least until 3.4. > > Interestingly, Javier Martin has fixed field_count handling in mx2_camera, > but, apparently, it also has to be fixed in other soc-camera drivers. So, > a patch for that might follow later in the 3.3 cycle. > > The following changes since commit 1a5cd29631a6b75e49e6ad8a770ab9d69cda0fa2: > > [media] tda10021: Add support for DVB-C Annex C (2011-12-20 14:01:08 -0200) > > are available in the git repository at: > git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.3 > > Guennadi Liakhovetski (4): > V4L: soc-camera: remove redundant parameter from the .set_bus_param() > method > V4L: mt9m111: cleanly separate register contexts > V4L: mt9m111: power down most circuits when suspended > V4L: mt9m111: properly implement .s_crop and .s_fmt(), reset on STREAMON > > Javier Martin (2): > media i.MX27 camera: add support for YUV420 format. > media i.MX27 camera: Fix field_count handling. So, you already applied my patch related to "field_count" handling. I was preparing a v3 for that patch to fix the frame_count type issue and to really provide frame loss detection but I can prepare it on top of the old one if you want. Regards. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media i.MX27 camera: properly detect frame loss.
As V4L2 specification states, frame_count must also
regard lost frames so that the user can handle that
case properly.
This patch adds a mechanism to increment the frame
counter even when a video buffer is not available
and a discard buffer is used.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 54 --
1 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ca76dd2..b244714 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -256,6 +256,7 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
+ unsigned intfirstirq;
};
/* buffer for one video frame */
@@ -370,6 +371,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
pcdev->icd = icd;
pcdev->frame_count = 0;
+ pcdev->firstirq = 1;
dev_info(icd->parent, "Camera driver attached to camera %d\n",
icd->devnum);
@@ -572,6 +574,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
struct soc_camera_host *ici =
to_soc_camera_host(icd->parent);
struct mx2_camera_dev *pcdev = ici->priv;
+ struct mx2_fmt_cfg *prp = pcdev->emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -584,6 +587,26 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
list_add_tail(&vb->queue, &pcdev->capture);
if (mx27_camera_emma(pcdev)) {
+ if (prp->cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp->cfg.in_fmt |
+ prp->cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev->base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp->cfg.in_fmt |
+ prp->cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev->base_emma + PRP_CNTL);
+ }
goto out;
} else { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
@@ -747,16 +770,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev->discard_buffer_dma,
pcdev->base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp->cfg.in_fmt |
- prp->cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev->base_emma + PRP_CNTL);
-
writel((icd->user_width << 16) | icd->user_height,
pcdev->base_emma + PRP_SRC_FRAME_SIZE);
writel((icd->user_width << 16) | icd->user_height,
@@ -784,15 +797,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
pcdev->base_emma + PRP_SOURCE_CR_PTR);
}
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp->cfg.in_fmt |
- prp->cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev->base_emma + PRP_CNTL);
-
writel((icd->user_width << 16) | icd->user_height,
pcdev->base_emma + PRP_SRC_FRAME_SIZE);
@@ -1214,7 +1218,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
vb->state = state;
do_gettimeofday(&vb->ts);
vb->field_count = pcdev->frame_count * 2;
- pcdev->frame_count++;
wake_up(&vb->done);
}
@@ -1239,6 +1242,17 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
return;
}
+ /*
+* According to V4L2 specification, f
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
Hi, do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MEM2MEM devices: how to handle sequence number?
Hi, i've just arrived the office after holidays and it seems you have agreed some solution to the sequence number issue. As I understand, for a case where there is 1:1 correspondence between input and output (which is my case) I should do the following: - keep an internal frame counter associated with the output queue. - return the frame number when the user calls VIDIOC_QBUF on the output. - pass the output frame number to the capture queue in a 1:1 basis So in my chain of three processed nodes each node has its own internal frame counter and frame loss should be checked at the video source. Is that OK? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: vmalloc-based allocator user pointer handling
Hi, what is the status of this patch? Did you finally merge it in any tree? I am willing to extend it so that it can support pfn mappings as soon as it's ready. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: tvp5150: Add mbus_fmt callbacks.
Hi Mauro, any more comments on this? Will you please merge the last version which includes the fixes you requested? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MEM2MEM devices: how to handle sequence number?
Just one more question about this. The v4l2 encoder, which is the last element in my processing chain, is an H.264 encoder that has to know about previous frames to encode. For these kind of devices it is very useful to know whether a frame has been lost to introduce a skip frame and improve the encoding process. But, with the current approach we don't have any way to communicate this to the device. One option would be that the user specified a sequence number when issuing VIDIOC_QBUF at the output queue so that the device could detect any discontinuity and introduce a skip frame. But this would break your rule that sequence number introduced at the output queue has to be ignored by the driver. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
Signed-off-by: Javier Martin
---
drivers/media/video/videobuf2-vmalloc.c | 66 +++---
1 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..5bc7cec 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -71,6 +72,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ unsigned long int physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +83,34 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr & ~PAGE_MASK;
buf->size = size;
- first = vaddr >> PAGE_SHIFT;
- last = (vaddr + size - 1) >> PAGE_SHIFT;
- buf->n_pages = last - first + 1;
- buf->pages = kzalloc(buf->n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf->pages)
- goto fail_pages_array_alloc;
-
- /* current->mm->mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current->mm, vaddr & PAGE_MASK,
- buf->n_pages, write, 1, /* force */
- buf->pages, NULL);
- if (n_pages != buf->n_pages)
- goto fail_get_user_pages;
-
- buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1, PAGE_KERNEL);
- if (!buf->vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current->mm, vaddr);
+ if (vma && (vma->vm_flags & VM_IO) && (vma->vm_pgoff)) {
+ physp = (vma->vm_pgoff << PAGE_SHIFT) + (vaddr - vma->vm_start);
+ buf->vaddr = ioremap_nocache(physp, size);
+ if (!buf->vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr >> PAGE_SHIFT;
+ last = (vaddr + size - 1) >> PAGE_SHIFT;
+ buf->n_pages = last - first + 1;
+ buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf->pages)
+ goto fail_pages_array_alloc;
+
+ /* current->mm->mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current->mm,
+vaddr & PAGE_MASK, buf->n_pages,
+write,1, /* force */
+buf->pages, NULL);
+ if (n_pages != buf->n_pages)
+ goto fail_get_user_pages;
+
+ buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf->vaddr)
+ goto fail_get_user_pages;
+ }
buf->vaddr += offset;
return buf;
@@ -120,14 +134,18 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf->n_pages);
- for (i = 0; i < buf->n_pages; ++i) {
- if (buf->write)
- set_page_dirty_lock(buf->pages[i]);
- put_page(buf->pages[i]);
+ if (buf->pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf->n_pages);
+ for (i = 0; i < buf->n_pages; ++i) {
+ if (buf->write)
+ set_page_dirty_lock(buf->pages[i]);
+ put_page(buf->pages[i]);
+ }
+ kfree(buf->pages);
+ } else {
+ iounmap(buf->vaddr);
}
- kfree(buf->pages);
kfree(buf);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] uvcvideo: Allow userptr IO mode.
Userptr can be very useful if a UVC camera
is requested to use video buffers allocated
by another processing device. So that
buffers don't need to be copied.
Signed-off-by: Javier Martin
---
drivers/media/video/uvc/uvc_queue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 518f77d..8f54e24 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -126,7 +126,7 @@ void uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type,
int drop_corrupted)
{
queue->queue.type = type;
- queue->queue.io_modes = VB2_MMAP;
+ queue->queue.io_modes = VB2_MMAP | VB2_USERPTR;
queue->queue.drv_priv = queue;
queue->queue.buf_struct_size = sizeof(struct uvc_buffer);
queue->queue.ops = &uvc_queue_qops;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
On 2 January 2012 22:12, Sylwester Nawrocki wrote: > Hi Javier, > > On 01/02/2012 10:31 AM, javier Martin wrote: >> Hi, >> do you have any more concerns or comments on this patch? >> I can't find it in media_tree. Has it been merged somewhere else? > > If you think your driver is good enough for merging, if you didn't > do so already, you should normally send Mauro a git pull request. > Please see: > > http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request > > And here you can find some examples: > http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=PULL&archive=both Do you mean I have to set up a public GIT repository? Is this mandatory? I am not a subsystem maintainer, just casual developer. What about this? http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: vb2: support userptr for PFN mappings.
Hi Laurent,
thank you for your review.
On 2 January 2012 20:00, Laurent Pinchart
wrote:
> Hi Javier,
>
> Thanks for the patch.
>
> On Monday 02 January 2012 15:12:22 Javier Martin wrote:
>> Some video devices need to use contiguous memory
>> which is not backed by pages as it happens with
>> vmalloc. This patch provides userptr handling for
>> those devices.
>
> What's your main use case ? Capturing to the frame buffer ?
My main use case is capturing to my mx2_emmaprp mem2mem driver which
converts from YUV422 to YUV420 format in HW.
>> Signed-off-by: Javier Martin
>> ---
>> drivers/media/video/videobuf2-vmalloc.c | 66
>> +++--- 1 files changed, 42 insertions(+), 24
>> deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf2-vmalloc.c
>> b/drivers/media/video/videobuf2-vmalloc.c index 03aa62f..5bc7cec 100644
>> --- a/drivers/media/video/videobuf2-vmalloc.c
>> +++ b/drivers/media/video/videobuf2-vmalloc.c
>> @@ -15,6 +15,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> Please keep headers sorted alphabetically.
OK. I didn't know that was the rule.
>> #include
>> #include
>> @@ -71,6 +72,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
>> unsigned long vaddr, struct vb2_vmalloc_buf *buf;
>> unsigned long first, last;
>> int n_pages, offset;
>> + struct vm_area_struct *vma;
>> + unsigned long int physp;
>>
>> buf = kzalloc(sizeof(*buf), GFP_KERNEL);
>> if (!buf)
>> @@ -80,23 +83,34 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
>> unsigned long vaddr, offset = vaddr & ~PAGE_MASK;
>> buf->size = size;
>>
>> - first = vaddr >> PAGE_SHIFT;
>> - last = (vaddr + size - 1) >> PAGE_SHIFT;
>> - buf->n_pages = last - first + 1;
>> - buf->pages = kzalloc(buf->n_pages * sizeof(struct page *), GFP_KERNEL);
>> - if (!buf->pages)
>> - goto fail_pages_array_alloc;
>> -
>> - /* current->mm->mmap_sem is taken by videobuf2 core */
>> - n_pages = get_user_pages(current, current->mm, vaddr & PAGE_MASK,
>> - buf->n_pages, write, 1, /* force */
>> - buf->pages, NULL);
>> - if (n_pages != buf->n_pages)
>> - goto fail_get_user_pages;
>> -
>> - buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1, PAGE_KERNEL);
>> - if (!buf->vaddr)
>> - goto fail_get_user_pages;
>> + vma = find_vma(current->mm, vaddr);
>> + if (vma && (vma->vm_flags & VM_IO) && (vma->vm_pgoff)) {
>> + physp = (vma->vm_pgoff << PAGE_SHIFT) + (vaddr -
>> vma->vm_start);
>> + buf->vaddr = ioremap_nocache(physp, size);
>> + if (!buf->vaddr)
>> + goto fail_pages_array_alloc;
>
> What if the region spans multiple VMAs ? Shouldn't you at least verify that
> the region is physically contiguous, and that all VMAs share the same flags ?
> That's what the OMAP3 ISP driver does (in ispqueue.c). Maybe it's overkill
> though.
>
> If you do that, the could might be cleaner if you split this function in two,
> as in the OMAP3 ISP driver.
Yes, I suspected this could probably be troublesome. I'll take a look
at OMAP3 ISP and see what I can do.
>> + } else {
>> + first = vaddr >> PAGE_SHIFT;
>> + last = (vaddr + size - 1) >> PAGE_SHIFT;
>> + buf->n_pages = last - first + 1;
>> + buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
>> + GFP_KERNEL);
>> + if (!buf->pages)
>> + goto fail_pages_array_alloc;
>> +
>> + /* current->mm->mmap_sem is taken by videobuf2 core */
>> + n_pages = get_user_pages(current, current->mm,
>> + vaddr & PAGE_MASK, buf->n_pages,
>> + write,1, /* force */
>> + buf->pages, NULL);
>> + if (n_pages != buf->n_pages)
>> + goto fail_get_user_pages;
>> +
>> + buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
>> + PAGE_KERNEL);
>> + if (!buf->vaddr)
>>
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
Added Mauro to CC. On 3 January 2012 08:43, javier Martin wrote: > On 2 January 2012 22:12, Sylwester Nawrocki wrote: >> Hi Javier, >> >> On 01/02/2012 10:31 AM, javier Martin wrote: >>> Hi, >>> do you have any more concerns or comments on this patch? >>> I can't find it in media_tree. Has it been merged somewhere else? >> >> If you think your driver is good enough for merging, if you didn't >> do so already, you should normally send Mauro a git pull request. >> Please see: >> >> http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request >> >> And here you can find some examples: >> http://patchwork.linuxtv.org/project/linux-media/list/?state=*&q=PULL&archive=both > > Do you mean I have to set up a public GIT repository? Is this mandatory? > I am not a subsystem maintainer, just casual developer. > > What about this? > > http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v1:
- Use vb2_get_contig_userptr() which provides page
locking and contiguous memory check.
Signed-off-by: Javier Martin
---
drivers/media/video/videobuf2-vmalloc.c | 74 +--
1 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..8248e56 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,40 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr & ~PAGE_MASK;
buf->size = size;
- first = vaddr >> PAGE_SHIFT;
- last = (vaddr + size - 1) >> PAGE_SHIFT;
- buf->n_pages = last - first + 1;
- buf->pages = kzalloc(buf->n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf->pages)
- goto fail_pages_array_alloc;
- /* current->mm->mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current->mm, vaddr & PAGE_MASK,
- buf->n_pages, write, 1, /* force */
- buf->pages, NULL);
- if (n_pages != buf->n_pages)
- goto fail_get_user_pages;
-
- buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1, PAGE_KERNEL);
- if (!buf->vaddr)
- goto fail_get_user_pages;
+ down_read(¤t->mm->mmap_sem);
+ vma = find_vma(current->mm, vaddr);
+ if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
+ up_read(¤t->mm->mmap_sem);
+ if (vb2_get_contig_userptr(vaddr, size, &res_vma, &physp))
+ goto fail_pages_array_alloc;
+ buf->vma = res_vma;
+ buf->vaddr = ioremap_nocache(physp, size);
+ if (!buf->vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ up_read(¤t->mm->mmap_sem);
+ first = vaddr >> PAGE_SHIFT;
+ last = (vaddr + size - 1) >> PAGE_SHIFT;
+ buf->n_pages = last - first + 1;
+ buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf->pages)
+ goto fail_pages_array_alloc;
+
+ /* current->mm->mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current->mm,
+vaddr & PAGE_MASK, buf->n_pages,
+write, 1, /* force */
+buf->pages, NULL);
+ if (n_pages != buf->n_pages)
+ goto fail_get_user_pages;
+
+ buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf->vaddr)
+ goto fail_get_user_pages;
+ }
buf->vaddr += offset;
return buf;
@@ -120,14 +142,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf->n_pages);
- for (i = 0; i < buf->n_pages; ++i) {
- if (buf->write)
- set_page_dirty_lock(buf->pages[i]);
- put_page(buf->pages[i]);
+ if (buf->pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf->n_pages);
+ for (i = 0; i < buf->n_pages; ++i) {
+ if (buf->write)
+ set_page_dirty_lock(buf->pages[i]);
+ put_page(b
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
Guennadi,
probably you could answer me some question:
as we agreed I'm trying to implement ENUM_INPUT support to soc-camera
through pads. This means I must be able to pass the tvp5150 decoder
some platform_data in order to configure what inputs are really routed
in my board.
For that purpose I do the following in my board specific code:
static struct tvp5150_platform_data visstrim_tvp5150_data = {
.inputs = 55,
};
static struct i2c_board_info visstrim_i2c_camera = {
.type = "tvp5150",
.addr = 0x5d,
.platform_data = &visstrim_tvp5150_data,
};
static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0,/* Must match with the camera ID */
.board_info = &visstrim_i2c_camera,
.i2c_adapter_id = 0,
.power = visstrim_camera_power,
.reset = visstrim_camera_reset,
};
static struct platform_device visstrim_tvp5150_soc = {
.name = "soc-camera-pdrv",
.id = 0,
.dev= {
.platform_data = &iclink_tvp5150,
},
};
However, it seems soc-camera ignores "board_info.platform_data" field
and assigns a value of its own:
http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/soc_camera.c#L1006
How am I suppose to pass that information to the tvp5150 then?
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v3] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v2:
- Do not grab mm->mmap_sem.
Signed-off-by: Javier Martin
---
drivers/media/video/videobuf2-vmalloc.c | 71 +--
1 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..e621db6 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,9 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ struct vm_area_struct *res_vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +85,37 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr & ~PAGE_MASK;
buf->size = size;
- first = vaddr >> PAGE_SHIFT;
- last = (vaddr + size - 1) >> PAGE_SHIFT;
- buf->n_pages = last - first + 1;
- buf->pages = kzalloc(buf->n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf->pages)
- goto fail_pages_array_alloc;
- /* current->mm->mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current->mm, vaddr & PAGE_MASK,
- buf->n_pages, write, 1, /* force */
- buf->pages, NULL);
- if (n_pages != buf->n_pages)
- goto fail_get_user_pages;
-
- buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1, PAGE_KERNEL);
- if (!buf->vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current->mm, vaddr);
+ if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
+ if (vb2_get_contig_userptr(vaddr, size, &res_vma, &physp))
+ goto fail_pages_array_alloc;
+ buf->vma = res_vma;
+ buf->vaddr = ioremap_nocache(physp, size);
+ if (!buf->vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr >> PAGE_SHIFT;
+ last = (vaddr + size - 1) >> PAGE_SHIFT;
+ buf->n_pages = last - first + 1;
+ buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf->pages)
+ goto fail_pages_array_alloc;
+
+ /* current->mm->mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current->mm,
+vaddr & PAGE_MASK, buf->n_pages,
+write, 1, /* force */
+buf->pages, NULL);
+ if (n_pages != buf->n_pages)
+ goto fail_get_user_pages;
+
+ buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf->vaddr)
+ goto fail_get_user_pages;
+ }
buf->vaddr += offset;
return buf;
@@ -120,14 +139,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf->n_pages);
- for (i = 0; i < buf->n_pages; ++i) {
- if (buf->write)
- set_page_dirty_lock(buf->pages[i]);
- put_page(buf->pages[i]);
+ if (buf->pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf->n_pages);
+ for (i = 0; i < buf->n_pages; ++i) {
+ if (buf->write)
+ set_page_dirty_lock(buf->pages[i]);
+ put_page(buf->pages[i]);
+ }
+ kfree(buf->pages);
+ } else {
+ if (buf->vma)
+ vb2_put_vma(buf->vma);
+ iounmap(buf-&
Re: [PATCH] V4L: soc-camera: provide support for S_INPUT.
Hi Guennadi.
Thanks for your help.
On 3 January 2012 16:05, Guennadi Liakhovetski wrote:
> Hi Javier
>
> On Tue, 3 Jan 2012, javier Martin wrote:
>
>> Guennadi,
>> probably you could answer me some question:
>>
>> as we agreed I'm trying to implement ENUM_INPUT support to soc-camera
>> through pads.
>
> No, you probably mean in the subdev driver, not in soc-camera core.
>
>> This means I must be able to pass the tvp5150 decoder
>> some platform_data in order to configure what inputs are really routed
>> in my board.
>>
>> For that purpose I do the following in my board specific code:
>>
>> static struct tvp5150_platform_data visstrim_tvp5150_data = {
>> .inputs = 55,
>> };
>>
>> static struct i2c_board_info visstrim_i2c_camera = {
>> .type = "tvp5150",
>> .addr = 0x5d,
>> .platform_data = &visstrim_tvp5150_data,
>> };
>>
>> static struct soc_camera_link iclink_tvp5150 = {
>> .bus_id = 0, /* Must match with the camera ID */
>> .board_info = &visstrim_i2c_camera,
>> .i2c_adapter_id = 0,
>> .power = visstrim_camera_power,
>> .reset = visstrim_camera_reset,
>> };
>>
>> static struct platform_device visstrim_tvp5150_soc = {
>> .name = "soc-camera-pdrv",
>> .id = 0,
>> .dev = {
>> .platform_data = &iclink_tvp5150,
>> },
>> };
>>
>>
>> However, it seems soc-camera ignores "board_info.platform_data" field
>> and assigns a value of its own:
>>
>> http://lxr.linux.no/#linux+v3.1.6/drivers/media/video/soc_camera.c#L1006
>>
>>
>> How am I suppose to pass that information to the tvp5150 then?
>
> Have a look at some examples, e.g., arch/sh/boards/mach-migor/setup.c:
>
> static struct soc_camera_link ov7725_link = {
> .power = ov7725_power,
> .board_info = &migor_i2c_camera[0],
> .i2c_adapter_id = 0,
> .priv = &ov7725_info,
> };
>
> I.e., soc-camera expects you to use the struct soc_camera_link::priv field
> for subdevice private platform data.
For ov7725 it is a natural thing to do since it was originally
developed for soc-camera and it can easily do the following to access
platform data:
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
pdata = icl->priv;
However, tvp5150 is not aware about soc_camera. I should be able to
tell whether it's being used with soc-camera or not. If soc camera was
used I would do the previous method to retrieve platform data.
But if soc-camera was not used I would do the classic method:
struct tvp5150_platform_data *pdata = client->dev.platform_data;
The problem is how to distinguish in tvp5150 whether I am using
soc_camera or not.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v4] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
---
Changes since v3:
- Remove vma_res variable.
Signed-off-by: Javier Martin
---
drivers/media/video/videobuf2-vmalloc.c | 70 +--
1 files changed, 47 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..f9ff15f 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -10,6 +10,7 @@
* the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -22,6 +23,7 @@
struct vb2_vmalloc_buf {
void*vaddr;
struct page **pages;
+ struct vm_area_struct *vma;
int write;
unsigned long size;
unsigned intn_pages;
@@ -71,6 +73,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ dma_addr_t physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +84,37 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr & ~PAGE_MASK;
buf->size = size;
- first = vaddr >> PAGE_SHIFT;
- last = (vaddr + size - 1) >> PAGE_SHIFT;
- buf->n_pages = last - first + 1;
- buf->pages = kzalloc(buf->n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf->pages)
- goto fail_pages_array_alloc;
- /* current->mm->mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current->mm, vaddr & PAGE_MASK,
- buf->n_pages, write, 1, /* force */
- buf->pages, NULL);
- if (n_pages != buf->n_pages)
- goto fail_get_user_pages;
-
- buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1, PAGE_KERNEL);
- if (!buf->vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current->mm, vaddr);
+ if (vma && (vma->vm_flags & VM_PFNMAP) && (vma->vm_pgoff)) {
+ if (vb2_get_contig_userptr(vaddr, size, &vma, &physp))
+ goto fail_pages_array_alloc;
+ buf->vma = vma;
+ buf->vaddr = ioremap_nocache(physp, size);
+ if (!buf->vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr >> PAGE_SHIFT;
+ last = (vaddr + size - 1) >> PAGE_SHIFT;
+ buf->n_pages = last - first + 1;
+ buf->pages = kzalloc(buf->n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf->pages)
+ goto fail_pages_array_alloc;
+
+ /* current->mm->mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current->mm,
+vaddr & PAGE_MASK, buf->n_pages,
+write, 1, /* force */
+buf->pages, NULL);
+ if (n_pages != buf->n_pages)
+ goto fail_get_user_pages;
+
+ buf->vaddr = vm_map_ram(buf->pages, buf->n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf->vaddr)
+ goto fail_get_user_pages;
+ }
buf->vaddr += offset;
return buf;
@@ -120,14 +138,20 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf->vaddr & PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf->n_pages);
- for (i = 0; i < buf->n_pages; ++i) {
- if (buf->write)
- set_page_dirty_lock(buf->pages[i]);
- put_page(buf->pages[i]);
+ if (buf->pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf->n_pages);
+ for (i = 0; i < buf->n_pages; ++i) {
+ if (buf->write)
+ set_page_dirty_lock(buf->pages[i]);
+ put_page(buf->pages[i]);
+ }
+ kfree(buf->pages);
+ } else {
+ if (buf->vma)
+ vb2_put_vma(buf->vma);
+ iounmap(buf->vaddr);
}
- kfree(buf->pages);
kfree(buf);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: tvp5150: Add mbus_fmt callbacks.
These callbacks allow a host video driver
to poll video formats supported by tvp5150.
---
Changes since v1:
Fix standard handling in tvp5150_mbus_fmt()
---
drivers/media/video/tvp5150.c | 67 +
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
}
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+ int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+ switch (val & 0x0F) {
+ case 0x01:
+ return V4L2_STD_NTSC;
+ case 0x03:
+ return V4L2_STD_PAL;
+ case 0x05:
+ return V4L2_STD_PAL_M;
+ case 0x07:
+ return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+ case 0x09:
+ return V4L2_STD_NTSC_443;
+ case 0xb:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+ enum v4l2_mbus_pixelcode *code)
+{
+ if (index)
+ return -EINVAL;
+
+ *code = V4L2_MBUS_FMT_YUYV8_2X8;
+ return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+ struct v4l2_mbus_framefmt *f)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+ v4l2_std_id std;
+
+ if (f == NULL)
+ return -EINVAL;
+
+ tvp5150_reset(sd, 0);
+
+ /* Calculate height and width based on current standard */
+ if (decoder->norm == V4L2_STD_ALL)
+ std = tvp5150_read_std(sd);
+ else
+ std = decoder->norm;
+
+ f->width = 720;
+ if (std & V4L2_STD_525_60)
+ f->height = 480;
+ else
+ f->height = 576;
+
+ f->code = V4L2_MBUS_FMT_YUYV8_2X8;
+ f->field = V4L2_FIELD_SEQ_TB;
+ f->colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+ v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
+ f->height);
+ return 0;
+}
+
/
I2C Command
/
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops
= {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+ .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+ .s_mbus_fmt = tvp5150_mbus_fmt,
+ .try_mbus_fmt = tvp5150_mbus_fmt,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v4] media: vb2: support userptr for PFN mappings.
Hi Marek, On 9 January 2012 11:14, Marek Szyprowski wrote: > Hello, > > On Wednesday, January 04, 2012 5:19 PM Javier Martin wrote: > >> Some video devices need to use contiguous memory >> which is not backed by pages as it happens with >> vmalloc. This patch provides userptr handling for >> those devices. >> >> --- >> Changes since v3: >> - Remove vma_res variable. >> >> Signed-off-by: Javier Martin > > Acked-by: Marek Szyprowski > > Do you plan to put a git tree with all your patches and send a pull request > to Mauro? If not I will take this patch and put it on my vb2 branch. Is this mandatory for Mauro to merge one's patches? Because I've sent several patches in the patch and haven't received response yet. Anyway, I prefer you to take this patch. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media i.MX27 camera: properly detect frame loss.
Hi Guennadi, this is the patch I mentioned that fixes sequence count so that it complies with v4l2 API. Will you please merge? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media i.MX27 camera: properly detect frame loss.
Hi Guennadi,
thank you for your review.
On 10 January 2012 12:00, Guennadi Liakhovetski wrote:
> Hi Javier
>
> On Mon, 2 Jan 2012, Javier Martin wrote:
>
>> As V4L2 specification states, frame_count must also
>> regard lost frames so that the user can handle that
>> case properly.
>>
>> This patch adds a mechanism to increment the frame
>> counter even when a video buffer is not available
>> and a discard buffer is used.
>>
>> Signed-off-by: Javier Martin
>> ---
>> drivers/media/video/mx2_camera.c | 54
>> --
>> 1 files changed, 34 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/media/video/mx2_camera.c
>> b/drivers/media/video/mx2_camera.c
>> index ca76dd2..b244714 100644
>> --- a/drivers/media/video/mx2_camera.c
>> +++ b/drivers/media/video/mx2_camera.c
>> @@ -256,6 +256,7 @@ struct mx2_camera_dev {
>> size_t discard_size;
>> struct mx2_fmt_cfg *emma_prp;
>> u32 frame_count;
>> + unsigned int firstirq;
>
> _if_ we indeed end up using this field, it seems it can be just a bool.
>
>> };
>>
>> /* buffer for one video frame */
>> @@ -370,6 +371,7 @@ static int mx2_camera_add_device(struct
>> soc_camera_device *icd)
>>
>> pcdev->icd = icd;
>> pcdev->frame_count = 0;
>> + pcdev->firstirq = 1;
>>
>> dev_info(icd->parent, "Camera driver attached to camera %d\n",
>> icd->devnum);
>> @@ -572,6 +574,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
>> struct soc_camera_host *ici =
>> to_soc_camera_host(icd->parent);
>> struct mx2_camera_dev *pcdev = ici->priv;
>> + struct mx2_fmt_cfg *prp = pcdev->emma_prp;
>> struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
>> unsigned long flags;
>>
>> @@ -584,6 +587,26 @@ static void mx2_videobuf_queue(struct videobuf_queue
>> *vq,
>> list_add_tail(&vb->queue, &pcdev->capture);
>>
>> if (mx27_camera_emma(pcdev)) {
>> + if (prp->cfg.channel == 1) {
>> + writel(PRP_CNTL_CH1EN |
>> + PRP_CNTL_CSIEN |
>> + prp->cfg.in_fmt |
>> + prp->cfg.out_fmt |
>> + PRP_CNTL_CH1_LEN |
>> + PRP_CNTL_CH1BYP |
>> + PRP_CNTL_CH1_TSKIP(0) |
>> + PRP_CNTL_IN_TSKIP(0),
>> + pcdev->base_emma + PRP_CNTL);
>> + } else {
>> + writel(PRP_CNTL_CH2EN |
>> + PRP_CNTL_CSIEN |
>> + prp->cfg.in_fmt |
>> + prp->cfg.out_fmt |
>> + PRP_CNTL_CH2_LEN |
>> + PRP_CNTL_CH2_TSKIP(0) |
>> + PRP_CNTL_IN_TSKIP(0),
>> + pcdev->base_emma + PRP_CNTL);
>> + }
>
> Is this related and why is this needed?
This is needed to make sure PrP only starts capturing frames when at
least one buffer is available in the queue. This guarantees the first
video buffer will be written to the discard buffer and the second will
be stored to the free buffer.
>> goto out;
>> } else { /* cpu_is_mx25() */
>> u32 csicr3, dma_inten = 0;
>> @@ -747,16 +770,6 @@ static void mx27_camera_emma_buf_init(struct
>> soc_camera_device *icd,
>> writel(pcdev->discard_buffer_dma,
>> pcdev->base_emma + PRP_DEST_RGB2_PTR);
>>
>> - writel(PRP_CNTL_CH1EN |
>> - PRP_CNTL_CSIEN |
>> - prp->cfg.in_fmt |
>> - prp->cfg.out_fmt |
>> - PRP_CNTL_CH1_LEN |
>> - PRP_CNTL_CH1BYP |
>> - PRP_CNTL_CH1_TSKIP(0) |
>> - PRP_CNTL_IN_TSKIP(0),
>> - pcdev->base_emma + PRP_CNTL);
>> -
>> writel((icd->user_width << 16) | icd->user_height,
>> pcdev->base_emma + PRP_SRC_FRAME_SIZE);
>> writel((icd->user_width << 16) | icd->user_
[PATCH v2] media i.MX27 camera: properly detect frame loss.
As V4L2 specification states, frame_count must also
regard lost frames so that the user can handle that
case properly.
This patch adds a mechanism to increment the frame
counter even when a video buffer is not available
and a discard buffer is used.
---
Changes since v1:
- Initialize "frame_count" to -1 instead of using
"firstirq" variable.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 45 -
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ca76dd2..68038e7 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -369,7 +369,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev->csicr1, pcdev->base_csi + CSICR1);
pcdev->icd = icd;
- pcdev->frame_count = 0;
+ pcdev->frame_count = -1;
dev_info(icd->parent, "Camera driver attached to camera %d\n",
icd->devnum);
@@ -572,6 +572,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
struct soc_camera_host *ici =
to_soc_camera_host(icd->parent);
struct mx2_camera_dev *pcdev = ici->priv;
+ struct mx2_fmt_cfg *prp = pcdev->emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -584,6 +585,26 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
list_add_tail(&vb->queue, &pcdev->capture);
if (mx27_camera_emma(pcdev)) {
+ if (prp->cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp->cfg.in_fmt |
+ prp->cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev->base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp->cfg.in_fmt |
+ prp->cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev->base_emma + PRP_CNTL);
+ }
goto out;
} else { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
@@ -747,16 +768,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev->discard_buffer_dma,
pcdev->base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp->cfg.in_fmt |
- prp->cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev->base_emma + PRP_CNTL);
-
writel((icd->user_width << 16) | icd->user_height,
pcdev->base_emma + PRP_SRC_FRAME_SIZE);
writel((icd->user_width << 16) | icd->user_height,
@@ -784,15 +795,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
pcdev->base_emma + PRP_SOURCE_CR_PTR);
}
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp->cfg.in_fmt |
- prp->cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev->base_emma + PRP_CNTL);
-
writel((icd->user_width << 16) | icd->user_height,
pcdev->base_emma + PRP_SRC_FRAME_SIZE);
@@ -1214,7 +1216,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
vb->state = state;
do_gettimeofday(&vb->ts);
vb->field_count = pcdev->frame_count * 2;
- pcdev->frame_count++;
wake_up(&vb->done);
}
@@ -1239,6 +1240,8 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
return;
}
+ pcdev->frame_count++;
+
buf = list_entry(pcdev->capture.next,
struct mx2_buffer, vb.queue);
-
Re: [PATCH 2/2] uvcvideo: Allow userptr IO mode.
Hi Laurent, FYI Marek has already merged 1/2 into his vb2-fixes branch. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.3] mx2 emma-prp mem2mem driver
Hi Mauro, The following changes since commit 240ab508aa9fb7a294b0ecb563b19ead000b2463: Mauro Carvalho Chehab (1): [media] [PATCH] don't reset the delivery system on DTV_CLEAR are available in the git repository at: git://github.com/jmartinc/video_visstrim.git for_v3.3 Javier Martin (2): MEM2MEM: Add support for eMMa-PrP mem2mem operations. MX2: Add platform definitions for eMMa-PrP device. arch/arm/mach-imx/clock-imx27.c |2 +- arch/arm/mach-imx/devices-imx27.h |2 + arch/arm/plat-mxc/devices/platform-mx2-camera.c | 18 + arch/arm/plat-mxc/include/mach/devices-common.h |2 + drivers/media/video/Kconfig | 10 + drivers/media/video/Makefile|2 + drivers/media/video/mx2_emmaprp.c | 1008 +++ 7 files changed, 1043 insertions(+), 1 deletions(-) create mode 100644 drivers/media/video/mx2_emmaprp.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
coda: i.MX6 decoding performance issues for multi-streaming
Hi, we have an i.MX6 Solo based board running the latest mainline kernel (4.15.3). As part of our development we were measuring the decoding performance of the i.MX6 coda chip. For that purpose we are feeding the decoder with 640x368 @ 30fps H.264 streams that have been generated by another i.MX6 coda encoder configured with fixed qp = 25 and gopsize = 16. For 1-2 streams it works smoothly. However, when adding the 3rd stream the first decoder instance starts to output these kind of errors: DEC_PIC_SUCCESS = 2097153 -> 0x21 DEC_PIC_SUCCESS = 2621441 -> 0x280001 Every time one of these errors appears we can observe a weird artifact in the decoded video (pixelated macroblocks and/or jumps back in time). I tried looking at the original VPU lib implementation by Freescale [1] but they don't seem to handle these errors either. As I don't have access to any kind of Coda IP documentation it's quite hard to me to perform any additional debugging. Has anyone experienced these kind of performance issues too? I'm open to any suggestions and willing to perform extra tests to get to the bottom of this. Regards, Javier. [1] https://github.com/genesi/imx-lib/blob/master/vpu/vpu_lib.c#L2926
Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Sorry everyone about my previous e-mail with all the HTML garbage. Here is the plain text answer instead. Hi Philipp, thanks for your answer. On 13/03/18 12:20, Philipp Zabel wrote: > Hi Javier, > > On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote: >> Hi, >> we have an i.MX6 Solo based board running the latest mainline kernel >> (4.15.3). >> >> As part of our development we were measuring the decoding performance of >> the i.MX6 coda chip. >> >> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264 >> streams that have been generated by another i.MX6 coda encoder >> configured with fixed qp = 25 and gopsize = 16. >> >> For 1-2 streams it works smoothly. However, when adding the 3rd stream >> the first decoder instance starts to output these kind of errors: >> >> DEC_PIC_SUCCESS = 2097153 -> 0x21 >> DEC_PIC_SUCCESS = 2621441 -> 0x280001 > I think these might be (recoverable?) error flags, but so far I have > never seen them myself. > I've had reports of those occurring occasionally with certain streams > (not encoded by coda, regardless of the number of running decoder > instances) though. > > What is the coda firmware version you are using? I'm currently using 3.1.1 both for encoding and decoding. I think I got it from the latest BSP provided by NXP. Now that you mention it the driver is printing these messages at probe time which I had ignored so far: coda 204.vpu: Firmware code revision: 46056 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 3.1.1 coda 204.vpu: codec registered as /dev/video[3-4] Do you think I should use an older version instead? Also, do you think it would be worth trying different parameters in the encoder to see how the decoder responds in those cases? Regards, Javier.
Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Hello,
On 14/03/18 14:57, Philipp Zabel wrote:
On Wed, 2018-03-14 at 13:05 +0100, Javier Martin wrote:
Sorry everyone about my previous e-mail with all the HTML garbage. Here
is the plain text answer instead.
Hi Philipp,
thanks for your answer.
On 13/03/18 12:20, Philipp Zabel wrote:
> Hi Javier,
>
> On Mon, 2018-03-12 at 17:54 +0100, Javier Martin wrote:
>> Hi,
>> we have an i.MX6 Solo based board running the latest mainline kernel
>> (4.15.3).
>>
>> As part of our development we were measuring the decoding
performance of
>> the i.MX6 coda chip.
>>
>> For that purpose we are feeding the decoder with 640x368 @ 30fps H.264
>> streams that have been generated by another i.MX6 coda encoder
>> configured with fixed qp = 25 and gopsize = 16.
Those are the defaults. Is the encoder running on the same system, at
the same time? Or are you decoding a previously encoded stream (multiple
previously encoded streams)?
The encoder is running on a different system with an older 4.1.0 kernel.
Altough the firmware version in the code is 3.1.1 as well.
Do you think I should try updating the system in the encoder to kernel
4.15 too and see if that makes any difference?
[...]
I'm currently using 3.1.1 both for encoding and decoding. I think I got
it from the latest BSP provided by NXP. Now that you mention it the
driver is printing these messages at probe time which I had ignored so far:
coda 204.vpu: Firmware code revision: 46056
coda 204.vpu: Initialized CODA960.
coda 204.vpu: Unsupported firmware version: 3.1.1
coda 204.vpu: codec registered as /dev/video[3-4]
That is strange, commit be7f1ab26f42 ("media: coda: mark CODA960
firmware versions 2.3.10 and 3.1.1 as supported") was merged
in v4.14.
You are right, those messages where taken from an old 4.1 kernel and not
from the latest 4.15 where they don't appear any longer. Sorry for the
noise.
Do you think I should use an older version instead?
Unfortunately I have no indication that this would help.
Also, do you think it would be worth trying different parameters in the
encoder to see how the decoder responds in those cases?
Possibly. It would be interesting to know if this happens more often for
low resolutions / low quality / static frames than high resolutions /
high quality / high movement.
I can easily prepare a test matrix with several resolutions, QPs and
content and let you know the results. Although first I'd like to know
your opinion on whether I should update the encoder to kernel 4.15 too.
Regards,
Javier.
Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Hello Philipp, On 14/03/18 16:11, Philipp Zabel wrote: Hi Javier, On Wed, 2018-03-14 at 15:35 +0100, Javier Martin wrote: [...] The encoder is running on a different system with an older 4.1.0 kernel. Altough the firmware version in the code is 3.1.1 as well. Do you think I should try updating the system in the encoder to kernel 4.15 too and see if that makes any difference? I don't think that should matter. It'd be more interesting if GOP size has a significant influence. Does the Problem also appear in I-frame only streams? OK, I've performed some tests with several resolutions and gop sizes, here is the table with the results: Always playing 3 streams | Resolution | QP | GopSize | Kind of content | Result | | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| * The issues always happens in the first stream, the other 2 streams are fine. * With GopSize = 0 I can even decode 4 720p streams with no artifacts It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. Regards, Javier.
Re: [DE] Re: [CN] Re: [DE] Re: coda: i.MX6 decoding performance issues for multi-streaming
Sorry for resurrecting this thread but I'm still quite interested on making this scenario work: > OK, I've performed some tests with several resolutions and gop sizes, here is the table with the results: > > Always playing 3 streams > > | Resolution | QP | GopSize | Kind of content | Result | > | 640x368 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 640x368 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS| > | 320x192 | 25 |0 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 320x192 | 25 |16 | Waving hands | time shifts, no DEC_PIC_SUCCESS | > | 1280x720 | 25 |16 | Waving hands | macroblock artifacts and lots of DEC_PIC_SUCCESS messages | > | 1280x720 | 25 |0 | Waving hands | Surprisingly smooth, no artifacts, time shifts nor DEC_PIC_SUCCESS| > > * The issues always happens in the first stream, the other 2 streams are fine. > * With GopSize = 0 I can even decode 4 720p streams with no artifacts > > It looks like for small resolutions it suffers from time shifts when multi-streaming, always affecting the first stream for some reason. In this case gop size doesn't seem to make any difference. > > For higher resolutions like 720p using GopSize = 0 seems to improve things a lot. > Philipp, you mentioned some possible issue with context switches in a previous e-mail: > I fear this may be some interaction between coda context switches and > bitstream reader unit state. Philipp, do these results confirm your theory? Are there any more tests I could prepare to help get to the bottom of this or this is something that belongs entirely to the coda firmware domain? Does anyone know if the official BSP from NXP is able to decode 4 flows without issues?
RFC: ov5640 kernel driver.
Hi, we want to a v4l2 driver for the ov5640 sensor from Omnivision. AFAIK, there was an attempt in the past to mainline that driver [1] but it didn't make it in the end. Some people were asking for the code for the ov5640 and the ov5642 to be merged [2] as well but IMHO both sensors are not that similar so that it's worth a common driver. The approach we had in mind so far was creating a new, independent, v4l2-subdev driver for the ov5640 with mbus support. I've found several sources out there with code for the ov5640 but, surprisingly, few attempts to mainline it. I would whether it is just people didn't take the effort or there was something wrong with the code. Has anyone got some comments/advices on this before we start coding? Is anyone already working on this and maybe we can collaborate instead of having two forks of the same driver? Regards, Javier. [1] https://lwn.net/Articles/470643/ [2] http://www.spinics.net/lists/linux-omap/msg69611.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: Add a driver for the ov5640 sensor.
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640 &pinctrl_csi0>;
+ reg = <0x3c>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <&csi0_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
-&ldb {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <&timingr0>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <&timing1>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
-
Re: [PATCH] media: Add a driver for the ov5640 sensor.
Sorry for the unrelated patches,
I will submit this again.
On 30/09/15 09:34, Javier Martin wrote:
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts | 50 -
arch/arm/boot/dts/imx6qdl-var-som.dtsi | 422 ++
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
drivers/media/i2c/ov5642.c | 129 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 30 +-
8 files changed, 1702 insertions(+), 391 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640 &pinctrl_csi0>;
+ reg = <0x3c>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <&csi0_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
index 5431e90..f92f68c 100644
--- a/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
+++ b/arch/arm/boot/dts/imx6dl-var-som-solo-vsc.dts
@@ -23,53 +23,3 @@
};
-&ldb {
- status = "okay";
-
- lvds-channel@0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di0";
- status = "okay";
-
- display-timings {
- native-mode = <&timingr0>;
- timingr0: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
- hfront-porch = <50>;
- vback-porch = <6>;
- vfront-porch = <6>;
- hsync-len = <60>;
- vsync-len = <11>;
- };
- };
- };
-
- lvds-channel@1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <24>;
- crtc = "ipu1-di1";
- primary;
- status = "okay";
-
- display-timings {
- native-mode = <&timing1>;
- timing1: hsd100pxn1 {
- clock-frequency = <7110>;
- hactive = <1280>;
- vactive = <800>;
- hback-porch = <50>;
-
[PATCH v2] media: Add a driver for the ov5640 sensor.
The ov5640 sensor from Omnivision supports up to 2592x1944
and both CSI and MIPI interfaces.
The following driver adds support for the CSI interface only
and VGA, 720p resolutions at 30fps.
Signed-off-by: Javier Martin
---
.../devicetree/bindings/media/i2c/ov5640.txt | 47 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov5640.c | 1403
4 files changed, 1462 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 drivers/media/i2c/ov5640.c
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..2e93e97
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,47 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5640 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1932V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+- compatible: value should be "ovti,ov5640"
+- clocks: reference to the xclk clock
+- clock-names: should be "xclk"
+- clock-rates: the xclk clock frequency
+
+Optional Properties:
+- reset-gpio: Chip reset GPIO
+- pwdn-gpio: Chip power down GPIO
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5640: ov5640@3c {
+ compatible = "ovti,ov5640";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ov5640 &pinctrl_csi0>;
+ reg = <0x3c>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-rates = <2400>;
+
+ reset-gpio = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pwdn-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+
+ port {
+ ov5640_to_csi0: endpoint {
+ remote-endpoint = <&csi0_from_ov5640>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 6f30ea7..8c6689b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -488,6 +488,17 @@ config VIDEO_OV7640
To compile this driver as a module, choose M here: the
module will be called ov7640.
+config VIDEO_OV5640
+ tristate "OmniVision OV5640 sensor support"
+ depends on I2C && VIDEO_V4L2
+ depends on MEDIA_CAMERA_SUPPORT
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV5640 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5640.
+
config VIDEO_OV7670
tristate "OmniVision OV7670 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 34e7da2..65b224f 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
new file mode 100644
index 000..e06b812
--- /dev/null
+++ b/drivers/media/i2c/ov5640.c
@@ -0,0 +1,1403 @@
+/*
+ * Driver for the OV5640 sensor from Omnivision CSI interface only.
+ *
+ * Copyright (C) 2015 By Tech Design S.L. All Rights Reserved.
+ * Copyright (C) 2012-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Based on the MT9P031 driver and an out of tree ov5640 driver by Freescale:
+ * https://github.com/varigit/linux-2.6-imx/blob/imx_3.14.38_6qp_beta-var02/
+ * drivers/media/platform/mxc/capture/ov5640.c
+ *
+ */
+
+/*
+ * 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
+ * (at your option) any later version.
+
+ * This pro
i.MX6 video capture support in mainline
Hello, we have an BD-SL-i.MX6 platform (compatible with the Nitrogen6X) where we are currently running the BSP from Freescale, which is based on kernel 3.10 if I recall properly. We are aware that those drivers have some issues, specially when it comes to compliance with the V4L2 frameworks like the media controller API, stability, etc... Furthermore, we need to use the mainline kernel because some of the drivers that we need to use are not available in the Freescale kernel. The biggest problem that we have found so far for switching to the mainline kernel is the video capture support in the I.MX6 IPU. I've been following some old e-mail threads (from 2014) and I eventually found Philipp Zabel's repository branch 'nitrogen6x-ipu-media' which has what seems to be an early version of an i.MX6 IPU capture driver via the CSI interface. We've got here the same setup with an ov5642 sensor connected to the CSI interface and we have been giving a try to the driver. This is what we have tried so far: cat /dev/video0 # This is needed so that open gets called and the csi links are created media-ctl -l '"ov5642 1-003c":0->"mipi_ipu1_mux":1[1], "/soc/ipu@0240/port@0":1->"IPU0 SMFC0":0[1]' media-ctl -l '"IPU0 SMFC0":1->"imx-ipuv3-camera.2":0[1]' The last command will fail like this: imx-ipuv3 240.ipu: invalid link 'IPU0 SMFC0'(5):1 -> 'imx-ipuv3-camera.2'(2):0 Unable to parse link: Invalid argument (22) The reason it fails, apparently, is that the links that have been created when opening /dev/video0 are not included in the "ipu_links[]" static table defined in "drivers/gpio/ipu-v3/ipu-media.c" which is where the "ipu_smfc_link_setup()" function tries to find a valid link. I've got some questions regarding this driver and iMX6 video capture support in general that someone here may gladly answer: a) Is anyone currently working on mainlining iMX6 video capture support? I know about Steve's and Philipp's work but I haven't seen any progress since September 2014. b) Does anyone know whether it's possible to capture YUV420P video using the driver in Philipp's repository? If so could you please provide the pipeline setup that you used with media-ctl? c) If we were willing to help with mainline submission of this driver what issues should we focus on? Regards, Javier. [1] git://git.pengutronix.de/git/pza/linux.git -- 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
coda: Problems with encoding in i.MX6DL.
Hello, I am running kernel 4.1 in a var-dvk-solo-linux evaluation board from Variscite. This is what I get at system start-up: coda 204.vpu: Firmware code revision: 34588 coda 204.vpu: Initialized CODA960. coda 204.vpu: Unsupported firmware version: 2.1.8 coda 204.vpu: codec registered as /dev/video[0-1] Apparently, the firmware is being loaded properly although it complains about that version not being supported. After queuing some YUV420 buffers with a simple application I perform a VIDIOC_STREAMON in both the CAPTURE and the OUTPUT interfaces but I get the following error: coda 204.vpu: coda is not initialized. [ cut here ] WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792 vb2_start_streaming+0xe0/0x15c() Modules linked in: CPU: 0 PID: 91 Comm: wmip_bsp_tests Tainted: GW 4.1.0-4-g192a113-dirty #96 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r6:c0815888 r5: r4:c08d3764 r3: [] (show_stack) from [] (dump_stack+0x8c/0x9c) [] (dump_stack) from [] (warn_slowpath_common+0x88/0xb8) r5:0700 r4: [] (warn_slowpath_common) from [] (warn_slowpath_null+0x24/0x2c) r8:edc35000 r7: r6:ee1ee408 r5:ee1ee4d8 r4:fff2 [] (warn_slowpath_null) from [] (vb2_start_streaming+0xe0/0x15c) [] (vb2_start_streaming) from [] (vb2_internal_streamon+0x118/0x164) r7: r6:edc1614c r5:ee1ee400 r4:ee1ee408 [] (vb2_internal_streamon) from [] (vb2_streamon+0x38/0x58) r5:ee1ee400 r4:0001 [] (vb2_streamon) from [] (v4l2_m2m_streamon+0x38/0x54) [] (v4l2_m2m_streamon) from [] (v4l2_m2m_ioctl_streamon+0x18/0x1c) r5:ee82f068 r4:40045612 [] (v4l2_m2m_ioctl_streamon) from [] (v4l_streamon+0x20/0x24) [] (v4l_streamon) from [] (__video_do_ioctl+0x264/0x2cc) [] (__video_do_ioctl) from [] (video_usercopy+0x190/0x48c) r10:ee1ebe20 r9:0001 r8:be916b74 r7: r6: r5:c04775ac r4:40045612 [] (video_usercopy) from [] (video_ioctl2+0x18/0x1c) r10:eea7dd88 r9:be916b74 r8:ee82fcf0 r7:40045612 r6:be916b74 r5:edc35000 r4:ee82f068 [] (video_ioctl2) from [] (v4l2_ioctl+0xac/0xc8) [] (v4l2_ioctl) from [] (do_vfs_ioctl+0x430/0x624) r8:0003 r7:be916b74 r6:0003 r5:edc35000 r4:edc35000 r3:c04739a0 [] (do_vfs_ioctl) from [] (SyS_ioctl+0x3c/0x64) r10: r9:ee1ea000 r8:0003 r7:be916b74 r6:40045612 r5:edc35000 r4:edc35000 [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x3c) r8:c000f8c4 r7:0036 r6:8aa8 r5: r4: r3:be916b74 ---[ end trace 2b0ba71bfb12fec4 ]--- As anyone seen the same issue? Could be related to the "Unsupported firmware version" complaint? Do you know where to get the 2.1.5 firmware for the i.MX6D? Regards, Javier. -- 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: coda: Problems with encoding in i.MX6DL.
Hi Philipp,
thanks for your fast answer.
Apparently, the firmware is being loaded properly although it complains
about that version not being supported.
After queuing some YUV420 buffers with a simple application I perform a
VIDIOC_STREAMON in both the CAPTURE and the OUTPUT interfaces but I get
the following error:
coda 204.vpu: coda is not initialized.
... but then suddenly it's not.
(coda_is_initialized just checks whether PC != 0)
Could this have something to do with the PU power domain? Do all coda
registers read 0x0 ?
Do you have CONFIG_PM disabled? Check if d438462c20a3 ("ARM: imx6: gpc:
always enable PU domain if CONFIG_PM is not set") makes a difference.
I think that patch hasn't made it into stable yet.
Indeed, I was having problems with the runtime PM from the beginning and
hacked up the code in the gpmc a bit to make sure the coda was always
enabled but somehow I forgot to comment the poweroff callback and the
codas was being powered off and never turned on again.
Just in case it is useful for someone else these are the functions in
arch/arm/mach-imx/gpc.c whose code I completely commented out:
_imx6q_pm_pu_power_off
imx6q_pm_pu_power_off
Anyway, it looks like power management for the coda is a bit broken in
the i.MX6D. I'll leave it disabled for now so that I continue with my
development but I plan to have a look at it later on to see if I can fix
it properly.
[ cut here ]
WARNING: CPU: 0 PID: 91 at drivers/media/v4l2-core/videobuf2-core.c:1792
vb2_start_streaming+0xe0/0x15c()
That is because after copying buffers to the bitstream, the driver
currently marks them as done. When start_streaming fails, videobuf2
expects drivers to re-queue them. So we'd have to flush the bitstream
and re-queue the buffers so they can be copied to the bitstream all over
during the next try.
This warning is a result of incomplete error handling in the coda
start_streaming implementation.
I see, I might look into this if I manage to get some spare time.
Regards,
Javier.
--
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
imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
Hi, I am using mainline kernel 4.1 and I was writing a small application that uses double buffering to read YUV420 frames from a file at 30fps and displays them using the overlay plane in the imx-drm driver. The first issue I noticed is that the image was green so I had to apply the following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- 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: imx-drm: Color issues scanning out YUV420 frames through the overlay plane.
Sorry for sending this to the wrong list. On 07/08/15 09:25, Javier Martin wrote: Hi, I am using mainline kernel 4.1 and I was writing a small application that uses double buffering to read YUV420 frames from a file at 30fps and displays them using the overlay plane in the imx-drm driver. The first issue I noticed is that the image was green so I had to apply the following patches to make the U and V components be scanned out properly: http://lists.freedesktop.org/archives/dri-devel/2014-October/071052.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071025.html http://lists.freedesktop.org/archives/dri-devel/2014-October/071048.html The thing is that, even after applying the 3 patches above, colors are a bit strange. They seem about right but there are some artifacts, like a saturation effect that spoils the image. You can see some snapshots here to see what I am talking about: https://imageshack.com/i/f0nAM5Xbj https://imageshack.com/i/hl7bZMNjj https://imageshack.com/i/eyRjURxRj And the original video is the first one in this page: http://media.xiph.org/video/derf/ On the other hand, colors in the primary plane using the fbdev interface and RGB look correct. Has anyone seen something similar or is YUV420 working fine for you? Regards, Javier. -- 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
Question regarding soc-camera v4l subdev status.
Hi, I know that soc-camera has been recently added support for v4l subdev. But, this does mean that now old encoder and sensor drivers like: http://lxr.linux.no/#linux+v2.6.33/drivers/media/video/tvp5150.c http://lxr.linux.no/#linux+v2.6.33/drivers/media/video/ov7670.c are now compatible with host camera drivers? Or, on the other hand, is the subdev support partially implemented right now? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
