This driver wasn't converted to the new clock framework
(e038ed50a4a767add205094c035b6943e7b30140).
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 47 +-
1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/
k 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.
n benefit.
Sure, though I will need some help because it seems some related
frameworks are not ready for what we want to achieve.
--
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
--
accepts YUV420 as input.
Signed-off-by: Javier Martin
---
arch/arm/mach-imx/devices-imx27.h |2 +
arch/arm/plat-mxc/devices/platform-mx2-camera.c | 33 +
arch/arm/plat-mxc/include/mach/devices-common.h |2 +
drivers/media/video/Kconfig | 11 +
drivers
'working' state?
--
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
On 4 November 2011 11:41, Laurent Pinchart
wrote:
> Hi Javier,
>
> On Wednesday 02 November 2011 17:33:16 javier Martin wrote:
>> On 2 November 2011 17:12, Devin Heitmueller wrote:
>> > I've actually got a very similar issue and have been looking into it
>> &g
);
> extern int uvc_query_ctrl(struct uvc_device *dev, __u8 query, __u8 unit,
> __u8 intfnum, __u8 cs, void *data, __u16 size);
> +void uvc_video_clock_update(struct uvc_streaming *stream,
> + struct v4l2_buffer *v4l2_buf,
> +
s I'll have to prepare a second version with all the fixes
you've pointed out which seem quite reasonable to me.
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
i.MX2x SoCs have a PrP which is capable of resizing and format
conversion of video frames. This driver provides support for
resizing and format conversion from YUYV to YUV420.
This operation is of the utmost importance since some of these
SoCs like i.MX27 include an H.264 video codec which only
a
eMMa-PrP device included in Freescale i.MX2 chips can also
be used separately to process memory buffers.
Signed-off-by: Javier Martin
---
arch/arm/mach-imx/devices-imx27.h |2 +
arch/arm/plat-mxc/devices/platform-mx2-camera.c | 33 +++
arch/arm/plat-mxc
Changes since v1:
- Embed queue data in ctx structure to allow multi instance.
- Remove redundant job_ready callback.
- Adjust format against device capabilities.
- Register/unregister video device at the right time.
- Other minor coding fixes.
Signed-off-by: Javier Martin
---
drivers/media
gt;> + if (!pdev)
>> + goto err;
>> +
>> + ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
>> + if (ret)
>> + goto err;
>> +
>> + return pdev;
>> +err:
>> + platform_device_put(pd
Hi Sascha and Sylwester,
you comments are very appreciated.
I will send an v3 version solving all the issues you mentioned.
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
Hi Sascha,
On 22 November 2011 22:06, Sascha Hauer wrote:
> On Tue, Nov 22, 2011 at 01:01:55PM +0100, Javier Martin wrote:
>> eMMa-PrP device included in Freescale i.MX2 chips can also
>> be used separately to process memory buffers.
>>
>> Signed-off-by: Javier Marti
_REGISTER_CLOCK("imx27-fec.0", NULL, fec_clk)
_REGISTER_CLOCK(NULL, "emi", emi_clk)
If I do that, mx2_camera.c will stop working.
Furthermore it does not work for this driver either (I get an error on
clk_get() ).
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
i.MX2x SoCs have a PrP which is capable of resizing and format
conversion of video frames. This driver provides support for
resizing and format conversion from YUYV to YUV420.
This operation is of the utmost importance since some of these
SoCs like i.MX27 include an H.264 video codec which only
ac
eMMa-PrP device included in Freescale i.MX2 chips can also
be used separately to process memory buffers.
Changes since v2:
- Define imx_add_mx2_emmaprp function which also registers device,
not only alloc.
- Change definition of emma_clk.
- Minor fixes.
Signed-off-by: Javier Martin
---
arch
Changes since v2:
- Use devres to simplify error handling.
- Remove unused structures.
- Fix clock handling.
- Other minor problems.
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Javier Martin
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers
Hi Fabio,
On 23 November 2011 16:19, Fabio Estevam wrote:
> Javier,
>
> On Wed, Nov 23, 2011 at 1:13 PM, Javier Martin
> wrote:
>> Changes since v2:
>> - Use devres to simplify error handling.
>> - Remove unused structures.
>> - Fix clock handling.
>&g
Changes since v3:
Patch order inverted as requested by Mauro.
Now adjusting of the image dimensions is made using v4l_bound_align_image().
Some coding style fixes.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
Mo
eMMa-PrP device included in Freescale i.MX2 chips can also
be used separately to process memory buffers. This patch
provides arch glue code for the driver which provides this
functionality.
Acked-by: Sascha Hauer
Signed-off-by: Javier Martin
---
arch/arm/mach-imx/clock-imx27.c
accepts YUV420 as input.
Reviewed-by: Sylwester Nawrocki
Signed-off-by: Javier Martin
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers/media/video/mx2_emmaprp.c | 1008 +
3 files changed, 1020 insertions(+), 0
This patch uses channel 2 of the eMMa-PrP to convert
format provided by the sensor to YUV420.
This format is very useful since it is used by the
internal H.264 encoder.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 291 +++---
1 files
In page 23 of the datasheet of this chip (SLES098A)
it is stated that de default input for this chip
is Composite AIP1A which is the same as COMPOSITE0
in the driver.
Signed-off-by: Javier Martin
---
drivers/media/video/tvp5150.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
These callbacks allow a host video driver
to poll video supported video formats of tvp5150.
Signed-off-by: Javier Martin
---
drivers/media/video/tvp5150.c | 72 +
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video
Hi Mauro,
thank you for your review, I will prepare a new version with those fixes.
--
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
owever, 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- Santan
> 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
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 subjec
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
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-si
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
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
>> -
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.
>
> Sur
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-c
orted).
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
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 inpu
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).
>&g
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,
>>
n 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
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,
>&g
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
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 unsubscr
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
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
> i
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
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 u
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, Javie
tx = &context_a;
+
ret = mt9m111_s_power(&mt9m111->subdev, 1);
if (ret < 0)
return ret;
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-silico
oc_camera_device *icd,
>> writel(prp->cfg.ch1_pixel,
>> pcdev->base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
>> } else { /* channel 2 */
>> + writel((pcdev->s_width << 16) | pcdev->s_height,
>> +
struct i2c_client *client = v4l2_get_subdevdata(&mt9m111->subdev);
>
> - if (on)
> + if (val == V4L2_EXPOSURE_AUTO)
> return reg_set(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
> return reg_clear(OPER_MODE_CTRL, MT9M111_OPMODE_AUTOEXPO_EN);
> }
>
Hi Benoît,
thank you for your answer.
On 7 March 2013 13:13, Benoît Thébaudeau wrote:
> Dear Javier Martin,
>
> On Thursday, March 7, 2013 10:43:42 AM, Javier Martin wrote:
>> Hi,
>> I am testing mt9m131 sensor (which is supported in mt9m111.c) in
>> mainline kern
1C12STCH%20ES/557-1251-ND/1643271)
but, unfortunately, I don't have one of these available. It could be
very useful to test the sensor with this board with the configuration
Aptina recommends and see whether the "grey layer effect" still
persists.
I will try to contact Aptina'
atic int __init omap2_iommu_init(void)
{
printk("%s\n", __func__);
return omap_install_iommu_arch(&omap2_iommu_ops);
}
module_init(omap2_iommu_init);
Does anyone know what could be the reason?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina
lour-quality judgement to the reader(s) :-)
Thank you for your feedback. It seems that we all have a similar colour quality.
If Aptina comes up with better settings or I find them I'll post a
patch for you to test.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Av
gone.
However, according to the previous thread, omap3isp register should
return error but an oops should not be generated. So I think there is
a bug here anyway.
--
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
Hi Laurent,
thank you for your answer.
On 11 March 2013 16:01, Laurent Pinchart
wrote:
> Hi Javier,
>
> On Monday 11 March 2013 13:18:12 javier Martin wrote:
>> I've just found the following thread where te problem is explained:
>> http://lists.infradead.org/piper
e information about the current
> status.
So what kind of changes are required to make this work? Are we talking
about migrating each soc-camera sensor separately, soc-camera
framework changes, both of them?
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros
Hi Guernnadi, Christoph,
On 12 March 2013 09:25, Christoph Fritz wrote:
> On Tue, 2013-03-12 at 08:58 +0100, Guennadi Liakhovetski wrote:
>> On Thu, 7 Mar 2013, javier Martin wrote:
>
>> > What mbus format are you using? Could you please check if the s_width
>> >
On 12 March 2013 10:39, Guennadi Liakhovetski wrote:
> On Tue, 12 Mar 2013, javier Martin wrote:
>
>> Hi Guernnadi, Christoph,
>>
>> On 12 March 2013 09:25, Christoph Fritz wrote:
>> > On Tue, 2013-03-12 at 08:58 +0100, Guennadi Liakhovetski wrote:
>> >
5);
+v4l2_ctrl_new_std(&mt9m111->hdl, &mt9m111_ctrl_ops, V4L2_CID_EXPOSURE,
+ 1, 0x, 1, 0x219);
v4l2_ctrl_new_std(&mt9m111->hdl, &mt9m111_ctrl_ops,
V4L2_CID_VFLIP, 0, 1, 1, 0);
v4l2_ctrl_new_std(&mt9m111-
401 - 461 of 461 matches
Mail list logo
