RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-06 Thread Hiremath, Vaibhav 

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Monday, September 05, 2011 6:20 PM
 To: Mauro Carvalho Chehab
 Cc: Hiremath, Vaibhav; Ravi, Deepthy; linux-me...@vger.kernel.org; linux-
 ker...@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 hvaib...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-06 Thread Laurent Pinchart 
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.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-06 Thread Mauro Carvalho Chehab 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-05 Thread Laurent Pinchart 
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 hvaib...@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

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-04 Thread Laurent Pinchart 
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 hvaib...@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.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-04 Thread Mauro Carvalho Chehab 
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 hvaib...@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

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-09-03 Thread Mauro Carvalho Chehab 
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 hvaib...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Laurent Pinchart 
On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@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 hvaib...@ti.com
 Signed-off-by: Deepthy Ravi deepthy.r...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Ravi, Deepthy 
On Wed, Aug 24, 2011 at 4:47 PM, Laurent Pinchart
[laurent.pinch...@ideasonboard.com] wrote:
 On Friday 19 August 2011 15:48:45 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@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 hvaib...@ti.com
 Signed-off-by: Deepthy Ravi deepthy.r...@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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Laurent Pinchart 
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 hvaib...@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.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Hiremath, Vaibhav 

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, August 24, 2011 5:00 PM
 To: Ravi, Deepthy
 Cc: mche...@infradead.org; linux-me...@vger.kernel.org; linux-
 ker...@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 hvaib...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Andy Shevchenko 
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.

-- 
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Hiremath, Vaibhav 

 -Original Message-
 From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com]
 Sent: Wednesday, August 24, 2011 6:26 PM
 To: Hiremath, Vaibhav
 Cc: Laurent Pinchart; Ravi, Deepthy; mche...@infradead.org; linux-
 me...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
 o...@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.shevche...@linux.intel.com
 Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Laurent Pinchart 
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 hvaib...@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.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

2011-08-24 Thread Hiremath, Vaibhav 

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Wednesday, August 24, 2011 6:56 PM
 To: Hiremath, Vaibhav
 Cc: Ravi, Deepthy; mche...@infradead.org; linux-me...@vger.kernel.org;
 linux-ker...@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 hvaib...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html