RE: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Mauro

Thank you for your suggestion on this.

Now I have another problem. The ISP needs the following parameters of the sensor to set the acquisition interface, but I can not find a suitable subdev ioctls to get them from sensor driver. 

bus_width; width of the buss connecting sensor and ISP.
field_sel; field selection, even or odd.
ycseq; YCbCr sequence, YCbCr or YCrCb or CbYCrY or CrYCbY
conv422; subsampling type, co-sited 4:4:4 or non-cosited 4:4:4 or color interpolation
bpat; bayer sampling sequence, RGRG GBGB or GRGR BGBG or ...
hpol; horizontal sync polarity
vpol; vertical sync polarity
edge; sampling edge

Best Regards
Jinlu Yu
UMG UPSG PRC
INET: 8758 1603
TEL:  86 10 8217 1603
FAX:  86 10 8286 1400
-----Original Message-----
From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxxxxx] 
Sent: 2009年9月24日 19:45
To: Yu, Jinlu
Cc: linux-media@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 0/5] V4L2 patches for Intel Moorestown Camera Imaging

Em Thu, 24 Sep 2009 19:21:40 +0800
"Yu, Jinlu" <jinlu.yu@xxxxxxxxx> escreveu:

> Hi, Hans/Guennadi
> 
> I am modifying these drivers to comply with v4l2 framework. I have finished replacing our buffer managing code with utility function from videobuf-core.c and videobuf-dma-contig.c. Now I am working on the subdev. One thing I am sure is that each sensor should be registered as a v4l2_subdev and ISP (Image Signal Processor) is registered as a v4l2_device acting as the bridge device. 
> 
> But we have two ways to deal with the relationship of sensor and ISP, and we don't know which one is better. Could you help me on this?
> 
> No.1. Register the ISP as a video_device (/dev/video0) and treat each of the sensor (SOC and RAW) as an input of the ISP. If I want to change the sensor, use the VIDIOC_S_INPUT to change input from sensor A to sensor B. But I have a concern about this ioctl. Since I didn't find any code related HW pipeline status checking and HW register setting in the implement of this ioctl (e.g. vino_s_input in /drivers/media/video/vino.c). So don't I have to stream-off the HW pipeline and change the HW register setting for the new input? Or is it application's responsibility to stream-off the pipeline and renegotiate the parameters for the new input?
> 
> No.2. Combine the SOC sensor together with the ISP as Channel One and register it as /dev/video0, and combine the RAW sensor together with the ISP as Channel Two and register it as /dev/video1. Surely, only one channel works at a certain time due to HW restriction. When I want to change the sensor (e.g. from SOC sensor to RAW sensor), just close /dev/video0 and open /dev/video1.

The better seems to be No. 1. As you need to re-negotiate parameters for
switching from one sensor to another, if some app tries to change from one
input to another while streaming, you should just return -EBUSY, if it is not
possible to switch (for example, if the selected format/resolution/frame rate
is incompatible).



Cheers,
Mauro
?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?{?夸z罐?+€?zf"?????i?????_璁?:+v??撸?


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux