linux-kernel - Re: [Freedreno] [PATCH 3/3] drm/msm/dsi: Enable DATABUS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <117d21da-aa44-9439-5d5b-9a9144b53979@quicinc.com>
Date:   Fri, 23 Jun 2023 13:34:06 -0700
From:   Abhinav Kumar <quic_abhinavk@...cinc.com>
To:     Marijn Suijten <marijn.suijten@...ainline.org>
CC:     Jessica Zhang <quic_jesszhan@...cinc.com>,
        <freedreno@...ts.freedesktop.org>, Sean Paul <sean@...rly.run>,
        <dri-devel@...ts.freedesktop.org>, <linux-kernel@...r.kernel.org>,
        Rob Clark <robdclark@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        <linux-arm-msm@...r.kernel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        David Airlie <airlied@...il.com>
Subject: Re: [Freedreno] [PATCH 3/3] drm/msm/dsi: Enable DATABUS_WIDEN for DSI
 command mode



On 6/23/2023 1:14 PM, Marijn Suijten wrote:
> On 2023-06-23 10:29:51, Abhinav Kumar wrote:
> <snip>
>> The concept is quite simple
>>
>> one pixel per clock for uncompresssed without widebubus
>>
>> 2 pixels per clock for uncompressed with widebus (only enabled for DP
>> not DSI)
>>
>> 3 bytes worth of data for compressed without widebus
>>
>> 6 bytes worth of data for compressed with widebus
>>
>> When compression happens, we cannot quantify with pixels as the boundary
>> is not defined with respect to bytes.
>>
>> You brought up uncompressed in your below comment so I assumed your
>> question of /2 was about uncompressed too.
> 
> No clue where things are going wrong, but you either avoid or
> misunderstand the question.
> 
> (Talking exclusively about compressed data here!)
> 
> pclk is determined based on the number of bytes.
> 
> When widebus is enabled, we transfer twice as many bytes per pclk cycle.
> 
> Can pclk be reduced by a factor two, as that should still be enough to
> transfer the same amount of bytes when widebus is enabled?
> 

I dont know where the misunderstanding is too.

I already did answer that pclk can be /2 for uncompressed.

But for compressed it will be divided by the compression ration.

What is still missing here. Please clarify.

>>>> We tried our best to respond and explain to all your queries both on the
>>>> bug and the patch but i guess it just kept coming :)
>>>
>>> Then send less patches!  As long as there is activity on the mailing
>>> list there'll always be questions going back and forth, and I don't
>>> think that's unreasonable.
>>>
>>> Unless you want to push patches into mainline without questioning.
>>>
>>
>> the comments were bordering the line of becoming irrelevant to the
>> patches like discussing video mode on a command mode patch when we had
>> explained many many times that we did not validate them.
> 
> You(r team) came up with irrelevant video-mode checks in these patches,
> and you keep bringing up topics that I did not mention (such as
> suddently talking about uncompressed formats above).  Stop pretending
> there's any nefarious intent here unless you intend to push external
> contributors away.
> 

There is no nefarious intent. If it was there we would not have spent 2 
weeks to answer every question on the bug and explaining every math 
about it despite calling our patches hacks.

So either something is still missing in our answers or the questions.

So please ask the question whatever has not been answered one more time.

>> I dont want to add more comments to this. Lets stop discussing this and
>> focus more on this patch.
> 
> Perhaps if you answer the question?
> 
> - Marijn