Hi, On Friday 02 September 2011 23:30:11 Sakari Ailus wrote: > On Fri, Sep 02, 2011 at 11:38:06AM +0200, Alain VOLMAT wrote: > > I'm writing you in order to have some advices in the design of the V4L2 > > driver for a rather complex device. It is mainly related to > > device/subdev/media controller. > > > > This driver would target SoCs which usually handle inputs (capture > > devices, for ex LinuxDVB, HDMI capture), several layers of graphical or > > video planes and outputs such as HDMI/analog. Basically we have 3 levels, > > capture devices data being pushed onto planes and planes being mixed on > > outputs. Moreover it is also possible to input or output datas from > > several points of the device. > > Do you have a graphical representation of the flow of data inside the > device and memory inputs / outputs? I second Sakari's request here. It would be much easier to advice you with a block diagram of your hardware. > > The idea is to take advantage of the new MediaController in order to be > > able to define internal data path by linking capture devices to layers > > and layers to outputs. Since MediaController allows to link pads of > > entities together, our understanding is that we need to have 1 subdevice > > per hardware resource. That is if we have 2 planes, we will have 2 > > subdevices handling them. Same for outputs and capture. Is our > > understanding correct ? > > I think this dependes a little what are the capabilities of those hardware > resources. If they contain several steps of complex image processing this > might be the case. For example, the following diagram contains the OMAP 3 > ISP media controller graph: > > <URL:http://www.ideasonboard.org/media/omap3isp.ps> > > The graph represents a digital camera with sensor, lens and flash. The ISP > (image signal processor) consists of several subdevs in the graph. > > > A second point is now about the number of devices. I think we have 2 ways > > #of doing that, and I would like to get your opinions about those 2 ways. > > #1 Single device: I could think of a single device which expose several > > inputs and outputs. We could enumerate them with VIDIOC_ENUM* and select > > them using VIDIOC_S_*. After the selection, data exchange could be done > > upon specifying a proper buffer type. The merit of such model is that an > > application using such device would only have to access the single > > available /dev/video0 for everything, without having to know if video0 is > > for capture, video1 output and so on. > > > > #2 Multiple device: In such case, each video device would only provide a > > single (or small amount of similar) input or output. So several video > > device nodes would be available to the application. Looking at some other > > drivers around such as the OMAP4 ISP or Samsung S5P, it seems to be the > > I believe you refer to OMAP 3, not 4? > > > preferred way to go, is that correct ? This way also fit more in the V4L2 > > model of device type (Video capture device, video output device) since > > way #1 would at last create a single big device which implement a mix of > > all those devices. > > In general, V4L2 device nodes should represent memory input / output for > the device, or a DMA engine. The devices you are referring to above offer > possibilities to write the data to memory in several points in the > pipeline. Based on what you're writing above, it sounds like to me that > your device should likely expose several V4L2 device nodes. This is my opinion as well. > > As far as the media controller is concerned, since all those resources > > are not sharable, it seems proper to have only a single media entry > > point in > > The interface to user space should also be such that it doesn't place > artificial limitations on what data paths can be used: the same driver > should be usable without changes in all situations. Of course one might not > implement each and every feature right away. > > > order to setup the SoC and internal data path (and not abstract media to > > match their video device counterpart) > > I'm afraid I don't know enough to comment this. It would be quite helpful > if you can provide more detailed information on the hardware. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
