<lumag>
vkoul, narmstrong: I don't seem to be able to create repositories under CLO/linaro/qcomlt/. Could you please create /linaro/qcomlt/private/firmware/rb5-lt9611uxc-releases ?
<lumag>
or probably just .../lt9611uxc-releases
<lumag>
Oops
<Degdag_Med[m]>
<lumag> "Degdag_Med, https://pastebin...." <- This seem to works
<Degdag_Med[m]>
Thanks I'll see if I can get keyboard input working since I can't interact with it right now
<lumag>
ack
<lumag>
Degdag_Med[m], if you have working USB, you can try using adb or just using the serdev usb gadget and then using it as a terminal
<Degdag_Med[m]>
<lumag> "Degdag_Med, if you have working..." <- I don't have PC so I'll try to use USB host and a keyboard for that
<lumag>
I see
<Degdag_Med[m]>
USB host used to work for me duh to mu-sm8150 uefi firmware so that's fibe
<Degdag_Med[m]>
s/fibe/fine/
<lumag>
Another option might be to start kmscube as a service :D
<lumag>
THough I'v never tried that
Danct12 has quit [Quit: WeeChat 3.8]
<Degdag_Med[m]>
Phosh works fine now
<Degdag_Med[m]>
Looks smooth to me
<Degdag_Med[m]>
lumag: thanks for your help
<lumag>
Degdag_Med[m], great :-)
<lumag>
I've sent the patches. If you can reply with Tested-by, this might help :-)
<lumag>
Thanks a lot for testing and for bringing up new devices
<Degdag_Med[m]>
lumag: How I can do that ?
<Degdag_Med[m]>
Sorry I'm now to all this
<lumag>
I think you should have been CC-ed on all three patches. Reply-all (keeping all mailing lists and persons) with the plain-text mails (e.g. not HTMLs) with the text 'Tested-by: you-name <email@example.com'> under the commit message part.
<lumag>
Should be fine as long as it will not be sent as HTML message. Also generally it is suggested to reply below / in the middle of the text, rather than on top of it.
<Degdag_Med[m]>
<lumag> "Should be fine as long as it..." <- Like that fine !?
<lumag>
Yep, thank you
<Degdag_Med[m]>
Should I replay to all 3 patches ?
<lumag>
Degdag_Med[m], you reply went to me only
<lumag>
There should be a reply-all button.
<lumag>
And I got it as HTML mail :-(
<Degdag_Med[m]>
Dos gmail send it automatically as HTML ?
<lumag>
I think so. In Android client there seems to be no way to change that. If sketching the plain-text email is hard, it's not urgent.
<lumag>
In the worst case I'll just pick the tag on my own.
<Degdag_Med[m]>
Can I use web browser for that ?
<lumag>
Degdag_Med[m], yes, just press reply-all, then under three dots menu, check the 'Plain-text mode' line.
<lumag>
You can delete the patch body, leaving just the commit message/tags and your reply.
<Degdag_Med[m]>
Not sure if I did it correctly
<lumag>
Degdag_Med[m], perfect!
srichara has joined #linux-msm
junari has joined #linux-msm
<minecrell>
aka_[m], lumag: sorry, too much confusing text for me. Is there something wrong in gcc-msm8909?
<Marijn[m]>
<lumag> "Degdag_Med, ah, no. It has..." <- Would it make sense for it to fall back to a `.mdt` extension if the `.mbn` file is not found? Konrad (and the majority, though not all of dts' `firmware-name` upstream) likes to hardcode paths to squashed firmware files, requiring one to either squash downstream firmware or have a bunch of `.mbn -> .mdt` symlinks in their firmware folder 😬
<Marijn[m]>
The file format is the same after all, and __qcom_mdt_load uses different techniques to figure out whether to load sections defined in the program header from .bNN files
<aka_[m]>
<minecrell> "aka_, lumag: sorry, too much..." <- minecrell: appears to not be at the end
<aka_[m]>
i have no 8909 flat and it appears its different from 8916/8953
<aka_[m]>
only naming of _early i could protest because its mostly main output
<aka_[m]>
ya probably got inspired by 8953 right?
<minecrell>
aka_[m]: for the naming, yeah
<minecrell>
well, don't remember where I took it from but it wasn't my idea
<minecrell>
aka_[m]: do you mean the BIMC_PLL BIT(2) vs BIT(3)?
<aka_[m]>
Yea
<aka_[m]>
But ds driver says different compared to 8916/8953 flat
<aka_[m]>
Sadly lk does not define this pll to have any double check source
<minecrell>
hm yeah seems to be swapped compared to 8916
<minecrell>
well, seems like lumag confirmed it's right for 8909 with the docs?
<aka_[m]>
But that's how ds driver says so maybe that was a case, yea prob right
rmsilva_ is now known as rmsilva
pespin has joined #linux-msm
srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
junari_ has joined #linux-msm
junari has quit [Ping timeout: 480 seconds]
junari_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
Danct12 has quit [Ping timeout: 480 seconds]
srichara has quit [Remote host closed the connection]
<aka_[m]>
lumag: im now in job and somehow was thinking about that pll situation.
<aka_[m]>
Shouldn't we have like pll definition and every single active output be modeled as separate clock?
<aka_[m]>
For now we define pll and assume it's "early" or whatever
<aka_[m]>
Then we define let's say post_div and parent on top of that
<lumag>
aka_[m], Theoretically yes, with the ability to turn outputs on and off via the control register
<lumag>
However, as I wrote, this part of PLL configuration was mostly static up to now.
<lumag>
Maybe bamse or konradybcio can ad danything on top.
<aka_[m]>
I guess pll_votes on old clk pll did something like that but it was probably for gpllX root and not specific outputs
<aka_[m]>
Like in 8976 there is gpll0_vote
<aka_[m]>
lumag: do you have cpufreq on 8974 working?
<aka_[m]>
I was thinking on some stuff and would be nice to know vco bit value in each freq range
<lumag>
aka_[m], haven't looked into it.
<lumag>
I'd prefer to finish 8064 first, it is somewhat simpler.
<aka_[m]>
I guess converting low_vco field into proper vco_table would look nice
<minecrell>
lumag: I'm a bit "jealous" of those static speedbin/pvs voltage tables compared to the more complicated CPR fun :D
<lumag>
minecrell, I have semi-finished 8996 CPR
<lumag>
Been there
junari_ has joined #linux-msm
jessica_24 has joined #linux-msm
<minecrell>
lumag: btw I'm (quite slowly) working on adding full non-psci cpuidle for the SPM/SAW driver, i.e. the cluster idle states. Would you be interested in testing it on apq8064 at some point? Would hope it will work by just adding the necessary definitions, not sure if there is extra magic needed for the really really really old platforms
<Degdag_Med[m]>
<Marijn[m]> "Would it make sense for it to..." <- The driver actually define the axxx_zap.mdt/ .bxx files so I think it should fallback to the mdt header if mbn not found . not sure though
<Degdag_Med[m]>
PS : regarding GPU / screen , when I adjust brightness it show some artifact / graphic glitch on the screen as long as I'm adjusting the brightness
<Degdag_Med[m]>
Is it a common issue on cmd mode panel or rather duh to mesa driver !?
<lumag>
Degdag_Med[m], do you have an external pwm or the panel handles backlight on its own?
<Degdag_Med[m]>
Frame rate seems to not hit the full 60hz
<Degdag_Med[m]>
Tested glxgears full screen it gos up to 54.xxhz
<Degdag_Med[m]>
lumag: Bl_Ctrl_dcs
<lumag>
If there is a play with LPM during backlight setting, you might want to try removing that
<Degdag_Med[m]>
> <@degdag:matrix.org> Frame rate seems to not hit the full 60hz
<Degdag_Med[m]>
But it seems stable at least
<Degdag_Med[m]>
> Tested glxgears full screen it gos up to 54.xxhz
<Degdag_Med[m]>
lumag: OK I'll see
<lumag>
Marijn[m], Degdag_Med[m] regarding mbn / mdt. We have been trying to push towards .mbn for several reasons. But if it makes your life easier, you can always point to the .mdt file. You have to specify it in the DTS anyway.
<lumag>
If you submit it to the mailine kernel, we'll ask you to use "qcom/SoC/Vendor/device/foo.mbn", but that's for the official inclusion.
<lumag>
minecrell, that would be interesting to test. On 8064 there is a separate L2 SAW2 (which we do not use at all ATM).
<minecrell>
lumag: yeah it's always like this. On multi-cluster platforms like msm8939 there is 8x CPU SAW, 2x L2 SAW and 1x CCI SAW
<lumag>
It was funny that apq8064 uses RPM regulators for L2, while in theory they could have used the SAW2.
<minecrell>
lumag: Is it a shared power rail maybe? or dedicated for the L2 cache?
<lumag>
dedicated
<lumag>
Ugh. shared with some other rails
<lumag>
users
<minecrell>
lumag: looks like pm8921_l24 is just VDDMX like on many other SoCs where we model it as power domain (in rpmpd)
<konradybcio>
minecrell: we can't really fit it into rpmpd without adding non-smd rpm support there
<lumag>
There could have been a separate rpm-non-smd-pd driver, but I don't feel like adding one would be a good idea
<minecrell>
lumag: does the old rpm also have active-only votes?
<lumag>
minecrell, good question, I have not looked into that yet
<minecrell>
there are some mentions of a "sleep set", although the board files are terrible to read
<minecrell>
lumag: fwiw I have a draft for a simple "regulator-power-domain" that allows effectively defining own voltage corners/levels on top of a regulator. But it's made for a different use case and wouldn't really work for more complex setups like these active/sleep variants in RPM
<minecrell>
I also have a draft to add support for raw voltages in rpmpd, e.g. for VDDMX on 8974 and 8226 which doesn't support corners yet. These are just early ideas so far though, something I was considering to have consistent interfaces across all SoCs
<lumag>
minecrell, why would you like to do that? Just for unification?
<lumag>
I'm just not sure, what would it buy us.
* lumag
still has to look at GPU supplies for 8064, Adreno doesn't seem fully stable there.
<minecrell>
lumag: Unification is one motivation. The "regulator-power-domain" is something I'm considering as simple drop-in alternative for CPR where one sets the ceiling voltages (basically DVFS instead of AVS). Given the complexity of CPR I think it would be good to have this as intermediary step to allow adding cpufreq before figuring out all the
<minecrell>
SoC-specific details of CPR. It's still much better than no cpufreq/voltage scaling at all.
<minecrell>
lumag: For VDDMX on 8226/8974 the motivation is that smd-regulator has no "active-only" support, it's somewhat controversial to add, while rpmpd has the support and we already use it for newer SoCs. So it would be easier to reason for adding this into rpmpd rather than extending smd-regulator
<lumag>
minecrell, most likely you can just bump up the corresponding voltages.
<lumag>
for the smd-regulator you can try using suspend states already handled by the regulator core.
<minecrell>
lumag: as I explained to konradybcio recently it's not the same. RPM sleep states are activated by cpuidle, they are unrelated to the system suspend support of the regulator subsystem
<konradybcio>
to clarify
<konradybcio>
mpm is registered to be notified of when the cpu goes idle
junari__ has joined #linux-msm
<konradybcio>
then the mpm driver writes some registers
<konradybcio>
cpus go idle
<konradybcio>
rpm notices
<konradybcio>
sleep set kicks in
<konradybcio>
(AFAICT)
<minecrell>
konradybcio: the sleep set is activated by a special command in the SPM/SAW, you don't need MPM for that
<konradybcio>
well.. the mpm driver pokes the apcs mailbox
<konradybcio>
and SAWs are not exposed on newer platforms
<minecrell>
well then you trigger it via the magic psci parameter
<lumag>
minecrell, in the downstream the SPM states have .notify_rpm option
<minecrell>
the MPM is just for the wakeup stuff
<minecrell>
right, it's that
<lumag>
ack
<lumag>
Fortunately I skipped it :-D
junari_ has quit [Ping timeout: 480 seconds]
<minecrell>
lumag: Thanks to cpuidle and the "active-only" magic you can [on some SoCs?] run at max cpufreq (performance) and still have equal power consumption than on min cpufreq. The CPU rail is turned off completely (-> voltage doesn't matter) and shared power rails are scaled down while the cpu is idle
<minecrell>
On 8909 I even measured a slightly lower(!) power consumption with "performance" on a idle system compared to "powersave". My guess it it takes longer to go through the CPU power-off/power-on cycle on minimum cpufreq
<lumag>
I believe that's why we have schedutil and ondemand. Because powersave is not actully saving the power.
<lumag>
minecrell, and active-only is also supported for regulators? IOW voltage-voted resources?
<konradybcio>
all rpm resources
<konradybcio>
clk, bw, volt
<lumag>
hmm, interesting.
<lumag>
You might have to register two regulators then.
<lumag>
and tell that one of them is the bypass of the active one.
<lumag>
I have slight doubts about the reg-as-PD, but let's see the code first
<minecrell>
lumag: My motivation is that the "active-only" use case only exists for shared power rails that are typically represented as power domains (such as VDDCX, VDDMX, VDDPX). I consider the values sent to the RPM (corner, level, voltage) as an implementation detail
<Marijn[m]>
<Degdag_Med[m]> "PS : regarding GPU / screen..." <- Same here on some random panels/devices, and on some panels DCS backlight doesn't work at all after _prepare :)
<minecrell>
The assumption is that the raw voltages that are actually being used still correspond to some fixed set of "performance states" (/"corners"/"levels")
<minecrell>
I'll have to see if this assumption holds
<Marijn[m]>
> <@degdag:matrix.org> Frame rate seems to not hit the full 60hz
<Marijn[m]>
> Tested glxgears full screen it gos up to 54.xxhz
<Marijn[m]>
Maybe bump the clocks a little bit? What are your porches currently, and do you have a reference `qcom,mdss-dsi-panel-clockrate` downstream?
svarbanov has quit [Ping timeout: 480 seconds]
<Marijn[m]>
<lumag> "Marijn, Degdag_Med[m] regarding..." <- The DTS is upstream (or in the process of being upstreamed) and that uses `.mbn`, but it'd be more convenient for me to _fall back to `.mdt`_ without having to do anything. I.e. I don't want to maintain my own out-of-tree `firmware-name` overlay nor symlinks in the vendor folder...
<Marijn[m]>
lumag: what are those "several reasons"? Maybe one is compelling enough that I run downstream dumps through `pil-squasher` instead ;)
<Marijn[m]>
<lumag> "If you submit it to the mailine..." <- Fwiw I doubt legalese allows me to push anything here, but IANAL
<lumag>
Marijn[m], less interaction with userspace, lesser probability of an error by mixing files from different releases, less clutter in the /lib/firmware/qcom/foo, etc.
svarbanov has joined #linux-msm
<lumag>
And for the userspace it is extremely true if FW_USER_HELPER is in play
<Marijn[m]>
Fair enough, having 6-or-so parts does look a bit messy, especially if some are within the file size (but zeroed out or something)
<lumag>
Re upstreaming - I was talking about the DT upstreaming
<Marijn[m]>
lumag: yes, I remember that causing 60-second lockups on some setup
<z3ntu>
lumag: aka_ I have something working for msm8974 cpufreq, I'll happily share if someone wants to work on it
<Marijn[m]>
lumag: yes sure, that's the format we use when upstreaming
svarbanov has quit [Remote host closed the connection]
svarbanov has joined #linux-msm
<lumag>
Marijn[m], good :-)
<krzk>
minecrell: about "glink-rpm-edge" of yours, qcom,remote-pid exists in glink-edge in one version, so this is not a blocker
<lumag>
z3ntu, I can not promise to work on it in a timely manner.
<krzk>
btw, it would be much easier to find people if they had proper name under whois or at least nick was similar :/
<lumag>
so far, the lack of iommu is more depressing (at least for my usecase).
<konradybcio>
mal can we beat the dead horse of msm8974 iommu again? :P
<krzk>
I
<krzk>
I'll just respond to the mail
<mal>
konradybcio: maybe I should again try to have a look, last time I broke it when trying to clean it and also found a possibly problematic part in the code
junari__ has quit [Ping timeout: 480 seconds]
<lumag>
Another item on my 'strange items' to do list is the 8064-interconnect
<lumag>
(konradybcio should be laughing at this point)
<konradybcio>
lumag i'm about to use my schengen privileges and go pull some plugs out of some computers
<mal>
it's a shame I couldn't yet figure out why display won't work on my msm8226 tablet, that would have been also good device to also use for iommu testing, afaik msm8226 and msm8974 use same iommu
<lumag>
konradybcio, ?
<konradybcio>
lumag i'm not sure i even wanna see it happen, too scary perspectives :D
<lumag>
:D :D :D
<lumag>
mal, I think 8226 display was posted and merged lately.
<mal>
lumag: yes but I can't get it to work on my device, it probes and everything, kmscube claims to run bot nothing ever shows up on screen. I just get flood of "dsi_err_worker: status=4"
<lumag>
Ah
<lumag>
This is strange, since 8974 is working perfectly here.
<mal>
maybe the panel is not properly powered or something, it uses similar way that matissevewifi in msm8916-mainline has
<konradybcio>
mal status 4 doesn't mean much.. generally the panel doesn't like the way you talk to it or refuses to communicate
<konradybcio>
ask z3ntu for cursed panels on 8226 devices
<mal>
so it has a dsi-lvds bridge but we just skip the init of that and use simple panel
<mal>
there is mainline driver for the bridge but it wasn't working for matissevewifi so I devices to not use it on my matissewifi either
<lumag>
mal: can you try printing status in dsi_fifo_status() ?
<lumag>
We should really improve DSI error reporting
<mal>
ok, I can try
<Marijn[m]>
Ah, status=4 or status=0xc
<mal>
my device has pm8226 gpio enabling the panel power so not sure if that is correctly done in my dts
<Marijn[m]>
Sometimes it helped for us to flip the panel power / reset GPIO... Used to be quite tricky to follow downstream what's high and what's low
<mal>
in downstream kernel this is the way the gpio is toggled in the code gpio_set_value_cansleep(msd.lcd_en_gpio,(1<<1));//PMIC GPIO
<mal>
lumag: status in dsi_fifo_status is 0x88881000
<Degdag_Med[m]>
<Marijn[m]> "> <@degdag:matrix.org> Frame..." <- Yes i have this reference on my panel dts
<Degdag_Med[m]>
Should I apply similar patch for bumping up the clock like you did in your last patch ?
<Degdag_Med[m]>
<Marijn[m]> "Same here on some random panels..." <- It works for my / kind of , but it's not configured correctly yet
<Degdag_Med[m]>
* It works for me / kind of , but it's not configured correctly yet
swdefrgthfgjhk has joined #linux-msm
<Marijn[m]>
> <@degdag:matrix.org> Yes i have this reference on my panel dts
<Marijn[m]>
> Should I apply similar patch for bumping up the clock like you did in your last patch ?
<Marijn[m]>
`sofef01: Calculate the exact porch needed to bump pclk high enough`? Yes.
<Marijn[m]>
Someone is following my github closely ;)
<Marijn[m]>
<Degdag_Med[m]> "https://github.com/MiCode/Xiaomi..."; <- Ah also a jitter of 5 over 1, meaning `dsi_transfer_time_us` becomes `14000` too
<Marijn[m]>
So if qcom,mdss-dsi-panel-clockrate doesn't work we can calculate an even higher clock based on the jitter and transfer parametrs
<minecrell>
krzk: sorry, the name has long historical reasons... :D
<minecrell>
krzk: if I understood you correctly I'll just edit the glink-edge.yaml binding to not select on the node name, more cleanup could be done in a separate series
<minecrell>
lumag: another indication/characteristic of a power domain compared to a regulator is that it has "I want at least this voltage, but higher is fine" built-in by design
<minecrell>
lumag: consider implementing active-only regulators as second regulator instance, you need to handle regulator_set_voltage(active_sleep, min=1.8V, max=1.8V) and regulator_set_voltage(active_only, 3.3V, 3.3V). These are conflicting requests on two separate regulators that must fail. To handle that the aggregation functionality of the regulator core
<minecrell>
lumag: a power domain consumer only votes for a "minimum performance state" (no maximum), so the implementation is much easier (= max(active_sleep->state, active_only->state))
<minecrell>
must be reimplemented. set_voltage_triplet(min=, preferred=, max=) could be even more complicated
<minecrell>
but yeah this is just something I was exploring at some point, it's not investigated far enough to be able to post a patch set right now
<mal>
lumag: based on that status all data lanes have underflow and the random 99991000 tells that those are reported as empty
telent has quit [Read error: Connection reset by peer]
telent has joined #linux-msm
<krzk>
minecrell: yes, plus some testing, to be sure that no issues are introduced.
<minecrell>
krzk: of course, I wouldn't dare to submit such a patch without dt_binding_check&dtbs_check :D
<krzk>
minecrell: and DTS, AFAIR most of remoteproc bindings have no warnings
<Degdag_Med[m]>
<Marijn[m]> "So if qcom,mdss-dsi-panel-..." <- Huum thanks i will see what i can get
<Marijn[m]>
Degdag_Med: careful with it though, it's not always correct
<Marijn[m]>
I have a script that calculates the desired clocks, hardocde that (either in dsi_host.c or directly in the porches) and try to see what sticks, then take the lowest
pespin has quit [Remote host closed the connection]
telent9 has joined #linux-msm
mort_5 has joined #linux-msm
calebccff_ has joined #linux-msm
swdefrgt- has joined #linux-msm
gpiccoli_ has joined #linux-msm
__lore__ has joined #linux-msm
krzk_ has joined #linux-msm
animist1 has joined #linux-msm
telent has quit [charon.oftc.net helix.oftc.net]
swdefrgthfgjhk has quit [charon.oftc.net helix.oftc.net]
krzk has quit [charon.oftc.net helix.oftc.net]
_lore_ has quit [charon.oftc.net helix.oftc.net]
calebccff has quit [charon.oftc.net helix.oftc.net]
Prawn[m] has quit [charon.oftc.net helix.oftc.net]
z3ntu has quit [charon.oftc.net helix.oftc.net]
danylo has quit [charon.oftc.net helix.oftc.net]
Leandro[m] has quit [charon.oftc.net helix.oftc.net]
jrole_8tst-j[m] has quit [charon.oftc.net helix.oftc.net]
go4godvin has quit [charon.oftc.net helix.oftc.net]
Mis012[m] has quit [charon.oftc.net helix.oftc.net]
Tooniis[m] has quit [charon.oftc.net helix.oftc.net]
alfayt[m] has quit [charon.oftc.net helix.oftc.net]
ywnkmn[m] has quit [charon.oftc.net helix.oftc.net]
aka_[m] has quit [charon.oftc.net helix.oftc.net]
mort_ has quit [charon.oftc.net helix.oftc.net]
animist has quit [charon.oftc.net helix.oftc.net]
gpiccoli has quit [charon.oftc.net helix.oftc.net]
telent9 is now known as telent
go4godvin has joined #linux-msm
go4godvin is now known as Guest2915
<Degdag_Med[m]>
<Marijn[m]> "I have a script that calculates..." <- Thanks I'll see about this when I have some free time next week