Em 06-09-2011 11:47, Laurent Pinchart escreveu: > Hi Vaibhav, > > On Tuesday 06 September 2011 16:12:35 Hiremath, Vaibhav wrote: >> On Monday, September 05, 2011 6:20 PM Laurent Pinchart wrote: >>> On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote: >> >> <snip> >> >>> I don't mind splitting the config option. An alternative would be to >>> compile media_entity_init() and media_entity_cleanup() based on >>> CONFIG_MEDIA_SUPPORT instead of CONFIG_MEDIA_CONTROLLER, but that looks a >>> bit hackish to me. >>> >>>> Also, I don't like the idea of increasing drivers complexity for the >>>> existing drivers that work properly without MC. All those core >>>> conversions that were done in the last two years caused already too much >>>> instability to them. >>>> >>>> We should really avoid touching on them again for something that won't >>>> be adding any new feature nor fixing any known bug. >>> >>> We don't have to convert them all in one go right now, we can implement >>> pad-level operations support selectively when a subdev driver becomes used >>> by an MC-enabled host/bridge driver. >> >> I completely agree that we should not be duplicating the code just for sake >> of it. >> >> Isn't the wrapper approach seems feasible here? > > As explained in a previous e-mail, a wrapper sounds like a good approach to > me, to emulate video::* operations based on pad::* operations. We want to move > to pad::* operations, so we should not perform emulation the other way around. We have 300+ drivers under /drivers/media. Just a few of them need MC API. Good sense says that we shouldn't touch on 300+ just because of half dozen drivers. So, if a wrapper is needed, it should be done for the other side. Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
