Hans, I haven't gone through the RFC, but thought will respond to the below comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-karicheri2@xxxxxx >>> >>> I may be mistaken, but I don't believe soundcards have this same >>> complexity are media board. >> >> When I launch alsa-mixer I see 4 input devices where I can select 4 >> difference sources. This gives 16 combinations which is enough for me to >> call it 'complex' . >> >>>> Could entities not be completely addressed (configuration ioctls) >>>> through >>>> the mc-node? >>> >>> Not sure what you mean. >> >> Instead of having a device node for each entity, the ioctls for each >> entities are done on the media controller-node address an entity by ID. > >I definitely don't want to go there. Use device nodes (video, fb, alsa, >dvb, etc) for streaming the actual media as we always did and use the >media controller for controlling the board. It keeps everything nicely >separate and clean. > What you mean by controlling the board? We have currently ported DMxxx VPBE display drivers to 2.6.31 (Not submitted yet to mainline). In our current implementation, the output and standard/mode are controlled through sysfs because it is a common functionality affecting both v4l and FBDev framebuffer devices. Traditional applications such x-windows should be able to stream video/graphics to VPBE output. V4l2 applications should be able to stream video. Both these devices needs to know the display parameters such as frame buffer resolution, field etc that are to be configured in the video or osd layers in VPBE to output frames to the encoder that is driving the output. So to stream, first the output and mode/standard are selected using sysfs command and then the application is started. Following scenarios are supported by VPBE display drivers in our internal release:- 1)Traditional FBDev applications (x-window) can be run using OSD device. Allows changing mode/standards at the output using fbset command. 2)v4l2 driver doesn't provide s_output/s_std support since it is done through sysfs. 3)Applications that requires to stream both graphics and video to the output uses both FBDev and V4l2 devices. So these application first set the output and mode/standard using sysfs, before doing io operations with these devices. There is an encoder manager to which all available encoders registers (using internally developed interface) and based on commands received at Fbdev/sysfs interfaces, the current encoder is selected by the encoder manager and current standard is selected. The encoder manager provides API to retrieve current timing information from the current encoder. FBDev and V4L2 drivers uses this API to configure OSD/video layers for streaming. As you can see, controlling output/mode is a common function required for both v4l2 and FBDev devices. One way to do this to modify the encoder manager such that it load up the encoder sub devices. This will allow our customers to migrate to this driver on GIT kernel with minimum effort. If v4l2 display bridge driver load up the sub devices, it will make FBDev driver useless unless media controller has some way to handle this scenario. Any idea if media controller RFC address this? I will go over the RFC in details, but if you have a ready answer, let me know. Thanks >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 -- 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
