> Em 20-10-2010 10:40, Hans Verkuil escreveu:
>>
>>> Em 20-10-2010 05:07, Hans Verkuil escreveu:
>>>> On Wednesday, October 20, 2010 02:32:11 Jonathan Corbet wrote:
>>>>> OK, here's a new version of the patch, done against the V4L tree.
>>>>> Now
>>>>> with 100% fewer compiler errors! It took a while to figure out the
>>>>> API
>>>>> changes, and I'm not convinced I like them all - the controller
>>>>> driver
>>>>> didn't used to have to worry about format details, but now it does -
>>>>> but so it goes.
>>>>
>>>> I'm afraid that that change is a sign of V4L growing up and being used
>>>> in
>>>> much more demanding environments like the omap3. While the pixel
>>>> format
>>>> and
>>>> media bus format have a trivial mapping in this controller driver,
>>>> things
>>>> become a lot more complicated if the same sensor driver were to be
>>>> used
>>>> in
>>>> e.g. the omap3 SoC.
>>>>
>>>> The sensor driver does not know what the video will look like in
>>>> memory.
>>>> It
>>>> just passes the video data over a physical bus to some other device.
>>>> That
>>>> other device is what usually determines how the video data it receives
>>>> over
>>>> the bus is DMA-ed into memory. Simple devices just copy the video data
>>>> almost
>>>> directly to memory, but more complex devices can do colorspace
>>>> transformations,
>>>> dword swapping, 4:2:2 to 4:2:0 conversions, scaling, etc., etc.
>>>>
>>>> So what finally arrives in memory may look completely different from
>>>> what the
>>>> sensor supplies.
>>>>
>>>> The consequence of supporting these more complex devices is that it
>>>> also
>>>> makes simple device drivers a bit more complex.
>>>
>>> Hans,
>>>
>>> The kABI changes should not cause troubles for driver developers.
>>>
>>> I actually tried to look how to fix the conflicts, and it is not
>>> trivial
>>> to convert
>>> a driver to mbus (well, I'd say that there are 50% of chance of getting
>>> the wrong
>>> values, as just inspecting the source code, it is impossible to know if
>>> the bus
>>> is LE or BE).
>>>
>>> In a matter of fact, we're using the "MBUS" format to do two different
>>> things:
>>> a) configure the FOURCC image format;
>>> b) configure the type of mbus.
>>>
>>> While all drivers need to do (a), just a few need to do (b), as, for
>>> most
>>> cases,
>>> the bridge driver just accepts one fixed format.
>>>
>>> I can't imagine how a driver like gspca, where most of the work is done
>>> via reverse
>>> engineering could be converted correctly, as I doubt that developers
>>> have
>>> any glue
>>> about the endianness used on all webcams (or any other parameter for
>>> the
>>> streaming
>>> bus between the sensor and the bridge).
>>>
>>> So, while I understand that this is needed for complex devices used on
>>> embedded,
>>> the kABI changes should not cause troubles for other developers,
>>> otherwise, they
>>> may just put some "fake" values to workaround the kABI "pedantic"
>>> requirements,
>>> causing future problems when someone would try to use it with those
>>> more
>>> complex
>>> devices or do some other workarounds.
>>>
>>> I suspect that we'll need to do some cleanups on it, as, on all drivers
>>> but soc_camera
>>> and omap3 (and maybe a few other hardware), just passing the fourcc
>>> format
>>> is enough.
>>
>> Actually such a fake value exists: V4L2_MBUS_FIXED. This is used by most
>> if not all non-sensor subdevices. They tend to have only a single
>> format,
>> so there is no need to complicate matters. Sensors however often have
>> multiple bus formats so you need to set it up correctly. Even though a
>> sensor may at the moment only be used by a 'simple' bridge driver, that
>> doesn't mean that someone can't hook the same sensor up to an omap3 or
>> something like that.
>
> The V4L2_MBUS_FIXED applies only if the sensor supports just one fourcc
> format.
> This limits its usage.
Well, if you can support multiple formats, then why not specify them from
the very beginning? Or at least the formats currently supported by a
bridge driver. It's really the whole point of these formats that you can
actually specify what you want. Just using MBUS_FIXED in a sensor driver
will prevent it from ever being used by a more complex bridge driver. And
worse, trying to figure out the right format after the fact can be quite
difficult.
>> Sensor drivers should handle this right from the very beginning. And it
>> is
>> really not that difficult.
>>
>> Regarding gspca: reversed engineered drivers typically do not use
>> subdevices. (actually gspca doesn't use subdevs at all). So the problem
>> doesn't exist. The whole concept of a reversed engineered sensor
>> sub-device driver makes no sense.
>
> I don't agree. I think that gspca driver should be converted to use
> sensor drivers, instead of reinventing the wheel for each new webcam.
I agree for those sensors where we actually have datasheets. If it is a
reversed engineered sensor then I don't think it makes much sense. It's
very unlikely that that sensor 'driver' can ever be reused in e.g. a SoC
environment. Of course, there may be exceptions.
But yes, I would certainly applaud a move towards using sub-device sensors
in gspca where possible and reasonable.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
