Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-31 Thread Mauro Carvalho Chehab 
Em Thu, 30 May 2013 21:00:01 +0200
Jon Arne Jørgensen jona...@jonarne.no escreveu:

 On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
  On Thu, 30 May 2013 07:21:36 +0200
  Jon Arne Jørgensen jona...@jonarne.no wrote:
  
   On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
Mauro Carvalho Chehab mche...@redhat.com wrote:

Em Wed, 29 May 2013 22:41:16 +0200
Jon Arne Jørgensen jona...@jonarne.no escreveu:

 Change all default values in the initial setup table to match the
table
 in the datasheet.

This is not a good idea, as it can produce undesired side effects
on the existing drivers that depend on it, and can't be easily
tested.

Please, don't change the current default. It is, of course, OK
to change them if needed via the information provided inside the
platform data.
   
I was going to make a comment along the same line as Mauro.  
Please leave the driver defaults alone.  It is almost impossible to
regression test all the different devices with a SAA7113 chip, to
ensure the change doesn't cause someone's device to not work
properly.
   
   
   You guys are totally right.
   
   What if I clone the original saa7113_init table into a new one, and
   make the driver use the new one if the calling driver sets
   platform_data.
   
   Something like this?
   
   switch (state-ident) {
   case V4L2_IDENT_SAA7111:
   case V4L2_IDENT_SAA7111A:
   saa711x_writeregs(sd, saa7111_init);
   break;
   case V4L2_IDENT_GM7113C:
   case V4L2_IDENT_SAA7113:
   - saa711x_writeregs(sd, saa7113_init);
   + if (client-dev.platform_data)
   + saa711x_writeregs(sd, saa7113_new_init);
   + else
   + saa711x_writeregs(sd, saa7113_init);
  
  I would rather have the platform_data provide the new table. Or if you
  think bulk of the table will be the same for most users, then perhaps
  add there an enum saying which table to use - and name the tables
  according to the chip variant it applies to.
  
 
 I think the bulk of the table will be the same for all drivers.
 It's one bit here and one bit there that needs changing.
 As the driver didn't support platform data.
 Changing to a new init table for the drivers that implement
 platform_data shouldn't cause any regressions.

There are several things that are very bad on passing a table via
platform data:

1) you're adding saa711x-specific data at the bridge driver,
   so, the saa711x code is spread on several places at the
   long term;

2) some part of the saa711x code may override the data there, 
   as it is not aware about what bits should be preserved from
   the new device;

3) due (2), latter changes on the code are more likely to
   cause regressions;

4) also due to (2), some hacks can be needed, in order to warn
   saa711x to handle some things differently.

That's why it is a way better to add meaningful parameters telling what
bits are needed for the driver to work with the bridge. That's also
why we do this with all other drivers.

Regards,
Mauro
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-31 Thread Timo Teras 
On Fri, 31 May 2013 10:08:27 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:

 Em Thu, 30 May 2013 21:00:01 +0200
 Jon Arne Jørgensen jona...@jonarne.no escreveu:
 
  On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
   I would rather have the platform_data provide the new table. Or
   if you think bulk of the table will be the same for most users,
   then perhaps add there an enum saying which table to use - and
   name the tables according to the chip variant it applies to.
   
  
  I think the bulk of the table will be the same for all drivers.
  It's one bit here and one bit there that needs changing.
  As the driver didn't support platform data.
  Changing to a new init table for the drivers that implement
  platform_data shouldn't cause any regressions.
 
 There are several things that are very bad on passing a table via
 platform data:

Sorry, my wording was self-conflicting. The intention was to
suggest providing an enum saying which table to use. Not that the
platform data would provide the whole table.

   1) you're adding saa711x-specific data at the bridge driver,
  so, the saa711x code is spread on several places at the
  long term;
 
   2) some part of the saa711x code may override the data there, 
  as it is not aware about what bits should be preserved from
  the new device;
 
   3) due (2), latter changes on the code are more likely to
  cause regressions;
 
   4) also due to (2), some hacks can be needed, in order to warn
  saa711x to handle some things differently.

Agreed.

 That's why it is a way better to add meaningful parameters telling
 what bits are needed for the driver to work with the bridge. That's
 also why we do this with all other drivers.

Based on the latest patch, more of these bits need to be controlled
individually than I figured. So yes, individual meaningful bits do make
the most sense.

Thanks,
 Timo
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-31 Thread Jon Arne Jørgensen 
On Fri, May 31, 2013 at 10:08:27AM -0300, Mauro Carvalho Chehab wrote:
 Em Thu, 30 May 2013 21:00:01 +0200
 Jon Arne Jørgensen jona...@jonarne.no escreveu:
 
  On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
   On Thu, 30 May 2013 07:21:36 +0200
   Jon Arne Jørgensen jona...@jonarne.no wrote:
   
On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
 Mauro Carvalho Chehab mche...@redhat.com wrote:
 
 Em Wed, 29 May 2013 22:41:16 +0200
 Jon Arne Jørgensen jona...@jonarne.no escreveu:
 
  Change all default values in the initial setup table to match the
 table
  in the datasheet.
 
 This is not a good idea, as it can produce undesired side effects
 on the existing drivers that depend on it, and can't be easily
 tested.
 
 Please, don't change the current default. It is, of course, OK
 to change them if needed via the information provided inside the
 platform data.

 I was going to make a comment along the same line as Mauro.  
 Please leave the driver defaults alone.  It is almost impossible to
 regression test all the different devices with a SAA7113 chip, to
 ensure the change doesn't cause someone's device to not work
 properly.


You guys are totally right.

What if I clone the original saa7113_init table into a new one, and
make the driver use the new one if the calling driver sets
platform_data.

Something like this?

switch (state-ident) {
case V4L2_IDENT_SAA7111:
case V4L2_IDENT_SAA7111A:
saa711x_writeregs(sd, saa7111_init);
break;
case V4L2_IDENT_GM7113C:
case V4L2_IDENT_SAA7113:
-   saa711x_writeregs(sd, saa7113_init);
+   if (client-dev.platform_data)
+   saa711x_writeregs(sd, saa7113_new_init);
+   else
+   saa711x_writeregs(sd, saa7113_init);
   
   I would rather have the platform_data provide the new table. Or if you
   think bulk of the table will be the same for most users, then perhaps
   add there an enum saying which table to use - and name the tables
   according to the chip variant it applies to.
   
  
  I think the bulk of the table will be the same for all drivers.
  It's one bit here and one bit there that needs changing.
  As the driver didn't support platform data.
  Changing to a new init table for the drivers that implement
  platform_data shouldn't cause any regressions.
 
 There are several things that are very bad on passing a table via
 platform data:
 
   1) you're adding saa711x-specific data at the bridge driver,
  so, the saa711x code is spread on several places at the
  long term;
 
   2) some part of the saa711x code may override the data there, 
  as it is not aware about what bits should be preserved from
  the new device;
 
   3) due (2), latter changes on the code are more likely to
  cause regressions;
 
   4) also due to (2), some hacks can be needed, in order to warn
  saa711x to handle some things differently.
 
 That's why it is a way better to add meaningful parameters telling what
 bits are needed for the driver to work with the bridge. That's also
 why we do this with all other drivers.
 

I agree with you here.
I never planned to pass the table via platform data.

I've just posted a new version of this patch set.
Please have a look.

Best regards
Jon Arne Jørgensen

 Regards,
 Mauro
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-30 Thread Jon Arne Jørgensen 
On Thu, May 30, 2013 at 08:33:32AM +0300, Timo Teras wrote:
 On Thu, 30 May 2013 07:21:36 +0200
 Jon Arne Jørgensen jona...@jonarne.no wrote:
 
  On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
   Mauro Carvalho Chehab mche...@redhat.com wrote:
   
   Em Wed, 29 May 2013 22:41:16 +0200
   Jon Arne Jørgensen jona...@jonarne.no escreveu:
   
Change all default values in the initial setup table to match the
   table
in the datasheet.
   
   This is not a good idea, as it can produce undesired side effects
   on the existing drivers that depend on it, and can't be easily
   tested.
   
   Please, don't change the current default. It is, of course, OK
   to change them if needed via the information provided inside the
   platform data.
  
   I was going to make a comment along the same line as Mauro.  
   Please leave the driver defaults alone.  It is almost impossible to
   regression test all the different devices with a SAA7113 chip, to
   ensure the change doesn't cause someone's device to not work
   properly.
  
  
  You guys are totally right.
  
  What if I clone the original saa7113_init table into a new one, and
  make the driver use the new one if the calling driver sets
  platform_data.
  
  Something like this?
  
  switch (state-ident) {
  case V4L2_IDENT_SAA7111:
  case V4L2_IDENT_SAA7111A:
  saa711x_writeregs(sd, saa7111_init);
  break;
  case V4L2_IDENT_GM7113C:
  case V4L2_IDENT_SAA7113:
  -   saa711x_writeregs(sd, saa7113_init);
  +   if (client-dev.platform_data)
  +   saa711x_writeregs(sd, saa7113_new_init);
  +   else
  +   saa711x_writeregs(sd, saa7113_init);
 
 I would rather have the platform_data provide the new table. Or if you
 think bulk of the table will be the same for most users, then perhaps
 add there an enum saying which table to use - and name the tables
 according to the chip variant it applies to.
 

I think the bulk of the table will be the same for all drivers.
It's one bit here and one bit there that needs changing.
As the driver didn't support platform data.
Changing to a new init table for the drivers that implement
platform_data shouldn't cause any regressions.

Best regards
Jon Arne Jørgensen

 - Timo
 --
 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
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Mauro Carvalho Chehab 
Em Wed, 29 May 2013 22:41:16 +0200
Jon Arne Jørgensen jona...@jonarne.no escreveu:

 Change all default values in the initial setup table to match the table
 in the datasheet.

This is not a good idea, as it can produce undesired side effects
on the existing drivers that depend on it, and can't be easily
tested.

Please, don't change the current default. It is, of course, OK
to change them if needed via the information provided inside the
platform data.

Regards,
Mauro
 
 Signed-off-by: Jon Arne Jørgensen jona...@jonarne.no
 ---
  drivers/media/i2c/saa7115.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/media/i2c/saa7115.c b/drivers/media/i2c/saa7115.c
 index d6f589a..4403679 100644
 --- a/drivers/media/i2c/saa7115.c
 +++ b/drivers/media/i2c/saa7115.c
 @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
  static const unsigned char saa7113_init[] = {
   R_01_INC_DELAY, 0x08,
   R_02_INPUT_CNTL_1, 0xc2,
 - R_03_INPUT_CNTL_2, 0x30,
 + R_03_INPUT_CNTL_2, 0x33,
   R_04_INPUT_CNTL_3, 0x00,
   R_05_INPUT_CNTL_4, 0x00,
 - R_06_H_SYNC_START, 0x89,
 + R_06_H_SYNC_START, 0xe9,
   R_07_H_SYNC_STOP, 0x0d,
 - R_08_SYNC_CNTL, 0x88,
 + R_08_SYNC_CNTL, 0x98,
   R_09_LUMA_CNTL, 0x01,
   R_0A_LUMA_BRIGHT_CNTL, 0x80,
   R_0B_LUMA_CONTRAST_CNTL, 0x47,
 @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
   R_0D_CHROMA_HUE_CNTL, 0x00,
   R_0E_CHROMA_CNTL_1, 0x01,
   R_0F_CHROMA_GAIN_CNTL, 0x2a,
 - R_10_CHROMA_CNTL_2, 0x08,
 + R_10_CHROMA_CNTL_2, 0x00,
   R_11_MODE_DELAY_CNTL, 0x0c,
 - R_12_RT_SIGNAL_CNTL, 0x07,
 + R_12_RT_SIGNAL_CNTL, 0x01,
   R_13_RT_X_PORT_OUT_CNTL, 0x00,
 - R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
 + R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
   R_15_VGATE_START_FID_CHG, 0x00,
   R_16_VGATE_STOP, 0x00,
   R_17_MISC_VGATE_CONF_AND_MSB, 0x00,


-- 

Cheers,
Mauro
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Andy Walls 
Mauro Carvalho Chehab mche...@redhat.com wrote:

Em Wed, 29 May 2013 22:41:16 +0200
Jon Arne Jørgensen jona...@jonarne.no escreveu:

 Change all default values in the initial setup table to match the
table
 in the datasheet.

This is not a good idea, as it can produce undesired side effects
on the existing drivers that depend on it, and can't be easily
tested.

Please, don't change the current default. It is, of course, OK
to change them if needed via the information provided inside the
platform data.

Regards,
Mauro
 
 Signed-off-by: Jon Arne Jørgensen jona...@jonarne.no
 ---
  drivers/media/i2c/saa7115.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/media/i2c/saa7115.c
b/drivers/media/i2c/saa7115.c
 index d6f589a..4403679 100644
 --- a/drivers/media/i2c/saa7115.c
 +++ b/drivers/media/i2c/saa7115.c
 @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
  static const unsigned char saa7113_init[] = {
  R_01_INC_DELAY, 0x08,
  R_02_INPUT_CNTL_1, 0xc2,
 -R_03_INPUT_CNTL_2, 0x30,
 +R_03_INPUT_CNTL_2, 0x33,
  R_04_INPUT_CNTL_3, 0x00,
  R_05_INPUT_CNTL_4, 0x00,
 -R_06_H_SYNC_START, 0x89,
 +R_06_H_SYNC_START, 0xe9,
  R_07_H_SYNC_STOP, 0x0d,
 -R_08_SYNC_CNTL, 0x88,
 +R_08_SYNC_CNTL, 0x98,
  R_09_LUMA_CNTL, 0x01,
  R_0A_LUMA_BRIGHT_CNTL, 0x80,
  R_0B_LUMA_CONTRAST_CNTL, 0x47,
 @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
  R_0D_CHROMA_HUE_CNTL, 0x00,
  R_0E_CHROMA_CNTL_1, 0x01,
  R_0F_CHROMA_GAIN_CNTL, 0x2a,
 -R_10_CHROMA_CNTL_2, 0x08,
 +R_10_CHROMA_CNTL_2, 0x00,
  R_11_MODE_DELAY_CNTL, 0x0c,
 -R_12_RT_SIGNAL_CNTL, 0x07,
 +R_12_RT_SIGNAL_CNTL, 0x01,
  R_13_RT_X_PORT_OUT_CNTL, 0x00,
 -R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
 +R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
  R_15_VGATE_START_FID_CHG, 0x00,
  R_16_VGATE_STOP, 0x00,
  R_17_MISC_VGATE_CONF_AND_MSB, 0x00,


-- 

Cheers,
Mauro
--
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

I was going to make a comment along the same line as Mauro.  
Please leave the driver defaults alone.  It is almost impossible to regression 
test all the different devices with a SAA7113 chip, to ensure the change 
doesn't cause someone's device to not work properly.

Regards,
Andy

--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Jon Arne Jørgensen 
On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
 Mauro Carvalho Chehab mche...@redhat.com wrote:
 
 Em Wed, 29 May 2013 22:41:16 +0200
 Jon Arne Jørgensen jona...@jonarne.no escreveu:
 
  Change all default values in the initial setup table to match the
 table
  in the datasheet.
 
 This is not a good idea, as it can produce undesired side effects
 on the existing drivers that depend on it, and can't be easily
 tested.
 
 Please, don't change the current default. It is, of course, OK
 to change them if needed via the information provided inside the
 platform data.
 
 Regards,
 Mauro
  
  Signed-off-by: Jon Arne Jørgensen jona...@jonarne.no
  ---
   drivers/media/i2c/saa7115.c | 12 ++--
   1 file changed, 6 insertions(+), 6 deletions(-)
  
  diff --git a/drivers/media/i2c/saa7115.c
 b/drivers/media/i2c/saa7115.c
  index d6f589a..4403679 100644
  --- a/drivers/media/i2c/saa7115.c
  +++ b/drivers/media/i2c/saa7115.c
  @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
   static const unsigned char saa7113_init[] = {
 R_01_INC_DELAY, 0x08,
 R_02_INPUT_CNTL_1, 0xc2,
  -  R_03_INPUT_CNTL_2, 0x30,
  +  R_03_INPUT_CNTL_2, 0x33,
 R_04_INPUT_CNTL_3, 0x00,
 R_05_INPUT_CNTL_4, 0x00,
  -  R_06_H_SYNC_START, 0x89,
  +  R_06_H_SYNC_START, 0xe9,
 R_07_H_SYNC_STOP, 0x0d,
  -  R_08_SYNC_CNTL, 0x88,
  +  R_08_SYNC_CNTL, 0x98,
 R_09_LUMA_CNTL, 0x01,
 R_0A_LUMA_BRIGHT_CNTL, 0x80,
 R_0B_LUMA_CONTRAST_CNTL, 0x47,
  @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
 R_0D_CHROMA_HUE_CNTL, 0x00,
 R_0E_CHROMA_CNTL_1, 0x01,
 R_0F_CHROMA_GAIN_CNTL, 0x2a,
  -  R_10_CHROMA_CNTL_2, 0x08,
  +  R_10_CHROMA_CNTL_2, 0x00,
 R_11_MODE_DELAY_CNTL, 0x0c,
  -  R_12_RT_SIGNAL_CNTL, 0x07,
  +  R_12_RT_SIGNAL_CNTL, 0x01,
 R_13_RT_X_PORT_OUT_CNTL, 0x00,
  -  R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
  +  R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
 R_15_VGATE_START_FID_CHG, 0x00,
 R_16_VGATE_STOP, 0x00,
 R_17_MISC_VGATE_CONF_AND_MSB, 0x00,
 
 
 -- 
 
 Cheers,
 Mauro
 --
 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
 
 I was going to make a comment along the same line as Mauro.  
 Please leave the driver defaults alone.  It is almost impossible to 
 regression test all the different devices with a SAA7113 chip, to ensure the 
 change doesn't cause someone's device to not work properly.


You guys are totally right.

What if I clone the original saa7113_init table into a new one, and make
the driver use the new one if the calling driver sets platform_data.

Something like this?

switch (state-ident) {
case V4L2_IDENT_SAA7111:
case V4L2_IDENT_SAA7111A:
saa711x_writeregs(sd, saa7111_init);
break;
case V4L2_IDENT_GM7113C:
case V4L2_IDENT_SAA7113:
-   saa711x_writeregs(sd, saa7113_init);
+   if (client-dev.platform_data)
+   saa711x_writeregs(sd, saa7113_new_init);
+   else
+   saa711x_writeregs(sd, saa7113_init);

break;
default:
state-crystal_freq = SAA7115_FREQ_32_11_MHZ;
saa711x_writeregs(sd, saa7115_init_auto_input);
}
if (state-ident  V4L2_IDENT_SAA7111A)
saa711x_writeregs(sd, saa7115_init_misc);

if (client-dev.platform_data) {
struct saa7115_platform_data *data = client-dev.platform_data;
saa7115_load_platform_data(state, data);
}

It's not strictly necessary, but it feels a lot cleaner?
Would you accept this into the kernel, or would it just increase
maintenance?

Best regards
Jon Arne Jørgensen

 Regards,
 Andy
 
 --
 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
--
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: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

2013-05-29 Thread Timo Teras 
On Thu, 30 May 2013 07:21:36 +0200
Jon Arne Jørgensen jona...@jonarne.no wrote:

 On Wed, May 29, 2013 at 10:19:49PM -0400, Andy Walls wrote:
  Mauro Carvalho Chehab mche...@redhat.com wrote:
  
  Em Wed, 29 May 2013 22:41:16 +0200
  Jon Arne Jørgensen jona...@jonarne.no escreveu:
  
   Change all default values in the initial setup table to match the
  table
   in the datasheet.
  
  This is not a good idea, as it can produce undesired side effects
  on the existing drivers that depend on it, and can't be easily
  tested.
  
  Please, don't change the current default. It is, of course, OK
  to change them if needed via the information provided inside the
  platform data.
 
  I was going to make a comment along the same line as Mauro.  
  Please leave the driver defaults alone.  It is almost impossible to
  regression test all the different devices with a SAA7113 chip, to
  ensure the change doesn't cause someone's device to not work
  properly.
 
 
 You guys are totally right.
 
 What if I clone the original saa7113_init table into a new one, and
 make the driver use the new one if the calling driver sets
 platform_data.
 
 Something like this?
 
 switch (state-ident) {
 case V4L2_IDENT_SAA7111:
 case V4L2_IDENT_SAA7111A:
 saa711x_writeregs(sd, saa7111_init);
 break;
 case V4L2_IDENT_GM7113C:
 case V4L2_IDENT_SAA7113:
 - saa711x_writeregs(sd, saa7113_init);
 + if (client-dev.platform_data)
 + saa711x_writeregs(sd, saa7113_new_init);
 + else
 + saa711x_writeregs(sd, saa7113_init);

I would rather have the platform_data provide the new table. Or if you
think bulk of the table will be the same for most users, then perhaps
add there an enum saying which table to use - and name the tables
according to the chip variant it applies to.

- Timo
--
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