subject:"Re\: \[PATCH v1 0\/6\] Add support of OV9655 camera"

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-08 Thread Sakari Ailus

Hi Nikolaus,

On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote:
> Hi Sakari,
> 
> > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller :
> > 
> > Hi Hugues,
> > 
> >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
> >> 
> >> Hi Nikolaus,
> >> 
> >> nothing really strange in trace, I wanted to check the latest S_FMT and 
> >> it is well 1280x1024 YUV:
>  [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
> >> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> >> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> >> xfer_func=0
> >> 
> > 
> > Thanks for cross-checking.
> > 
> >> You're right that it seems that the ISP is not seeing any data in input.
> >> Have you double checked the polarities of sync signals ? I see 
> >> differences in devicetree:
> >> 960 ov9655: endpoint {
> >> 961 remote-endpoint = <_ep>;
> >> 962 #if 0   // not used by camera driver - define _ep for isp
> >> 963 bus-width = <8>;
> >> 964 data-shift = <2>;   /* Lines 
> >> 9:2 are used */
> >> 965 hsync-active = <1>; /* Active 
> >> high */
> >> 966 vsync-active = <1>; /* Active 
> >> high */
> >> 967 data-active = <1>;  /* Active 
> >> high */
> >> 968 pclk-sample = <1>;  /* Rising */
> >> 969 #endif
> >> 
> >> Which has been commented out in flavour of:
> >> 
> >> 1011 /* parallel camera interface */
> >> 1012 _ep {
> >> 1013 remote-endpoint = <>;
> >> 1014 ti,isp-clock-divisor = <1>;
> >> 1015 ti,strobe-mode;
> >> 1016 bus-width = <8>;/* Used data lines */
> >> 1017 data-shift = <2>; /* Lines 9:2 are used */
> >> 1018 hsync-active = <0>; /* Active low */
> >> 1019 vsync-active = <1>; /* Active high */
> >> 1020 data-active = <1>;/* Active high */
> >> 1021 pclk-sample = <1>;/* Rising */
> >> 1022 };
> >> 
> >> there is a difference regarding active level of hsync.
> > 
> > Yes, this is from experimenting with our driver patch series to
> > do the setup in the camera driver. Both chips can configure polarities
> > but we now have only system defaults in the camera driver. Therefore,
> > it is commented out for the camera DT node.
> > 
> > The problem is that we never had all this working in DT mode so
> > our setup here might indeed be buggy.
> > 
> > On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> > does match the signals seen by oscilloscope.
> > 
> > I will try asap if this makes a difference. There are only 4 combinations...
> > 
> > My expectation is that wrong polarity would only move the
> > active trigger point around so that I would expect an image
> > shifted left/right or up/down.
> > 
> > But I don't know enough details of the isp. If it is triggering
> > sync not by edge but by state and stopping capture for the wrong
> > state of the sync signal it might not receive enough lines or pixels
> > as it was initialized for and therefore it may simply wait for
> > more data instead of reporting "done with 1280x1024 pixels".
> > 
> >> 
> >> Nevertheless seems OK if I check OMAP3 ISP register:
> >> CCDC SYN_MODE=0x00071704
> >> #define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
> >> #define ISPCCDC_SYN_MODE_HDPOL (1 << 3)
> >> 
> >> seems well that vertical is 1 and horizontal is 0.
> >> 
> 
> I found your old e-mail with a similar issue (CCDC stop timeout):
> 
> https://www.spinics.net/lists/linux-media/msg60096.html
> 
> It looks as if our media-ctl commands are almost the same as in
> the example given by Adriano and it confirms that /dev/video2
> is the right channel.
> 
> In your answer you recommended to check /proc/interrupts which
> did help Adriano.
> 
> Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
> interrupts per second. This means VSYNC seems to arrive at ~15 fps.
> 
> But we still have the timeouts and no image in mplayer.
> 
> Can we easily check if HSYNC is also arriving at the CCDC or has
> wrong polarity?

What you can try to switch the polarity in CCDC configuration. The CCDC
processes a pre-determined number of lines and if the hsync polarity
configuration is wrong, it will likely end up missing one. This should be
especially easy to misconfigure with serial busses but this isn't the
problem here as you have a parallel bus. You could try switching the vsync
polarity, too.

There are probably better informed people around, I've never used the
parallel interface (except with the CCP2 / CSI-2 receivers).

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-08 Thread Sakari Ailus

Hi Nikolaus,

On Wed, Jul 05, 2017 at 04:02:04PM +0200, H. Nikolaus Schaller wrote:
> Hi Sakari,
> 
> > Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller :
> > 
> > Hi Hugues,
> > 
> >> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
> >> 
> >> Hi Nikolaus,
> >> 
> >> nothing really strange in trace, I wanted to check the latest S_FMT and 
> >> it is well 1280x1024 YUV:
>  [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
> >> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> >> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> >> xfer_func=0
> >> 
> > 
> > Thanks for cross-checking.
> > 
> >> You're right that it seems that the ISP is not seeing any data in input.
> >> Have you double checked the polarities of sync signals ? I see 
> >> differences in devicetree:
> >> 960 ov9655: endpoint {
> >> 961 remote-endpoint = <_ep>;
> >> 962 #if 0   // not used by camera driver - define _ep for isp
> >> 963 bus-width = <8>;
> >> 964 data-shift = <2>;   /* Lines 
> >> 9:2 are used */
> >> 965 hsync-active = <1>; /* Active 
> >> high */
> >> 966 vsync-active = <1>; /* Active 
> >> high */
> >> 967 data-active = <1>;  /* Active 
> >> high */
> >> 968 pclk-sample = <1>;  /* Rising */
> >> 969 #endif
> >> 
> >> Which has been commented out in flavour of:
> >> 
> >> 1011 /* parallel camera interface */
> >> 1012 _ep {
> >> 1013 remote-endpoint = <>;
> >> 1014 ti,isp-clock-divisor = <1>;
> >> 1015 ti,strobe-mode;
> >> 1016 bus-width = <8>;/* Used data lines */
> >> 1017 data-shift = <2>; /* Lines 9:2 are used */
> >> 1018 hsync-active = <0>; /* Active low */
> >> 1019 vsync-active = <1>; /* Active high */
> >> 1020 data-active = <1>;/* Active high */
> >> 1021 pclk-sample = <1>;/* Rising */
> >> 1022 };
> >> 
> >> there is a difference regarding active level of hsync.
> > 
> > Yes, this is from experimenting with our driver patch series to
> > do the setup in the camera driver. Both chips can configure polarities
> > but we now have only system defaults in the camera driver. Therefore,
> > it is commented out for the camera DT node.
> > 
> > The problem is that we never had all this working in DT mode so
> > our setup here might indeed be buggy.
> > 
> > On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> > does match the signals seen by oscilloscope.
> > 
> > I will try asap if this makes a difference. There are only 4 combinations...
> > 
> > My expectation is that wrong polarity would only move the
> > active trigger point around so that I would expect an image
> > shifted left/right or up/down.
> > 
> > But I don't know enough details of the isp. If it is triggering
> > sync not by edge but by state and stopping capture for the wrong
> > state of the sync signal it might not receive enough lines or pixels
> > as it was initialized for and therefore it may simply wait for
> > more data instead of reporting "done with 1280x1024 pixels".
> > 
> >> 
> >> Nevertheless seems OK if I check OMAP3 ISP register:
> >> CCDC SYN_MODE=0x00071704
> >> #define ISPCCDC_SYN_MODE_VDPOL (1 << 2)
> >> #define ISPCCDC_SYN_MODE_HDPOL (1 << 3)
> >> 
> >> seems well that vertical is 1 and horizontal is 0.
> >> 
> 
> I found your old e-mail with a similar issue (CCDC stop timeout):
> 
> https://www.spinics.net/lists/linux-media/msg60096.html
> 
> It looks as if our media-ctl commands are almost the same as in
> the example given by Adriano and it confirms that /dev/video2
> is the right channel.
> 
> In your answer you recommended to check /proc/interrupts which
> did help Adriano.
> 
> Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
> interrupts per second. This means VSYNC seems to arrive at ~15 fps.
> 
> But we still have the timeouts and no image in mplayer.
> 
> Can we easily check if HSYNC is also arriving at the CCDC or has
> wrong polarity?

What you can try to switch the polarity in CCDC configuration. The CCDC
processes a pre-determined number of lines and if the hsync polarity
configuration is wrong, it will likely end up missing one. This should be
especially easy to misconfigure with serial busses but this isn't the
problem here as you have a parallel bus. You could try switching the vsync
polarity, too.

There are probably better informed people around, I've never used the
parallel interface (except with the CCP2 / CSI-2 receivers).

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-05 Thread H. Nikolaus Schaller

Hi Sakari,

> Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller :
> 
> Hi Hugues,
> 
>> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
>> 
>> Hi Nikolaus,
>> 
>> nothing really strange in trace, I wanted to check the latest S_FMT and 
>> it is well 1280x1024 YUV:
 [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
>> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
>> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
>> xfer_func=0
>> 
> 
> Thanks for cross-checking.
> 
>> You're right that it seems that the ISP is not seeing any data in input.
>> Have you double checked the polarities of sync signals ? I see 
>> differences in devicetree:
>> 960 ov9655: endpoint {
>> 961 remote-endpoint = <_ep>;
>> 962 #if 0   // not used by camera driver - define _ep for isp
>> 963 bus-width = <8>;
>> 964 data-shift = <2>;   /* Lines 
>> 9:2 are used */
>> 965 hsync-active = <1>; /* Active 
>> high */
>> 966 vsync-active = <1>; /* Active 
>> high */
>> 967 data-active = <1>;  /* Active 
>> high */
>> 968 pclk-sample = <1>;  /* Rising */
>> 969 #endif
>> 
>> Which has been commented out in flavour of:
>> 
>> 1011 /* parallel camera interface */
>> 1012 _ep {
>> 1013 remote-endpoint = <>;
>> 1014 ti,isp-clock-divisor = <1>;
>> 1015 ti,strobe-mode;
>> 1016 bus-width = <8>;/* Used data lines */
>> 1017 data-shift = <2>; /* Lines 9:2 are used */
>> 1018 hsync-active = <0>; /* Active low */
>> 1019 vsync-active = <1>; /* Active high */
>> 1020 data-active = <1>;/* Active high */
>> 1021 pclk-sample = <1>;/* Rising */
>> 1022 };
>> 
>> there is a difference regarding active level of hsync.
> 
> Yes, this is from experimenting with our driver patch series to
> do the setup in the camera driver. Both chips can configure polarities
> but we now have only system defaults in the camera driver. Therefore,
> it is commented out for the camera DT node.
> 
> The problem is that we never had all this working in DT mode so
> our setup here might indeed be buggy.
> 
> On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> does match the signals seen by oscilloscope.
> 
> I will try asap if this makes a difference. There are only 4 combinations...
> 
> My expectation is that wrong polarity would only move the
> active trigger point around so that I would expect an image
> shifted left/right or up/down.
> 
> But I don't know enough details of the isp. If it is triggering
> sync not by edge but by state and stopping capture for the wrong
> state of the sync signal it might not receive enough lines or pixels
> as it was initialized for and therefore it may simply wait for
> more data instead of reporting "done with 1280x1024 pixels".
> 
>> 
>> Nevertheless seems OK if I check OMAP3 ISP register:
>> CCDC SYN_MODE=0x00071704
>> #define ISPCCDC_SYN_MODE_VDPOL   (1 << 2)
>> #define ISPCCDC_SYN_MODE_HDPOL   (1 << 3)
>> 
>> seems well that vertical is 1 and horizontal is 0.
>> 

I found your old e-mail with a similar issue (CCDC stop timeout):

https://www.spinics.net/lists/linux-media/msg60096.html

It looks as if our media-ctl commands are almost the same as in
the example given by Adriano and it confirms that /dev/video2
is the right channel.

In your answer you recommended to check /proc/interrupts which
did help Adriano.

Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
interrupts per second. This means VSYNC seems to arrive at ~15 fps.

But we still have the timeouts and no image in mplayer.

Can we easily check if HSYNC is also arriving at the CCDC or has
wrong polarity?

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-05 Thread H. Nikolaus Schaller

Hi Sakari,

> Am 03.07.2017 um 14:23 schrieb H. Nikolaus Schaller :
> 
> Hi Hugues,
> 
>> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
>> 
>> Hi Nikolaus,
>> 
>> nothing really strange in trace, I wanted to check the latest S_FMT and 
>> it is well 1280x1024 YUV:
 [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
>> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
>> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
>> xfer_func=0
>> 
> 
> Thanks for cross-checking.
> 
>> You're right that it seems that the ISP is not seeing any data in input.
>> Have you double checked the polarities of sync signals ? I see 
>> differences in devicetree:
>> 960 ov9655: endpoint {
>> 961 remote-endpoint = <_ep>;
>> 962 #if 0   // not used by camera driver - define _ep for isp
>> 963 bus-width = <8>;
>> 964 data-shift = <2>;   /* Lines 
>> 9:2 are used */
>> 965 hsync-active = <1>; /* Active 
>> high */
>> 966 vsync-active = <1>; /* Active 
>> high */
>> 967 data-active = <1>;  /* Active 
>> high */
>> 968 pclk-sample = <1>;  /* Rising */
>> 969 #endif
>> 
>> Which has been commented out in flavour of:
>> 
>> 1011 /* parallel camera interface */
>> 1012 _ep {
>> 1013 remote-endpoint = <>;
>> 1014 ti,isp-clock-divisor = <1>;
>> 1015 ti,strobe-mode;
>> 1016 bus-width = <8>;/* Used data lines */
>> 1017 data-shift = <2>; /* Lines 9:2 are used */
>> 1018 hsync-active = <0>; /* Active low */
>> 1019 vsync-active = <1>; /* Active high */
>> 1020 data-active = <1>;/* Active high */
>> 1021 pclk-sample = <1>;/* Rising */
>> 1022 };
>> 
>> there is a difference regarding active level of hsync.
> 
> Yes, this is from experimenting with our driver patch series to
> do the setup in the camera driver. Both chips can configure polarities
> but we now have only system defaults in the camera driver. Therefore,
> it is commented out for the camera DT node.
> 
> The problem is that we never had all this working in DT mode so
> our setup here might indeed be buggy.
> 
> On the other hand the polarity (HSYNC act. low and VSYNC act. high)
> does match the signals seen by oscilloscope.
> 
> I will try asap if this makes a difference. There are only 4 combinations...
> 
> My expectation is that wrong polarity would only move the
> active trigger point around so that I would expect an image
> shifted left/right or up/down.
> 
> But I don't know enough details of the isp. If it is triggering
> sync not by edge but by state and stopping capture for the wrong
> state of the sync signal it might not receive enough lines or pixels
> as it was initialized for and therefore it may simply wait for
> more data instead of reporting "done with 1280x1024 pixels".
> 
>> 
>> Nevertheless seems OK if I check OMAP3 ISP register:
>> CCDC SYN_MODE=0x00071704
>> #define ISPCCDC_SYN_MODE_VDPOL   (1 << 2)
>> #define ISPCCDC_SYN_MODE_HDPOL   (1 << 3)
>> 
>> seems well that vertical is 1 and horizontal is 0.
>> 

I found your old e-mail with a similar issue (CCDC stop timeout):

https://www.spinics.net/lists/linux-media/msg60096.html

It looks as if our media-ctl commands are almost the same as in
the example given by Adriano and it confirms that /dev/video2
is the right channel.

In your answer you recommended to check /proc/interrupts which
did help Adriano.

Yes, we see the "OMAP3 ISP" entry go up roughly with 15-20
interrupts per second. This means VSYNC seems to arrive at ~15 fps.

But we still have the timeouts and no image in mplayer.

Can we easily check if HSYNC is also arriving at the CCDC or has
wrong polarity?

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
> 
> Hi Nikolaus,
> 
> nothing really strange in trace, I wanted to check the latest S_FMT and 
> it is well 1280x1024 YUV:
>>> [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> xfer_func=0
> 

Thanks for cross-checking.

> You're right that it seems that the ISP is not seeing any data in input.
> Have you double checked the polarities of sync signals ? I see 
> differences in devicetree:
>  960 ov9655: endpoint {
>  961 remote-endpoint = <_ep>;
>  962 #if 0   // not used by camera driver - define _ep for isp
>  963 bus-width = <8>;
>  964 data-shift = <2>;   /* Lines 
> 9:2 are used */
>  965 hsync-active = <1>; /* Active 
> high */
>  966 vsync-active = <1>; /* Active 
> high */
>  967 data-active = <1>;  /* Active 
> high */
>  968 pclk-sample = <1>;  /* Rising */
>  969 #endif
> 
> Which has been commented out in flavour of:
> 
> 1011 /* parallel camera interface */
> 1012 _ep {
> 1013 remote-endpoint = <>;
> 1014 ti,isp-clock-divisor = <1>;
> 1015 ti,strobe-mode;
> 1016 bus-width = <8>;/* Used data lines */
> 1017 data-shift = <2>; /* Lines 9:2 are used */
> 1018 hsync-active = <0>; /* Active low */
> 1019 vsync-active = <1>; /* Active high */
> 1020 data-active = <1>;/* Active high */
> 1021 pclk-sample = <1>;/* Rising */
> 1022 };
> 
> there is a difference regarding active level of hsync.

Yes, this is from experimenting with our driver patch series to
do the setup in the camera driver. Both chips can configure polarities
but we now have only system defaults in the camera driver. Therefore,
it is commented out for the camera DT node.

The problem is that we never had all this working in DT mode so
our setup here might indeed be buggy.

On the other hand the polarity (HSYNC act. low and VSYNC act. high)
does match the signals seen by oscilloscope.

I will try asap if this makes a difference. There are only 4 combinations...

My expectation is that wrong polarity would only move the
active trigger point around so that I would expect an image
shifted left/right or up/down.

But I don't know enough details of the isp. If it is triggering
sync not by edge but by state and stopping capture for the wrong
state of the sync signal it might not receive enough lines or pixels
as it was initialized for and therefore it may simply wait for
more data instead of reporting "done with 1280x1024 pixels".

> 
> Nevertheless seems OK if I check OMAP3 ISP register:
> CCDC SYN_MODE=0x00071704
> #define ISPCCDC_SYN_MODE_VDPOL(1 << 2)
> #define ISPCCDC_SYN_MODE_HDPOL(1 << 3)
> 
> seems well that vertical is 1 and horizontal is 0.
> 

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 03.07.2017 um 14:03 schrieb Hugues FRUCHET :
> 
> Hi Nikolaus,
> 
> nothing really strange in trace, I wanted to check the latest S_FMT and 
> it is well 1280x1024 YUV:
>>> [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
> height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> xfer_func=0
> 

Thanks for cross-checking.

> You're right that it seems that the ISP is not seeing any data in input.
> Have you double checked the polarities of sync signals ? I see 
> differences in devicetree:
>  960 ov9655: endpoint {
>  961 remote-endpoint = <_ep>;
>  962 #if 0   // not used by camera driver - define _ep for isp
>  963 bus-width = <8>;
>  964 data-shift = <2>;   /* Lines 
> 9:2 are used */
>  965 hsync-active = <1>; /* Active 
> high */
>  966 vsync-active = <1>; /* Active 
> high */
>  967 data-active = <1>;  /* Active 
> high */
>  968 pclk-sample = <1>;  /* Rising */
>  969 #endif
> 
> Which has been commented out in flavour of:
> 
> 1011 /* parallel camera interface */
> 1012 _ep {
> 1013 remote-endpoint = <>;
> 1014 ti,isp-clock-divisor = <1>;
> 1015 ti,strobe-mode;
> 1016 bus-width = <8>;/* Used data lines */
> 1017 data-shift = <2>; /* Lines 9:2 are used */
> 1018 hsync-active = <0>; /* Active low */
> 1019 vsync-active = <1>; /* Active high */
> 1020 data-active = <1>;/* Active high */
> 1021 pclk-sample = <1>;/* Rising */
> 1022 };
> 
> there is a difference regarding active level of hsync.

Yes, this is from experimenting with our driver patch series to
do the setup in the camera driver. Both chips can configure polarities
but we now have only system defaults in the camera driver. Therefore,
it is commented out for the camera DT node.

The problem is that we never had all this working in DT mode so
our setup here might indeed be buggy.

On the other hand the polarity (HSYNC act. low and VSYNC act. high)
does match the signals seen by oscilloscope.

I will try asap if this makes a difference. There are only 4 combinations...

My expectation is that wrong polarity would only move the
active trigger point around so that I would expect an image
shifted left/right or up/down.

But I don't know enough details of the isp. If it is triggering
sync not by edge but by state and stopping capture for the wrong
state of the sync signal it might not receive enough lines or pixels
as it was initialized for and therefore it may simply wait for
more data instead of reporting "done with 1280x1024 pixels".

> 
> Nevertheless seems OK if I check OMAP3 ISP register:
> CCDC SYN_MODE=0x00071704
> #define ISPCCDC_SYN_MODE_VDPOL(1 << 2)
> #define ISPCCDC_SYN_MODE_HDPOL(1 << 3)
> 
> seems well that vertical is 1 and horizontal is 0.
> 

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread Hugues FRUCHET

Hi Nikolaus,

nothing really strange in trace, I wanted to check the latest S_FMT and 
it is well 1280x1024 YUV:
 >> [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
xfer_func=0

You're right that it seems that the ISP is not seeing any data in input.
Have you double checked the polarities of sync signals ? I see 
differences in devicetree:
  960 ov9655: endpoint {
  961 remote-endpoint = <_ep>;
  962 #if 0   // not used by camera driver - define _ep for isp
  963 bus-width = <8>;
  964 data-shift = <2>;   /* Lines 
9:2 are used */
  965 hsync-active = <1>; /* Active 
high */
  966 vsync-active = <1>; /* Active 
high */
  967 data-active = <1>;  /* Active 
high */
  968 pclk-sample = <1>;  /* Rising */
  969 #endif

Which has been commented out in flavour of:

1011 /* parallel camera interface */
1012 _ep {
1013 remote-endpoint = <>;
1014 ti,isp-clock-divisor = <1>;
1015 ti,strobe-mode;
1016 bus-width = <8>;/* Used data lines */
1017 data-shift = <2>; /* Lines 9:2 are used */
1018 hsync-active = <0>; /* Active low */
1019 vsync-active = <1>; /* Active high */
1020 data-active = <1>;/* Active high */
1021 pclk-sample = <1>;/* Rising */
1022 };

there is a difference regarding active level of hsync.

Nevertheless seems OK if I check OMAP3 ISP register:
CCDC SYN_MODE=0x00071704
#define ISPCCDC_SYN_MODE_VDPOL  (1 << 2)
#define ISPCCDC_SYN_MODE_HDPOL  (1 << 3)

seems well that vertical is 1 and horizontal is 0.


BR,
Hugues.

On 07/03/2017 11:14 AM, H. Nikolaus Schaller wrote:
> Hi Hugues,
> 
>> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET :
>>
>> Hi Nikolaus,
>> Could you enable V4L2 UAPI traces ? Something like:
>> echo 0xFF >  /sys/devices/platform/soc/.> name>/video4linux/video2/dev_debug
>>
>> you will see then in kernel dmesg the V4L2 calls and their
>> parameters/return values.
> 
> Nice.
> 
>> root@letux:~# echo 255 
>> >/sys/devices/platform/6800.ocp/480bc000.isp/video4linux/video2/dev_debug
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> [  425.216094] video2: open (0)
>> [  425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC 
>> output, bus=media, version=0x00040c00, capabilities=0x8423, 
>> device_caps=0x0421
>> [  425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
>> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
>> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [  425.254699] video2: VIDIOC_G_STD: error -25: std=0x
>> [  425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, 
>> capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, 
>> readbuffers=0
>> v4l2: ioctl get standard failed: Invalid argumen[  425.275573] video2: 
>> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
>> t
>> Selected device: OMAP3 ISP CCDC output
>>   Capa[  425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
>> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
>> bilities:  video capture  video output  streamin[  425.306396] video2: 
>> VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, 
>> std=0x, status=0x0, capabilities=0x0
>> g
>>   supported norms:
>>   inputs: 0 = camera;[  425.323822] video2: VIDIOC_G_INPUT: value=0
>>
>>   Current input: 0
>> [  425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, 
>> flags=0x0, pixelformat=, description=''
>>   Current format: unknown (0x0)
>> [  425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
>> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
>> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [  425.367858] video2:

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread Hugues FRUCHET

Hi Nikolaus,

nothing really strange in trace, I wanted to check the latest S_FMT and 
it is well 1280x1024 YUV:
 >> [  425.579498] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, 
height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
xfer_func=0

You're right that it seems that the ISP is not seeing any data in input.
Have you double checked the polarities of sync signals ? I see 
differences in devicetree:
  960 ov9655: endpoint {
  961 remote-endpoint = <_ep>;
  962 #if 0   // not used by camera driver - define _ep for isp
  963 bus-width = <8>;
  964 data-shift = <2>;   /* Lines 
9:2 are used */
  965 hsync-active = <1>; /* Active 
high */
  966 vsync-active = <1>; /* Active 
high */
  967 data-active = <1>;  /* Active 
high */
  968 pclk-sample = <1>;  /* Rising */
  969 #endif

Which has been commented out in flavour of:

1011 /* parallel camera interface */
1012 _ep {
1013 remote-endpoint = <>;
1014 ti,isp-clock-divisor = <1>;
1015 ti,strobe-mode;
1016 bus-width = <8>;/* Used data lines */
1017 data-shift = <2>; /* Lines 9:2 are used */
1018 hsync-active = <0>; /* Active low */
1019 vsync-active = <1>; /* Active high */
1020 data-active = <1>;/* Active high */
1021 pclk-sample = <1>;/* Rising */
1022 };

there is a difference regarding active level of hsync.

Nevertheless seems OK if I check OMAP3 ISP register:
CCDC SYN_MODE=0x00071704
#define ISPCCDC_SYN_MODE_VDPOL  (1 << 2)
#define ISPCCDC_SYN_MODE_HDPOL  (1 << 3)

seems well that vertical is 1 and horizontal is 0.


BR,
Hugues.

On 07/03/2017 11:14 AM, H. Nikolaus Schaller wrote:
> Hi Hugues,
> 
>> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET :
>>
>> Hi Nikolaus,
>> Could you enable V4L2 UAPI traces ? Something like:
>> echo 0xFF >  /sys/devices/platform/soc/.> name>/video4linux/video2/dev_debug
>>
>> you will see then in kernel dmesg the V4L2 calls and their
>> parameters/return values.
> 
> Nice.
> 
>> root@letux:~# echo 255 
>> >/sys/devices/platform/6800.ocp/480bc000.isp/video4linux/video2/dev_debug
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> [  425.216094] video2: open (0)
>> [  425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC 
>> output, bus=media, version=0x00040c00, capabilities=0x8423, 
>> device_caps=0x0421
>> [  425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
>> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
>> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [  425.254699] video2: VIDIOC_G_STD: error -25: std=0x
>> [  425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, 
>> capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, 
>> readbuffers=0
>> v4l2: ioctl get standard failed: Invalid argumen[  425.275573] video2: 
>> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
>> t
>> Selected device: OMAP3 ISP CCDC output
>>   Capa[  425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
>> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
>> bilities:  video capture  video output  streamin[  425.306396] video2: 
>> VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, 
>> std=0x, status=0x0, capabilities=0x0
>> g
>>   supported norms:
>>   inputs: 0 = camera;[  425.323822] video2: VIDIOC_G_INPUT: value=0
>>
>>   Current input: 0
>> [  425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, 
>> flags=0x0, pixelformat=, description=''
>>   Current format: unknown (0x0)
>> [  425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
>> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
>> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
>> [  425.367858] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, 
>>

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET :
> 
> Hi Nikolaus,
> Could you enable V4L2 UAPI traces ? Something like:
> echo 0xFF >  /sys/devices/platform/soc/. name>/video4linux/video2/dev_debug
> 
> you will see then in kernel dmesg the V4L2 calls and their 
> parameters/return values.

Nice.

> root@letux:~# echo 255 
> >/sys/devices/platform/6800.ocp/480bc000.isp/video4linux/video2/dev_debug
> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> [  425.216094] video2: open (0)
> [  425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC 
> output, bus=media, version=0x00040c00, capabilities=0x8423, 
> device_caps=0x0421
> [  425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.254699] video2: VIDIOC_G_STD: error -25: std=0x
> [  425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, 
> capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, 
> readbuffers=0
> v4l2: ioctl get standard failed: Invalid argumen[  425.275573] video2: 
> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> t
> Selected device: OMAP3 ISP CCDC output
>  Capa[  425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
> bilities:  video capture  video output  streamin[  425.306396] video2: 
> VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, 
> std=0x, status=0x0, capabilities=0x0
> g
>  supported norms:
>  inputs: 0 = camera;[  425.323822] video2: VIDIOC_G_INPUT: value=0
> 
>  Current input: 0
> [  425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, 
> flags=0x0, pixelformat=, description=''
>  Current format: unknown (0x0)
> [  425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.367858] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.386627] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.405334] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.425720] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
> [  425.439727] video2: VIDIOC_S_INPUT: value=0
> [  425.445159] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, 
> fps=0/0, framelines=0
> tv.c: norm_from_string(pal): Bogus norm paramete[  425.455871] video2: 
> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> r, setting default.
> v4l2: ioctl enum norm failed: In[  425.470397] video2: VIDIOC_G_FMT: 
> type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, 
> bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, 
> quantization=0, xfer_func=0
> appropriate ioctl for device
> Error: Cannot set [  425.493743] video2: VIDIOC_S_FMT: type=vid-cap, 
> width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> xfer_func=0
> norm!
> [  425.517669] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, 
> pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.538238] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, 
> pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.558990] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, 
>

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 03.07.2017 um 10:16 schrieb Hugues FRUCHET :
> 
> Hi Nikolaus,
> Could you enable V4L2 UAPI traces ? Something like:
> echo 0xFF >  /sys/devices/platform/soc/. name>/video4linux/video2/dev_debug
> 
> you will see then in kernel dmesg the V4L2 calls and their 
> parameters/return values.

Nice.

> root@letux:~# echo 255 
> >/sys/devices/platform/6800.ocp/480bc000.isp/video4linux/video2/dev_debug
> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> [  425.216094] video2: open (0)
> [  425.219329] video2: VIDIOC_QUERYCAP: driver=ispvideo, card=OMAP3 ISP CCDC 
> output, bus=media, version=0x00040c00, capabilities=0x8423, 
> device_caps=0x0421
> [  425.236389] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.254699] video2: VIDIOC_G_STD: error -25: std=0x
> [  425.260620] video2: VIDIOC_G_PARM: error -22: type=vid-cap, 
> capability=0x0, capturemode=0x0, timeperframe=0/0, extendedmode=0, 
> readbuffers=0
> v4l2: ioctl get standard failed: Invalid argumen[  425.275573] video2: 
> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> t
> Selected device: OMAP3 ISP CCDC output
>  Capa[  425.289398] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
> bilities:  video capture  video output  streamin[  425.306396] video2: 
> VIDIOC_ENUMINPUT: error -22: index=1, name=, type=0, audioset=0x0, tuner=0, 
> std=0x, status=0x0, capabilities=0x0
> g
>  supported norms:
>  inputs: 0 = camera;[  425.323822] video2: VIDIOC_G_INPUT: value=0
> 
>  Current input: 0
> [  425.332580] video2: VIDIOC_ENUM_FMT: error -25: index=0, type=vid-cap, 
> flags=0x0, pixelformat=, description=''
>  Current format: unknown (0x0)
> [  425.345428] video2: VIDIOC_G_FMT: type=vid-cap, width=0, height=0, 
> pixelformat=, field=any, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.367858] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.386627] video2: VIDIOC_G_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=, field=none, bytesperline=0, sizeimage=0, colorspace=0, 
> flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.405334] video2: VIDIOC_S_FMT: type=vid-cap, width=640, height=480, 
> pixelformat=UYVY, field=none, bytesperline=1280, sizeimage=614400, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.425720] video2: VIDIOC_ENUMINPUT: index=0, name=camera, type=2, 
> audioset=0x0, tuner=0, std=0x, status=0x0, capabilities=0x0
> [  425.439727] video2: VIDIOC_S_INPUT: value=0
> [  425.445159] video2: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, 
> fps=0/0, framelines=0
> tv.c: norm_from_string(pal): Bogus norm paramete[  425.455871] video2: 
> VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
> r, setting default.
> v4l2: ioctl enum norm failed: In[  425.470397] video2: VIDIOC_G_FMT: 
> type=vid-cap, width=640, height=480, pixelformat=UYVY, field=none, 
> bytesperline=1280, sizeimage=614400, colorspace=0, flags=0x0, ycbcr_enc=0, 
> quantization=0, xfer_func=0
> appropriate ioctl for device
> Error: Cannot set [  425.493743] video2: VIDIOC_S_FMT: type=vid-cap, 
> width=1280, height=1024, pixelformat=UYVY, field=none, bytesperline=2560, 
> sizeimage=2621440, colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, 
> xfer_func=0
> norm!
> [  425.517669] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, 
> pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.538238] video2: VIDIOC_S_FMT: type=vid-cap, width=1280, height=1024, 
> pixelformat=UYVY, field=none, bytesperline=2560, sizeimage=2621440, 
> colorspace=0, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
> [  425.558990] video2: VIDIOC_G_FMT: type=vid-cap, width=1280, height=1024, 
> pixelformat=UYVY, field=none, bytesperline=2560,

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread Hugues FRUCHET

Hi Nikolaus,
Could you enable V4L2 UAPI traces ? Something like:
echo 0xFF >  /sys/devices/platform/soc/./video4linux/video2/dev_debug

you will see then in kernel dmesg the V4L2 calls and their 
parameters/return values.

BR,
Hugues.

On 07/01/2017 11:00 PM, H. Nikolaus Schaller wrote:
> Hi,
> 
> Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for 
> omap3isp compatibility
> (see 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1
>  ).
> 
> And secondly, I have tried to add some SXGA config and it looks good by 
> oscilloscope:
> - XCLK ca. 24 MHz
> - PCLK ca. 12 MHz
> - HREF ca. 15.6 kHz negative going impulses
> - VSYNC ca. 15 Hz (fps) positive going impulses
> - D8 data line shows changing 0/1 patterns which depend on light falling in 
> camera lens
> 
> But mplayer still shows a green screen and reports v4l2: select timeout.
> 
> I assume we should see a at least scrambled image but not a green screen,
> even if sync position and polarity or data format would not be correctly
> set up.
> 
> This time the omap3isp is fully initialized and does a register dump:
> 
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
> 
> NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")
> 
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
> 
> ^^^ does not look harmful
> 
>> Selected device: OMAP3 ISP CCDC output
>>   Capabilities:  video capture  video output  streaming
>>   supported norms:
>>   inputs: 0 = camera;
>>   Current input: 0
>>   Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
> 
> ^^^ does not look harmful
> 
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
> 
> ^^^ does not look harmful
> 
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
> 
> ^^^ does not look harmful
> 
>> [  558.848815] configuring for 1280(2560)x1024
>> [  558.854003] omap3isp 480bc000.isp: -CCDC Register 
>> dump-
>> [  558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x
>> [  558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
>> [  558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x
>> [  558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x
>> [  558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x04ff
>> [  558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x
>> [  558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x03ff
>> [  558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0x00ff
>> [  558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x0a00
>> [  558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x
>> [  558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x4000
>> [  558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x0010
>> [  558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x
>> [  558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
>> [  558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x
>> [  558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x
>> [  558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x
>> [  558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
>> [  558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x0004
>> [  558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x
>> [  559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x8800
>> [  559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x
>> [  559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x
>> [  559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x
>> [  559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x
>> [  559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x
>> [  559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x
>> [  559.047790] omap3isp

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-03 Thread Hugues FRUCHET

Hi Nikolaus,
Could you enable V4L2 UAPI traces ? Something like:
echo 0xFF >  /sys/devices/platform/soc/./video4linux/video2/dev_debug

you will see then in kernel dmesg the V4L2 calls and their 
parameters/return values.

BR,
Hugues.

On 07/01/2017 11:00 PM, H. Nikolaus Schaller wrote:
> Hi,
> 
> Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for 
> omap3isp compatibility
> (see 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1
>  ).
> 
> And secondly, I have tried to add some SXGA config and it looks good by 
> oscilloscope:
> - XCLK ca. 24 MHz
> - PCLK ca. 12 MHz
> - HREF ca. 15.6 kHz negative going impulses
> - VSYNC ca. 15 Hz (fps) positive going impulses
> - D8 data line shows changing 0/1 patterns which depend on light falling in 
> camera lens
> 
> But mplayer still shows a green screen and reports v4l2: select timeout.
> 
> I assume we should see a at least scrambled image but not a green screen,
> even if sync position and polarity or data format would not be correctly
> set up.
> 
> This time the omap3isp is fully initialized and does a register dump:
> 
>> root@letux:~# ./camera-demo sxga
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
> 
> NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")
> 
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
> 
> ^^^ does not look harmful
> 
>> Selected device: OMAP3 ISP CCDC output
>>   Capabilities:  video capture  video output  streaming
>>   supported norms:
>>   inputs: 0 = camera;
>>   Current input: 0
>>   Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
> 
> ^^^ does not look harmful
> 
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
> 
> ^^^ does not look harmful
> 
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
> 
> ^^^ does not look harmful
> 
>> [  558.848815] configuring for 1280(2560)x1024
>> [  558.854003] omap3isp 480bc000.isp: -CCDC Register 
>> dump-
>> [  558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x
>> [  558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
>> [  558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x
>> [  558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x
>> [  558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x04ff
>> [  558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x
>> [  558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x03ff
>> [  558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0x00ff
>> [  558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x0a00
>> [  558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x
>> [  558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x4000
>> [  558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x0010
>> [  558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x
>> [  558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
>> [  558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x
>> [  558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x
>> [  558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x
>> [  558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
>> [  558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x0004
>> [  558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x
>> [  559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x8800
>> [  559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x
>> [  559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x
>> [  559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x
>> [  559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x
>> [  559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x
>> [  559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x
>> [  559.047790] omap3isp 480bc000.isp: ###CCDC

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-01 Thread H. Nikolaus Schaller

Hi,

Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for omap3isp 
compatibility
(see 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1
 ).

And secondly, I have tried to add some SXGA config and it looks good by 
oscilloscope:
- XCLK ca. 24 MHz
- PCLK ca. 12 MHz
- HREF ca. 15.6 kHz negative going impulses
- VSYNC ca. 15 Hz (fps) positive going impulses
- D8 data line shows changing 0/1 patterns which depend on light falling in 
camera lens

But mplayer still shows a green screen and reports v4l2: select timeout.

I assume we should see a at least scrambled image but not a green screen,
even if sync position and polarity or data format would not be correctly
set up.

This time the omap3isp is fully initialized and does a register dump:

> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11

NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")

> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument

^^^ does not look harmful

> Selected device: OMAP3 ISP CCDC output
>  Capabilities:  video capture  video output  streaming
>  supported norms:
>  inputs: 0 = camera;
>  Current input: 0
>  Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device

^^^ does not look harmful

> Error: Cannot set norm!
> Selected input hasn't got a tuner!

^^^ does not look harmful

> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device

^^^ does not look harmful

> [  558.848815] configuring for 1280(2560)x1024
> [  558.854003] omap3isp 480bc000.isp: -CCDC Register 
> dump-
> [  558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x
> [  558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
> [  558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x
> [  558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x
> [  558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x04ff
> [  558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x
> [  558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x03ff
> [  558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0x00ff
> [  558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x0a00
> [  558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x
> [  558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x4000
> [  558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x0010
> [  558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x
> [  558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
> [  558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x
> [  558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x
> [  558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x
> [  558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
> [  558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x0004
> [  558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x
> [  559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x8800
> [  559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x
> [  559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x
> [  559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x
> [  559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x
> [  559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x
> [  559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x
> [  559.047790] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x
> [  559.054687] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x
> [  559.061645] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x6600
> [  559.068084] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x
> [  559.075378] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x
> [  559.082916] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x
> [  559.090454] omap3isp 480bc000.isp: 
>

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-07-01 Thread H. Nikolaus Schaller

Hi,

Firstly, it turned out that we also must have V4L2_CID_PIXEL_RATE for omap3isp 
compatibility
(see 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?=0bc77f3f06fcf2ca7b7fad782d70926cd4d235f1
 ).

And secondly, I have tried to add some SXGA config and it looks good by 
oscilloscope:
- XCLK ca. 24 MHz
- PCLK ca. 12 MHz
- HREF ca. 15.6 kHz negative going impulses
- VSYNC ca. 15 Hz (fps) positive going impulses
- D8 data line shows changing 0/1 patterns which depend on light falling in 
camera lens

But mplayer still shows a green screen and reports v4l2: select timeout.

I assume we should see a at least scrambled image but not a green screen,
even if sync position and polarity or data format would not be correctly
set up.

This time the omap3isp is fully initialized and does a register dump:

> root@letux:~# ./camera-demo sxga
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11

NOTE: /dev/video2 is $(media-ctl -e "OMAP3 ISP CCDC output")

> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument

^^^ does not look harmful

> Selected device: OMAP3 ISP CCDC output
>  Capabilities:  video capture  video output  streaming
>  supported norms:
>  inputs: 0 = camera;
>  Current input: 0
>  Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device

^^^ does not look harmful

> Error: Cannot set norm!
> Selected input hasn't got a tuner!

^^^ does not look harmful

> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device

^^^ does not look harmful

> [  558.848815] configuring for 1280(2560)x1024
> [  558.854003] omap3isp 480bc000.isp: -CCDC Register 
> dump-
> [  558.863983] omap3isp 480bc000.isp: ###CCDC PCR=0x
> [  558.870880] omap3isp 480bc000.isp: ###CCDC SYN_MODE=0x00071704
> [  558.877227] omap3isp 480bc000.isp: ###CCDC HD_VD_WID=0x
> [  558.884613] omap3isp 480bc000.isp: ###CCDC PIX_LINES=0x
> [  558.891876] omap3isp 480bc000.isp: ###CCDC HORZ_INFO=0x04ff
> [  558.898132] omap3isp 480bc000.isp: ###CCDC VERT_START=0x
> [  558.905700] omap3isp 480bc000.isp: ###CCDC VERT_LINES=0x03ff
> [  558.913421] omap3isp 480bc000.isp: ###CCDC CULLING=0x00ff
> [  558.920471] omap3isp 480bc000.isp: ###CCDC HSIZE_OFF=0x0a00
> [  558.926727] omap3isp 480bc000.isp: ###CCDC SDOFST=0x
> [  558.933929] omap3isp 480bc000.isp: ###CCDC SDR_ADDR=0x4000
> [  558.940948] omap3isp 480bc000.isp: ###CCDC CLAMP=0x0010
> [  558.946990] omap3isp 480bc000.isp: ###CCDC DCSUB=0x
> [  558.953948] omap3isp 480bc000.isp: ###CCDC COLPTN=0xbb11bb11
> [  558.960845] omap3isp 480bc000.isp: ###CCDC BLKCMP=0x
> [  558.966888] omap3isp 480bc000.isp: ###CCDC FPC=0x
> [  558.973724] omap3isp 480bc000.isp: ###CCDC FPC_ADDR=0x
> [  558.982757] omap3isp 480bc000.isp: ###CCDC VDINT=0x03fe02aa
> [  558.988769] omap3isp 480bc000.isp: ###CCDC ALAW=0x0004
> [  558.995483] omap3isp 480bc000.isp: ###CCDC REC656IF=0x
> [  559.002380] omap3isp 480bc000.isp: ###CCDC CFG=0x8800
> [  559.008056] omap3isp 480bc000.isp: ###CCDC FMTCFG=0x
> [  559.014892] omap3isp 480bc000.isp: ###CCDC FMT_HORZ=0x
> [  559.021697] omap3isp 480bc000.isp: ###CCDC FMT_VERT=0x
> [  559.027954] omap3isp 480bc000.isp: ###CCDC PRGEVEN0=0x
> [  559.034912] omap3isp 480bc000.isp: ###CCDC PRGEVEN1=0x
> [  559.041748] omap3isp 480bc000.isp: ###CCDC PRGODD0=0x
> [  559.047790] omap3isp 480bc000.isp: ###CCDC PRGODD1=0x
> [  559.054687] omap3isp 480bc000.isp: ###CCDC VP_OUT=0x
> [  559.061645] omap3isp 480bc000.isp: ###CCDC LSC_CONFIG=0x6600
> [  559.068084] omap3isp 480bc000.isp: ###CCDC LSC_INITIAL=0x
> [  559.075378] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_BASE=0x
> [  559.082916] omap3isp 480bc000.isp: ###CCDC LSC_TABLE_OFFSET=0x
> [  559.090454] omap3isp 480bc000.isp: 
>

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-27 Thread Hugues FRUCHET

Hi Nikolaus,

I would propose to work first on YUV support, so you can test a YUV VGA 
grabbing using your OMPA3 setup, I will add this support then in patch 
serie.

For the co-work, let's continue on IRC (irc.freenode.net), chat #v4l, my 
pseudo is "hfr".

BR,
Hugues.

On 06/26/2017 06:28 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
> 
>> Am 26.06.2017 um 15:19 schrieb Hugues FRUCHET :
>>
>> Nikolaus,
>> some comments about pixel format/resolution below:
>>
>> On 06/26/2017 10:39 AM, Pavel Machek wrote:
>>> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
 Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>
> Hi!
>
>> * unfortunately we still get no image :(
>>
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
>> Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface 
>> indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green 
>> screen.
>
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
>
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

 We did have yet another (non-DT) camera driver and media-ctl working in 
 with 3.12.37,
 but had no success yet to update it to work with modern kernels or 
 drivers. It
 is either that the (newer) drivers missing something or the media-ctl has 
 changed.

 Here is the log of our scripts with Hugues' driver and our latest setup:

 root@letux:~# ./camera-demo sxga
 DISPLAY=:0
 XAUTHORITY=tcp
 Camera: /dev/v4l-subdev8
 Setting mode sxga
 media-ctl -r
 media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
 media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
 media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>>>
>>> Ok, so you are using capture, not preview.
>>>
>>> You may want to try this one:
>>>
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel 
>>> Date:   Mon Feb 13 21:26:51 2017 +0100
>>>
>>>  omap3isp: fix VP2SDR bit so capture (not preview) works
>>>
>>>  This is neccessary for capture (not preview) to work properly on
>>>  N900. Why is unknown.
>>> 
>>> Pavel
>>>
 ### starting mplayer in sxga mode ###
 mplayer tv:// -vf rotate=2 -tv 
 driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 
 -vo x11
>>
>> => "outfmt=uyvy:width=1280:height=1024"
>>
>> Nikolaus,
>> Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
>> perhaps this explain partly your troubles ?
> 
> Ah, I see. The driver should support SXGA and UYVY2X8 (because our 3.12 
> compatible driver did).
> 
> This very old (but working) non-DT driver for 3.12 kernels
> was not based on the ov9650.c code but mt9p031.c:
> 
>   
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/media/i2c/ov9655.c;hb=refs/heads/3.12.37
> 
> We abandoned this independent driver because we felt (like you) that 
> extending the existing
> ov9650 driver is a better solution for mainline.
> 
> 
> At least in theory. Therefore I assumed your submission supports SXGA and 
> UYVY as well,
> since your work is based on ours.
> 
> Nevertheless, VGA resolution doesn't work either.
> 
> root@letux:~# ./camera-demo vga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode vga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 640x480]'
> ### starting mplayer in vga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=640:height=480:fps=30 -vo x11
> 
> 
> A little later it reports a NULL pointer dereference in ccdc_link_validate() 
> / ccdc_is_shiftable().
> 
> It appears as if the input format translates into a NULL pointer by
> omap3isp_video_format_info(0x1008).
> 
> This NULL pointer is not catched by ccdc_is_shiftable().
> 
> And it indicates that the camera driver is doing a format that is not
> supported by omap3isp...
> 
> 
> So how should we proceed?
> 
> It looks as if your driver supports your scenario (STM32F746G-DISCO) in 
> VGA/RGB565
> and our drivers (basically) support ours (omap3isp) in VGA/SXGA but UYVY.
> 
> We certainly need a generic driver that supports all platforms and formats. So
> we somehow need to get all this stuff into a single driver.
> 
>

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-27 Thread Hugues FRUCHET

Hi Nikolaus,

I would propose to work first on YUV support, so you can test a YUV VGA 
grabbing using your OMPA3 setup, I will add this support then in patch 
serie.

For the co-work, let's continue on IRC (irc.freenode.net), chat #v4l, my 
pseudo is "hfr".

BR,
Hugues.

On 06/26/2017 06:28 PM, H. Nikolaus Schaller wrote:
> Hi Hugues,
> 
>> Am 26.06.2017 um 15:19 schrieb Hugues FRUCHET :
>>
>> Nikolaus,
>> some comments about pixel format/resolution below:
>>
>> On 06/26/2017 10:39 AM, Pavel Machek wrote:
>>> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
 Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>
> Hi!
>
>> * unfortunately we still get no image :(
>>
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
>> Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface 
>> indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green 
>> screen.
>
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
>
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

 We did have yet another (non-DT) camera driver and media-ctl working in 
 with 3.12.37,
 but had no success yet to update it to work with modern kernels or 
 drivers. It
 is either that the (newer) drivers missing something or the media-ctl has 
 changed.

 Here is the log of our scripts with Hugues' driver and our latest setup:

 root@letux:~# ./camera-demo sxga
 DISPLAY=:0
 XAUTHORITY=tcp
 Camera: /dev/v4l-subdev8
 Setting mode sxga
 media-ctl -r
 media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
 media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
 media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
 media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
>>>
>>> Ok, so you are using capture, not preview.
>>>
>>> You may want to try this one:
>>>
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel 
>>> Date:   Mon Feb 13 21:26:51 2017 +0100
>>>
>>>  omap3isp: fix VP2SDR bit so capture (not preview) works
>>>
>>>  This is neccessary for capture (not preview) to work properly on
>>>  N900. Why is unknown.
>>> 
>>> Pavel
>>>
 ### starting mplayer in sxga mode ###
 mplayer tv:// -vf rotate=2 -tv 
 driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 
 -vo x11
>>
>> => "outfmt=uyvy:width=1280:height=1024"
>>
>> Nikolaus,
>> Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
>> perhaps this explain partly your troubles ?
> 
> Ah, I see. The driver should support SXGA and UYVY2X8 (because our 3.12 
> compatible driver did).
> 
> This very old (but working) non-DT driver for 3.12 kernels
> was not based on the ov9650.c code but mt9p031.c:
> 
>   
> http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/media/i2c/ov9655.c;hb=refs/heads/3.12.37
> 
> We abandoned this independent driver because we felt (like you) that 
> extending the existing
> ov9650 driver is a better solution for mainline.
> 
> 
> At least in theory. Therefore I assumed your submission supports SXGA and 
> UYVY as well,
> since your work is based on ours.
> 
> Nevertheless, VGA resolution doesn't work either.
> 
> root@letux:~# ./camera-demo vga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode vga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 640x480]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 640x480]'
> ### starting mplayer in vga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=640:height=480:fps=30 -vo x11
> 
> 
> A little later it reports a NULL pointer dereference in ccdc_link_validate() 
> / ccdc_is_shiftable().
> 
> It appears as if the input format translates into a NULL pointer by
> omap3isp_video_format_info(0x1008).
> 
> This NULL pointer is not catched by ccdc_is_shiftable().
> 
> And it indicates that the camera driver is doing a format that is not
> supported by omap3isp...
> 
> 
> So how should we proceed?
> 
> It looks as if your driver supports your scenario (STM32F746G-DISCO) in 
> VGA/RGB565
> and our drivers (basically) support ours (omap3isp) in VGA/SXGA but UYVY.
> 
> We certainly need a generic driver that supports all platforms and formats. So
> we somehow need to get all this stuff into a single driver.
> 
> Working on two different patch sets doesn't make

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller


> Am 26.06.2017 um 13:16 schrieb Pavel Machek :
> 
> Hi!
> 
>>> You may want to try this one:
>>> 
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel 
>>> Date:   Mon Feb 13 21:26:51 2017 +0100
>>> 
>>>   omap3isp: fix VP2SDR bit so capture (not preview) works
>>> 
>>>   This is neccessary for capture (not preview) to work properly on
>>>   N900. Why is unknown.
>> 
>> Ah, interesting. I will give it a try.
>> 
>> Do you please have a link to the repo where this commit can be
>>> found?
> 
> This branch, as mentioned before:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Thanks.

I have merged this patch but unfortunately, it does not make the green screen 
go away.

Neither with our own driver nor with the new one by Hugues (which turned out to 
not
support SXGA at all but I tried VGA).

I think we should postpone debugging this until Hugues proposed patches are 
better reviewed.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller


> Am 26.06.2017 um 13:16 schrieb Pavel Machek :
> 
> Hi!
> 
>>> You may want to try this one:
>>> 
>>> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
>>> Author: Pavel 
>>> Date:   Mon Feb 13 21:26:51 2017 +0100
>>> 
>>>   omap3isp: fix VP2SDR bit so capture (not preview) works
>>> 
>>>   This is neccessary for capture (not preview) to work properly on
>>>   N900. Why is unknown.
>> 
>> Ah, interesting. I will give it a try.
>> 
>> Do you please have a link to the repo where this commit can be
>>> found?
> 
> This branch, as mentioned before:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Thanks.

I have merged this patch but unfortunately, it does not make the green screen 
go away.

Neither with our own driver nor with the new one by Hugues (which turned out to 
not
support SXGA at all but I tried VGA).

I think we should postpone debugging this until Hugues proposed patches are 
better reviewed.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Hugues FRUCHET

Nikolaus,
some comments about pixel format/resolution below:

On 06/26/2017 10:39 AM, Pavel Machek wrote:
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>>
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>>>
>>> Hi!
>>>
 * unfortunately we still get no image :(

 The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
 Image Signal Processor) which
 we were not yet able to solve. Oscilloscoping signals on the interface 
 indicated that signals and
 sync are correct. But we do not know since mplayer only shows a green 
 screen.
>>>
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>>
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>>
>> We did have yet another (non-DT) camera driver and media-ctl working in with 
>> 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. 
>> It
>> is either that the (newer) drivers missing something or the media-ctl has 
>> changed.
>>
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>>
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> 
> Ok, so you are using capture, not preview.
> 
> You may want to try this one:
> 
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel 
> Date:   Mon Feb 13 21:26:51 2017 +0100
> 
>  omap3isp: fix VP2SDR bit so capture (not preview) works
> 
>  This is neccessary for capture (not preview) to work properly on
>  N900. Why is unknown.
>   
>   Pavel
> 
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11

=> "outfmt=uyvy:width=1280:height=1024"

Nikolaus,
Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
perhaps this explain partly your troubles ?

>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>>   Capabilities:  video capture  video output  streaming
>>   supported norms:
>>   inputs: 0 = camera;
>>   Current input: 0
>>   Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
>> yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>>
>> BR and thanks,
>> Nikolaus
>>
> 
> 
>

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Hugues FRUCHET

Nikolaus,
some comments about pixel format/resolution below:

On 06/26/2017 10:39 AM, Pavel Machek wrote:
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>>
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>>>
>>> Hi!
>>>
 * unfortunately we still get no image :(

 The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
 Image Signal Processor) which
 we were not yet able to solve. Oscilloscoping signals on the interface 
 indicated that signals and
 sync are correct. But we do not know since mplayer only shows a green 
 screen.
>>>
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>>
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>>
>> We did have yet another (non-DT) camera driver and media-ctl working in with 
>> 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. 
>> It
>> is either that the (newer) drivers missing something or the media-ctl has 
>> changed.
>>
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>>
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> 
> Ok, so you are using capture, not preview.
> 
> You may want to try this one:
> 
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel 
> Date:   Mon Feb 13 21:26:51 2017 +0100
> 
>  omap3isp: fix VP2SDR bit so capture (not preview) works
> 
>  This is neccessary for capture (not preview) to work properly on
>  N900. Why is unknown.
>   
>   Pavel
> 
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11

=> "outfmt=uyvy:width=1280:height=1024"

Nikolaus,
Be careful that only VGA/RGB565 is coded in this basic version of OV9655,
perhaps this explain partly your troubles ?

>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>>
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>>   name: Video 4 Linux 2 input
>>   author: Martin Olschewski 
>>   comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>>   Capabilities:  video capture  video output  streaming
>>   supported norms:
>>   inputs: 0 = camera;
>>   Current input: 0
>>   Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
>> yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
>>
>>
>> MPlayer interrupted by signal 2 in module: filter_video
>> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>>
>> Exiting... (Quit)
>> root@letux:~#
>>
>> BR and thanks,
>> Nikolaus
>>
> 
> 
>

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Pavel Machek

Hi!

> > You may want to try this one:
> > 
> > commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> > Author: Pavel 
> > Date:   Mon Feb 13 21:26:51 2017 +0100
> > 
> >omap3isp: fix VP2SDR bit so capture (not preview) works
> > 
> >This is neccessary for capture (not preview) to work properly on
> >N900. Why is unknown.
> 
> Ah, interesting. I will give it a try.
> 
> Do you please have a link to the repo where this commit can be
> > found?

This branch, as mentioned before:

https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Pavel Machek

Hi!

> > You may want to try this one:
> > 
> > commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> > Author: Pavel 
> > Date:   Mon Feb 13 21:26:51 2017 +0100
> > 
> >omap3isp: fix VP2SDR bit so capture (not preview) works
> > 
> >This is neccessary for capture (not preview) to work properly on
> >N900. Why is unknown.
> 
> Ah, interesting. I will give it a try.
> 
> Do you please have a link to the repo where this commit can be
> > found?

This branch, as mentioned before:

https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-n900.git/log/?h=camera-fw5-6

Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Hugues FRUCHET

Hi Nikolaus,

On 06/22/2017 05:41 PM, H. Nikolaus Schaller wrote:
> 
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>>
>> This patchset enables OV9655 camera support.
>>
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>>
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>>
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>> [1].
> 
> Great!
> 
> I will test as soon as possible.
> 

Many thanks for your active review and testing Nikolaus !

>> OV9655 registers sequences come from STM32CubeF7 embedded software [2].
> 
> There is also a preliminary data sheet, e.g. here:
> 
> http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

This is the datasheet I've used for registers naming and signification.

BR,
Hugues.
> 
>>
>> [1] 
>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
>> [2] 
>> https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
>>
>> ===
>> = history =
>> ===
>> version 1:
>>   - Initial submission.
>>
>> H. Nikolaus Schaller (1):
>>   DT bindings: add bindings for ov965x camera module
>>
>> Hugues Fruchet (5):
>>   [media] ov9650: add device tree support
>>   [media] ov9650: select the nearest higher resolution
>>   [media] ov9650: use write_array() for resolution sequences
>>   [media] ov9650: add multiple variant support
>>   [media] ov9650: add support of OV9655 variant
>>
>> .../devicetree/bindings/media/i2c/ov965x.txt   |  37 +
>> drivers/media/i2c/Kconfig  |   6 +-
>> drivers/media/i2c/ov9650.c | 792 
>> +
>> 3 files changed, 704 insertions(+), 131 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>
>> -- 
>> 1.9.1
>>
> 
> BR and thanks,
> Nikolaus Schaller
>

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Hugues FRUCHET

Hi Nikolaus,

On 06/22/2017 05:41 PM, H. Nikolaus Schaller wrote:
> 
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>>
>> This patchset enables OV9655 camera support.
>>
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>>
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>>
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>> [1].
> 
> Great!
> 
> I will test as soon as possible.
> 

Many thanks for your active review and testing Nikolaus !

>> OV9655 registers sequences come from STM32CubeF7 embedded software [2].
> 
> There is also a preliminary data sheet, e.g. here:
> 
> http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

This is the datasheet I've used for registers naming and signification.

BR,
Hugues.
> 
>>
>> [1] 
>> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
>> [2] 
>> https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
>>
>> ===
>> = history =
>> ===
>> version 1:
>>   - Initial submission.
>>
>> H. Nikolaus Schaller (1):
>>   DT bindings: add bindings for ov965x camera module
>>
>> Hugues Fruchet (5):
>>   [media] ov9650: add device tree support
>>   [media] ov9650: select the nearest higher resolution
>>   [media] ov9650: use write_array() for resolution sequences
>>   [media] ov9650: add multiple variant support
>>   [media] ov9650: add support of OV9655 variant
>>
>> .../devicetree/bindings/media/i2c/ov965x.txt   |  37 +
>> drivers/media/i2c/Kconfig  |   6 +-
>> drivers/media/i2c/ov9650.c | 792 
>> +
>> 3 files changed, 704 insertions(+), 131 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
>>
>> -- 
>> 1.9.1
>>
> 
> BR and thanks,
> Nikolaus Schaller
>

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Pavel,

> Am 26.06.2017 um 10:39 schrieb Pavel Machek :
> 
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>> 
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>>> 
>>> Hi!
>>> 
 * unfortunately we still get no image :(
 
 The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
 Image Signal Processor) which
 we were not yet able to solve. Oscilloscoping signals on the interface 
 indicated that signals and
 sync are correct. But we do not know since mplayer only shows a green 
 screen.
>>> 
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>> 
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>> 
>> We did have yet another (non-DT) camera driver and media-ctl working in with 
>> 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. 
>> It
>> is either that the (newer) drivers missing something or the media-ctl has 
>> changed.
>> 
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>> 
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> 
> Ok, so you are using capture, not preview.

Yes.

> 
> You may want to try this one:
> 
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel 
> Date:   Mon Feb 13 21:26:51 2017 +0100
> 
>omap3isp: fix VP2SDR bit so capture (not preview) works
> 
>This is neccessary for capture (not preview) to work properly on
>N900. Why is unknown.

Ah, interesting. I will give it a try.

Do you please have a link to the repo where this commit can be found?

BR and thanks,
Nikolaus

> 
>   Pavel
> 
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>> 
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski 
>> comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>> Capabilities:  video capture  video output  streaming
>> supported norms:
>> inputs: 0 = camera;
>> Current input: 0
>> Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
>> yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
>> 
>> 
>> MPlayer interrupted by signal 2 in module: filter_video
>> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>> 
>> Exiting... (Quit)
>> root@letux:~#
>> 
>> BR and thanks,
>> Nikolaus
>> 
> 
> 
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Pavel,

> Am 26.06.2017 um 10:39 schrieb Pavel Machek :
> 
> On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
>> Hi Pavel,
>> 
>>> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
>>> 
>>> Hi!
>>> 
 * unfortunately we still get no image :(
 
 The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
 Image Signal Processor) which
 we were not yet able to solve. Oscilloscoping signals on the interface 
 indicated that signals and
 sync are correct. But we do not know since mplayer only shows a green 
 screen.
>>> 
>>> What mplayer command line do you use? How did you set up the pipeline
>>> with media-ctl?
>>> 
>>> On kernel.org, I have tree called camera-fw5-6 , where camera works
>>> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
>>> for testing.
>> 
>> We did have yet another (non-DT) camera driver and media-ctl working in with 
>> 3.12.37,
>> but had no success yet to update it to work with modern kernels or drivers. 
>> It
>> is either that the (newer) drivers missing something or the media-ctl has 
>> changed.
>> 
>> Here is the log of our scripts with Hugues' driver and our latest setup:
>> 
>> root@letux:~# ./camera-demo sxga
>> DISPLAY=:0
>> XAUTHORITY=tcp
>> Camera: /dev/v4l-subdev8
>> Setting mode sxga
>> media-ctl -r
>> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
>> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
>> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
>> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
> 
> Ok, so you are using capture, not preview.

Yes.

> 
> You may want to try this one:
> 
> commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
> Author: Pavel 
> Date:   Mon Feb 13 21:26:51 2017 +0100
> 
>omap3isp: fix VP2SDR bit so capture (not preview) works
> 
>This is neccessary for capture (not preview) to work properly on
>N900. Why is unknown.

Ah, interesting. I will give it a try.

Do you please have a link to the repo where this commit can be found?

BR and thanks,
Nikolaus

> 
>   Pavel
> 
>> ### starting mplayer in sxga mode ###
>> mplayer tv:// -vf rotate=2 -tv 
>> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
>> x11
>> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
>> 
>> Playing tv://.
>> Detected file format: TV
>> Selected driver: v4l2
>> name: Video 4 Linux 2 input
>> author: Martin Olschewski 
>> comment: first try, more to come ;-)
>> v4l2: ioctl get standard failed: Invalid argument
>> Selected device: OMAP3 ISP CCDC output
>> Capabilities:  video capture  video output  streaming
>> supported norms:
>> inputs: 0 = camera;
>> Current input: 0
>> Current format: unknown (0x0)
>> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
>> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
>> Error: Cannot set norm!
>> Selected input hasn't got a tuner!
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl query control failed: Inappropriate ioctl for device
>> v4l2: ioctl streamon failed: Broken pipe
>> [ass] auto-open
>> Opening video filter: [rotate=2]
>> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
>> Could not find matching colorspace - retrying with -vf scale...
>> Opening video filter: [scale]
>> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
>> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
>> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
>> yuv420p to bgra.
>> Colorspace details not fully supported by selected vo.
>> Selected video codec: RAW UYVY [raw]
>> Audio: no sound
>> Starting playback...
>> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
>> 
>> 
>> MPlayer interrupted by signal 2 in module: filter_video
>> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
>> v4l2: ioctl set mute failed: Inappropriate ioctl for device
>> v4l2: 0 frames successfully processed, 0 frames dropped.
>> 
>> Exiting... (Quit)
>> root@letux:~#
>> 
>> BR and thanks,
>> Nikolaus
>> 
> 
> 
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Pavel Machek

On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
> Hi Pavel,
> 
> > Am 25.06.2017 um 11:18 schrieb Pavel Machek :
> > 
> > Hi!
> > 
> >> * unfortunately we still get no image :(
> >> 
> >> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
> >> Image Signal Processor) which
> >> we were not yet able to solve. Oscilloscoping signals on the interface 
> >> indicated that signals and
> >> sync are correct. But we do not know since mplayer only shows a green 
> >> screen.
> > 
> > What mplayer command line do you use? How did you set up the pipeline
> > with media-ctl?
> > 
> > On kernel.org, I have tree called camera-fw5-6 , where camera works
> > for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> > for testing.
> 
> We did have yet another (non-DT) camera driver and media-ctl working in with 
> 3.12.37,
> but had no success yet to update it to work with modern kernels or drivers. It
> is either that the (newer) drivers missing something or the media-ctl has 
> changed.
> 
> Here is the log of our scripts with Hugues' driver and our latest setup:
> 
> root@letux:~# ./camera-demo sxga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'

Ok, so you are using capture, not preview.

You may want to try this one:

commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
Author: Pavel 
Date:   Mon Feb 13 21:26:51 2017 +0100

omap3isp: fix VP2SDR bit so capture (not preview) works

This is neccessary for capture (not preview) to work properly on
N900. Why is unknown.

Pavel

> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument
> Selected device: OMAP3 ISP CCDC output
>  Capabilities:  video capture  video output  streaming
>  supported norms:
>  inputs: 0 = camera;
>  Current input: 0
>  Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
> Error: Cannot set norm!
> Selected input hasn't got a tuner!
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl streamon failed: Broken pipe
> [ass] auto-open
> Opening video filter: [rotate=2]
> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
> yuv420p to bgra.
> Colorspace details not fully supported by selected vo.
> Selected video codec: RAW UYVY [raw]
> Audio: no sound
> Starting playback...
> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
> 
> 
> MPlayer interrupted by signal 2 in module: filter_video
> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: 0 frames successfully processed, 0 frames dropped.
> 
> Exiting... (Quit)
> root@letux:~#
> 
> BR and thanks,
> Nikolaus
> 



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread Pavel Machek

On Mon 2017-06-26 08:05:04, H. Nikolaus Schaller wrote:
> Hi Pavel,
> 
> > Am 25.06.2017 um 11:18 schrieb Pavel Machek :
> > 
> > Hi!
> > 
> >> * unfortunately we still get no image :(
> >> 
> >> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
> >> Image Signal Processor) which
> >> we were not yet able to solve. Oscilloscoping signals on the interface 
> >> indicated that signals and
> >> sync are correct. But we do not know since mplayer only shows a green 
> >> screen.
> > 
> > What mplayer command line do you use? How did you set up the pipeline
> > with media-ctl?
> > 
> > On kernel.org, I have tree called camera-fw5-6 , where camera works
> > for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> > for testing.
> 
> We did have yet another (non-DT) camera driver and media-ctl working in with 
> 3.12.37,
> but had no success yet to update it to work with modern kernels or drivers. It
> is either that the (newer) drivers missing something or the media-ctl has 
> changed.
> 
> Here is the log of our scripts with Hugues' driver and our latest setup:
> 
> root@letux:~# ./camera-demo sxga
> DISPLAY=:0
> XAUTHORITY=tcp
> Camera: /dev/v4l-subdev8
> Setting mode sxga
> media-ctl -r
> media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
> media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
> media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
> media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'

Ok, so you are using capture, not preview.

You may want to try this one:

commit 0eae9d2a8f096f703cbc8f9a0ab155cd3cc14cef
Author: Pavel 
Date:   Mon Feb 13 21:26:51 2017 +0100

omap3isp: fix VP2SDR bit so capture (not preview) works

This is neccessary for capture (not preview) to work properly on
N900. Why is unknown.

Pavel

> ### starting mplayer in sxga mode ###
> mplayer tv:// -vf rotate=2 -tv 
> driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo 
> x11
> MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team
> 
> Playing tv://.
> Detected file format: TV
> Selected driver: v4l2
>  name: Video 4 Linux 2 input
>  author: Martin Olschewski 
>  comment: first try, more to come ;-)
> v4l2: ioctl get standard failed: Invalid argument
> Selected device: OMAP3 ISP CCDC output
>  Capabilities:  video capture  video output  streaming
>  supported norms:
>  inputs: 0 = camera;
>  Current input: 0
>  Current format: unknown (0x0)
> tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
> v4l2: ioctl enum norm failed: Inappropriate ioctl for device
> Error: Cannot set norm!
> Selected input hasn't got a tuner!
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl query control failed: Inappropriate ioctl for device
> v4l2: ioctl streamon failed: Broken pipe
> [ass] auto-open
> Opening video filter: [rotate=2]
> VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> [swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
> VO: [x11] 1024x1280 => 1024x1280 Planar YV12
> [swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from 
> yuv420p to bgra.
> Colorspace details not fully supported by selected vo.
> Selected video codec: RAW UYVY [raw]
> Audio: no sound
> Starting playback...
> V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>
> 
> 
> MPlayer interrupted by signal 2 in module: filter_video
> V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
> v4l2: ioctl set mute failed: Inappropriate ioctl for device
> v4l2: 0 frames successfully processed, 0 frames dropped.
> 
> Exiting... (Quit)
> root@letux:~#
> 
> BR and thanks,
> Nikolaus
> 



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
> 
> Hi!
> 
>> * unfortunately we still get no image :(
>> 
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
>> Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface 
>> indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green screen.
> 
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
> 
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

We did have yet another (non-DT) camera driver and media-ctl working in with 
3.12.37,
but had no success yet to update it to work with modern kernels or drivers. It
is either that the (newer) drivers missing something or the media-ctl has 
changed.

Here is the log of our scripts with Hugues' driver and our latest setup:

root@letux:~# ./camera-demo sxga
DISPLAY=:0
XAUTHORITY=tcp
Camera: /dev/v4l-subdev8
Setting mode sxga
media-ctl -r
media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
### starting mplayer in sxga mode ###
mplayer tv:// -vf rotate=2 -tv 
driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team

Playing tv://.
Detected file format: TV
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski 
 comment: first try, more to come ;-)
v4l2: ioctl get standard failed: Invalid argument
Selected device: OMAP3 ISP CCDC output
 Capabilities:  video capture  video output  streaming
 supported norms:
 inputs: 0 = camera;
 Current input: 0
 Current format: unknown (0x0)
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Inappropriate ioctl for device
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl streamon failed: Broken pipe
[ass] auto-open
Opening video filter: [rotate=2]
VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
[swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
VO: [x11] 1024x1280 => 1024x1280 Planar YV12
[swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p 
to bgra.
Colorspace details not fully supported by selected vo.
Selected video codec: RAW UYVY [raw]
Audio: no sound
Starting playback...
V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>


MPlayer interrupted by signal 2 in module: filter_video
V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: 0 frames successfully processed, 0 frames dropped.

Exiting... (Quit)
root@letux:~#

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Pavel,

> Am 25.06.2017 um 11:18 schrieb Pavel Machek :
> 
> Hi!
> 
>> * unfortunately we still get no image :(
>> 
>> The latter is likely a setup issue of our camera interface (OMAP3 ISP = 
>> Image Signal Processor) which
>> we were not yet able to solve. Oscilloscoping signals on the interface 
>> indicated that signals and
>> sync are correct. But we do not know since mplayer only shows a green screen.
> 
> What mplayer command line do you use? How did you set up the pipeline
> with media-ctl?
> 
> On kernel.org, I have tree called camera-fw5-6 , where camera works
> for me on n900. On gitlab, there's modifed fcam-dev, which can be used
> for testing.

We did have yet another (non-DT) camera driver and media-ctl working in with 
3.12.37,
but had no success yet to update it to work with modern kernels or drivers. It
is either that the (newer) drivers missing something or the media-ctl has 
changed.

Here is the log of our scripts with Hugues' driver and our latest setup:

root@letux:~# ./camera-demo sxga
DISPLAY=:0
XAUTHORITY=tcp
Camera: /dev/v4l-subdev8
Setting mode sxga
media-ctl -r
media-ctl -l '"ov965x":0 -> "OMAP3 ISP CCDC":0[1]'
media-ctl -l '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0[1]'
media-ctl -V '"ov965x":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":0 [UYVY2X8 1280x1024]'
media-ctl -V '"OMAP3 ISP CCDC":1 [UYVY 1280x1024]'
### starting mplayer in sxga mode ###
mplayer tv:// -vf rotate=2 -tv 
driver=v4l2:device=/dev/video2:outfmt=uyvy:width=1280:height=1024:fps=15 -vo x11
MPlayer2 2.0-728-g2c378c7-4+b1 (C) 2000-2012 MPlayer Team

Playing tv://.
Detected file format: TV
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski 
 comment: first try, more to come ;-)
v4l2: ioctl get standard failed: Invalid argument
Selected device: OMAP3 ISP CCDC output
 Capabilities:  video capture  video output  streaming
 supported norms:
 inputs: 0 = camera;
 Current input: 0
 Current format: unknown (0x0)
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Inappropriate ioctl for device
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl query control failed: Inappropriate ioctl for device
v4l2: ioctl streamon failed: Broken pipe
[ass] auto-open
Opening video filter: [rotate=2]
VIDEO:  1280x1024  15.000 fps0.0 kbps ( 0.0 kB/s)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
[swscaler @ 0xb5ca9980]using unscaled uyvy422 -> yuv420p special converter
VO: [x11] 1024x1280 => 1024x1280 Planar YV12
[swscaler @ 0xb5ca9980]No accelerated colorspace conversion found from yuv420p 
to bgra.
Colorspace details not fully supported by selected vo.
Selected video codec: RAW UYVY [raw]
Audio: no sound
Starting playback...
V:   0.0  10/ 10 ??% ??% ??,?% 0 0 $<3>


MPlayer interrupted by signal 2 in module: filter_video
V:   0.0  11/ 11 ??% ??% ??,?% 0 0 $<3>
v4l2: ioctl set mute failed: Inappropriate ioctl for device
v4l2: 0 frames successfully processed, 0 frames dropped.

Exiting... (Quit)
root@letux:~#

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller :
> 
> Hi Hugues,
> 
>> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller :
>> 
>> 
>>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>>> 
>>> This patchset enables OV9655 camera support.
>>> 
>>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>>> plugged on connector P1 of STM32F746G-DISCO board.
>>> Due to lack of OV9650/52 hardware support, the modified related code
>>> could not have been checked for non-regression.
>>> 
>>> First patches upgrade current support of OV9650/52 to prepare then
>>> introduction of OV9655 variant patch.
>>> Because of OV9655 register set slightly different from OV9650/9652,
>>> not all of the driver features are supported (controls). Supported
>>> resolutions are limited to VGA, QVGA, QQVGA.
>>> Supported format is limited to RGB565.
>>> Controls are limited to color bar test pattern for test purpose.
>>> 
>>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>>> [1].
>> 
>> Great!
> 
> Thanks again for picking up or work and trying to get it upstream.
> 
>> 
>> I will test as soon as possible.

Here are some more test results and fixes:

> 
> I have tried and had to fix some issues first:
> * gpio properties have a different name than in our approach (but that is 
> something maintainers have to decide and is easy to follow this or that way)
> * there is no clock-frequency property which makes the driver request a clock 
> frequency (something our camera interface expects this way)

This can indeed be replaced by assigned-clock-rates and no additional
driver code. So there is no need to implement anything new here.

> * there is no vana-supply regulator and we need that to power on/off the 
> camera on demand (reset and pwdn isn't enough in our hardware)

this is something we still need to have added by patch



> * for some unknown reason the driver does not load automatically from DT 
> compatibility string and needs to be explicitly modprobed

This turned out to be because the i2c device ids are upper case while 
compatible-strings
are lower-case. See comment for patch 6/6.

BR and looking forward to v2,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-26 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 23.06.2017 um 12:25 schrieb H. Nikolaus Schaller :
> 
> Hi Hugues,
> 
>> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller :
>> 
>> 
>>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>>> 
>>> This patchset enables OV9655 camera support.
>>> 
>>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>>> plugged on connector P1 of STM32F746G-DISCO board.
>>> Due to lack of OV9650/52 hardware support, the modified related code
>>> could not have been checked for non-regression.
>>> 
>>> First patches upgrade current support of OV9650/52 to prepare then
>>> introduction of OV9655 variant patch.
>>> Because of OV9655 register set slightly different from OV9650/9652,
>>> not all of the driver features are supported (controls). Supported
>>> resolutions are limited to VGA, QVGA, QQVGA.
>>> Supported format is limited to RGB565.
>>> Controls are limited to color bar test pattern for test purpose.
>>> 
>>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>>> [1].
>> 
>> Great!
> 
> Thanks again for picking up or work and trying to get it upstream.
> 
>> 
>> I will test as soon as possible.

Here are some more test results and fixes:

> 
> I have tried and had to fix some issues first:
> * gpio properties have a different name than in our approach (but that is 
> something maintainers have to decide and is easy to follow this or that way)
> * there is no clock-frequency property which makes the driver request a clock 
> frequency (something our camera interface expects this way)

This can indeed be replaced by assigned-clock-rates and no additional
driver code. So there is no need to implement anything new here.

> * there is no vana-supply regulator and we need that to power on/off the 
> camera on demand (reset and pwdn isn't enough in our hardware)

this is something we still need to have added by patch



> * for some unknown reason the driver does not load automatically from DT 
> compatibility string and needs to be explicitly modprobed

This turned out to be because the i2c device ids are upper case while 
compatible-strings
are lower-case. See comment for patch 6/6.

BR and looking forward to v2,
Nikolaus

omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-25 Thread Pavel Machek

Hi!

> * unfortunately we still get no image :(
> 
> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image 
> Signal Processor) which
> we were not yet able to solve. Oscilloscoping signals on the interface 
> indicated that signals and
> sync are correct. But we do not know since mplayer only shows a green screen.

What mplayer command line do you use? How did you set up the pipeline
with media-ctl?

On kernel.org, I have tree called camera-fw5-6 , where camera works
for me on n900. On gitlab, there's modifed fcam-dev, which can be used
for testing.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

omap3isp camera was Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-25 Thread Pavel Machek

Hi!

> * unfortunately we still get no image :(
> 
> The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image 
> Signal Processor) which
> we were not yet able to solve. Oscilloscoping signals on the interface 
> indicated that signals and
> sync are correct. But we do not know since mplayer only shows a green screen.

What mplayer command line do you use? How did you set up the pipeline
with media-ctl?

On kernel.org, I have tree called camera-fw5-6 , where camera works
for me on n900. On gitlab, there's modifed fcam-dev, which can be used
for testing.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-23 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller :
> 
> 
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>> 
>> This patchset enables OV9655 camera support.
>> 
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>> 
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>> 
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>> [1].
> 
> Great!

Thanks again for picking up or work and trying to get it upstream.

> 
> I will test as soon as possible.

I have tried and had to fix some issues first:
* gpio properties have a different name than in our approach (but that is 
something maintainers have to decide and is easy to follow this or that way)
* there is no clock-frequency property which makes the driver request a clock 
frequency (something our camera interface expects this way)
* there is no vana-supply regulator and we need that to power on/off the camera 
on demand (reset and pwdn isn't enough in our hardware)
* for some unknown reason the driver does not load automatically from DT 
compatibility string and needs to be explicitly modprobed
* unfortunately we still get no image :(

The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image 
Signal Processor) which
we were not yet able to solve. Oscilloscoping signals on the interface 
indicated that signals and
sync are correct. But we do not know since mplayer only shows a green screen.

Therefore we had not submitted anything upstream ourselves, because our driver 
setup
isn't finished and completely working.

I have written some more specific comments linked to proposals for patches as 
answer to your [PATCH v1 1/6]

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-23 Thread H. Nikolaus Schaller

Hi Hugues,

> Am 22.06.2017 um 17:41 schrieb H. Nikolaus Schaller :
> 
> 
>> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
>> 
>> This patchset enables OV9655 camera support.
>> 
>> OV9655 support has been tested using STM32F4DIS-CAM extension board
>> plugged on connector P1 of STM32F746G-DISCO board.
>> Due to lack of OV9650/52 hardware support, the modified related code
>> could not have been checked for non-regression.
>> 
>> First patches upgrade current support of OV9650/52 to prepare then
>> introduction of OV9655 variant patch.
>> Because of OV9655 register set slightly different from OV9650/9652,
>> not all of the driver features are supported (controls). Supported
>> resolutions are limited to VGA, QVGA, QQVGA.
>> Supported format is limited to RGB565.
>> Controls are limited to color bar test pattern for test purpose.
>> 
>> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
>> [1].
> 
> Great!

Thanks again for picking up or work and trying to get it upstream.

> 
> I will test as soon as possible.

I have tried and had to fix some issues first:
* gpio properties have a different name than in our approach (but that is 
something maintainers have to decide and is easy to follow this or that way)
* there is no clock-frequency property which makes the driver request a clock 
frequency (something our camera interface expects this way)
* there is no vana-supply regulator and we need that to power on/off the camera 
on demand (reset and pwdn isn't enough in our hardware)
* for some unknown reason the driver does not load automatically from DT 
compatibility string and needs to be explicitly modprobed
* unfortunately we still get no image :(

The latter is likely a setup issue of our camera interface (OMAP3 ISP = Image 
Signal Processor) which
we were not yet able to solve. Oscilloscoping signals on the interface 
indicated that signals and
sync are correct. But we do not know since mplayer only shows a green screen.

Therefore we had not submitted anything upstream ourselves, because our driver 
setup
isn't finished and completely working.

I have written some more specific comments linked to proposals for patches as 
answer to your [PATCH v1 1/6]

BR and thanks,
Nikolaus

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-22 Thread H. Nikolaus Schaller


> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
> 
> This patchset enables OV9655 camera support.
> 
> OV9655 support has been tested using STM32F4DIS-CAM extension board
> plugged on connector P1 of STM32F746G-DISCO board.
> Due to lack of OV9650/52 hardware support, the modified related code
> could not have been checked for non-regression.
> 
> First patches upgrade current support of OV9650/52 to prepare then
> introduction of OV9655 variant patch.
> Because of OV9655 register set slightly different from OV9650/9652,
> not all of the driver features are supported (controls). Supported
> resolutions are limited to VGA, QVGA, QQVGA.
> Supported format is limited to RGB565.
> Controls are limited to color bar test pattern for test purpose.
> 
> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
> [1].

Great!

I will test as soon as possible.

> OV9655 registers sequences come from STM32CubeF7 embedded software [2].

There is also a preliminary data sheet, e.g. here:

http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

> 
> [1] 
> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
> [2] 
> https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
> 
> ===
> = history =
> ===
> version 1:
>  - Initial submission.
> 
> H. Nikolaus Schaller (1):
>  DT bindings: add bindings for ov965x camera module
> 
> Hugues Fruchet (5):
>  [media] ov9650: add device tree support
>  [media] ov9650: select the nearest higher resolution
>  [media] ov9650: use write_array() for resolution sequences
>  [media] ov9650: add multiple variant support
>  [media] ov9650: add support of OV9655 variant
> 
> .../devicetree/bindings/media/i2c/ov965x.txt   |  37 +
> drivers/media/i2c/Kconfig  |   6 +-
> drivers/media/i2c/ov9650.c | 792 +
> 3 files changed, 704 insertions(+), 131 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
> 
> -- 
> 1.9.1
> 

BR and thanks,
Nikolaus Schaller

Re: [PATCH v1 0/6] Add support of OV9655 camera

2017-06-22 Thread H. Nikolaus Schaller


> Am 22.06.2017 um 17:05 schrieb Hugues Fruchet :
> 
> This patchset enables OV9655 camera support.
> 
> OV9655 support has been tested using STM32F4DIS-CAM extension board
> plugged on connector P1 of STM32F746G-DISCO board.
> Due to lack of OV9650/52 hardware support, the modified related code
> could not have been checked for non-regression.
> 
> First patches upgrade current support of OV9650/52 to prepare then
> introduction of OV9655 variant patch.
> Because of OV9655 register set slightly different from OV9650/9652,
> not all of the driver features are supported (controls). Supported
> resolutions are limited to VGA, QVGA, QQVGA.
> Supported format is limited to RGB565.
> Controls are limited to color bar test pattern for test purpose.
> 
> OV9655 initial support is based on a driver written by H. Nikolaus Schaller 
> [1].

Great!

I will test as soon as possible.

> OV9655 registers sequences come from STM32CubeF7 embedded software [2].

There is also a preliminary data sheet, e.g. here:

http://electricstuff.co.uk/OV9655-datasheet-annotated.pdf

> 
> [1] 
> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/video/ov9655
> [2] 
> https://developer.mbed.org/teams/ST/code/BSP_DISCO_F746NG/file/e1d9da7fe856/Drivers/BSP/Components/ov9655/ov9655.c
> 
> ===
> = history =
> ===
> version 1:
>  - Initial submission.
> 
> H. Nikolaus Schaller (1):
>  DT bindings: add bindings for ov965x camera module
> 
> Hugues Fruchet (5):
>  [media] ov9650: add device tree support
>  [media] ov9650: select the nearest higher resolution
>  [media] ov9650: use write_array() for resolution sequences
>  [media] ov9650: add multiple variant support
>  [media] ov9650: add support of OV9655 variant
> 
> .../devicetree/bindings/media/i2c/ov965x.txt   |  37 +
> drivers/media/i2c/Kconfig  |   6 +-
> drivers/media/i2c/ov9650.c | 792 +
> 3 files changed, 704 insertions(+), 131 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov965x.txt
> 
> -- 
> 1.9.1
> 

BR and thanks,
Nikolaus Schaller

38 matches

Mail list logo