Hi Sascha, On Friday 26 April 2013 11:15:56 Sascha Hauer wrote: > On Fri, Apr 26, 2013 at 10:43:28AM +0200, Guennadi Liakhovetski wrote: > > On Fri, 26 Apr 2013, Sascha Hauer wrote: > > > > > That information should be conveyed by platform/DT data for the > > > > > host, and be used to convert the 12-bit media bus code into a 8-bit > > > > > media bus code in the host (a core helper function would probably > > > > > be helpful). > > > > > > > > Yes, and we discussed this before too, I think. I proposed based then > > > > to implement some compatibility table of "trivial" transformations, > > > > like a 12-bit Bayer, right-shifted by 4 bits, produces a respective 8- > > > > bit Bayer etc. Such transformations would fit nicely in soc_mediabus.c > > > > ;-) This just needs to be implemented... > > > > > > These "trivial" transformations may turn out not to be so trivial. In > > > the devicetree we would then need kind of 'shift-4-bit-left' properties. > > > > We already have a "data-shift" property exactly for this purpose. > > > > > How about instead describing the sensor node with: > > > mbus-formats = <0x3010, 0x2013>; > > > > > > and the corresponding host interface with: > > > mbus-formats = <0x3013, 0x2001>; > > > > How would this describe _how_ the transformation should be performed? > > nth index in the sensor array matches nth index in the csi array. The > above describes: > > V4L2_MBUS_FMT_SGBRG12_1X12 on the sensor matches V4L2_MBUS_FMT_SGBRG8_1X8 on > the host V4L2_MBUS_FMT_Y12_1X12 on the sensor matches V4L2_MBUS_FMT_Y8_1X8 > on the host > > effectively implementing a shift by four bits. But also more complicated > transformations could be described, like a colour space converter > implemented in a DSP (not sure if anyone does this, but you get the > idea) If there's a component on the board between the sensor and the host it should be modeled as a proper subdev. I don't think trying to describe anything more complex than shifting the lanes in the device tree sensor and/or bridge data is a good idea. > > And why does the host driver need mbus formats? > > Because mbus formats are effectively the input of a host driver. I assumed > that we translate the mbus formats the sensor can output into the > corresponding mbus formats that arrive at the host interface. Then > afterwards the usual translation from mbus to fourcc a host interface can do > is performed. I think what you aim at instead is a translation directly from > the sensor to memory which I think is more complicated to build correctly. The sensor knows what mbus formats it supports at its output, and the host knows what mbus formats it supports at its inputs. Both information can be queried from user space and kernel space. With the data lanes shift property the host can then compute the mbus format it will receive at its input. I don't think we need to specify that in DT. -- Regards, Laurent Pinchart -- 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
