lkml.org 
[lkml]   [2020]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can
From
Date

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'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

\
 
 \ /
  Last update: 2020-07-10 05:12    [W:0.059 / U:5.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site