media: ti-vpe: cal: Fix ths_term/ths_settle parameters
authorBenoit Parrot <bparrot@ti.com>
Tue, 12 Nov 2019 14:53:36 +0000 (15:53 +0100)
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Mon, 9 Dec 2019 10:27:25 +0000 (11:27 +0100)
commit5f9f2fb7c46f00d1b6a7b1ab743daf8f993148d4
treeb9eb5b337c732170725d3cb21dfacabe2d742589
parent6713feb7c6fdad329bd4168a9d2f7d5e9a67099a
media: ti-vpe: cal: Fix ths_term/ths_settle parameters

The current method to calculate the ddr clk period is wrong.
Therefore the ths_term calculation is incorrect.
Also it was wrongly assumed that the ths_settle parameter
was based on the control clock instead of the pixel clock.

Since the DPHY can tolerate quite a bit a of variation,
capture was still mostly working with the 2 tested modes
when the pixel clock was close to the control clock
(i.e. 96 Mhz). But it would quickly stops working when
using different modes or when customers used different
sensors altogether.

Calculating the DDRClk period needs to take into account
the pixel bit width and the number of active data lanes.

Based on the latest technical reference manual these
parameters should now be calculated as follows:

THS_TERM: Programmed value = floor(20 ns/DDRClk period)
THS_SETTLE: Programmed value = floor(105 ns/DDRClk period) + 4

Also originally 'depth' was used to represent the number of
bits a pixel would use once stored in memory (i.e. the
container size). To accurately calculate the THS_* parameters
we need to use the actual number of bits per pixels coming
in from the sensor. So we are renaming 'depth' to 'bpp' (bits
per pixels) and update the format table to show the actual
number of bits per pixel being received.

The "container" size will be derived from the "bpp" value.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
drivers/media/platform/ti-vpe/cal.c