Re: What todo with cams which have 2 drivers?

[Hans Verkuil <hverkuil@xxxxxxxxx>]

On Tuesday 26 August 2008 23:26:41 Hans de Goede wrote:
> Hans Verkuil wrote:
> > 
> > In general I am getting worried by the lack of a common standard to
> > interface to sensor and controller drivers. I'm no expert on webcams, so
> > correct me if I'm wrong, but it seems to me that the correct design would
> > be to have a generic API to these devices that can be used by the various
> > USB or platform drivers.
> > 
> > But for e.g. the mt9* sensors we have three that use the soc_camera
> > interface, one using the sn9c102 interface and I know of two more that
> > are not yet in v4l-dvb but that will use the v4l2-int-device.h interface.
> > It's a mess in my opinion.
> > 
> 
> It is indeed, in my experience so far the easiest solution is to see the bridge 
> and sensor (and this the whole cam) as one device. 80% of the per sensor code 
> in a bridge driver is setting up the bridge to talk to the cam (there are 
> various connections between the 2 possible and most bridges support multiple 
> connection types) and 80% of the sensor code is configuring the sensor for a 
> specific bridge (same story). The remaining 20% of sensor code is rather boring 
>   (poking registers to set things like conteast and brightness) and since the 
> sensor needs to be programmed to talk to the bridge in a bridge specific way 
> there is little to gain from having seperate sensor drivers as those still need 
> to be patched for a new bridge type before the sensor will work with a certain 
> bridge.
> 
> If you for example look at the attempting to be generic ovchipcam drivers in 
> the current kernel tree, which contain code for the ov6xxx and ov7xxx sensors, 
> then the attach routine contains the following:
> 
>          switch (adap->id) {
>          case I2C_HW_SMBUS_OV511:
>          case I2C_HW_SMBUS_OV518:
>          case I2C_HW_SMBUS_W9968CF:
>                  PDEBUG(1, "Adapter ID 0x%06x accepted", adap->id);
>                  break;
>          default:
>                  PDEBUG(1, "Adapter ID 0x%06x rejected", adap->id);
>                  return -ENODEV;
>          }
> 
> IOW this generic sensor code will only work with 3 know bridges and some of the 
> code itself is bridge specific too, for example in ov6x30.c :
> 
>          if (win->format == VIDEO_PALETTE_GREY) {
>                  if (c->adapter->id == I2C_HW_SMBUS_OV518) {
>                          /* Do nothing - we're already in 8-bit mode */
>                  } else {
>                          ov_write_mask(c, 0x13, 0x20, 0x20);
>                  }
>          } else {
>                  /* The OV518 needs special treatment. Although both the OV518
>                   * and the OV6630 support a 16-bit video bus, only the 8 bit Y
>                   * bus is actually used. The UV bus is tied to ground.
>                   * Therefore, the OV6630 needs to be in 8-bit multiplexed
>                   * output mode */
> 
>                  if (c->adapter->id == I2C_HW_SMBUS_OV518) {
>                          /* Do nothing - we want to stay in 8-bit mode */
>                          /* Warning: Messing with reg 0x13 breaks OV518 color */
>                  } else {
>                          ov_write_mask(c, 0x13, 0x00, 0x20);
>                  }
>          }
> 
> I've done a comparison of code size between trying to use generic sensor code 
> (which isn't that generic at all see above) and just putting sensor specific 
> code into each bridge driver separately, see:
> http://marc.info/?l=linux-video&m=121645882518114&w=2
> 
> So my conclusion (for now) is that trying to separate the sensor code out of 
> the bridge drivers is not worth it. I plan to rewrite the ov511/ov518 driver 
> for v4l2 using gspca (so that libv4l can be used to decode the special JPEG-ish 
> format making these cams actually work). For this rewrite I will probably 
> remove the ovcamchip stuff and just put sensor init and ctrl code in the bridge 
> driver, probably resulting in a smaller driver.

Interesting results. And I think it makes sense for these sensor devices. It
definitely does not make sense elsewhere (e.g. the video/audio encoder and
decoder i2c devices are very much reusable in other drivers).

I think it is a reasonable approach. I'm getting very annoyed at all the
attempts at creating generic APIs for these devices, which is probably an
indication that this approach might not be a good fit here.

> > I think it would be interesting to discuss this further with you in Portland.
> 
> Yes it would, I think we need to make an agenda what we want to discuss (both 
> in the miniconf and outside of that).

Mauro intends to organize discussion sessions in addition to the miniconf itself.
There will be no lack of topics to talk about.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list