djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
junari_ has joined #linux-msm
junari__ has joined #linux-msm
junari_ has quit [Ping timeout: 480 seconds]
junari__ has quit [Ping timeout: 480 seconds]
junari has joined #linux-msm
junari has quit [Ping timeout: 480 seconds]
<JIaxyga[m]>
Hey Marijn! I tested dsc on linux next branch. I get a black screen with flickering every 10 seconds for interference. Then I tested on your branch and got the same thing but with bootloop. Can you look at my panel driver and dpu? We tested dpu on xiaomi-davinci which doesn't have dsc and got image using panel. https://github.com/sm7150-mainline/linux/commits/test_dsc
junari has quit [Remote host closed the connection]
<JIaxyga[m]>
<JIaxyga[m]> "Hey Marijn! I tested dsc on..." <- There is something wrong with the dpu. I cant push fix cuz git on mac works disgusting
<Marijn[m]>
JIaxyga: there are some funky defconfig things on that branch that are required for one device, but make other devices bootloop (regards to crypto algorithms and fs encryption...), perhaps not a good idea to use it as a base
<Marijn[m]>
JIaxyga: perhaps I should do the same for sm8150 on DPU 5.0, to more closely match your environment
<JIaxyga[m]>
I have a few fixes. Ill try them when I get home. And I will send you a video of the display behavior
<JIaxyga[m]>
Look at the panel driver, does it look good to you?
<Marijn[m]>
JIaxyga: do you also have a device tree for the panel? SM7150 DPU porting looks okay on the surface (reusing most of the important SM8150 bits like ctl and intf), and the rest should be "confirmed to work" via the non-DSC K20 device :)
pespin has joined #linux-msm
<JIaxyga[m]>
Marijn[m]: do you mean downstream dts?
<Marijn[m]>
Yeah
<Marijn[m]>
You must've linked it before when I contributed that DSC setup to your mainline panel
<Marijn[m]>
Anyway, for starters I'd disable the reset sequence in case one of your setup commands is wrong and the panel isn't properly brought up. Comment out all the reset_gpio bits including GPIOD_OUT_HIGH probing so that it doesn't interfere
<Marijn[m]>
After that, check what you get in dmesg: pingpong timeouts?
<Marijn[m]>
JIaxyga: defconfig _embeds_ physical firmware files on my host computer in the kernel image, so that they don't need to be provided by some ramdisk/userspace... But those should all be commented out on my branch
<Marijn[m]>
JIaxyga: `MODULE_FIRMWARE()` on the other hand is used for depmod and friends (AFAIK...), I think to figure out dependencies
<aka_[m]>
i can look on tg for groups and check if i can find console-ramoops-es to check
<lumag>
aka_[m], my main concern is whether a separate hfpll will be good enough. Compare this with 8996 or any other user, who declared hfpll as a part of the clock driver, because there are more bits and pieces surrounding the PLL.
<lumag>
I took a glance at 8956.dtsi, it seems there is a pll+mux.
<aka_[m]>
apcs-ipc-msm8916
<aka_[m]>
scalling of cci is for now not there
<aka_[m]>
just maxed it
<aka_[m]>
its same setup like 8939
<aka_[m]>
we use this same stuff on ipqs
<aka_[m]>
lumag: good enough that its still better than nothing i believe
<lumag>
aka_[m], the problem is that once you put it to DT, you have to maintain it forever.
<aka_[m]>
so best for me to not put anything in DT
<aka_[m]>
then it can be dropped later from drivers if unused
<lumag>
aka_[m], hmm, this looks nice.
<lumag>
I feared that the regions would overlap
<aka_[m]>
which regions?
<lumag>
of pll and mux
<aka_[m]>
nah
<lumag>
or intra-pll
<aka_[m]>
pll is far away
<aka_[m]>
like 0x6000
<lumag>
Yep.
<aka_[m]>
tbh
<aka_[m]>
apcs thing
<aka_[m]>
its just
<aka_[m]>
misleading af
<aka_[m]>
it has so much stuff in it
<aka_[m]>
lumag: Vladmir have some idea of doing CCI inside ICC driver
<aka_[m]>
would that be suitable there too?
<aka_[m]>
bryanodonoghue: also have to do something about this on his 8939
<lumag>
This is what we did for 8996 and what is pending for 8064: use interconnect-clk to wrap the CCI clock as an interconnect, then let cores/cpufreq vote on the requested bandwidth.
<aka_[m]>
i have plain ICC driver for 8976 which needs adjusting to latest changes from Konrad
<aka_[m]>
and regarding cpudvfs CPR appears to not be great thing
<aka_[m]>
minecrell: came with some impl of some qcom employee which just switched supported voltages
<lumag>
aka_[m], these are different items. So you can have good old icc-smd-rpm driver for the RPM interconnects and a separate interconnect for CCI.
<aka_[m]>
or can bundle them together
<aka_[m]>
konradybcio: so what do we do about that freqs?
<aka_[m]>
Change it to 2.16 to enjoy some free overclocking oot?
<aka_[m]>
Also not fully sure about rpmpd, yes resource names are software constructs but chances of having one ssingle device using some ultra-in-future resource name from 8998 is very low
<bryanodonoghue>
you want to scale the CCI = cache control interface - of course we aren't really voting for bandwidth on the CCI though
<bryanodonoghue>
...
<bryanodonoghue>
no we are
<bryanodonoghue>
well its not a vote
<bryanodonoghue>
we want to go to a new CPU OPP and the cache needs to scale to match
<bryanodonoghue>
you don't really have source and dest nodes per ICC providers
mal has quit [Quit: leaving]
<bryanodonoghue>
which I think is probably the main difference in CCI/CPUFreq (v) regular NOC in qcom
<bryanodonoghue>
sic - msm8939-type CPU/Cache setups
<bryanodonoghue>
all that said if it works - it might be a cleaner representation ...
<bryanodonoghue>
there's alot of contained knowledge in the various CPR implementations we have right now which might be difficult to capture and transmit into a different API/arch
<bryanodonoghue>
my only real comment on ICC is we are not "voting" for a frequency
<bryanodonoghue>
we are making a very explicit command
<bryanodonoghue>
if we don't drive the right voltage for the freq we request - it will collapse
<konradybcio>
I guess it wont go that high until you explicitly ask it to
<bryanodonoghue>
no but ICC aggregates votes
<bryanodonoghue>
we want to jump to a frequency after setting a voltage
<bryanodonoghue>
I think ICC can work and may be a nicer way to maintain
<bryanodonoghue>
but there's no aggregation use-case on CCI freq
<bryanodonoghue>
that's all
<bryanodonoghue>
although maybe that's wrong
mal has joined #linux-msm
<minecrell>
bryanodonoghue: I think you need to "aggregate" the votes from the two clusters? Both have an independent CCI "vote"
<bryanodonoghue>
there's nothing to say you can't run your cache slow but your cluster fast
<bryanodonoghue>
yeah - both clusters
<bryanodonoghue>
if we do 8939 as an interconnect then IMO qcs405 should also transition
<bryanodonoghue>
and just drop the CPR code entirely
<bryanodonoghue>
there's no point in doing it two different ways
<minecrell>
bryanodonoghue: uh, I'd expect that the CCI is cpr consumer
<minecrell>
cpr has nothing to do with interconnect
<bryanodonoghue>
so sorry the conversation is to use ICC as a wrapper around CPR then
<bryanodonoghue>
instead of binding it to an OPP connected to the CPUfreq ?
<minecrell>
bryanodonoghue: afaiu ICC would model the relation between cpufreq -> cci freq
<minecrell>
and then I'd expect both CPUs and CCI to be a consumer of the shared cpr power domain
<bryanodonoghue>
Hmm, I think I like that suggestion
<bryanodonoghue>
as we say each cluster votes
<bryanodonoghue>
"votes"
<minecrell>
bryanodonoghue: I think ICC would be an alternative/replacement for the devfreq(?) setup you have downstream for 8939
<bryanodonoghue>
its better than having a fixed relationship between cpufreq and cci freq in the dts
<ungeskriptet>
Marijn: I manage to get some kind of dmesg at the top of the screen with every reset_gpio reference removed
<Marijn[m]>
Timeouts are timeouts, you really don't want them to happen because it means the panel is not responding
<Marijn[m]>
ungeskriptet: just in case: can you also remove most of your _on() function minus exit_sleep, compression_mode, set_column/page_address, set_tear_on, set_display_on?
<Marijn[m]>
ungeskriptet: perhaps any of the other setup commands is sending something invalid that cause the panel to fail to interpret the data
<Marijn[m]>
But this doesn't look like typical DSC corruption... especially with the panel able to properly understand a little bit of the signal
<Marijn[m]>
konradybcio: do you recognize that pattern? I recall having/seeing it or something like it before on one of our Sony panels
<konradybcio>
unsure
<konradybcio>
but the dmesg contains dsi err worker status=c
<konradybcio>
so that may suggest the panel is ded
<ungeskriptet>
Marijn: I think I don't have anything related to set_column/page_address
<ungeskriptet>
This happens when I use the init seq for the 60 Hz timing
<adomerle[m]>
<JIaxyga[m]> "Hey Marijn! I tested dsc on..." <- I have the same issue with vayu (shares the same panel), let me know if you were able to get it to work