Re: RFC: Move the deprecated et61x251 and sn9c102 to staging

[Hans de Goede <hdegoede@redhat.com>]

Hi,

One small correction to the sn9c102 sensor table, the
mt9v111 sensor is handled by sonixj, so the table of
bridge/sensor combi's supported by sn9c102, looks like this:

sn9c101/102:
hv7131d
mi0343 *
ov7630
pas106b
pas202bcb
tas5110c1b
tas5110d
tas5130d1b

sn9c103:
hv7131r *
mi0360 *
ov7630
pas202bcb

sn9c105/120:
hv7131r
mi0360
mt9v111
ov7630
ov7660

So only 3 raw bayer + custom compression models supported by
sn9c102 are not supported by gspca_sonixb, and all jpeg models
are supported by gspca_sonixj. Porting the 3 remaining models
over should be relatively easy, but I (I more or less maintain
the sonixb driver) really need hardware access to ensure things
stay working.

Second correction, I was looking at an old tree and failed to
notice that the zc0301 driver has already bitten the dust
(good!).

Regards,

Hans

On 01/02/2011 05:34 PM, Hans de Goede wrote:
> Hi,
>
> On 01/02/2011 12:25 PM, Hans Verkuil wrote:
>> On Sunday, January 02, 2011 11:41:31 Mauro Carvalho Chehab wrote:
>>> Em 01-01-2011 17:53, Hans Verkuil escreveu:
>>>> The subject says it all:
>>>>
>>>> If there are no objections, then I propose that the deprecated et61x251 and
>>>> sn9c102 are moved to staging for 2.6.38 and marked for removal in 2.6.39.
>>>
>>> Nack.
>>>
>>> There are several USB ID's on sn9c102 not covered by gspca driver yet.
>>
>> Why are these drivers marked deprecated then?
>>
>
> You'll have to look at me for the deprecation marking.
>
> I did this because they are unmaintained and buggy in some areas and thus really
> should go away. Also note that looking at usb-id's is *not* useful with these
> drivers as when Luca wrote them he simply included large lists of usb-id's without
> the drivers actually being tested with cams with those id's. Usually when a bridge
> supports a range of configurable id's, this is used to have one generic (win32)
> driver and the usb product id indicates which sensor is used.
>
> I did a patch removing a whole bunch of usb-id's from the sn9c102 driver in the
> past as we knew which sensors those id's corresponded with and Luca's driver never
> supported these sensors, so the claiming of the usb-id's was bogus.
>
> However for many usb-id's claimed by the sn9c102 driver we don't know what sensor
> they belong to (or if any devices with that id exists out there at all), so I left
> them in to not cause regressions.
>
> So if we want to see where we stand wrt replacing Luca's old drivers with gspca
> subdrivers, you should look at the list of supported sensors.
>
> I've made a list for all sn9c102 supported bridge + sensor combinations and
> marked the ones which are not yet supported by gscpa:
>
> sn9c101/102:
> hv7131d
> mi0343 *
> ov7630
> pas106b
> pas202bcb
> tas5110c1b
> tas5110d
> tas5130d1b
>
> sn9c103:
> hv7131r *
> mi0360 *
> ov7630
> pas202bcb
>
> sn9c105/120:
> hv7131r
> mi0360
> mt9v111 *
> ov7630
> ov7660
>
> So we have 3 models not yet supported in the sonixb driver (and sonixb
> cams are quite rare now a days). And 1 model in the sonixj driver.
>
> Note btw that I've disabled all Luca's drivers (et61x251, sn9c102 and
> zc0301) in Fedora kernels for several Fedora releases already and sofar
> I've received one bug report about this, which is resolved now as I
> recently added support for the hv7131d sensor to the sonixb driver
> (thanks to said bug report).
>
> So all in all I believe that moving the sn9c102 driver to staging, or
> at least remove all usb-id's which are a doublure with gspca's sonixb
> and sonixj drivers is the right thing to do.
>
>>> It seems to me that et61x251 will also stay there for a long time, as there are
>>> just two devices supported by gspca driver, while et61x251 supports 25.
>>>
>>> Btw, we currently have a conflict with this USB ID:
>>> USB_DEVICE(0x102c, 0x6151),
>>>
>>> Both etoms and et61x251 support it, and there's no #if to disable it on one
>>> driver, if both drivers are compiled. We need to disable it either at gspca_etoms
>>> or at et61x251, in order to avoid users of having a random experience with this
>>> device.
>>
>> Surely such devices should be removed from et61x251 or sn9c102 as soon as they are
>> added to gspca?
>
> The problem is that the initial gspcav2 core + subdrivers as it entered the mainline
> is derived from / a partial rewrite of the out of tree v4l1 gspca drivers / framework
> as such the register init sequences for bridges + sensors were not all tested when
> gspca entered the mainline so in the case of untested bridge + sensor combo's which
> were already supported by Luca's mainline drivers, we added #ifdef's to use Luca's
> drivers in case both are compiled in. As more and more people tested the gspca drivers
> most of these #ifdef's were reversed to prefer the gspca sub drivers if both
> were compiled in, one ubs-id at a time.
>
> Looking at both drivers, the gspca one supports both the tas5130 and pas106 sensors,
> where as the et61x251 driver only supports the tas5130 sensor. The conflicting usb id
> 102c:6151 is for a camera with the pas106 sensor, so the solution is to remove this
> usb id from the et61x251 driver, as it does not support this id, despite claiming it.
>
> Looking closer at the et61x251 driver, one finds this beauty inside
> et61x251_tas5130d1b.c, which is the only sensor module for the et61x251 driver:
>
> int et61x251_probe_tas5130d1b(struct et61x251_device* cam)
> {
> const struct usb_device_id tas5130d1b_id_table[] = {
> { USB_DEVICE(0x102c, 0x6251), },
> { }
> };
>
> /* Sensor detection is based on USB pid/vid */
> if (!et61x251_match_id(cam, tas5130d1b_id_table))
> return -ENODEV;
>
> ...
>
> IOW the et61x251 driver, in classical Luca style if I may say so, only supports usb id
> 102c:6251, despite claiming many many more. So moving forward we should:
>
> 1) Remove all bogus usb id's from the et61x251 driver, as trying to use any of these
> devices with it will fail, as it won't be able to find a working sensor module
> (I thought I did a patch for this once before, but either my memory is failing or
> the patch got lost).
>
> 2) Since it then 100% overlaps with the etoms driver, move it to staging
>
> ###
>
> I notice that the zc0301 driver is missing from your list to move to staging, it
> 100% overlaps with the gspca zc3xx driver. And where as the zc0301 driver
> only claims to support 2 usb-id's (and 2 sensor types), the gspca zc3xx driver
> supports 53 usb id's and 19 sensor types.
>
> Note that the zc3xx bridge is special in that the usb-id does not always uniquely
> identify a bridge/sensor combo. One needs to do actual i2c bus probing to figure
> out which sensor is attached (like with the ov51x / ovfx2 bridges)...
>
> And the zc0301 driver claims to support the 0ac8:303b, which is a generic
> id, which may ship with many types of sensors, including many not supported by
> the zc0301 driver, so effectively it only supports 1 usb-id properly.
>
> So the zc0301 driver should be moved to staging too IMHO.
>
> Regards,
>
> Hans