RE: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-27 Thread Narnakaje, Snehaprabha 
Santiago, Kevin,

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Monday, October 26, 2009 5:35 PM
 To: santiago.nu...@ridgerun.com
 Cc: Narnakaje, Snehaprabha; davinci-linux-open-
 sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
 me...@vger.kernel.org
 Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
 
 Santiago Nunez-Corrales snu...@ridgerun.com writes:
 
  Kevin Hilman wrote:
  santiago.nu...@ridgerun.com writes:
 
 
  From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 
  This patch provides support for TVP7002 in architecture definitions
  within DM365.
 
  Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
  ---
   arch/arm/mach-davinci/board-dm365-evm.c |  170
 ++-
   1 files changed, 166 insertions(+), 4 deletions(-)
 
  diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
 davinci/board-dm365-evm.c
  index a1d5e7d..6c544d3 100644
  --- a/arch/arm/mach-davinci/board-dm365-evm.c
  +++ b/arch/arm/mach-davinci/board-dm365-evm.c
  @@ -38,6 +38,11 @@
   #include mach/common.h
   #include mach/mmc.h
   #include mach/nand.h
  +#include mach/gpio.h
  +#include linux/videodev2.h
  +#include media/tvp514x.h
  +#include media/tvp7002.h
  +#include media/davinci/videohd.h
 static inline int have_imager(void)
  @@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
   {
  - /* REVISIT when it's supported, trigger via Kconfig */
  +#ifdef CONFIG_VIDEO_TVP7002
  + return 1;
  +#else
return 0;
  +#endif
 
 
  I've said this before, but I'll say it again.  I don't like the
  #ifdef-on-Kconfig-option here.
 
  Can you add a probe hook to the platform_data so that when the tvp7002
  is found it can call pdata-probe() which could then set a flag
  for use by have_tvp7002().
 
  This will have he same effect without the ifdef since if the driver
  is not compiled in, its probe can never be triggered.
 
  Kevin
 
 
  Kevin,
 
  I've been working on this particular implementation. This
  board-dm365-evm.c is specific to the board, therefore I don't still
  get the point of not having those values wired to the board file, but
  I know it'd be nice to have the CPLD configuration triggered upon
  TVP7002 detection. I see two options:
 
 Having them in the board file is appropriate, what I object to is the
 selection by Kconfig.  Run-time detection is always preferred when
 possible.

We have this CPLD init API - evm_init_cpld() called from the dm365_evm_init() 
function. The CPLD init API was trying to initialize the CPLD, based on the 
default configuration. I believe David Brownell had this placeholder for 
have_imager() and have_tvp7002() APIs since, we have different CPLD settings 
for the imager, tvp7002 and tvp5146 for the video input source.

 
  1. Do the callback function inside pdata and initialize it at driver
  load time (tvp7002_probe). Set tvp5146 as default and override when
  driver loads (and restore when unloads).
 
 This is the preferred option to me.

We can decide on the default video input source to be TVP5146. However we do 
not need a new callback function. We already have the VPFE .setup_input 
callback API dm365evm_setup_video_input() for the same purpose. The VPFE 
.setup_input API is called when each of the decoders (sub-devices) registered 
with VPFE capture driver. It is also called when the application decides on an 
input source and switches between the input sources.

So, TVP5146 remains as the default video input source, only until VPFE probe is 
called, which registers the all decoders (sub-devices) defined in the VPFE 
platform data. This also means that the last decoder in the VPFE platform data 
remains active after boot-up. One can change the order in the VPFE platform 
data if a particular input source needs to remain active after boot-up. Note 
that application can always switch the input-source at run time.

I quickly tried removing the have_imager() construct in the evm_init_cpld() and 
here is the output -

Starting kernel ...

Uncompressing 
Linux...
 done, booting the kernel.
Linux version 2.6.32-rc2-davinci1-dirty 
...
CPU: Testing write buffer coherency: ok
DaVinci: 8 gpio irqs
NET: Registered protocol family 16
EVM: tvp5146 SD video input
bio: create slab bio-0 at 0
SCSI subsystem initialized
...
vpfe_init
vpfe-capture: vpss clock vpss_master enabled
vpfe-capture vpfe-capture: v4l2 device registered
vpfe-capture vpfe-capture: video device registered
EVM: switch to tvp5146 SD video input
tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!
vpfe-capture vpfe-capture: v4l2 sub device tvp5146 registered
EVM: switch to tvp7002 HD video input
tvp7002 1-005c: tvp7002 1-005c decoder driver registered !!
vpfe-capture vpfe-capture: v4l2 sub device tvp7002

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-27 Thread Santiago Nunez-Corrales 

Sneha,


So, if I got it right, have_tvp7002 is unnecessary since that 
initialization is done via the CPLD interface. Therefore, all I need to 
do is actually remove the logic for the device from board-dm365-evm.h. 
Am I right? If so, should I also remove the logic for tvp5146?


Regards,

Narnakaje, Snehaprabha wrote:

Santiago, Kevin,

  

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

Santiago Nunez-Corrales snu...@ridgerun.com writes:



Kevin Hilman wrote:
  

santiago.nu...@ridgerun.com writes:




From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides support for TVP7002 in architecture definitions
within DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 arch/arm/mach-davinci/board-dm365-evm.c |  170
  

++-


 1 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
  

davinci/board-dm365-evm.c


index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
 #include mach/common.h
 #include mach/mmc.h
 #include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
   static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
  static inline int have_tvp7002(void)
 {
-   /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+   return 1;
+#else
return 0;
+#endif

  

I've said this before, but I'll say it again.  I don't like the
#ifdef-on-Kconfig-option here.

Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().

This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.

Kevin




Kevin,

I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:
  

Having them in the board file is appropriate, what I object to is the
selection by Kconfig.  Run-time detection is always preferred when
possible.



We have this CPLD init API - evm_init_cpld() called from the dm365_evm_init() 
function. The CPLD init API was trying to initialize the CPLD, based on the 
default configuration. I believe David Brownell had this placeholder for 
have_imager() and have_tvp7002() APIs since, we have different CPLD settings 
for the imager, tvp7002 and tvp5146 for the video input source.

  

1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).
  

This is the preferred option to me.



We can decide on the default video input source to be TVP5146. However we do 
not need a new callback function. We already have the VPFE .setup_input 
callback API dm365evm_setup_video_input() for the same purpose. The VPFE 
.setup_input API is called when each of the decoders (sub-devices) registered 
with VPFE capture driver. It is also called when the application decides on an 
input source and switches between the input sources.

So, TVP5146 remains as the default video input source, only until VPFE probe is 
called, which registers the all decoders (sub-devices) defined in the VPFE 
platform data. This also means that the last decoder in the VPFE platform data 
remains active after boot-up. One can change the order in the VPFE platform 
data if a particular input source needs to remain active after boot-up. Note 
that application can always switch the input-source at run time.

I quickly tried removing the have_imager() construct in the evm_init_cpld() and 
here is the output -

Starting kernel ...

Uncompressing 
Linux...
 done, booting the kernel.
Linux version 2.6.32-rc2-davinci1-dirty 
...

CPU: Testing write buffer coherency: ok
DaVinci: 8 gpio irqs
NET: Registered protocol family 16
EVM: tvp5146 SD video input
bio: create slab bio-0 at 0
SCSI subsystem initialized
...
vpfe_init
vpfe-capture: vpss clock vpss_master enabled
vpfe-capture vpfe-capture: v4l2 device registered
vpfe-capture vpfe-capture: video device

RE: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-27 Thread Narnakaje, Snehaprabha 


 -Original Message-
 From: Santiago Nunez-Corrales [mailto:snu...@ridgerun.com]
 Sent: Tuesday, October 27, 2009 11:54 AM
 To: Narnakaje, Snehaprabha
 Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com;
 todd.fisc...@ridgerun.com; linux-media@vger.kernel.org
 Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
 
 Sneha,
 
 
 So, if I got it right, have_tvp7002 is unnecessary since that
 initialization is done via the CPLD interface. Therefore, all I need to
 do is actually remove the logic for the device from board-dm365-evm.h.
 Am I right? If so, should I also remove the logic for tvp5146?


Santiago,

Yes, have_tvp7002 is not necessary. In fact evm_init_cpld() is also not 
necessary from video input source selection perspective. At this point, you can 
remove have_tvp7002() and keep the default as TVP5146. The evm_init_cpld() 
requires some cleanup for have_imager() as well. I am expecting Murali to 
provide patches for this sometime soon.

This brings up another concern. Your board setup related patches are dependent 
on one of the old patches from Neil Sikka - to add TVP5146 capture support. 
That patch is not in the mainline yet and requires re-submission by Murali.

I suggest you complete the TVP7002 sub-device driver (tvp7002.c and tvp7002.h), 
submit patches and follow up with the approval in the V4L2 community.

Patches corresponding to VPFE and DM365 board setup can be handled by Murali, 
working with you.

Thanks
Sneha

 
 Regards,
 
 Narnakaje, Snehaprabha wrote:
  Santiago, Kevin,
 
 
  -Original Message-
  From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
  Sent: Monday, October 26, 2009 5:35 PM
  To: santiago.nu...@ridgerun.com
  Cc: Narnakaje, Snehaprabha; davinci-linux-open-
  sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
  me...@vger.kernel.org
  Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board
 
  Santiago Nunez-Corrales snu...@ridgerun.com writes:
 
 
  Kevin Hilman wrote:
 
  santiago.nu...@ridgerun.com writes:
 
 
 
  From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 
  This patch provides support for TVP7002 in architecture definitions
  within DM365.
 
  Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
  ---
   arch/arm/mach-davinci/board-dm365-evm.c |  170
 
  ++-
 
   1 files changed, 166 insertions(+), 4 deletions(-)
 
  diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
 b/arch/arm/mach-
 
  davinci/board-dm365-evm.c
 
  index a1d5e7d..6c544d3 100644
  --- a/arch/arm/mach-davinci/board-dm365-evm.c
  +++ b/arch/arm/mach-davinci/board-dm365-evm.c
  @@ -38,6 +38,11 @@
   #include mach/common.h
   #include mach/mmc.h
   #include mach/nand.h
  +#include mach/gpio.h
  +#include linux/videodev2.h
  +#include media/tvp514x.h
  +#include media/tvp7002.h
  +#include media/davinci/videohd.h
 static inline int have_imager(void)
  @@ -48,8 +53,11 @@ static inline int have_imager(void)
static inline int have_tvp7002(void)
   {
  -   /* REVISIT when it's supported, trigger via Kconfig */
  +#ifdef CONFIG_VIDEO_TVP7002
  +   return 1;
  +#else
  return 0;
  +#endif
 
 
  I've said this before, but I'll say it again.  I don't like the
  #ifdef-on-Kconfig-option here.
 
  Can you add a probe hook to the platform_data so that when the
 tvp7002
  is found it can call pdata-probe() which could then set a flag
  for use by have_tvp7002().
 
  This will have he same effect without the ifdef since if the driver
  is not compiled in, its probe can never be triggered.
 
  Kevin
 
 
 
  Kevin,
 
  I've been working on this particular implementation. This
  board-dm365-evm.c is specific to the board, therefore I don't still
  get the point of not having those values wired to the board file, but
  I know it'd be nice to have the CPLD configuration triggered upon
  TVP7002 detection. I see two options:
 
  Having them in the board file is appropriate, what I object to is the
  selection by Kconfig.  Run-time detection is always preferred when
  possible.
 
 
  We have this CPLD init API - evm_init_cpld() called from the
 dm365_evm_init() function. The CPLD init API was trying to initialize the
 CPLD, based on the default configuration. I believe David Brownell had
 this placeholder for have_imager() and have_tvp7002() APIs since, we have
 different CPLD settings for the imager, tvp7002 and tvp5146 for the video
 input source.
 
 
  1. Do the callback function inside pdata and initialize it at driver
  load time (tvp7002_probe). Set tvp5146 as default and override when
  driver loads (and restore when unloads).
 
  This is the preferred option to me.
 
 
  We can decide on the default video input source to be TVP5146. However
 we do not need a new callback function. We already have the VPFE
 .setup_input callback API dm365evm_setup_video_input() for the same
 purpose. The VPFE .setup_input API is called when each of the decoders
 (sub-devices

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-27 Thread Santiago Nunez-Corrales 
Understood. I will send my refactoring according to community revisions 
I have up to now and wait for integration with Murali. I have some 
questions before fully using his DV interfaces.



Regards,

Narnakaje, Snehaprabha wrote:
  

-Original Message-
From: Santiago Nunez-Corrales [mailto:snu...@ridgerun.com]
Sent: Tuesday, October 27, 2009 11:54 AM
To: Narnakaje, Snehaprabha
Cc: Kevin Hilman; davinci-linux-open-sou...@linux.davincidsp.com;
todd.fisc...@ridgerun.com; linux-media@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

Sneha,


So, if I got it right, have_tvp7002 is unnecessary since that
initialization is done via the CPLD interface. Therefore, all I need to
do is actually remove the logic for the device from board-dm365-evm.h.
Am I right? If so, should I also remove the logic for tvp5146?




Santiago,

Yes, have_tvp7002 is not necessary. In fact evm_init_cpld() is also not 
necessary from video input source selection perspective. At this point, you can 
remove have_tvp7002() and keep the default as TVP5146. The evm_init_cpld() 
requires some cleanup for have_imager() as well. I am expecting Murali to 
provide patches for this sometime soon.

This brings up another concern. Your board setup related patches are dependent 
on one of the old patches from Neil Sikka - to add TVP5146 capture support. 
That patch is not in the mainline yet and requires re-submission by Murali.

I suggest you complete the TVP7002 sub-device driver (tvp7002.c and tvp7002.h), 
submit patches and follow up with the approval in the V4L2 community.

Patches corresponding to VPFE and DM365 board setup can be handled by Murali, 
working with you.

Thanks
Sneha

  

Regards,

Narnakaje, Snehaprabha wrote:


Santiago, Kevin,


  

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, October 26, 2009 5:35 PM
To: santiago.nu...@ridgerun.com
Cc: Narnakaje, Snehaprabha; davinci-linux-open-
sou...@linux.davincidsp.com; todd.fisc...@ridgerun.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

Santiago Nunez-Corrales snu...@ridgerun.com writes:




Kevin Hilman wrote:

  

santiago.nu...@ridgerun.com writes:





From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides support for TVP7002 in architecture definitions
within DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 arch/arm/mach-davinci/board-dm365-evm.c |  170

  

++-



 1 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
  

b/arch/arm/mach-


davinci/board-dm365-evm.c



index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
 #include mach/common.h
 #include mach/mmc.h
 #include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
   static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
  static inline int have_tvp7002(void)
 {
-   /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+   return 1;
+#else
return 0;
+#endif


  

I've said this before, but I'll say it again.  I don't like the
#ifdef-on-Kconfig-option here.

Can you add a probe hook to the platform_data so that when the


tvp7002


is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().

This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.

Kevin





Kevin,

I've been working on this particular implementation. This
board-dm365-evm.c is specific to the board, therefore I don't still
get the point of not having those values wired to the board file, but
I know it'd be nice to have the CPLD configuration triggered upon
TVP7002 detection. I see two options:

  

Having them in the board file is appropriate, what I object to is the
selection by Kconfig.  Run-time detection is always preferred when
possible.



We have this CPLD init API - evm_init_cpld() called from the
  

dm365_evm_init() function. The CPLD init API was trying to initialize the
CPLD, based on the default configuration. I believe David Brownell had
this placeholder for have_imager() and have_tvp7002() APIs since, we have
different CPLD settings for the imager, tvp7002 and tvp5146 for the video
input source.

  

1. Do the callback function inside pdata and initialize it at driver
load time (tvp7002_probe). Set tvp5146 as default and override when
driver loads (and restore when unloads).

  

This is the preferred option to me.



We can decide on the default

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-26 Thread Kevin Hilman 
Santiago Nunez-Corrales snu...@ridgerun.com writes:

 Kevin Hilman wrote:
 santiago.nu...@ridgerun.com writes:

   
 From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

 This patch provides support for TVP7002 in architecture definitions
 within DM365.

 Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 ---
  arch/arm/mach-davinci/board-dm365-evm.c |  170 
 ++-
  1 files changed, 166 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
 b/arch/arm/mach-davinci/board-dm365-evm.c
 index a1d5e7d..6c544d3 100644
 --- a/arch/arm/mach-davinci/board-dm365-evm.c
 +++ b/arch/arm/mach-davinci/board-dm365-evm.c
 @@ -38,6 +38,11 @@
  #include mach/common.h
  #include mach/mmc.h
  #include mach/nand.h
 +#include mach/gpio.h
 +#include linux/videodev2.h
 +#include media/tvp514x.h
 +#include media/tvp7002.h
 +#include media/davinci/videohd.h
static inline int have_imager(void)
 @@ -48,8 +53,11 @@ static inline int have_imager(void)
   static inline int have_tvp7002(void)
  {
 -   /* REVISIT when it's supported, trigger via Kconfig */
 +#ifdef CONFIG_VIDEO_TVP7002
 +   return 1;
 +#else
 return 0;
 +#endif
 

 I've said this before, but I'll say it again.  I don't like the
 #ifdef-on-Kconfig-option here.

 Can you add a probe hook to the platform_data so that when the tvp7002
 is found it can call pdata-probe() which could then set a flag
 for use by have_tvp7002().

 This will have he same effect without the ifdef since if the driver
 is not compiled in, its probe can never be triggered.

 Kevin

   
 Kevin,

 I've been working on this particular implementation. This
 board-dm365-evm.c is specific to the board, therefore I don't still
 get the point of not having those values wired to the board file, but
 I know it'd be nice to have the CPLD configuration triggered upon
 TVP7002 detection. I see two options:

Having them in the board file is appropriate, what I object to is the
selection by Kconfig.  Run-time detection is always preferred when
possible.

 1. Do the callback function inside pdata and initialize it at driver
 load time (tvp7002_probe). Set tvp5146 as default and override when
 driver loads (and restore when unloads).

This is the preferred option to me.

 2. Add an entry to sysfs such that it can be user-configurable whether
 to activate one of the other regardless of whether tvp5156 or tvp7002
 are actually there (the only result would be fail to access the
 device).

Why do you need sysfs options for switching?  Wouldn't building as
modules and loading/unloading the needed modules serve the same
purpose?

Remeber that the 'probe' isn't going to be called until the platform_driver
is registered, and that will (usually) happen at module load time.

 Sneha, do you have any suggestions on this one?

Kevin

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

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-23 Thread Santiago Nunez-Corrales 

Kevin Hilman wrote:

santiago.nu...@ridgerun.com writes:

  

From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides support for TVP7002 in architecture definitions
within DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 arch/arm/mach-davinci/board-dm365-evm.c |  170 ++-
 1 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
 #include mach/common.h
 #include mach/mmc.h
 #include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
 
 
 static inline int have_imager(void)

@@ -48,8 +53,11 @@ static inline int have_imager(void)
 
 static inline int have_tvp7002(void)

 {
-   /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+   return 1;
+#else
return 0;
+#endif



I've said this before, but I'll say it again.  I don't like the
#ifdef-on-Kconfig-option here.

Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().

This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.

Kevin

  

Kevin,

I've been working on this particular implementation. This 
board-dm365-evm.c is specific to the board, therefore I don't still get 
the point of not having those values wired to the board file, but I know 
it'd be nice to have the CPLD configuration triggered upon TVP7002 
detection. I see two options:


1. Do the callback function inside pdata and initialize it at driver 
load time (tvp7002_probe). Set tvp5146 as default and override when 
driver loads (and restore when unloads).


2. Add an entry to sysfs such that it can be user-configurable whether 
to activate one of the other regardless of whether tvp5156 or tvp7002 
are actually there (the only result would be fail to access the device).


Sneha, do you have any suggestions on this one?


Regards,

--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com


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

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-20 Thread Santiago Nunez-Corrales 

Sekhar,

Nori, Sekhar wrote:

On Fri, Oct 16, 2009 at 00:17:46, Kevin Hilman wrote:
  

santiago.nu...@ridgerun.com writes:



From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides support for TVP7002 in architecture definitions
within DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 arch/arm/mach-davinci/board-dm365-evm.c |  170 ++-
 1 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
 #include mach/common.h
 #include mach/mmc.h
 #include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h


 static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)

 static inline int have_tvp7002(void)
 {
-   /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+   return 1;
+#else
return 0;
+#endif
  

I've said this before, but I'll say it again.  I don't like the
#ifdef-on-Kconfig-option here.

Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().

This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.



But this wouldn't work when TVP7002 is built as a module. Correct?
The current patch does not take care of the module case as well.

Patch 6/6 of this series does seem to make the TVP7002 driver available
as module.

  
Well, that was the intention given the inherent convenience of 
loading/unloading the TVP7002 driver for applications. Now, given that 
scenario, I know the #ifdef option is not elegant, but it is simple and 
accomplishes the purpose with the module approach. Any other 
suggestions/ideas?



Thanks,
Sekhar
  


Regards,

--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com


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

[PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-15 Thread santiago . nunez 
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides support for TVP7002 in architecture definitions
within DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 arch/arm/mach-davinci/board-dm365-evm.c |  170 ++-
 1 files changed, 166 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index a1d5e7d..6c544d3 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,11 @@
 #include mach/common.h
 #include mach/mmc.h
 #include mach/nand.h
+#include mach/gpio.h
+#include linux/videodev2.h
+#include media/tvp514x.h
+#include media/tvp7002.h
+#include media/davinci/videohd.h
 
 
 static inline int have_imager(void)
@@ -48,8 +53,11 @@ static inline int have_imager(void)
 
 static inline int have_tvp7002(void)
 {
-   /* REVISIT when it's supported, trigger via Kconfig */
+#ifdef CONFIG_VIDEO_TVP7002
+   return 1;
+#else
return 0;
+#endif
 }
 
 
@@ -96,8 +104,26 @@ static inline int have_tvp7002(void)
 #define CPLD_CCD_DIR3  CPLD_OFFSET(0x3f,0)
 #define CPLD_CCD_IO3   CPLD_OFFSET(0x3f,1)
 
+#define CPLD_VIDEO_INPUT_MUX_MASK  0x7
+#define CPLD_VIDEO_INPUT_MUX_TVP7002   0x1
+#define CPLD_VIDEO_INPUT_MUX_IMAGER0x2
+#define CPLD_VIDEO_INPUT_MUX_TVP5146   0x5
+
 static void __iomem *cpld;
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
+/* tvp7002 platform data, used during reset and probe operations */
+static struct tvp7002_config tvp7002_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 0,
+   .vs_polarity = 0,
+   .fid_polarity = 0,
+};
 
 /* NOTE:  this is geared for the standard config, with a socketed
  * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors.  If you
@@ -207,6 +233,140 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT)  BIT(module ? 5 : 1));
 }
 
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = Composite,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = S-Video,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+#define TVP7002_STD_ALL(V4L2_STD_525P_60   | V4L2_STD_625P_50  |\
+   V4L2_STD_NTSC  | V4L2_STD_PAL   |\
+   V4L2_STD_720P_50   | V4L2_STD_720P_60   |\
+   V4L2_STD_1080I_50  | V4L2_STD_1080I_60  |\
+   V4L2_STD_1080P_50  | V4L2_STD_1080P_60)
+
+/* Inputs available at the TVP7002 */
+static struct v4l2_input tvp7002_inputs[] = {
+   {
+   .index = 0,
+   .name = Component,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP7002_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+{
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+   .module_name = tvp5146,
+   .grp_id = VPFE_SUBDEV_TVP5146,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO(tvp5146, 0x5d),
+   .platform_data = tvp5146_pdata,
+   },
+   },
+   {
+   .module_name = tvp7002,
+   .grp_id = VPFE_SUBDEV_TVP7002,
+   .num_inputs = ARRAY_SIZE(tvp7002_inputs),
+   .inputs = tvp7002_inputs,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT1120,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO(tvp7002, 0x5c),
+   .platform_data = tvp7002_pdata,
+   },
+   },
+   {
+   .module_name =

Re: [PATCH 2/6 v5] Support for TVP7002 in dm365 board

2009-10-15 Thread Kevin Hilman 
santiago.nu...@ridgerun.com writes:

 From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

 This patch provides support for TVP7002 in architecture definitions
 within DM365.

 Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
 ---
  arch/arm/mach-davinci/board-dm365-evm.c |  170 
 ++-
  1 files changed, 166 insertions(+), 4 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
 b/arch/arm/mach-davinci/board-dm365-evm.c
 index a1d5e7d..6c544d3 100644
 --- a/arch/arm/mach-davinci/board-dm365-evm.c
 +++ b/arch/arm/mach-davinci/board-dm365-evm.c
 @@ -38,6 +38,11 @@
  #include mach/common.h
  #include mach/mmc.h
  #include mach/nand.h
 +#include mach/gpio.h
 +#include linux/videodev2.h
 +#include media/tvp514x.h
 +#include media/tvp7002.h
 +#include media/davinci/videohd.h
  
  
  static inline int have_imager(void)
 @@ -48,8 +53,11 @@ static inline int have_imager(void)
  
  static inline int have_tvp7002(void)
  {
 - /* REVISIT when it's supported, trigger via Kconfig */
 +#ifdef CONFIG_VIDEO_TVP7002
 + return 1;
 +#else
   return 0;
 +#endif

I've said this before, but I'll say it again.  I don't like the
#ifdef-on-Kconfig-option here.

Can you add a probe hook to the platform_data so that when the tvp7002
is found it can call pdata-probe() which could then set a flag
for use by have_tvp7002().

This will have he same effect without the ifdef since if the driver
is not compiled in, its probe can never be triggered.

Kevin

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