| Message ID | 1313761725-6614-1-git-send-email-deepthy.ravi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > From: Vaibhav Hiremath <hvaibhav@ti.com> > > Fix the build break caused when CONFIG_MEDIA_CONTROLLER > option is disabled and if any sensor driver has to be used > between MC and non MC framework compatible devices. > > For example,if tvp514x video decoder driver migrated to > MC framework is being built without CONFIG_MEDIA_CONTROLLER > option enabled, the following error messages will result. > drivers/built-in.o: In function `tvp514x_remove': > drivers/media/video/tvp514x.c:1285: undefined reference to > `media_entity_cleanup' > drivers/built-in.o: In function `tvp514x_probe': > drivers/media/video/tvp514x.c:1237: undefined reference to > `media_entity_init' If the tvp514x is migrated to the MC framework, its Kconfig option should depend on MEDIA_CONTROLLER. > The file containing definitions of media_entity_init and > media_entity_cleanup functions will not be built if that > config option is disabled. And this is corrected by > defining two dummy functions. > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com> > --- > include/media/media-entity.h | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/include/media/media-entity.h b/include/media/media-entity.h > index cd8bca6..c90916e 100644 > --- a/include/media/media-entity.h > +++ b/include/media/media-entity.h > @@ -121,9 +121,18 @@ struct media_entity_graph { > int top; > }; > > +#ifdef CONFIG_MEDIA_CONTROLLER > int media_entity_init(struct media_entity *entity, u16 num_pads, > struct media_pad *pads, u16 extra_links); > void media_entity_cleanup(struct media_entity *entity); > +#else > +static inline int media_entity_init(struct media_entity *entity, u16 > num_pads, + struct media_pad *pads, u16 extra_links) > +{ > + return 0; > +} > +static inline void media_entity_cleanup(struct media_entity *entity) {} > +#endif > > int media_entity_create_link(struct media_entity *source, u16 source_pad, > struct media_entity *sink, u16 sink_pad, u32 flags);
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart [laurent.pinchart@ideasonboard.com] wrote: > On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: >> From: Vaibhav Hiremath <hvaibhav@ti.com> >> >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER >> option is disabled and if any sensor driver has to be used >> between MC and non MC framework compatible devices. >> >> For example,if tvp514x video decoder driver migrated to >> MC framework is being built without CONFIG_MEDIA_CONTROLLER >> option enabled, the following error messages will result. >> drivers/built-in.o: In function `tvp514x_remove': >> drivers/media/video/tvp514x.c:1285: undefined reference to >> `media_entity_cleanup' >> drivers/built-in.o: In function `tvp514x_probe': >> drivers/media/video/tvp514x.c:1237: undefined reference to >> `media_entity_init' > > If the tvp514x is migrated to the MC framework, its Kconfig option should > depend on MEDIA_CONTROLLER. >The same TVP514x driver is being used for both MC and non MC compatible devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA CONTROLLER, we cannot enable the driver for MC independent devices. >> The file containing definitions of media_entity_init and >> media_entity_cleanup functions will not be built if that >> config option is disabled. And this is corrected by >> defining two dummy functions. >> >> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> >> Signed-off-by: Deepthy Ravi <deepthy.ravi@ti.com> >> --- >> include/media/media-entity.h | 9 +++++++++ >> 1 files changed, 9 insertions(+), 0 deletions(-) >> >> diff --git a/include/media/media-entity.h b/include/media/media-entity.h >> index cd8bca6..c90916e 100644 >> --- a/include/media/media-entity.h >> +++ b/include/media/media-entity.h >> @@ -121,9 +121,18 @@ struct media_entity_graph { >> int top; >> }; >> >> +#ifdef CONFIG_MEDIA_CONTROLLER >> int media_entity_init(struct media_entity *entity, u16 num_pads, >> struct media_pad *pads, u16 extra_links); >> void media_entity_cleanup(struct media_entity *entity); >> +#else >> +static inline int media_entity_init(struct media_entity *entity, u16 >> num_pads, + struct media_pad *pads, u16 extra_links) >> +{ >> + return 0; >> +} >> +static inline void media_entity_cleanup(struct media_entity *entity) {} >> +#endif >> >> int media_entity_create_link(struct media_entity *source, u16 source_pad, >> struct media_entity *sink, u16 sink_pad, u32 flags); > > -- > Regards, > > Laurent Pinchart > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-inf >-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > > On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > >> > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > >> option is disabled and if any sensor driver has to be used > >> between MC and non MC framework compatible devices. > >> > >> For example,if tvp514x video decoder driver migrated to > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > >> option enabled, the following error messages will result. > >> drivers/built-in.o: In function `tvp514x_remove': > >> drivers/media/video/tvp514x.c:1285: undefined reference to > >> `media_entity_cleanup' > >> drivers/built-in.o: In function `tvp514x_probe': > >> drivers/media/video/tvp514x.c:1237: undefined reference to > >> `media_entity_init' > > > > If the tvp514x is migrated to the MC framework, its Kconfig option should > > depend on MEDIA_CONTROLLER. > > The same TVP514x driver is being used for both MC and non MC compatible > devices, for example OMAP3 and AM35x. So if it is made dependent on MEDIA > CONTROLLER, we cannot enable the driver for MC independent devices. Then you should use conditional compilation in the tvp514x driver itself. Or better, port the AM35x driver to the MC API.
> -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com] > Sent: Wednesday, August 24, 2011 5:00 PM > To: Ravi, Deepthy > Cc: mchehab@infradead.org; linux-media@vger.kernel.org; linux- > kernel@vger.kernel.org; linux-omap@vger.kernel.org; Hiremath, Vaibhav > Subject: Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and > > Hi, > > On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > > On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > > > On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > > >> > > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > >> option is disabled and if any sensor driver has to be used > > >> between MC and non MC framework compatible devices. > > >> > > >> For example,if tvp514x video decoder driver migrated to > > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > >> option enabled, the following error messages will result. > > >> drivers/built-in.o: In function `tvp514x_remove': > > >> drivers/media/video/tvp514x.c:1285: undefined reference to > > >> `media_entity_cleanup' > > >> drivers/built-in.o: In function `tvp514x_probe': > > >> drivers/media/video/tvp514x.c:1237: undefined reference to > > >> `media_entity_init' > > > > > > If the tvp514x is migrated to the MC framework, its Kconfig option > should > > > depend on MEDIA_CONTROLLER. > > > > The same TVP514x driver is being used for both MC and non MC compatible > > devices, for example OMAP3 and AM35x. So if it is made dependent on > MEDIA > > CONTROLLER, we cannot enable the driver for MC independent devices. > > Then you should use conditional compilation in the tvp514x driver itself. > Or [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in driver code. > better, port the AM35x driver to the MC API. > [Hiremath, Vaibhav] Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? Thanks, Vaibhav > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > > >> option is disabled and if any sensor driver has to be used > > > >> between MC and non MC framework compatible devices. > > > >> > > > >> For example,if tvp514x video decoder driver migrated to > > > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > > >> option enabled, the following error messages will result. > > > >> drivers/built-in.o: In function `tvp514x_remove': > > > >> drivers/media/video/tvp514x.c:1285: undefined reference to > > > >> `media_entity_cleanup' > > > >> drivers/built-in.o: In function `tvp514x_probe': > > > >> drivers/media/video/tvp514x.c:1237: undefined reference to > > > >> `media_entity_init' > > > > > > > > If the tvp514x is migrated to the MC framework, its Kconfig option > > should > > > > depend on MEDIA_CONTROLLER. > > > > > > The same TVP514x driver is being used for both MC and non MC compatible > > > devices, for example OMAP3 and AM35x. So if it is made dependent on > > MEDIA > > > CONTROLLER, we cannot enable the driver for MC independent devices. > > > > Then you should use conditional compilation in the tvp514x driver itself. > > Or > [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in driver code. > > > better, port the AM35x driver to the MC API. > > > [Hiremath, Vaibhav] > Why should we use MC if I have very simple device (like AM35x) which only supports single path? I can very well use simple V4L2 sub-dev based approach (master - slave), isn't it? Why should you break the API in unappropriated way? The patch is NACK, obviously.
> -----Original Message----- > From: Andy Shevchenko [mailto:andriy.shevchenko@linux.intel.com] > Sent: Wednesday, August 24, 2011 6:26 PM > To: Hiremath, Vaibhav > Cc: Laurent Pinchart; Ravi, Deepthy; mchehab@infradead.org; linux- > media@vger.kernel.org; linux-kernel@vger.kernel.org; linux- > omap@vger.kernel.org > Subject: RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and > > > > > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > > > >> option is disabled and if any sensor driver has to be used > > > > >> between MC and non MC framework compatible devices. > > > > >> > > > > >> For example,if tvp514x video decoder driver migrated to > > > > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > > > >> option enabled, the following error messages will result. > > > > >> drivers/built-in.o: In function `tvp514x_remove': > > > > >> drivers/media/video/tvp514x.c:1285: undefined reference to > > > > >> `media_entity_cleanup' > > > > >> drivers/built-in.o: In function `tvp514x_probe': > > > > >> drivers/media/video/tvp514x.c:1237: undefined reference to > > > > >> `media_entity_init' > > > > > > > > > > If the tvp514x is migrated to the MC framework, its Kconfig option > > > should > > > > > depend on MEDIA_CONTROLLER. > > > > > > > > The same TVP514x driver is being used for both MC and non MC > compatible > > > > devices, for example OMAP3 and AM35x. So if it is made dependent on > > > MEDIA > > > > CONTROLLER, we cannot enable the driver for MC independent devices. > > > > > > Then you should use conditional compilation in the tvp514x driver > itself. > > > Or > > [Hiremath, Vaibhav] No. I am not in favor of conditional compilation in > driver code. > > > > > better, port the AM35x driver to the MC API. > > > > > [Hiremath, Vaibhav] > > Why should we use MC if I have very simple device (like AM35x) which > only supports single path? I can very well use simple V4L2 sub-dev based > approach (master - slave), isn't it? > Why should you break the API in unappropriated way? [Hiremath, Vaibhav] Can you explain? Thanks, Vaibhav > > The patch is NACK, obviously. > > -- > Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Vaibhav, On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: > On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: > > On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > > > On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > > > > On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > > > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > > > >> > > > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > > >> option is disabled and if any sensor driver has to be used > > > >> between MC and non MC framework compatible devices. > > > >> > > > >> For example,if tvp514x video decoder driver migrated to > > > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > > >> option enabled, the following error messages will result. > > > >> drivers/built-in.o: In function `tvp514x_remove': > > > >> drivers/media/video/tvp514x.c:1285: undefined reference to > > > >> `media_entity_cleanup' > > > >> drivers/built-in.o: In function `tvp514x_probe': > > > >> drivers/media/video/tvp514x.c:1237: undefined reference to > > > >> `media_entity_init' > > > > > > > > If the tvp514x is migrated to the MC framework, its Kconfig option > > > > should depend on MEDIA_CONTROLLER. > > > > > > The same TVP514x driver is being used for both MC and non MC compatible > > > devices, for example OMAP3 and AM35x. So if it is made dependent on > > > MEDIA CONTROLLER, we cannot enable the driver for MC independent > > > devices. > > > > Then you should use conditional compilation in the tvp514x driver itself. > > Or > > No. I am not in favor of conditional compilation in driver code. Actually, thinking some more about this, you should make the tvp514x driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the driver will become unusable by applications that are not MC-aware. Hosts/bridges don't have to export subdev nodes, they can just call subdev pad-level operations internally and let applications control the whole device through a single V4L2 video node. > > better, port the AM35x driver to the MC API. > > Why should we use MC if I have very simple device (like AM35x) which only > supports single path? I can very well use simple V4L2 sub-dev based > approach (master - slave), isn't it? The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it doesn't have to expose them to userspace.
> -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com] > Sent: Wednesday, August 24, 2011 6:56 PM > To: Hiremath, Vaibhav > Cc: Ravi, Deepthy; mchehab@infradead.org; linux-media@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and > > Hi Vaibhav, > > On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: > > On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: > > > On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > > > > On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > > > > > On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > > > > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > > > > >> > > > > >> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > > > >> option is disabled and if any sensor driver has to be used > > > > >> between MC and non MC framework compatible devices. > > > > >> > > > > >> For example,if tvp514x video decoder driver migrated to > > > > >> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > > > >> option enabled, the following error messages will result. > > > > >> drivers/built-in.o: In function `tvp514x_remove': > > > > >> drivers/media/video/tvp514x.c:1285: undefined reference to > > > > >> `media_entity_cleanup' > > > > >> drivers/built-in.o: In function `tvp514x_probe': > > > > >> drivers/media/video/tvp514x.c:1237: undefined reference to > > > > >> `media_entity_init' > > > > > > > > > > If the tvp514x is migrated to the MC framework, its Kconfig option > > > > > should depend on MEDIA_CONTROLLER. > > > > > > > > The same TVP514x driver is being used for both MC and non MC > compatible > > > > devices, for example OMAP3 and AM35x. So if it is made dependent on > > > > MEDIA CONTROLLER, we cannot enable the driver for MC independent > > > > devices. > > > > > > Then you should use conditional compilation in the tvp514x driver > itself. > > > Or > > > > No. I am not in favor of conditional compilation in driver code. > > Actually, thinking some more about this, you should make the tvp514x > driver > depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that > the > driver will become unusable by applications that are not MC-aware. [Hiremath, Vaibhav] I am not referring to application here, there is no doubt that application must support non-MC devices. I should be able to use standard V4L2 streaming application and use it on streaming device node, the only change would be, for MC aware device, links need to be set before and for non-MC aware devices its default thing. > Hosts/bridges don't have to export subdev nodes, they can just call subdev > pad-level operations internally and let applications control the whole > device > through a single V4L2 video node. > [Hiremath, Vaibhav] Agreed. That's what I thought. > > > better, port the AM35x driver to the MC API. > > > > Why should we use MC if I have very simple device (like AM35x) which > only > > supports single path? I can very well use simple V4L2 sub-dev based > > approach (master - slave), isn't it? > > The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it > doesn't have to expose them to userspace. > [Hiremath, Vaibhav] Let me digest this. Thanks, Vaibhav > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em 24-08-2011 10:25, Laurent Pinchart escreveu: > Hi Vaibhav, > > On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: >> On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: >>> On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: >>>> On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: >>>>> On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: >>>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>>>>> >>>>>> Fix the build break caused when CONFIG_MEDIA_CONTROLLER >>>>>> option is disabled and if any sensor driver has to be used >>>>>> between MC and non MC framework compatible devices. >>>>>> >>>>>> For example,if tvp514x video decoder driver migrated to >>>>>> MC framework is being built without CONFIG_MEDIA_CONTROLLER >>>>>> option enabled, the following error messages will result. >>>>>> drivers/built-in.o: In function `tvp514x_remove': >>>>>> drivers/media/video/tvp514x.c:1285: undefined reference to >>>>>> `media_entity_cleanup' >>>>>> drivers/built-in.o: In function `tvp514x_probe': >>>>>> drivers/media/video/tvp514x.c:1237: undefined reference to >>>>>> `media_entity_init' >>>>> >>>>> If the tvp514x is migrated to the MC framework, its Kconfig option >>>>> should depend on MEDIA_CONTROLLER. >>>> >>>> The same TVP514x driver is being used for both MC and non MC compatible >>>> devices, for example OMAP3 and AM35x. So if it is made dependent on >>>> MEDIA CONTROLLER, we cannot enable the driver for MC independent >>>> devices. >>> >>> Then you should use conditional compilation in the tvp514x driver itself. >>> Or >> >> No. I am not in favor of conditional compilation in driver code. > > Actually, thinking some more about this, you should make the tvp514x driver > depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't mean that the > driver will become unusable by applications that are not MC-aware. > Hosts/bridges don't have to export subdev nodes, they can just call subdev > pad-level operations internally and let applications control the whole device > through a single V4L2 video node. > >>> better, port the AM35x driver to the MC API. >> >> Why should we use MC if I have very simple device (like AM35x) which only >> supports single path? I can very well use simple V4L2 sub-dev based >> approach (master - slave), isn't it? > > The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it > doesn't have to expose them to userspace. I don't agree. If AM35x doesn't expose the MC API to userspace, CONFIG_MEDIA_CONTROLLER should not be required at all. Also, according with the Linux best practices, when #if tests for config symbols are required, developers should put it into the header files, and not inside the code, as it helps to improve code readability. From Documentation/SubmittingPatches: 2) #ifdefs are ugly Code cluttered with ifdefs is difficult to read and maintain. Don't do it. Instead, put your ifdefs in a header, and conditionally define 'static inline' functions, or macros, which are used in the code. Let the compiler optimize away the "no-op" case. So, this patch is perfectly fine on my eyes. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mauro, On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: > Em 24-08-2011 10:25, Laurent Pinchart escreveu: > > On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: > >> On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: > >>> On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > >>>> On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > >>>>> On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > >>>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> > >>>>>> > >>>>>> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > >>>>>> option is disabled and if any sensor driver has to be used > >>>>>> between MC and non MC framework compatible devices. > >>>>>> > >>>>>> For example,if tvp514x video decoder driver migrated to > >>>>>> MC framework is being built without CONFIG_MEDIA_CONTROLLER > >>>>>> option enabled, the following error messages will result. > >>>>>> drivers/built-in.o: In function `tvp514x_remove': > >>>>>> drivers/media/video/tvp514x.c:1285: undefined reference to > >>>>>> `media_entity_cleanup' > >>>>>> drivers/built-in.o: In function `tvp514x_probe': > >>>>>> drivers/media/video/tvp514x.c:1237: undefined reference to > >>>>>> `media_entity_init' > >>>>> > >>>>> If the tvp514x is migrated to the MC framework, its Kconfig option > >>>>> should depend on MEDIA_CONTROLLER. > >>>> > >>>> The same TVP514x driver is being used for both MC and non MC > >>>> compatible devices, for example OMAP3 and AM35x. So if it is made > >>>> dependent on MEDIA CONTROLLER, we cannot enable the driver for MC > >>>> independent devices. > >>> > >>> Then you should use conditional compilation in the tvp514x driver > >>> itself. Or > >> > >> No. I am not in favor of conditional compilation in driver code. > > > > Actually, thinking some more about this, you should make the tvp514x > > driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't > > mean that the driver will become unusable by applications that are not > > MC-aware. Hosts/bridges don't have to export subdev nodes, they can just > > call subdev pad-level operations internally and let applications control > > the whole device through a single V4L2 video node. > > > >>> better, port the AM35x driver to the MC API. > >> > >> Why should we use MC if I have very simple device (like AM35x) which > >> only supports single path? I can very well use simple V4L2 sub-dev > >> based approach (master - slave), isn't it? > > > > The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it > > doesn't have to expose them to userspace. > > I don't agree. If AM35x doesn't expose the MC API to userspace, > CONFIG_MEDIA_CONTROLLER should not be required at all. > > Also, according with the Linux best practices, when #if tests for config > symbols are required, developers should put it into the header files, and > not inside the code, as it helps to improve code readability. From > Documentation/SubmittingPatches: > > 2) #ifdefs are ugly > > Code cluttered with ifdefs is difficult to read and maintain. Don't do > it. Instead, put your ifdefs in a header, and conditionally define > 'static inline' functions, or macros, which are used in the code. > Let the compiler optimize away the "no-op" case. > > So, this patch is perfectly fine on my eyes. I'm sorry, but I don't agree. Regarding the V4L2 subdev pad-level API, the goal is to convert all host and subdev drivers to it, so that's definitely the way to go. This does *not* mean that subdevs must expose a subdev device node. That's entirely optional. What I'm talking about is switching from video::*_mbus_fmt operations to pad::*_fmt operations. The pad-level format operations are very similar to video-level format operations, and more generic. Drivers shouldn't implement both. Regarding the MC API, drivers are not required to register a media_device instance. I have no issue with that. However, drivers should initialized the subdev's embedded media_entity, as that's required by subdev pad-level operations to get the number of pads for a subdev. This will result in no modification to the userspace.
Em 04-09-2011 06:01, Laurent Pinchart escreveu: > Hi Mauro, > > On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: >> Em 24-08-2011 10:25, Laurent Pinchart escreveu: >>> On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: >>>> On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: >>>>> On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: >>>>>> On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: >>>>>>> On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: >>>>>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>>>>>>> >>>>>>>> Fix the build break caused when CONFIG_MEDIA_CONTROLLER >>>>>>>> option is disabled and if any sensor driver has to be used >>>>>>>> between MC and non MC framework compatible devices. >>>>>>>> >>>>>>>> For example,if tvp514x video decoder driver migrated to >>>>>>>> MC framework is being built without CONFIG_MEDIA_CONTROLLER >>>>>>>> option enabled, the following error messages will result. >>>>>>>> drivers/built-in.o: In function `tvp514x_remove': >>>>>>>> drivers/media/video/tvp514x.c:1285: undefined reference to >>>>>>>> `media_entity_cleanup' >>>>>>>> drivers/built-in.o: In function `tvp514x_probe': >>>>>>>> drivers/media/video/tvp514x.c:1237: undefined reference to >>>>>>>> `media_entity_init' >>>>>>> >>>>>>> If the tvp514x is migrated to the MC framework, its Kconfig option >>>>>>> should depend on MEDIA_CONTROLLER. >>>>>> >>>>>> The same TVP514x driver is being used for both MC and non MC >>>>>> compatible devices, for example OMAP3 and AM35x. So if it is made >>>>>> dependent on MEDIA CONTROLLER, we cannot enable the driver for MC >>>>>> independent devices. >>>>> >>>>> Then you should use conditional compilation in the tvp514x driver >>>>> itself. Or >>>> >>>> No. I am not in favor of conditional compilation in driver code. >>> >>> Actually, thinking some more about this, you should make the tvp514x >>> driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't >>> mean that the driver will become unusable by applications that are not >>> MC-aware. Hosts/bridges don't have to export subdev nodes, they can just >>> call subdev pad-level operations internally and let applications control >>> the whole device through a single V4L2 video node. >>> >>>>> better, port the AM35x driver to the MC API. >>>> >>>> Why should we use MC if I have very simple device (like AM35x) which >>>> only supports single path? I can very well use simple V4L2 sub-dev >>>> based approach (master - slave), isn't it? >>> >>> The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but it >>> doesn't have to expose them to userspace. >> >> I don't agree. If AM35x doesn't expose the MC API to userspace, >> CONFIG_MEDIA_CONTROLLER should not be required at all. >> >> Also, according with the Linux best practices, when #if tests for config >> symbols are required, developers should put it into the header files, and >> not inside the code, as it helps to improve code readability. From >> Documentation/SubmittingPatches: >> >> 2) #ifdefs are ugly >> >> Code cluttered with ifdefs is difficult to read and maintain. Don't do >> it. Instead, put your ifdefs in a header, and conditionally define >> 'static inline' functions, or macros, which are used in the code. >> Let the compiler optimize away the "no-op" case. >> >> So, this patch is perfectly fine on my eyes. > > I'm sorry, but I don't agree. > > Regarding the V4L2 subdev pad-level API, the goal is to convert all host and > subdev drivers to it, so that's definitely the way to go. This does *not* mean > that subdevs must expose a subdev device node. That's entirely optional. What > I'm talking about is switching from video::*_mbus_fmt operations to pad::*_fmt > operations. The pad-level format operations are very similar to video-level > format operations, and more generic. Drivers shouldn't implement both. I agree that implementing two ways for doing the same thing is a bad idea, but especially since your idea is to convert all subdevs to it, this type of conversion should not require enabling CONFIG_MEDIA_CONTROLLER, as this feature is used to enable the MC userspace API. > Regarding the MC API, drivers are not required to register a media_device > instance. I have no issue with that. However, drivers should initialized the > subdev's embedded media_entity, as that's required by subdev pad-level > operations to get the number of pads for a subdev. There are two solutions: 1) add some "fallback" method at the core to use the video::*_mbus_fmt way, when MC is disabled; 2) split the config options into two: one configurable by the user to enable the userspace MC API, and another, used internally that would select the MC internal API when drivers need it. As your plan is to convert all drivers to the new way, (2) doesn't make much sense in long term, as, at the end, all drivers will be selecting it. 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. > > This will result in no modification to the userspace. > Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mauro, On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote: > Em 04-09-2011 06:01, Laurent Pinchart escreveu: > > On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: > >> Em 24-08-2011 10:25, Laurent Pinchart escreveu: > >>> On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: > >>>> On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: > >>>>> On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > >>>>>> On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > >>>>>>> On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > >>>>>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> > >>>>>>>> > >>>>>>>> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > >>>>>>>> option is disabled and if any sensor driver has to be used > >>>>>>>> between MC and non MC framework compatible devices. > >>>>>>>> > >>>>>>>> For example,if tvp514x video decoder driver migrated to > >>>>>>>> MC framework is being built without CONFIG_MEDIA_CONTROLLER > >>>>>>>> option enabled, the following error messages will result. > >>>>>>>> drivers/built-in.o: In function `tvp514x_remove': > >>>>>>>> drivers/media/video/tvp514x.c:1285: undefined reference to > >>>>>>>> `media_entity_cleanup' > >>>>>>>> drivers/built-in.o: In function `tvp514x_probe': > >>>>>>>> drivers/media/video/tvp514x.c:1237: undefined reference to > >>>>>>>> `media_entity_init' > >>>>>>> > >>>>>>> If the tvp514x is migrated to the MC framework, its Kconfig option > >>>>>>> should depend on MEDIA_CONTROLLER. > >>>>>> > >>>>>> The same TVP514x driver is being used for both MC and non MC > >>>>>> compatible devices, for example OMAP3 and AM35x. So if it is made > >>>>>> dependent on MEDIA CONTROLLER, we cannot enable the driver for MC > >>>>>> independent devices. > >>>>> > >>>>> Then you should use conditional compilation in the tvp514x driver > >>>>> itself. Or > >>>> > >>>> No. I am not in favor of conditional compilation in driver code. > >>> > >>> Actually, thinking some more about this, you should make the tvp514x > >>> driver depend on CONFIG_MEDIA_CONTROLLER unconditionally. This doesn't > >>> mean that the driver will become unusable by applications that are not > >>> MC-aware. Hosts/bridges don't have to export subdev nodes, they can > >>> just call subdev pad-level operations internally and let applications > >>> control the whole device through a single V4L2 video node. > >>> > >>>>> better, port the AM35x driver to the MC API. > >>>> > >>>> Why should we use MC if I have very simple device (like AM35x) which > >>>> only supports single path? I can very well use simple V4L2 sub-dev > >>>> based approach (master - slave), isn't it? > >>> > >>> The AM35x driver should use the in-kernel MC and V4L2 subdev APIs, but > >>> it doesn't have to expose them to userspace. > >> > >> I don't agree. If AM35x doesn't expose the MC API to userspace, > >> CONFIG_MEDIA_CONTROLLER should not be required at all. > >> > >> Also, according with the Linux best practices, when #if tests for > >> config symbols are required, developers should put it into the header > >> files, and not inside the code, as it helps to improve code > >> readability. From > >> > >> Documentation/SubmittingPatches: > >> 2) #ifdefs are ugly > >> > >> Code cluttered with ifdefs is difficult to read and maintain. Don't do > >> it. Instead, put your ifdefs in a header, and conditionally define > >> 'static inline' functions, or macros, which are used in the code. > >> Let the compiler optimize away the "no-op" case. > >> > >> So, this patch is perfectly fine on my eyes. > > > > I'm sorry, but I don't agree. > > > > Regarding the V4L2 subdev pad-level API, the goal is to convert all host > > and subdev drivers to it, so that's definitely the way to go. This does > > *not* mean that subdevs must expose a subdev device node. That's > > entirely optional. What I'm talking about is switching from > > video::*_mbus_fmt operations to pad::*_fmt operations. The pad-level > > format operations are very similar to video-level format operations, and > > more generic. Drivers shouldn't implement both. > > I agree that implementing two ways for doing the same thing is a bad idea, > but especially since your idea is to convert all subdevs to it, this type > of conversion should not require enabling CONFIG_MEDIA_CONTROLLER, as this > feature is used to enable the MC userspace API. > > > Regarding the MC API, drivers are not required to register a media_device > > instance. I have no issue with that. However, drivers should initialized > > the subdev's embedded media_entity, as that's required by subdev > > pad-level operations to get the number of pads for a subdev. > > There are two solutions: > > 1) add some "fallback" method at the core to use the video::*_mbus_fmt way, > when MC is disabled; > > 2) split the config options into two: one configurable by the user to > enable the userspace MC API, and another, used internally that would > select the MC internal API when drivers need it. > > As your plan is to convert all drivers to the new way, (2) doesn't make > much sense in long term, as, at the end, all drivers will be selecting it. But (1) makes even less sense :-) The issue here is that MC-enabled drivers will use pad-level subdev operations, so those operations need to be implemented in subdev drivers used by MC-enabled hosts/bridges. I don't like the idea of having two sets of similar operations in subdevs, as that will result in duplicate code. We should thus implement only pad-level subdev operations for MC-aware subdevs (a wrapper method can be implemented in the code to convert video operations to subdev operations transparently for non MC-aware hosts/bridges). This requires media_entity_init() and media_entity_cleanup() being available to those subdev drivers regardless of whether the host/bridge exposes the MC API to userspace. 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. > > This will result in no modification to the userspace.
> -----Original Message----- > From: Laurent Pinchart [mailto:laurent.pinchart@ideasonboard.com] > Sent: Monday, September 05, 2011 6:20 PM > To: Mauro Carvalho Chehab > Cc: Hiremath, Vaibhav; Ravi, Deepthy; linux-media@vger.kernel.org; linux- > kernel@vger.kernel.org; linux-omap@vger.kernel.org > Subject: Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and > > Hi Mauro, > > On Sunday 04 September 2011 15:32:28 Mauro Carvalho Chehab wrote: > > Em 04-09-2011 06:01, Laurent Pinchart escreveu: > > > On Sunday 04 September 2011 00:21:38 Mauro Carvalho Chehab wrote: > > >> Em 24-08-2011 10:25, Laurent Pinchart escreveu: > > >>> On Wednesday 24 August 2011 14:19:01 Hiremath, Vaibhav wrote: > > >>>> On Wednesday, August 24, 2011 5:00 PM Laurent Pinchart wrote: > > >>>>> On Wednesday 24 August 2011 13:21:27 Ravi, Deepthy wrote: > > >>>>>> On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart wrote: > > >>>>>>> On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote: > > >>>>>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> > > >>>>>>>> > > >>>>>>>> Fix the build break caused when CONFIG_MEDIA_CONTROLLER > > >>>>>>>> option is disabled and if any sensor driver has to be used > > >>>>>>>> between MC and non MC framework compatible devices. > > >>>>>>>> > > >>>>>>>> For example,if tvp514x video decoder driver migrated to > > >>>>>>>> MC framework is being built without CONFIG_MEDIA_CONTROLLER > > >>>>>>>> option enabled, the following error messages will result. > > >>>>>>>> drivers/built-in.o: In function `tvp514x_remove': > > >>>>>>>> drivers/media/video/tvp514x.c:1285: undefined reference to > > >>>>>>>> `media_entity_cleanup' > > >>>>>>>> drivers/built-in.o: In function `tvp514x_probe': > > >>>>>>>> drivers/media/video/tvp514x.c:1237: undefined reference to > > >>>>>>>> `media_entity_init' <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. > [Hiremath, Vaibhav] I completely agree that we should not be duplicating the code just for sake of it. Isn't the wrapper approach seems feasible here? Thanks, Vaibhav > > > This will result in no modification to the userspace. > > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/media/media-entity.h b/include/media/media-entity.h index cd8bca6..c90916e 100644 --- a/include/media/media-entity.h +++ b/include/media/media-entity.h @@ -121,9 +121,18 @@ struct media_entity_graph { int top; }; +#ifdef CONFIG_MEDIA_CONTROLLER int media_entity_init(struct media_entity *entity, u16 num_pads, struct media_pad *pads, u16 extra_links); void media_entity_cleanup(struct media_entity *entity); +#else +static inline int media_entity_init(struct media_entity *entity, u16 num_pads, + struct media_pad *pads, u16 extra_links) +{ + return 0; +} +static inline void media_entity_cleanup(struct media_entity *entity) {} +#endif int media_entity_create_link(struct media_entity *source, u16 source_pad, struct media_entity *sink, u16 sink_pad, u32 flags);