RE: Requested feedback on V4L2 driver design
Laurent, Responses inline Puru, There is a question for you below. Can you look at it and provide an answer? Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Thursday, February 25, 2010 6:32 PM > To: Maupin, Chase > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org; Kamoolkar, Mugdha > Subject: Re: Requested feedback on V4L2 driver design > > Hi Chase, > > On Friday 12 February 2010 17:46:55 Maupin, Chase wrote: > > Laurent, > > > > First let me thank you for taking time to review this. > > You're welcome. > > [snip] > > > > -Original Message- > > > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > > > Sent: Thursday, February 11, 2010 7:23 PM > > > > > > On Monday 08 February 2010 16:08:37 Maupin, Chase wrote: > > [snip] > > > > > If you have additional questions or need more information please > feel > > > > free to contact us (we have setup a mailing list at > > > > vpss_driver_des...@list.ti.com) so we can answer them. > > > > > > I'll answer here as the instructions provided in the wiki to subscribe > to > > > the vpss_driver_design mailing list are incorrect (http://list.ti.com/ > > > isn't accessible, the name has no A record associated to it). I've > CC'ed > > > the list in case subscription wouldn't be required to post. > > > > The page for subscribing to the list requires a my.TI login which you > can > > setup at > > > https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainer<=m > > yti&j5=2&j3=1&goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi- > bin%2Fhome.pl%3FDCMP > > %3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. > > However, your reply to the list should be fine without subscribing. > > Thanks for the information, but http://list.ti.com/ still can't be > accessed. > The host list.ti.com has no A record, an HTTP connection can't thus be > established. I'm not sure what is going on here. Let me file a ticket with our IT group and see if they can fix the problem. > > > > 1. Multi-core design > > > > > > > > > OMAP3 was already a dual-core system, OMAP4 (I assume all this is > about > > > the OMAP4 processors family) seems to push the concept one step > further. > > > > > > With its heterogeneous multi-core design (ARM master CPU and slave > DSPs), > > > the OMAP architecture delivers high performances at the cost of higher > > > development time and effort as users need to write software for > completely > > > different cores, usually using different toolchains. This is in my > opinion > > > a good (or at least acceptable) trade-off between CPU power, > development > > > time and power consumption (DSPs being more efficient at signal > processing > > > at the cost of a higher development complexity). > > > > > > I'm a bit puzzled, however, by how the VPSS MCU will help improving > the > > > situation compared to the OMAP3 design. The VPSS MCU will provide an > API > > > that will expose a fixed subset of the hardware capabilities. This is > only > > > a guess, but I suppose the firmware will be fairly generic, and that > TI > > > will provide customized versions to big customers tailored for their > needs > > > and use cases. The "official" kernel drivers will then need to be > changed, > > > and those changes will have no chance to be accepted in the mainline > > > kernel. This will lead to forks and fragmentation of the developers > base > > > among the big players in the embedded markets. What will be the > > > compensation for that ? How will the VPSS MCU provide higher > performances > > > than the OMAP3 model ? > > > > The firmware on the VPSS MCU will be able to configure/control all of > the > > functionality that the VPSS MCU has and will be the same for all > > customers. The only part that may change is the proxy driver of the > > firmware. The proxy driver is the piece that will be responsible for > > taking the commands from the
RE: Requested feedback on V4L2 driver design
Laurent, Responses inline. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Thursday, February 25, 2010 6:35 PM > To: Maupin, Chase > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org > Subject: Re: Requested feedback on V4L2 driver design > > Hi Chase, > > On Tuesday 16 February 2010 14:00:11 Maupin, Chase wrote: > > Laurent, > > > > To follow up with some of the comments I made before I got additional > > clarification about the commands supported by the proxy driver running > on > > the VPSS MCU. The proxy will support all of the commands used by V4L2 > as > > well as those proposed extensions to V4L2 that Hans has mentioned. > > Basically, the list of commands supported at initial release is not only > > those required today, but a full set for all the features of the VPSS. > In > > this was as new APIs are added to V4L2 the support for those features > will > > already be supported by the VPSS MCU proxy driver. > > Thank you for the clarification. > > A few things are still uncleared to me, as stated in my previous mail > (from a > few minutes ago). My main question is, if the VPSS API is full-featured > and > accessible from the master CPU, why do we need a proxy driver in the > firmware > at all ? The proxy driver is the piece of code in the firmware that is actually exposing the VPSS API to the master CPU. It is responsible for listening for requests from the master CPU and then executing those requests on the VPSS CPU. Without the proxy there is no way to tell the VPSS CPU which functions to execute. > > > As for the license of the firmware this is still being worked. It is > > currently under TI proprietary license and will be distributed as binary > > under Technical Software Publicly Available (TSPA) which means it can be > > obtained by anyone. If you feel that source code is required for the > > firmware at launch to gain acceptance please let us know and we can > start > > working that issue. > > I think it would definitely help keeping the Linux driver and the VPSS > firmware in sync if the VPSS firmware source was available. The firmware > source code could even be distributed along with the Linux driver. Thanks for the input. We'll keep this in mind and see what we can do. > > By the way, will the firmware be loaded at runtime by the driver, or will > it > be stored internally in the chip ? The firmware will not be stored internally on the chip and will have to be loaded at runtime. We have not settled on how the loading will be done. Currently we are thinking on loading it from u-boot similar to an FPGA firmware load but it could also be done from the kernel. > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Requested feedback on V4L2 driver design
Laurent, Some additional information from the syslink team. Yes, the current Notify code is indeed going over the kernel mailbox code. You can find this code in drivers/dsp/syslink/notify_ducatidriver/notify_ducati.c. We have already pushed some mailbox patches specific to the new mailbox register set in OMAP4/Netra to kernel. These patches are available starting in 2.6.33. On our tree, we currently have some custom patches some of which were pushed to upstream and in the process of getting rolled into the upcoming 2.6.34 releases. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Kamoolkar, Mugdha > Sent: Wednesday, February 24, 2010 9:05 PM > To: Maupin, Chase; Laurent Pinchart > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org; Kanigeri, Hari; Shah, Bhavin; Anna, Suman > Subject: RE: Requested feedback on V4L2 driver design > > Chase, Laurent, > > Sorry for the extreme delay in my response ... > From the code available currently on omapzoom, our plans are to eventually > have only the Notify module in kernel-space. All the other code in > multicore_ipc will actually move to user-side. The Notify module gives > additional functionality over the basic mailbox driver to abstract the > single physical event into multiple logical events. This enables multiple > clients (one of which is the DSS driver) to use the single physical > interrupt for multiple different purposes in a fully modular manner. We > will ensure that the kernel-side Notify module is fully integrated into > the kernel in the proper way and still meets our functionality > requirements, taking feedback from the community into account. > > We are also making several changes in the APIs for all modules to make > them much easier to use. A lot of the complexity as seen by the user will > vanish underneath. This is still under progress, so it's not out on > omapzoom yet, but will definitely be done. > > > As soon as this is done, we will work on moving most of the modules > (except Notify) fully from kernel->user space. Once our kernel->user work > has at least gone far enough ahead to allow us to make a design proposal, > we will push it out for review to get your valuable feedback. > > I have also looped in the TI engineers who have worked on and pushed out > the omapzoom SysLink code. > > Regards, > Mugdha > > -Original Message- > From: Maupin, Chase > Sent: Friday, February 12, 2010 10:17 PM > To: Laurent Pinchart > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org; Kamoolkar, Mugdha > Subject: RE: Requested feedback on V4L2 driver design > > Laurent, > > First let me thank you for taking time to review this. I have made > comments below to address your concerns. > > Sincerely, > Chase Maupin > Software Applications > Catalog DSP Products > e-mail: chase.mau...@ti.com > phone: (281) 274-3285 > > For support: > Forums - http://community.ti.com/forums/ > Wiki - http://wiki.davincidsp.com/ > > > -Original Message- > > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > > Sent: Thursday, February 11, 2010 7:23 PM > > To: Maupin, Chase > > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > > discuss the VPSS driver design (May contain non-TIers); linux- > > me...@vger.kernel.org > > Subject: Re: Requested feedback on V4L2 driver design > > > > Hi Chase, > > > > On Monday 08 February 2010 16:08:37 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. > > > > Thank you very much for requesting feedback on the system design. I > > personally > > appreciate this, and I'm pretty sure that the feeling is shared by most > of > > the > > Linux kernel developers. > > > > > If you have additional questions or need more information please feel > > free > > > to contact us (we have setup a mailing
RE: Requested feedback on V4L2 driver design
Hans, Some follow-up from the syslink team about the driver code in the git tree. The only code to be referred on omapzoom that will actually be in the kernel is the Notify module. All the other code in multicore_ipc will actually move to user-side. The Notify module gives additional functionality over the basic mailbox driver to abstract the single physical event into multiple logical events. This enables multiple clients (one of which is the DSS driver) to use the single physical interrupt for multiple different purposes in a fully modular manner. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Tuesday, February 09, 2010 1:52 AM > To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com > Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com; > vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver > design (May contain non-TIers); linux-media@vger.kernel.org > 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_des...@list.ti.com) 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 :-) > > > > > 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
RE: Requested feedback on V4L2 driver design
Laurent, To follow up with some of the comments I made before I got additional clarification about the commands supported by the proxy driver running on the VPSS MCU. The proxy will support all of the commands used by V4L2 as well as those proposed extensions to V4L2 that Hans has mentioned. Basically, the list of commands supported at initial release is not only those required today, but a full set for all the features of the VPSS. In this was as new APIs are added to V4L2 the support for those features will already be supported by the VPSS MCU proxy driver. As for the license of the firmware this is still being worked. It is currently under TI proprietary license and will be distributed as binary under Technical Software Publicly Available (TSPA) which means it can be obtained by anyone. If you feel that source code is required for the firmware at launch to gain acceptance please let us know and we can start working that issue. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Thursday, February 11, 2010 7:23 PM > To: Maupin, Chase > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org > Subject: Re: Requested feedback on V4L2 driver design > > Hi Chase, > > On Monday 08 February 2010 16:08:37 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. > > Thank you very much for requesting feedback on the system design. I > personally > appreciate this, and I'm pretty sure that the feeling is shared by most of > the > Linux kernel developers. > > > If you have additional questions or need more information please feel > free > > to contact us (we have setup a mailing list at > > vpss_driver_des...@list.ti.com) so we can answer them. > > I'll answer here as the instructions provided in the wiki to subscribe to > the > vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't > accessible, the name has no A record associated to it). I've CC'ed the > list in > case subscription wouldn't be required to post. > > 1. Multi-core design > > > OMAP3 was already a dual-core system, OMAP4 (I assume all this is about > the > OMAP4 processors family) seems to push the concept one step further. > > With its heterogeneous multi-core design (ARM master CPU and slave DSPs), > the > OMAP architecture delivers high performances at the cost of higher > development > time and effort as users need to write software for completely different > cores, usually using different toolchains. This is in my opinion a good > (or at > least acceptable) trade-off between CPU power, development time and power > consumption (DSPs being more efficient at signal processing at the cost of > a > higher development complexity). > > I'm a bit puzzled, however, by how the VPSS MCU will help improving the > situation compared to the OMAP3 design. The VPSS MCU will provide an API > that > will expose a fixed subset of the hardware capabilities. This is only a > guess, > but I suppose the firmware will be fairly generic, and that TI will > provide > customized versions to big customers tailored for their needs and use > cases. > The "official" kernel drivers will then need to be changed, and those > changes > will have no chance to be accepted in the mainline kernel. This will lead > to > forks and fragmentation of the developers base among the big players in > the > embedded markets. What will be the compensation for that ? How will the > VPSS > MCU provide higher performances than the OMAP3 model ? > > 2. VPSS firmware and API > > > The wiki doesn't state under which license the VPSS MCU firmware will be > released, but I suppose it won't be open sourced. The VPSS API, which > seems > from the information provided in the wiki to mimic the V4L2 API at least > for > video capture and output, will thus be controlled by TI and pretty much > set > into stone. This means future extensions to the V4L2 API that will provide > more control over the devices to userspace applications will be stuck with > access to a limited subse
RE: Requested feedback on V4L2 driver design
Laurent, First let me thank you for taking time to review this. I have made comments below to address your concerns. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com phone: (281) 274-3285 For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Thursday, February 11, 2010 7:23 PM > To: Maupin, Chase > Cc: Hans Verkuil; sakari.ai...@maxwell.research.nokia.com; > mche...@infradead.org; vpss_driver_des...@list.ti.com - This list is to > discuss the VPSS driver design (May contain non-TIers); linux- > me...@vger.kernel.org > Subject: Re: Requested feedback on V4L2 driver design > > Hi Chase, > > On Monday 08 February 2010 16:08:37 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. > > Thank you very much for requesting feedback on the system design. I > personally > appreciate this, and I'm pretty sure that the feeling is shared by most of > the > Linux kernel developers. > > > If you have additional questions or need more information please feel > free > > to contact us (we have setup a mailing list at > > vpss_driver_des...@list.ti.com) so we can answer them. > > I'll answer here as the instructions provided in the wiki to subscribe to > the > vpss_driver_design mailing list are incorrect (http://list.ti.com/ isn't > accessible, the name has no A record associated to it). I've CC'ed the > list in > case subscription wouldn't be required to post. The page for subscribing to the list requires a my.TI login which you can setup at https://myportal.ti.com/portal/dt?provider=TIPassLoginSingleContainer<=myti&j5=2&j3=1&goto=https%3A%2F%2Fmy.ti.com%3A443%2Fcgi-bin%2Fhome.pl%3FDCMP%3DTIHeaderTracking%26HQS%3DOther%2BOT%2Bhdr_my_ti. However, your reply to the list should be fine without subscribing. > > 1. Multi-core design > > > OMAP3 was already a dual-core system, OMAP4 (I assume all this is about > the > OMAP4 processors family) seems to push the concept one step further. > > With its heterogeneous multi-core design (ARM master CPU and slave DSPs), > the > OMAP architecture delivers high performances at the cost of higher > development > time and effort as users need to write software for completely different > cores, usually using different toolchains. This is in my opinion a good > (or at > least acceptable) trade-off between CPU power, development time and power > consumption (DSPs being more efficient at signal processing at the cost of > a > higher development complexity). > > I'm a bit puzzled, however, by how the VPSS MCU will help improving the > situation compared to the OMAP3 design. The VPSS MCU will provide an API > that > will expose a fixed subset of the hardware capabilities. This is only a > guess, > but I suppose the firmware will be fairly generic, and that TI will > provide > customized versions to big customers tailored for their needs and use > cases. > The "official" kernel drivers will then need to be changed, and those > changes > will have no chance to be accepted in the mainline kernel. This will lead > to > forks and fragmentation of the developers base among the big players in > the > embedded markets. What will be the compensation for that ? How will the > VPSS > MCU provide higher performances than the OMAP3 model ? The firmware on the VPSS MCU will be able to configure/control all of the functionality that the VPSS MCU has and will be the same for all customers. The only part that may change is the proxy driver of the firmware. The proxy driver is the piece that will be responsible for taking the commands from the driver and telling the firmware to execute the operation. The initial version of the proxy will support all the standard V4L2 operations. As new operations (such as on the fly video scaling) are added to the V4L2 API the firmware may require an update to the proxy driver to handle these requests, but the underlying code will remain the same. For customers who wish to use features of the VPSS that are not supported by the current V4L2 APIs there are OpenMax components being developed that can also talk to the VPSS and support the full set of features of the VPSS. These components allow for additional use cases such as transferring data directly from other processing blocks such as the DSP to the VPSS without ever returning to the host processor (tu
RE: Requested feedback on V4L2 driver design
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Tuesday, February 09, 2010 1:52 AM > To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com > Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com; > vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver > design (May contain non-TIers); linux-media@vger.kernel.org > 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_des...@list.ti.com) 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 :-) > > > > > 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? I uploaded a preliminary version of the syslink User's Guide to the wiki page in the syslink section. You can find the pdf at http://wiki.davincidsp.com/images/3/30/Sprugo6a.pdf. Se
RE: Requested feedback on V4L2 driver design
> -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Tuesday, February 09, 2010 1:52 AM > To: Mauro Carvalho Chehab; laurent.pinch...@ideasonboard.com > Cc: Maupin, Chase; sakari.ai...@maxwell.research.nokia.com; > vpss_driver_des...@list.ti.com - This list is to discuss the VPSS driver > design (May contain non-TIers); linux-media@vger.kernel.org > 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_des...@list.ti.com) 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
Requested feedback on V4L2 driver design
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_Design. 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_des...@list.ti.com) so we can answer them. Sincerely, Chase Maupin Software Applications Catalog DSP Products e-mail: chase.mau...@ti.com For support: Forums - http://community.ti.com/forums/ Wiki - http://wiki.davincidsp.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
