Hans Verkuil wrote:
Situation 1
- Instance1: Select sensor 1, and Do queue/dequeue of buffers.
- Instance2: If sensor 1 is currently selected, Begin loop requesting
internally collected OMAP3ISP statistics (with V4L2 private based IOCTLs)
for performing user-side Auto-exposure, Auto White Balance, Auto Focus
algorithms. And Adjust gains (with S_CTRL) accordingly on sensor as a
result.
Question: if you have multiple sensors, and sensor 1 is selected, can you
still get statistics from sensor 2? Or is all this still limited to the
selected sensor? Just want to make sure I understand it all.
The ISP does have submodules and there are some ways of configuring the
data path inside the ISP, but in general just one sensor can be used at
a time in meaningful way.
Sergio, please correct me if I'm wrong: the only case I know that you
can do is to use the ISP normally (data flowing through pretty much all
the ISP modules) with one sensor and write the output of another sensor
directly to memory in one of the parallel/CCP2/CSI2 receivers.
I guess there's no use case for this, however. So just one user at a
time for the OMAP 3 ISP.
Another thing comes to my mind, though.
Sergio has posted earlier a patchset containing a driver for using the
ISP to process images from memory to memory. The ISP driver is used
roughly the same way as with the omap34xxcam and real sensors. The
interface towards the userspace offered by the driver, however, is
different, you probably saw it (preview and resizer wrappers).
My opinion has been that the memory-to-memory operation of the ISP
should also offer V4L2 interface. V4L2, however, doesn't support such
devices at the moment. The only differences that I can see is that
1. the input is a video buffer instead of sensor and
2. the source format needs to be specified somehow since the ISP can
also do format conversion. So it's output and input at the same time.
But if we had one video device per ISP, then memory-to-memory operation
would be just one... input or output or what? :)
Earlier we were thinking of creating one device node for it.
That is probably what the driver should do, yes. The V4L2 spec leaves it up
to the driver whether you can switch inputs while a capture is in progress.
In this case I think it is perfectly reasonably for the driver to
return -EBUSY.
Ok.
I'm not clear if this single-node idea is really helping the user to have
a simpler usage in Situation 1, which I feel will become pretty common on
this driver...
The spec is pretty clear about this, and existing v4l2 applications also
expect this behavior. Also, suppose you have two video nodes, what happens
when you want to use the inactive node? How can you tell it is inactive?
open() succeeds.
Currently you can have just one device node using the ISP open.
omap34xxcam_open() calls isp_get() which fails if the ISP use count was
non-zero (means one).
Or did I misunderstood something?
--
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
