On 02/17/2017 03:38 AM, Philipp Zabel wrote:
On Fri, 2017-02-17 at 11:06 +0000, Russell King - ARM Linux wrote:
On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
+static void csi2_dphy_init(struct csi2_dev *csi2)
+ * FIXME: 0x14 is derived from a fixed D-PHY reference
+ * clock from the HSI_TX PLL, and a fixed target lane max
+ * bandwidth of 300 Mbps. This value should be derived
If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?
I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.
I had code to calculate the number of needed lanes from the bit rate and
link frequency. I did not actually change the D-PHY register value.
And as you pointed out, calculating the number of lanes is not useful
without input from the sensor driver, as some lane configurations might
not be supported.
Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters. (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters. gcd() doesn't
help you in this instance.)
The tc358743 also currently only implements a fixed rate (of 594 Mbps).
I've analyzed the OV5640 video modes, and they generate the following
"sysclk"'s in Mhz:
But I don't know whether this is equivalent to bit rate. Is it the same
as Mbps-per-lane? If so, this could be indicated to the sink by
implementing V4L2_CID_LINK_FREQ in the ov5640.c sensor driver.
The Mbps-per-lane value would then be link_freq * 2, and then
Mbps-per-lane could be used to lookup the correct "hsfreqsel"
value to program the D-PHY.
I've added this to imx6-mipi-csi2.c. If the source didn't implement
V4L2_CID_LINK_FREQ then it uses a default 849 Mbps-per-lane.