dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Steev Klimaszewski <steev@kali.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	David Airlie <airlied@linux.ie>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Sean Paul <seanpaul@chromium.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Steev Klimaszewski <steev@gentoo.org>
Subject: Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
Date: Fri, 10 Jul 2020 01:15:28 -0500	[thread overview]
Message-ID: <f81f0d22-85d6-66eb-c8d9-345757f53959@kali.org> (raw)
In-Reply-To: <CAD=FV=VC+RP8WfS-yuc65WRN2KokNbAs-F3UdQtQoZjcMMSNFA@mail.gmail.com>

Hi,

On 7/9/20 11:12 PM, Doug Anderson wrote:
>> root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
>> root@c630:~# i2cdump ${bus} 0x50 i > edid
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-16, address 0x50, mode i2c block
>> Continue? [Y/n]
>> root@c630:~# edid-decode edid
>> edid-decode (hex):
>>
>> 00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
>> 01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
>> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
>> 01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
>> 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
>> 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
>> 00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a
>>
>> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
>> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
>> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
>> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
>> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
>> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
>> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
>> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29
>>
>> ----------------
>>
>> EDID version: 1.4
>> Manufacturer: BOE Model 2001 Serial Number 0
>> Made in week 1 of 2018
>> Digital display
>> 8 bits per primary color channel
>> DisplayPort interface
>> Maximum image size: 29 cm x 17 cm
>> Gamma: 2.20
>> Supported color formats: RGB 4:4:4, YCrCb 4:4:4
>> First detailed timing includes the native pixel format and preferred
>> refresh rate
>> Color Characteristics
>>     Red:   0.6484, 0.3447
>>     Green: 0.3310, 0.6181
>>     Blue:  0.1503, 0.0615
>>     White: 0.3125, 0.3281
>> Established Timings I & II: none
>> Standard Timings: none
>> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
>>                  1920 1968 2000 2200 ( 48  32 200)
>>                  1080 1083 1089 1120 (  3   6  31)
>>                  +hsync -vsync
>>                  VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
>> Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 1a  ................
>> Alphanumeric Data String: BOE CQ
>> Alphanumeric Data String: NV133FHM-N61
>> Checksum: 0x9a
>>
>> ----------------
>>
>> Unknown EDID Extension Block 0x03
>>     03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j.
>>     fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73  ... 9."nehwp..4s
>>     44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja
>>     92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9..
>>     66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp
>>     43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C......x..A..j(.
>>     45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E....*..5.4.>.^.
>>     30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.....1..;)
>> Checksum: 0x29 (should be 0x82)
>>
>>
>> - My edid does in fact say it's 8bit
> Crazy!  Mine:
>
> Extracted contents:
> header:          00 ff ff ff ff ff ff 00
> serial number:   09 e5 2d 08 00 00 00 00 23 1c
> version:         01 04
> basic params:    95 1d 11 78 02
> chroma info:     d5 00 a6 58 54 9f 27 0f 4f 57
> established:     00 00 00
> standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
> descriptor 1:    c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a
> descriptor 2:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> descriptor 3:    00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20
> descriptor 4:    00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a
> extensions:      00
> checksum:        40
>
> Manufacturer: BOE Model 82d Serial Number 0
> Made week 35 of 2018
> EDID version: 1.4
> Digital display
> 6 bits per primary color channel
> DisplayPort interface
> Maximum image size: 29 cm x 17 cm
> Gamma: 2.20
> Supported color formats: RGB 4:4:4
> First detailed timing is preferred timing
> Established timings supported:
> Standard timings supported:
> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
>                 1920 1968 2000 2200 hborder 0
>                 1080 1083 1089 1120 vborder 0
>                 +hsync -vsync
> Manufacturer-specified data, tag 0
> ASCII string: BOE
> ASCII string: NV133FHM-N62
> Checksum: 0x40 (valid)
>
> Unknown extension block
>
> EDID block does NOT conform to EDID 1.3!
>          Missing name descriptor
>          Missing monitor ranges
>          Detailed block string not properly terminated
> EDID block does not conform at all!
>          Has 128 nonconformant extension block(s)

I did attempt to modify the patch, and I don't think I did it correctly

Around line 232, I changed

IS_SC7180_TARGET(c->hw.hwversion))

to

IS_SC7180_TARGET(c->hw.hwversion) ||

IS_SDM845_TARGET(c->hw.hwversion))


But it would seem that only gets us 1/2 way there...

https://dev.gentoo.org/~steev/files/image2.jpg


But should I continue on this path, or should we be finding others who 
have an N61 and see what their EDID reports?

I have another c630, but unfortunately, it appears to have the IVO 
screen in it, instead of another N61.  I asked another user and he also 
had the IVO.

-- steev

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-07-10  7:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 22:35 [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP Douglas Anderson
2019-12-18 22:35 ` [PATCH v3 1/9] drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates Douglas Anderson
2020-02-03 23:31   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 2/9] drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int Douglas Anderson
2020-02-03 23:32   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 3/9] drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link Douglas Anderson
2020-02-03 23:33   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 4/9] drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta Douglas Anderson
2020-02-03 23:34   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 5/9] drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink Douglas Anderson
2020-02-03 23:35   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can Douglas Anderson
2020-02-03 23:37   ` Bjorn Andersson
2020-02-04  0:21     ` Doug Anderson
2020-02-12 23:04       ` Doug Anderson
2020-02-13  9:17         ` Neil Armstrong
     [not found]   ` <20200710011935.GA7056@gentoo.org>
2020-07-10  1:38     ` Doug Anderson
2020-07-10  2:14       ` Doug Anderson
2020-07-10  3:12         ` Steev Klimaszewski
2020-07-10  3:17           ` Steev Klimaszewski
2020-07-10  3:43             ` Steev Klimaszewski
2020-07-10  4:12               ` Doug Anderson
2020-07-10  6:15                 ` Steev Klimaszewski [this message]
2020-07-10 14:16                   ` Rob Clark
2020-07-10 14:47                   ` Doug Anderson
2020-07-10 17:10                     ` Steev Klimaszewski
2020-07-14 15:31                       ` Doug Anderson
2020-09-02 14:37                         ` Doug Anderson
2019-12-18 22:35 ` [PATCH v3 7/9] drm/bridge: ti-sn65dsi86: Group DP link training bits in a function Douglas Anderson
2020-02-03 23:39   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 8/9] drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail Douglas Anderson
2020-02-03 23:41   ` Bjorn Andersson
2019-12-18 22:35 ` [PATCH v3 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates Douglas Anderson
2020-02-03 23:43   ` Bjorn Andersson
2020-01-06 22:47 ` [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP Doug Anderson
2020-02-03 23:45 ` Bjorn Andersson
2020-02-13  9:51 ` Neil Armstrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f81f0d22-85d6-66eb-c8d9-345757f53959@kali.org \
    --to=steev@kali.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=robdclark@chromium.org \
    --cc=seanpaul@chromium.org \
    --cc=steev@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).