ChanServ changed the topic of #linux-msm to:
anholt has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
anholt has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
jhovold has joined #linux-msm
Daanct12 has quit [Quit: Leaving]
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #linux-msm
Daaanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
<Mis012[m]> ichernev: I might have a FLAT for that, but not sure if it has the info you need
jhovold has quit [Quit: WeeChat 3.4.1]
jhovold has joined #linux-msm
pevik has joined #linux-msm
<aka_[m]> any code snippet to dump me smr registers so i can figure out iommus for ufs?
<aka_[m]> or some good Qcom/Linaro employee to tell me iommus prop for UFS
<aka_[m]> * for UFS on SM6115(Bengal/scuba)
Daaanct12 has quit [Remote host closed the connection]
pespin has joined #linux-msm
pevik_ has quit [Remote host closed the connection]
<konradybcio> unless you're getting a mmu error (ESR 960000x) and a full platform crash when touching registers, you shouldn't need it
pespin has quit []
<aka_[m]> konradybcio: it cries same error like it did for z3ntu on 6350 and I got map for sid mapping already
<aka_[m]> Testing after I get back from job
pespin has joined #linux-msm
flto has quit [Remote host closed the connection]
flto has joined #linux-msm
pespin has quit [Remote host closed the connection]
pevik has quit [Ping timeout: 480 seconds]
<lumag_> sboyd, konradybcio, I have been digging into the 8996 cpu & cbf clocks. Two questions, if you by chance know the answer. First, why primary PLL params (config_ctl, test_ctl) differ from downstream v3 params? And second, any particular idea, why the primary PLL uses the huayra ops, rather than classic pll or alpha hwsm pll ops?
<konradybcio> 1. no idea, but it may have been updated over time
<konradybcio> 2. I think it's just a huayara pll?
<lumag_> Downstream uses variable_rate_hwfsm ops.
<lumag_> regarding No 1, it's funny that it uses part of the setting for 8996 v1-v2, part for v3.
<konradybcio> downstream used not to be very precise with plls
<konradybcio> before 8998 it had a common set of ops
<konradybcio> upstream does it "properly" with undocumented-downstream codenames
<konradybcio> and sometimes the ops upstream include more things than the downstream counterparts
<lumag_> :-)
<lumag_> I see, most probably it was for the dynamic update
<konradybcio> for example 8994 cpu plls are codename veyron iirc
<konradybcio> the only place i saw that name was a random caf commit from a late bsp that only hit lumias
<konradybcio> or rather its windows counterpart i guess, no other phone was updated that far
* lumag_ will dig further
<konradybcio> nice
<aka_[m]> iommu goes nuts tho
<konradybcio> now reboot and see if they didn't pull a sony on you xD
<aka_[m]> arm_smmu_context_fault: 461961 callbacks suppressed
<aka_[m]> konradybcio: twrp boots fine so we are good to go
<aka_[m]> if yes that would mean mdp iommu goes nuts
<aka_[m]> because:
<aka_[m]> iommus = <&apps_smmu 0x420 0x2>,
<aka_[m]> i wonder what would happen if i disable mdss and leave dpu config ctive
<konradybcio> dpu is a subdevice of mdss, it won't probe
<ichernev[m]> konradybcio: What is that supposed to mean?
<ichernev[m]> Messed up partitions? Faul smell? Blue smoke?
<aka_[m]> > <@ichernev:matrix.org> What is that supposed to mean?
<aka_[m]> > Messed up partitions? Faul smell? Blue smoke?
<aka_[m]> erased
<aka_[m]> wiped
<aka_[m]> clean
<aka_[m]> whatever
<konradybcio> partition't
<konradybcio> basically you can't boot anymore
<aka_[m]> konradybcio: well edl and programmer?
<konradybcio> only to edl, but oh wait you're not sony and you don't have the programmer so you can't flash it
<aka_[m]> so cannot you just ask for it?
<aka_[m]> its not like fucking it going to make big deal
<aka_[m]> you still need signed code
<konradybcio> nice joke
<konradybcio> top secret information
<konradybcio> it only leaked once for like 2013 z1
<aka_[m]> just hack OEM and leak it
<konradybcio> let's just say sony corp isn't exactly your-uncle-corp and they will make things secure before they will make them usable
<konradybcio> sometimes they forget about the latter
<aka_[m]> z3ntu: it appears there is no /dev/mmcblk*
<konradybcio> because you have no mmc/sdcard
<konradybcio> ufs has SCSI-style dev names
<konradybcio> /dev/sdaN etc
<aka_[m]> konradybcio: i wanted to bring sdhcard
<konradybcio> each "drive" corresponds to a LUN (a logical 'stronger' partition)
<aka_[m]> s/sdhcard/sdcard/
<konradybcio> oh ok
<konradybcio> make sure you have your regulators then..
<aka_[m]> it should probe error
<aka_[m]> or show inside devices_deferred
<aka_[m]> when it was dying i had dumps
<konradybcio> not exactly
<konradybcio> hardware needs to jump to a certain voltage for mmc logic to work
<konradybcio> i had sooooo many issues with this on msm8994 before i figured it out
<aka_[m]> konradybcio: had to lower it to nile level
<aka_[m]> because it wanted to 3.3
<konradybcio> that's qcom messing with the spec
<konradybcio> mainline driver implements the spec as it's written out
<aka_[m]> sdcc1 uses BI_TCXO freq
<aka_[m]> bit low
<aka_[m]> 19.2
<konradybcio> understandable it sleeps if it doesn't detect anything
<aka_[m]> there is some io bias also
<aka_[m]> on l7 and i made it always-on
<konradybcio> any cd-gpios?
<aka_[m]> ok im even more wrong
<aka_[m]> 400000 is freq for it
<aka_[m]> 4mhz?
<aka_[m]> or what
<aka_[m]> 0.4
<Mis012[m]> 50MHz would be more like it
<aka_[m]> no way
<aka_[m]> xo is 19.2
<Mis012[m]> but maybe it has it's own internal pll?
<aka_[m]> 19200000 vs 400000
<konradybcio> 40mhz sounds like low sdhci
<aka_[m]> Mis012: uh
<Mis012[m]> 0.4MHz sounds like sus
<Mis012[m]> aka_: hm, so it can do 50MHz?
<aka_[m]> look at first rate.....
<Mis012[m]> then I guess maybe 0.4MHz is allowed
<aka_[m]> what kind of shit is it
<Mis012[m]> SPI mode? /hides
<konradybcio> 8350 also has this
<konradybcio> 400 khz
<Mis012[m]> but do sdcards work at 0.4MHz
<Mis012[m]> outside SPI mode
<konradybcio> unlikely
<aka_[m]> konradybcio: imma try something stupid
<aka_[m]> adding iommu prop
<aka_[m]> to sdhc2
<aka_[m]> yolo
<Mis012[m]> what's all this iommu shit, did you really buy a device that runs Linux in a VM and you can't do anything about it...
<aka_[m]> no progress
<aka_[m]> it says adding to iommu group and nothing
<aka_[m]> do i need OPP table for it to work?
<Mis012[m]> depends if it's smart enough to not use modes which it can't set the right parameters for
<aka_[m]> downstream keeps spamming this:
<aka_[m]> sdhci_msm 4784000.sdhci: Debug feature enabled 0x0000004d
<aka_[m]> vdd: 0 (invalid) feels quite off
<aka_[m]> bus-width is set to 4
<aka_[m]> in dts
<aka_[m]> After forcing using system dma it still dies
<aka_[m]> [ 5.363512] sdhci_msm 4784000.sdhci: mmc1: pwr_irq for req: (1) timed out
<aka_[m]> [ 5.398824] mmc1: SDHCI controller on 4784000.sdhci [4784000.sdhci] using PIO
<aka_[m]> so debug.quirks=0x40
<aka_[m]> after adding reset to sdhc node it changed some props lol
<aka_[m]> well lets say it changed signal voltage
<aka_[m]> caps differ between downstream and mainline... (full message at https://matrix.org/_matrix/media/r0/download/matrix.org/sgwFICYLkWXjmNaWGNvCfOtZ)
<aka_[m]> didn't expect sdhci to be harder than ufs...
jhovold has quit [Ping timeout: 480 seconds]
<aka_[m]> without PIO mode it just ends with mmc1: SDHCI controller on 4784000.sdhci [4784000.sdhci] using ADMA 64-bit
<aka_[m]> downstream says its using adma 64 bit in legacy mode