[PATCHv2 03/22] drm/bridge: tc358767: fix ansi 8b10b use

[Tomi Valkeinen]

On 23/04/2019 17:56, Laurent Pinchart wrote:

>> During initial driver development I had one eDP display that reports 0 in Bit 0
>> (ANSI 8B/10B) of DPCD reg 0x0006 (MAIN_LINK_CHANNEL_CODING).
>> Also it does not react on setting Bit 0 (SET_ANSI 8B10B) in 0x0108
>> (MAIN_LINK_CHANNEL_CODING_SET) - after reading back it was 0 again.
>> So I had to disable 8B10 encoding on tc358767 side to make this display
>> work.
> 
> Out of curiosity, how does the eDP display recover the clock without
> 8B/10B encoding ?
> 
>> On other hand if there are displays that report zero bit 0 in
>> MAIN_LINK_CHANNEL_CODING while needing 8b10b then this patch looks
>> reasonable.
>>
>> May be driver should read back MAIN_LINK_CHANNEL_CODING_SET
>> register after setting it and check if 8b10b actually enabled?
> 
> This sounds like a reasonable thing to try. Tomi, do you still have
> accesss to those faulty monitors ?

On my monitor it does not seem to matter whether I write 0 or 1 to
MAIN_LINK_CHANNEL_CODING_SET, as long as I have 8b10b enabled on
TC358767 side. The writes do go through, and I can read the written bit
back.

So... I guess when we talk about eDP panels, there may be all kinds of
oddities, as they're usually meant to be used with a certain configuration.

But if everyone agrees that 8B10B is a normal, required feature of DP,
and there is an eDP panel that needs 8B10B disabled, maybe that panel
has to be handled separately as a special case? A dts entry to disable
8B10B? Or something. But it does not sound like a good idea for the
driver to try to guess this.

 Tomi

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