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

[Steev Klimaszewski]

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'll take a look at the patch and see what I can come up with... at 
> the moment, I'm forcing it to be 8bit and that does "work fine" but 
> I'd like it to be fixed properly instead of my hack.
>
> Thanks for your time and work!
>
> -- Steev
For what it's worth - the 5.8 that I'm testing is at 
https://github.com/steev/linux/commits/c630-5.8-rc4-inline-encryption