<lumag>
Anyway, you can ignore that for now and fix it later.
<aka_[m]>
lumag: thats great but for now gcc-msm8976 is very "custom" freq table is not exactly what DS does but rather what can be easily obtained with full freq general pll.
<aka_[m]>
some of these DS freqs come from dedicated oxili PLL which is at main_output_div= /2
<aka_[m]>
Konrad asked me in v1 why these freqs are different from ds, so that was a reason
<lumag>
aka_[m], as far as I undestand, bin 1 is rated for higher frequency, so it should be safe to run it at the default 600 MHz
<aka_[m]>
this bigger bin is probably 653
<lumag>
621.33 MHz
<aka_[m]>
20Mhz more doesn't seems like worth it
<aka_[m]>
and having to power oxili pll for it
<aka_[m]>
ok so in short i have v3 to resend tomorrow
<lumag>
ok, now back to the DPU question. msm8976 requires SMP (shared memory pool) support, which we do not have in DPU
<aka_[m]>
i asked about 8953
<aka_[m]>
you had patch for 8937/8953
<lumag>
Ah, excuse me
<aka_[m]>
maybe it ain't perfect but Luca Weiss said its working
<lumag>
Yes. I had posted that, need to verify that it doesn't break with respect to different configurations.
<lumag>
I hope to have cycles to finish QSEED2 and RGB scalers support, then we can land msm8996 / 37 / 17 / 53
<lumag>
and qcs40x
<lumag>
If it works :-D
pespin has joined #linux-msm
ungeskriptet is now known as Guest156
ungeskriptet has joined #linux-msm
Guest156 has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
jhovold has quit [Quit: WeeChat 4.2.1]
jhovold has joined #linux-msm
<strongtz[m]>
lumag: sorry for the late reply. kernel pd-mapper works with the pmic-glink patches now!
<strongtz[m]>
It works regardless of the userspace one being present or not
<lumag>
strongtz[m], could you please reply with the Tested-by, mentioning that you tested it with the fixes patchset also applied
<lumag>
(reply to the email)
<lumag>
and thanks a lot for the testing!
<strongtz[m]>
lumag: sure, I'll reply to it right away
<strongtz[m]>
lumag: uh after sending the mail I rebooted my device, and it doesn't work again :(((
<strongtz[m]>
PDR: tms/servreg get domain list txn wait failed: -110
<strongtz[m]>
PDR: service lookup for tms/servreg failed: -110
<strongtz[m]>
nothing works this time, including battmgr and audio stuff
<strongtz[m]>
I have a wild guess that this is more likely to happen when specifying "console=ttyMSM0,115200" in cmdline which slows down the boot process
<lumag>
Hmm, [ 5.602090] PDR: tms/servreg get domain list txn wait failed: -110
<lumag>
strongtz[m], btw: do you have brgl's patchset applied? I wonder what is the cause for PCIe backtrace?
<krzk>
DavidHeidelberg: hey, I see you will be on OSSNA soon?
<krzk>
DavidHeidelberg: we should meet, few folks from Linaro qcom are coming as well
<strongtz[m]>
lumag: the pwrseq patchset? I think that caused the pcie backtrace
<lumag>
strongtz[m], ack, brgl: have you seen such backtraces?
<lumag>
strongtz[m], I'll see what can be causing the timeout
<brgl>
strongtz[m] lumag: no I've never seen it. What platform is this? Doesn't seem like something supported upstream
<strongtz[m]>
that backtrace have also been noticed by Bjorn :P
<brgl>
strongtz[m] I'm asking because v6 works fine on R5and SM8[56]50
<strongtz[m]>
brgl: yes, I can confirm it's the latest one
<strongtz[m]>
It does work with the sysfs warnings
* brgl
is running a quick check
<brgl>
strongtz[m] nope, no such warnings on RB5 here, just a clean log on current next + pwrseq v6
* brgl
is checking sm8650 too
<lumag>
brgl: judging from the message kind, I'd suspect the probe deferral is in place somewhere.
<lumag>
Or lack of a cleanup
<brgl>
lumag: yeah, I think that too
<lumag>
Note, it warns on both platform resource and the proc dir
<strongtz[m]>
I'm building everything as built-in btw, so no modules
<brgl>
strongtz[m] ah, good point, I typically always use modules
<brgl>
let me check
<brgl>
lumag strongtz[m] it also says: "/devices/platform/soc@0/1c00000.pcie/pci0000:00/0000:00:00.0/resource0" which makes me think it has something to do with device links
<brgl>
and since I do fiddle with device links here, this may be the culprit
<brgl>
not undoing a device link somewhere
<strongtz[m]>
lumag: I tried again booting my device with no serial console for like 6 times, pd-mapper works every time
<lumag>
brgl: resource0 isn't a device link
<lumag>
strongtz[m], I think there is a race somwehere. Maybe with the pd-mapper server restart on new DSP registration
svarbanov has quit [Ping timeout: 480 seconds]
<brgl>
lumag strongtz[m] I can confirm that with built-in drivers I can see the warnings
<brgl>
I'll see about it next week
<brgl>
thanks for the report
jhovold has quit [Quit: WeeChat 4.2.1]
jhovold has joined #linux-msm
<brgl>
strongtz[m]: would you mind commenting under the v6 of the series so that there's some history on the mailing list of tracking this?
<JIaxyga[m]>
Hey calebccff:, Are you here?
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #linux-msm
pespin has quit []
svarbanov has joined #linux-msm
svarbanov has quit [Ping timeout: 480 seconds]
<aka_[m]>
lumag: hai
<aka_[m]>
question to you
<aka_[m]>
have you took a look at DPU layout on these older soc?
<aka_[m]>
somehow dpu_hwio does not fit descriptions for me
<aka_[m]>
ok my eyes are broken
<lumag>
aka_[m], any particular question?
<aka_[m]>
my eyes are wrong heh
<aka_[m]>
tho im looking at 8976 now
<aka_[m]>
and dpu_hwio does not fit there at all
<aka_[m]>
for example vsync_sel is somewhere else
<aka_[m]>
at first started checking if layout is same on 8953 and 0x10 before 0x08 got me confused
<lumag>
I'll take a look in 5 minutes
<lumag>
(at source files, I don't have regmaps for those chips)
<aka_[m]>
its fine on 8953 it seems
<aka_[m]>
Minecrell said 8916 requires smp but if layout is also off compared to other dpus it might not be enough
<aka_[m]>
lumag: yes and i wonder what is requirement for needing it
<lumag>
aka_[m], no idea unfortunately :-(
<aka_[m]>
i don't understand stack at all
<aka_[m]>
shared memory pool thats most what i understand in name
<aka_[m]>
maybe hardware is programmed in some way it wants stuff pushed in specific favor
<aka_[m]>
like we can feed dpu/mdss with cont_splash region
<lumag>
If I understand correctly, it is a buffer between memory interface and SSPP fetcher
<lumag>
ok. So for the VSYNC_SEL. I see that historically it used a different location (same as 8916) at least up to and including 8994.
<lumag>
the split_display registers that you have posted have a different base value
<lumag>
they are offsets within the subblock
<Marijn[m]>
Are we going to speedrun those SoCs on DPU?
<Marijn[m]>
Or can we finish proper Active CTL support first? I'll submit it now that dual-DSI-DSC is working and this is a hard requirement :)
<lumag>
Marijn[m], you are tough ;-)
<lumag>
No I'm not going to speedrun those chips. Unless somebody beats me and implements qseed2 and rgb scalers (anybody is welcome to do that, just ping me in advance).
<Marijn[m]>
lumag: if by tough you mean persistent in figuring out missing DPU features and issues, even after things not panning for out for well over half a year? Sure
<lumag>
:-D
<Marijn[m]>
Seems like it was worth it in the end, now that it reached the finish line
<lumag>
Marijn[m], ok, I want to fix the issue with the cmd-mode IRQs (either by reverting the commit or by finding a correct place to handle them).
<lumag>
Then I can get back to the active CTL. But I'd like to take a strange path of finishing my old patchset which reworks dpu_enc_phys and dpu_enc_virt interfaces first
<lumag>
Basically because I want to have more obvious code around CTL flushing, including but not limited to the whole needs_single flush
<lumag>
And because I want to send a single data structure to the CTL layer instead of calling it twice
<aka_[m]>
<lumag> "the split_display registers that..." <- base value?
<aka_[m]>
reset is 0x0
<lumag>
aka_[m], no, reset is 0x1e8 + -
<lumag>
aka_[m], no, reset is 0x1e8 + 0
<aka_[m]>
ah you mean base
<lumag>
Yes. Then split_display matches other chipsets
<aka_[m]>
its SPLIT_DISPLAY_EN ADDRESS 0x010C RW
<aka_[m]>
under MDSS_MDSS_TOP+0x000011E8
<aka_[m]>
CLK_CTRLX looks different on 8953 compared to 8976
<aka_[m]>
its 0x0 on reset on 8976
<lumag>
0x1e8 + 0x10c = 0x2f4
<lumag>
which matches dpu_hwio.h
<aka_[m]>
thats annoying part on 8953, in 8976 i have flat offsets from base
<Marijn[m]>
lumag: yeah you said you wanted to rework the series. We came to pretty much the same conclusion regarding the original implementation at least, but there are a few important DSC fixes that were missing
<Marijn[m]>
But I think I can land those without even going to active CTL just yet
<aka_[m]>
expected it to be less distinct and wanted to try just easy with platform data, but seems it won't be the case
<lumag>
Marijn[m], yes, please.
<Marijn[m]>
It's a really weird patch where we're going to stack S-o-b's again :)
<lumag>
aka_[m], hmm, interesting.
<lumag>
vsync_sel matches what I see for earlier chips
<lumag>
maybe it was some middle-mixed monster, where QC decided to stuff WD_TIMER_2 in a different way
<aka_[m]>
oh so these CLK_CTRLs control clocks for each block of LM/PP and so on
<aka_[m]>
8953 have more CLKs because more of LM/PP
<Marijn[m]>
So all you need then is the SMP implementation to talk to the DPU? :)
<aka_[m]>
no idea
<lumag>
Marijn[m], to fetch data from mem
<aka_[m]>
8953 have smp in hardware
<aka_[m]>
but no need for software
<aka_[m]>
mdss driver on downstream appears to require more props for smp than what we have in ds
<Marijn[m]>
Does it have writeback, rotator, or anything else?
<lumag>
8953 has WB0 and WB2
<aka_[m]>
lumag: 8976 has WB0
<aka_[m]>
WB0-WB4
<aka_[m]>
all of them
<aka_[m]>
8953 0-1-2
<aka_[m]>
well its just layout, it could be like on Kamorta where regions are described but not accessible
<aka_[m]>
like trying to read qmp-usb3-phy resets device if one ain't incorporated in design
<aka_[m]>
to access registers of these WBs we would need to enable first clocks to them in CLK_CTRLX registers right
<aka_[m]>
about rotator no idea i only see mention of it inside WBX regions
<aka_[m]>
ROTATOR_PIPE_DOWNSCALER
<lumag>
WB0 / WB1 are rotators - lightweight WB interfaces with rot90 support. They are tied to one DMA pipe only and do not use LM. On the contrary WB2/WB3 use full LM-based pipeline and thus can blend several planes, but they don't have rot90.
<lumag>
WB2/3 were targeting WFD - WiFi displays
<aka_[m]>
qcom,mdss-wfd-mode = "intf_no_dspp";
<aka_[m]>
so something supported on 8976
<lumag>
I haven't checked that part.
<lumag>
But also keep in mind that some other features also differ between those chips.
<lumag>
I think there were differences in the presence of RGB scaler (whether RGB plane can scale data or not)
<lumag>
At least I think I saw that in the fbdev driver
<aka_[m]>
ok time to sleep im pretty much feeling like this neanderthal guy who carefully listening to modern men talk
<aka_[m]>
you all should know this meme
<aka_[m]>
lumag: sounds like something related to MDP.VP_0.RGB_0.SSPP
<aka_[m]>
it has bunch of SRC_SIZE/OUT_SIZE registers