On Mon, May 6, 2019 at 2:59 AM Tomi Valkeinen wrote:
>
> Hi Laurent, Andrey,
>
> On 03/05/2019 20:11, Laurent Pinchart wrote:
> >> I agree that if the panel Andrey mentioned is still used, we need to
> >> handle it somehow. But I think explicitly handling such a case is better
> >> than guessing.
Hi Laurent, Andrey,
On 03/05/2019 20:11, Laurent Pinchart wrote:
>> I agree that if the panel Andrey mentioned is still used, we need to
>> handle it somehow. But I think explicitly handling such a case is better
>> than guessing.
>
> The risk may not be worth it, I agree. I would explain this in
Hi Tomi,
On Fri, May 03, 2019 at 04:17:41PM +0300, Tomi Valkeinen wrote:
> On 03/05/2019 15:48, Laurent Pinchart wrote:
> > On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
> >> On 23/04/2019 17:56, Laurent Pinchart wrote:
> >>
> During initial driver development I had one eDP
On 03/05/2019 15:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
>> 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 0
Hi Tomi,
On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
> 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
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
Hi Laurent,
On Tue, Apr 23, 2019 at 5:56 PM Laurent Pinchart
wrote:
>
> Hi Andrey,
>
> On Tue, Apr 23, 2019 at 11:19:17AM +0300, Andrey Gusakov wrote:
> > On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart wrote:
> > > On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> > >> DP alway
Hi Andrey,
On Tue, Apr 23, 2019 at 11:19:17AM +0300, Andrey Gusakov wrote:
> On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> >> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> >> the ANSI 8B10B b
Hi Laurent,
On Sun, Apr 21, 2019 at 12:14 AM Laurent Pinchart
wrote:
>
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> > DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> > the ANSI 8B10B bit set in DPCD, even if
Hi Tomi,
Thank you for the patch.
On Tue, Mar 26, 2019 at 12:31:27PM +0200, Tomi Valkeinen wrote:
> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> the ANSI 8B10B bit set in DPCD, even if it should always be set.
Makes you wonder why the bit is present :-) I've checked th
On 26.03.2019 11:31, Tomi Valkeinen wrote:
> DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
> the ANSI 8B10B bit set in DPCD, even if it should always be set.
>
> The tc358767 driver currently respects that flag, and turns the encoding
> off if the monitor does not have the b
DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
the ANSI 8B10B bit set in DPCD, even if it should always be set.
The tc358767 driver currently respects that flag, and turns the encoding
off if the monitor does not have the bit set, which then results in the
monitor not workin
12 matches
Mail list logo
