dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Steev Klimaszewski <steev@kali.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: Thu, 9 Jul 2020 21:12:06 -0700	[thread overview]
Message-ID: <CAD=FV=VC+RP8WfS-yuc65WRN2KokNbAs-F3UdQtQoZjcMMSNFA@mail.gmail.com> (raw)
In-Reply-To: <bc795659-7dd6-c667-1c93-4331510ecfbc@kali.org>

Hi,

On Thu, Jul 9, 2020 at 8:43 PM Steev Klimaszewski <steev@kali.org> wrote:
>
>
> On 7/9/20 10:17 PM, Steev Klimaszewski wrote:
> >
> > On 7/9/20 10:12 PM, Steev Klimaszewski wrote:
> >>
> >> On 7/9/20 9:14 PM, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson <dianders@chromium.org>
> >>> wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski
> >>>> <steev@gentoo.org> wrote:
> >>>>> Hi Doug,
> >>>>>
> >>>>> I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and
> >>>>> with this patch applied, there is really bad banding on the display.
> >>>>>
> >>>>> I'm really bad at explaining it, but you can see the differences
> >>>>> in the following:
> >>>>>
> >>>>> 24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
> >>>>>
> >>>>> 18bit (5.8/linux-next) -
> >>>>> https://dev.gentoo.org/~steev/files/image1.jpg
> >>>> Presumably this means that your panel is defined improperly? If the
> >>>> panel reports that it's a 6 bits per pixel panel but it's actually an
> >>>> 8 bits per pixel panel then you'll run into this problem.
> >>>>
> >>>> I would have to assume you have a bunch of out of tree patches to
> >>>> support your hardware since I don't see any device trees in linuxnext
> >>>> (other than cheza) that use this bridge chip.  Otherwise I could try
> >>>> to check and confirm that was the problem.
> >>> Ah, interesting.  Maybe you have the panel:
> >>>
> >>> boe,nv133fhm-n61
> >>>
> >>> As far as I can tell from the datasheet (I have the similar
> >>> boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
> >>> the banding goes away!  Maybe the panel itself knows how to dither???
> >>> ...or maybe the datasheet / edid are wrong and this is actually an
> >>> 8bpp panel.  Seems unlikely...
> >>>
> >>> In any case, one fix is to pick
> >>> <https://lore.kernel.org/dri-devel/1593087419-903-1-git-send-email-kalyan_t@codeaurora.org/>,
> >>>
> >>> though right now that patch is only enabled for sc7180.  Maybe you
> >>> could figure out how to apply it to your hardware?
> >>>
> >>> ...another fix would be to pretend that your panel is 8bpp even though
> >>> it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
> >>> from the EDID they'd go back to 6bpp.  You can read the EDID of your
> >>> panel with this:
> >>>
> >>> bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
> >>> i2cdump ${bus} 0x50 i
> >>>
> >>> When I do that and then decode it on the "boe,nv133fhm-n62" panel, I
> >>> find:
> >>>
> >>> 6 bits per primary color channel
> >>>
> >>> -Doug
> >>
> >>
> >> Hi Doug,
> >>
> >> Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say
> >> it's 6-bit according to panelook's specs for it.
>
>
> I derped again...
>
> 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)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-07-10  4:12 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 [this message]
2020-07-10  6:15                 ` Steev Klimaszewski
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='CAD=FV=VC+RP8WfS-yuc65WRN2KokNbAs-F3UdQtQoZjcMMSNFA@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.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 \
    --cc=steev@kali.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).