[PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

Peter Ujfalusi peter.ujfalusi at ti.com
Fri Mar 15 14:04:42 UTC 2019



On 15/03/2019 15.30, Tomi Valkeinen wrote:
> On 15/03/2019 14:28, Peter Ujfalusi wrote:
>> On 15/03/2019 14.07, Tomi Valkeinen wrote:
>>>> If the pclk-sample is not defined in DT, it will default to 0 which
>>>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>>>
>>>> But all the boards where I can find schematics with tfp410 have their
>>>> EDGE/HTPLG pin pulled up and according to the documentation when EDGE=1
>>>> then tfp410 will sample on the rising edge.
>>>>
>>>> imho the pclk_sample should be initialized to 1 to avoid regression for
>>>> most of the boards using tfp410.
>>>
>>> Define "regression" =). If the omapdrm driver was always using
>>> DRIVE_POSEDGE, this driver should also be using DRIVE_POSEDGE, no? If it
>>> does the same as the old driver, it can't be a regression. This is, of
>>> course, only considering omapdrm based boards.
>>>
>>> That said, it sounds odd that this would be wrong in the old driver, but
>>> then again, it might well be, as code related to these sync signals has
>>> changed sooo many times, and the related DSS registers are somewhat
>>> confusing.
>>
>> On the boards data skew is enabled as well with maximum delay selected
>> with DK1=DK2=DK3=1, so sampling of data is delayed by 3 * 350 ps, so
>> about 1 ns, not much, but might be enough for the signal to transition
>> on the bus so even if the HW drivers on POSEDGE and tfp410 samples on
>> POSEDGE (+1ns delay from the edge) we don't see corruption?
> 
> Ok. I don't think anyone has looked at it that closely. So, the syncs
> could well be wrong. Still, not a regression if it's the same way as it was.

True.

> If the fixed default works fine (or better) than the wrong ones, I think
> that can be the default. But I'd be careful about changing what the
> default is, if we've had it the old way for a long time.

The HW default in I2C mode is the EDGE=1 so SAMPLE_POSEDGE and it looks
to me that the same default was implemented via hw control on the boards
I can access the schematics.

If it was the other way in the past, then it is safer to not change the
default in the driver, but probably put a comment somewhere that the HW
default is the opposite?

In any case if the i2c control is implemented we will read and/or
configure the tfp410 anyways.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the dri-devel mailing list