> -----Original Message----- > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > Sent: Tuesday, February 09, 2010 1:52 AM > To: Mauro Carvalho Chehab; laurent.pinchart@xxxxxxxxxxxxxxxx > Cc: Maupin, Chase; sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx; > vpss_driver_design@xxxxxxxxxxx - This list is to discuss the VPSS driver > design (May contain non-TIers); linux-media@xxxxxxxxxxxxxxx > Subject: Re: Requested feedback on V4L2 driver design > > On Monday 08 February 2010 21:23:00 Mauro Carvalho Chehab wrote: > > Maupin, Chase wrote: > > > All, > > > > > > Texas Instruments (TI) is working on the design for the V4L2 capture > and display drivers for our next generation system-on-chip (SoC) processor > and would like to solicit your feedback. Our new SoCs have been improved > to allow for higher video resolutions and greater frame rates. To this > end the display hardware has been moved to a separate processing block > called the video processing subsystem (VPSS). The VPSS will be running a > firmware image that controls the capture/display hardware and services > requests from one or more host processors. > > > > > > Moving to a remote processor for the processing of video input and > output data requires that commands to control the hardware be passed to > this processing block using some form of inter-processor communication > (IPC). TI would like to solicit your feedback on proposal for the V4L2 > driver design to get a feel for whether or not this design would be > accepted into the Linux kernel. To this end we have put together an > overview of the design and usage on our wiki at > http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des > ign. We would greatly appreciate feedback from community members on the > acceptability of our driver design. > > > > > > If you have additional questions or need more information please feel > free to contact us (we have setup a mailing list at > vpss_driver_design@xxxxxxxxxxx) so we can answer them. > > > > > > > Hi Chase, > > > > I'm not sure if I got all the details on your proposal, so let me try to > give my > > understanding. > > > > First of all, for normal usage (e.g. capturing a stream or sending an > stream > > to an output device), the driver should work with only the standard V4L2 > API. > > I'm assuming that the driver will provide this capability. > > > > I understand that, being a SoC hardware, there are much more that can be > done > > than just doing the normal stream capture/output, already supported by > V4L2 API. > > > > For such advanced usages, we're open to a proposal to enhance the > existing API > > to support the needs. There are some important aspects that need to be > considered > > when designing any Linux userspace API's: > > The full functionality of this device can be handled by the proposals made > during > last year's LPC and that are currently being implemented/prototyped for > omap3. > That's no coincidence, by the way :-) Our initial goal is to enable the current V4L2 APIs and functionality that exist today and then to continue working to add new features that use new functionality as it becomes available. Of course we will be working with the V4L2 community on these features. > > > > > 1) kernel-userspace API's are forever. So, they need to be designed > in > > a way that new technology changes won't break the old API; > > > > 2) API's are meant to be generic. So, they needed to be designed in > a way > > that, if another hardware with similar features require an API, the > planned one > > should fit; > > > > 3) The API's should be, as much as possible, independent of the > hardware > > architecture. You'll see that even low-level architecture dependent > stuff, like > > bus drivers are designed in a way that they are not bound to a > particular hardware, > > but instead provide the same common methods to interact with the > hardware to other > > device drivers. > > > > That's said, it would be interesting if you could give us a more deep > detail on > > what kind of functionalities and how do you think you'll be implementing > them. > > For me the core issue will be the communication between the main ARM and > the ARM > controlling the VPSS. Looking at the syslink part of the git tree it all > looks > way overengineered to me. In particular the multicore_ipc directory. Is > all that > code involved in setting up the communication path between the main and > VPSS ARM? > Is there some more detailed document describing how the syslink code > works? Agreed. The most important aspect that we are hoping to get feedback on is using the syslink notify IPC for communication between the cores. In this use case much of the functionality of syslink is un-needed. The focus for this driver will be on using simple IPC where events are registered to send data between the host MCU and the VPSS. I'll get someone from the syslink team to comment here with more details but the basic idea is that the host MCU and the VPSS will have an event configured for handling requests. When the host MCU wants to sent a request to the VPSS it will create a command structure and pass a reference to that structure by using the sendEvent API. The sendEvent API will require that an event number be passed and a pointer to the command structure. > > What I would expect to see is standard mailbox functionality that is used > in other > places as well. I gather that at the bottom there actually seems to be a > mailbox > involved with syslink, but there also seems to be a lot of layers on top > of that. > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
