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?
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.
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