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: <26e3a5a5-2fcb-34ca-4644-8c37bd17a1e9@quicinc.com>
Date:   Fri, 23 Jun 2023 14:47:25 -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 2:33 PM, Marijn Suijten wrote:
> On 2023-06-23 13:34:06, Abhinav Kumar wrote:
>>
>>
>> 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.
> 
> Except that my question is about compressed.
> 
>> But for compressed it will be divided by the compression ration.
> 
> The question here is "why exactly"?  I am looking for the argument that
> justifies pclk being twice as high for the number of bytes we need to
> send.
> 

Ok I think I finally got your question. So you are asking that "Why 
cannot we half the pclk even for the compressed case?"

So pclk / = comp_ratio and then
further on top of that
pclk /= 2 for widebus?

Is that your question?

If so pls see below

> Is that answer: pclk is not only used for the bus between DPU and DSI?
> 
> If the answer to that question is yes, then I'd ask what the advantage
> is of widebus.
> 

pclk is only used between DPU and DSI.

let me explain the purpose of widebus.

If we take an input of 30bpp, then without widebus DPU can only send 24 
bits out.

So the compression ratio which we can achieve would only be 2.4 and not 
3 (24/10)

But with widebus, it can output 48bits and now since your source bpp is 
only 30bits we can send it out fully and get the 3:1 compression ratio.

So widebus actually makes it possible to get the full compression in the 
30bpp case. That would be the benefit of widebus for DSI.

Hope i was able to explain it now.

> <snip>
> 
> Let's leave the rest for what it is.
> 
> - Marijn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ