<krzk>
aka_[m]: you like to paste some links which do not work (need to download some stuff),it does not work like that. Links to pastebin-like would be ok, but forcing me to download just to see your response is not okay.
<krzk>
Really, using matrix for IRC is quite annoying for us, thus I just going to ignore such messages.
<aka_[m]>
ok, its on patchwork now, sorry
<Marijn[m]>
That's probably just matrix expanding the link to a webpage preview (image attachment) though the original link should be retained?
<aka_[m]>
i need to check how all of this look via irc
<krzk>
looks much poorer and less readable...
<krzk>
Also, longer messages are trimmed requiring to go to web page to get full message.
<Marijn[m]>
Hmm the raw body ("view source") in a matrix client contains the raw link... but sending a link makes the irc<->matrix bridge send the entire message as a downloadable HTML page. That's stupid
<krzk>
and the worse is how replies to messages look like. It's IMHO, unreadable.
<krzk>
look:
<krzk>
Librecat[m]> <ivoszbg[m]> "might be because of rgb888..." <- an older commit works with simplefb perfectly though
<krzk>
who replied to whom and why I need to go through some text to find actual answer... I am just ignoring such messages
<Marijn[m]>
That looks equally bad :)
dv_ has quit [Quit: WeeChat 3.0]
<aka_[m]>
What exactly is a difference between using qcom,ipc and mboxes?
<aka_[m]>
from what i see both describe bit location
<aka_[m]>
for qcom-ipc its base_reg offset bit, for mboxes its using register specified inside qcom_apcs_ipc_data and then later bit number
pespin has joined #linux-msm
<Marijn[m]>
aka_: I recall converting mboxes to ipc, afaik one is the old binding?
<minecrell>
Marijn[m]: it's the other way around, ipc is old and mbox is new
<Marijn[m]>
Hehe, then I've converted it the other way around but never fixup!-squashed or sent that patch
<Marijn[m]>
The numbers in dts are wrong anyway, and a fix for that likely got lost in the ether too
<aka_[m]>
so what would bre preferable? fixing and then converting to mboxes?
<aka_[m]>
or just keeping it ipc
<aka_[m]>
or like "Fix and convert to mboxes"
<aka_[m]>
tho using mboxes force us to be sure noone ever dare to switch data in driver so we don't end out-of register
<aka_[m]>
hmm, smsm still requires qcom,ipc-X binding
<Marijn[m]>
aka_: I think we converted the driver to support the new `mboxes` on a different driver or something. I've got some patches here but they're not mine, I'll ask the respective persont o make them public
<ungeskriptet>
Marijn: I just tried setting is_dual_dsi=false and this is how it looks
<ungeskriptet>
The lmdpdg driver also flickers green like this
<ungeskriptet>
Could it maybe be missing clocks? I remember I couldn't get simplefb working without disabling dispcc completely when booting without clk_ignore_unused
<Marijn[m]>
Dispcc should give you good clocks, but remember what I said about hacking the transfer time into the porches
<Marijn[m]>
I left my calculation script at home so I cannot tell you what their value should be... But the algorithm would be nice to have in lmdpdg until the kernel is fixed :)
<Marijn[m]>
But try something high like 1/4th of the panel width
<Marijn[m]>
ungeskriptet: any logs btw? I expect to only see half the panel updating here... Did you halve the mode width too?
<ungeskriptet>
Still the same with transfer_time added, but the errors seem to appear a little less now
<Marijn[m]>
ungeskriptet: did you add the pinctrl nodes back to the panel...? Not setting the `mdp_vsync` function may have timeout consequences because MDP waits for panel vsync which never arrives...
<Marijn[m]>
Though OTOH we submitted a hack to auto-trigger it after two frames...
<Marijn[m]>
ungeskriptet: was this test with or without the reset removed? Sometimes it helps to test without it until you are sure that the reset sequence is correct and the panel properly initializes with it
<Marijn[m]>
(For example the polarity is hard to get right...)
<ungeskriptet>
Reset function is still there
<ungeskriptet>
I'll try again without
<ungeskriptet>
Is it possible that I have two vsync pins?
<Marijn[m]>
Don't blindly use my reset sequence, it differs per panel
dliviu has quit [Ping timeout: 480 seconds]
<Marijn[m]>
The reason to remove the reset sequence is to keep the one provided by the bootloader... Which might work better especially if unsure about the polarity
<Marijn[m]>
When I had the polarities wrong the panel either remains black (because reset is asserted...) or the black and white noise you saw (no colors)
<ungeskriptet>
msm_dsi ae94000.dsi: [drm:msm_dsi_host_init] *ERROR* dsi_get_config: Version 3:20040000 Should I be worried about this or can I ignore this error for now?
nashpa has quit []
dliviu has joined #linux-msm
<Marijn[m]>
ungeskriptet: no issue, I just leveraged error prints as I was too lazy to enable drm.debug
<Marijn[m]>
And drm/msm is all over the place with pr_xxx vs dev_xxx vs drm prints vs DPU print macros...
<ungeskriptet>
ah right, i forgot i was using your branch
<Marijn[m]>
ungeskriptet: yeah sorry, it's a development branch, lots of hacks and WIP thingies :)
junari has joined #linux-msm
junari_ has joined #linux-msm
junari has quit [Ping timeout: 480 seconds]
Caterpillar has quit [Quit: Konversation terminated!]
<aka_[m]>
Marijn: do you have Angelo by your side anywhere?
dliviu has quit [Ping timeout: 480 seconds]
<Marijn[m]>
Only sporadically via pidgeon
<aka_[m]>
Uh I would like to discuss about rpmpd, wcnss region situation
<Marijn[m]>
Mailing list?
<aka_[m]>
Leaving us with splitting per board might break yaml checks for wcnss
<aka_[m]>
Yea
<Marijn[m]>
Don't take things off-list when multiple parties should be involved in the discussion
<Marijn[m]>
Maybe irc in this channel works though
<aka_[m]>
Marijn[m]: I cannot even reply on lists, otherwise I would do it
<konradybcio>
set up thunderbird
<konradybcio>
or neomutt
dliviu has joined #linux-msm
<Marijn[m]>
That is not handy if you wish to submit and collaborate... Why not?
<aka_[m]>
I don't feel like having much experience to complain
<aka_[m]>
I think I'm going to give up on 8976 tho, have my own featured tree and f rest.
<aka_[m]>
Not like I'm going to grab qcom prop rpm firmware for 8976 and show what kind of resources are supported
<aka_[m]>
Clearly loire is different as I my device was complaining when I tried to run sodp ports that this soc does not support glink
<aka_[m]>
Time to go back to 8953
<aka_[m]>
Fuxking autocorrection it's unreadable
<ungeskriptet>
Marijn: After adjusting the panel regulators a little I'm not getting this kernel panic: https://bpa.st/ORAQ
<ungeskriptet>
I'm not sure though which values I should use
<ungeskriptet>
Avdd and vddio have two different values for min/max volt