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