Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxx> wrote:
Hi,

On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski <steev@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/>,
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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux