013/11/3 Sebastian Reichel :
> Hi,
>
> This is an early RFC for omap3isp DT support. For now i just created a
> potential DT
> binding documentation based on the existing platform data:
>
> Binding for the OMAP3 Camera subsystem with the image signal processor (ISP)
> feature.
>
This is very int
Hi Laurent,
I was able to reliably get corrupted image when placing the pipeline in underrun
condition. The pipeline looks like this :
YUYV sensor -> CCDC -> Resizer -> V4L output
It seems that triggering 'frame sync event' before last line leads to
possible corrupted images
when using the resiz
It is my understanding that you should set up the format with
media-ctl, and only check
the result in your application. In other words, using G/S/TRY_FMT
ioctl on the video output
nodes won't work.
You can try the following pipeline :
ov3640 -> ccdc -> previewer -> previewer V4L2 output
and set p
2013/6/5 Guennadi Liakhovetski :
> Hi Phil
>
> Thanks for the patch. I'll look at it in more detail hopefully soon
> enough... One remark so far to Jean-Philippe's comment:
>
> On Tue, 4 Jun 2013, jean-philippe francois wrote:
>
>> 2013/6/3 Phil Edworth
2013/6/3 Phil Edworthy :
> Signed-off-by: Phil Edworthy
> ---
> v2:
> - Simplified flow in ov10635_s_ctrl.
> - Removed chip ident code - build tested only
>
> drivers/media/i2c/soc_camera/Kconfig |6 +
> drivers/media/i2c/soc_camera/Makefile |1 +
> drivers/media/i2c/soc_camera/ov106
2013/5/16 Laurent Pinchart :
> Hi Jean-Philippe,
>
> On Thursday 16 May 2013 10:21:14 jean-philippe francois wrote:
>> 2013/5/15 jean-philippe francois :
>> > Hi,
>> >
>> > I am working on a dm3730 based camera.
>> > The sensor input clock is pro
2013/5/15 jean-philippe francois :
> Hi,
>
> I am working on a dm3730 based camera.
> The sensor input clock is provided by the cpu via the CAM_XCLK pin.
> Here is the corresponding log :
>
> [9.115966] Entering cam_set_xclk
> [9.119781] omap3isp omap3isp: isp_set_
2013/5/15 jean-philippe francois :
> Hi,
>
> I am working on a dm3730 based camera.
> The sensor input clock is provided by the cpu via the CAM_XCLK pin.
> Here is the corresponding log :
>
> [9.115966] Entering cam_set_xclk
> [9.119781] omap3isp omap3isp: isp_set_
around 30 MHz
The crystal clock is 19.2 MHz
All this was correct with 3.6.11.
Jean-Philippe Francois
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
now any kernel tree
where isp is initialized for beagle board ?
Thank you,
Jean-Philippe François
2013/5/7 jean-philippe francois :
> 2013/5/7 Laurent Pinchart :
>> Hi Jean-Philippe,
>>
>> (CC'ed linux-omap)
>>
>> On Monday 06 May 2013 10:59:07 jean-phil
2013/5/7 Laurent Pinchart :
> Hi Jean-Philippe,
>
> (CC'ed linux-omap)
>
> On Monday 06 May 2013 10:59:07 jean-philippe francois wrote:
>> Hi,
>>
>> I am trying to use the previewer to debayer pictures coming from the
>> filesystem instead of the
Hi,
I am trying to use the previewer to debayer pictures coming from the
filesystem instead of the capture hardware. The media-ctl links are as
follows :
preview V4L input -> preview pad 0 (sink), preview pad 1(src)
->preview V4L output.
Input output format is set via media-ctl for the preview e
I know that it is still a workaround but I hope that maybe it will help
>> someone to understand the real cause of this issue.
>
> Do you get CCDC stop timeouts ? They are reported in the kernel log as "CCDC
> stop timeout!".
>
>> Le 13/12/2012 15:14, jean-philipp
Hi,
I have news on the "IRQ storm on second streamon" problem.
Reminder :
Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the
omap3-isp (at least until 3.4) will go into an interrupt storm when
streamon is called for the second time, unless you are able to stop
the sensor when not
2012/7/6 Laurent Pinchart :
> Hi everybody,
>
> Here's the second version of the non-GRBG Bayer patterns support for the OMAP3
> ISP preview engine. Compared to v1, the CFA table can be reconfigured at
> runtime, which resulted in several cleanup patches.
>
> The first patch is a v3.5 regression fi
2012/6/22 Laurent Pinchart :
> Hi Jean-Philippe,
>
> On Thursday 21 June 2012 15:35:52 jean-philippe francois wrote:
>> 2012/6/18 Laurent Pinchart :
>> > Rearrange the CFA interpolation coefficients table based on the Bayer
>> > pattern. Modifying the table during
2012/6/18 Laurent Pinchart :
> Rearrange the CFA interpolation coefficients table based on the Bayer
> pattern. Modifying the table during streaming isn't supported anymore,
> but didn't make sense in the first place anyway.
>
> Support for non-Bayer CFA patterns is dropped as they were not correct
2012/5/29 Laurent Pinchart :
> Hi Jean-Philippe,
>
> On Tuesday 29 May 2012 10:24:45 jean-philippe francois wrote:
>> Hi,
>>
>> omap3 ISP previewer block can convert a raw bayer image into a UYVY image.
>> Debayering coefficient are stored in an undocumented ta
Hi,
omap3 ISP previewer block can convert a raw bayer image
into a UYVY image. Debayering coefficient are stored in
an undocumented table. In the current form, only
GRBG format are converted correctly.
However, the other CFA arrangement can be transformed
in GRBG arrangement by shifting the image
2012/5/29 Alex Gershgorin :
>
> Hi Ritesh,
>
> Please send in the future CC to laurent.pinch...@ideasonboard.com and
> linux-media@vger.kernel.org
>
>> Hi Alex,
>> I also started working with OMAP35x torpedo kit, I successful compile Linux
>> 3.0 and ported on the board.
>> Device is booting corr
Hi,
omap3 ISP previewer block can convert a raw bayer image
into a UYVY image. Debayering coefficient are stored in
an undocumented table. In the current form, only
GRBG format are converted correctly.
However, the other CFA arrangement can be transformed
in GRBG arrangement by shifting the image
2012/5/2 Sergio Aguirre :
> This adds a very limited driver for ov5640, which
> only supports:
> - 2592x1944 @ ~7.5 fps
> - 1920x1080 @ ~15 fps,
> - 1280x720 @ ~24 fps,
> - 640x480 @ ~24 fps,
> - 320x240 @ ~24 fps,
>
> All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
>
There is already
Hi,
I am trying to get a working preview from a CMOS
sensor with a CFA bayer pattern.
Does the CCDC_COLPTN register have any effect on
previewer CFA interpolation ?
>From my experience it does not. I can set BGGR or GRBG,
but the output is always the same. When doing raw capture,
I get nice imag
subdev_pad_ops and video_ops both contains operation related
to format, crop and bus format.
When should one or the other be used ?
For example mt9p031 implement everything using pad_ops, but other drivers
use video_ops functions.
--
To unsubscribe from this list: send the line "unsubscribe linux-
Le 26 mars 2012 18:32, Gary Thomas a écrit :
> On 2012-03-26 09:37, Joshua Hintze wrote:
>>
>> Gary,
>>
>> I'm using linux branch from 2.6.39
>>
>> Fetch URL: git://www.sakoman.com/git/linux-omap-2.6
>> branch: omap-2.6.39
>>
>> I'm using an overo board so I figured I should follow Steve Sakoman's
Le 11 mars 2012 10:04, Sakari Ailus a écrit :
> Hi François,
>
> On Thu, Mar 08, 2012 at 04:06:34PM +0100, jean-philippe francois wrote:
>> Le 8 mars 2012 14:57, Sakari Ailus a écrit :
>> > Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as
>>
>> Thank you, I will try this and keep you posted.
>> With this sensor it is possible, but that is not the case for every
>> sensor out there.
>> Is this an ISP bug ?
>
> From my experience, the ISP doesn't handle free-running sensors very well.
> There are other things it doesn't handle well, such
Le 9 mars 2012 00:28, Laurent Pinchart
a écrit :
> On Thursday 08 March 2012 19:22:53 Sakari Ailus wrote:
>> On Wed, Mar 07, 2012 at 03:24:29PM +0100, jean-philippe francois wrote:
>> > Le 6 mars 2012 18:08, jean-philippe francois a
> écrit :
>> > > Hi,
>>
Le 8 mars 2012 14:57, Sakari Ailus a écrit :
> Add driver for SMIA++/SMIA image sensors. The driver exposes the sensor as
> three subdevs, pixel array, binner and scaler --- in case the device has a
> scaler.
>
> Currently it relies on the board code for external clock handling. There is
> no fast
Le 6 mars 2012 18:08, jean-philippe francois a écrit :
> Hi,
>
> I have a custom dm3730 board, running a 3.2.0 kernel.
> The board is equipped with an aptina MT9J sensor on
> parallel interface.
>
> Whenever I try to run yavta twice, the second run leads
Hi,
I have a custom dm3730 board, running a 3.2.0 kernel.
The board is equipped with an aptina MT9J sensor on
parallel interface.
Whenever I try to run yavta twice, the second run leads to a
soft lockup in omap3isp_video_queue_streamon (see below)
What can I do / test to debug this issue ?
# g
31 matches
Mail list logo
