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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
