Le vendredi 18 mai 2018 à 16:37 +0100, Dave Stevenson a écrit : > On 18 May 2018 at 16:05, Mauro Carvalho Chehab > <mchehab+samsung@xxxxxxxxxx> wrote: > > Em Fri, 18 May 2018 15:27:24 +0300 > > <snip> > > > > > > > There, instead of an USB camera, the hardware is equipped with a > > > > MC-based ISP, connected to its camera. Currently, despite having > > > > a Kernel driver for it, the camera doesn't work with any > > > > userspace application. > > > > > > > > I'm also aware of other projects that are considering the usage of > > > > mc-based devices for non-dedicated hardware. > > > > > > What are those projects ? > > > > Well, cheap ARM-based hardware like RPi3 already has this issue: they > > have an ISP (or some GPU firmware meant to emulate an ISP). While > > those hardware could have multiple sensors, typically they have just > > one. > > Slight hijack, but a closely linked issue for the Pi. > The way I understand the issue of V4L2 / MC on Pi is a more > fundamental mismatch in architecture. Please correct me if I'm wrong > here. > > The Pi CSI2 receiver peripheral always writes the incoming data to > SDRAM, and the ISP is then a memory to memory device. This is the same for IPU3 and some new can ARM ISP works like this too. Though, IPU3 is fixed, you simply enable / disable / configure the ISP base on the stats/metadata. Basically, it's not a single device, but really two separate thing, were the ISP could be used without a sensor. (Hope this make sense, need to be taken in consideration). > > V4L2 subdevices are not dma controllers and therefore have no buffers > allocated to them. So to support the full complexity of the pipeline > in V4L2 requires that something somewhere would have to be dequeuing > the buffers from the CSI receiver V4L2 device and queuing them to the > input of a (theoretical) ISP M2M V4L2 device, and returning them once > processed. The application only cares about the output of the ISP M2M > device. > > So I guess my question is whether there is a sane mechanism to remove > that buffer allocation and handling from the app? Without it we are > pretty much forced to hide bigger blobs of functionality to even > vaguely fit in with V4L2. > > I'm at the point where it shouldn't be a huge amount of work to create > at least a basic ISP V4L2 M2M device, but I'm not planning on doing it > if it pushes the above buffer handling onto the app because it simply > won't get used beyond demo apps. The likes of Cheese, Scratch, etc, > just won't do it. Well, would have to be a media controller running in M2M as it is not 1:1 in term of number of input : number of output. > > To avoid ambiguity, the Pi has a hardware ISP block. There are other > SoCs that use either GPU code or a DSP to implement their ISP. That's a good point, something that need to be kept in mind. > > Dave
Attachment:
signature.asc
Description: This is a digitally signed message part
