ChanServ changed the topic of #linux-msm to:
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
Danct12 has joined #linux-msm
Danct12 has quit [Quit: Leaving]
Danct12 has joined #linux-msm
jnn has joined #linux-msm
jn has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
jnn is now known as jn
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #linux-msm
<Mis012[m]> anyone has a clue what "DEFAULT" means here?
<Mis012[m]> also USB_EDL is probably a typo? :P
<jhugo> That looks like a GPIO definition
<jhugo> The described options are the selectable behaviors
<jhugo> essentially the boot modes
<jhugo> default would be default behavior (eg boot like normal). The other options would force the device to go into that mode
<Mis012[m]> it's QFPROM
<Mis012[m]> I'm pretty sure it's boot order
<Mis012[m]> actually, I guess DEFAULT would mean "whatever the straps say"?
<Mis012[m]> jhugo: since you're here, could you help get my SSC series merged finally? :P
<Mis012[m]> it seems to just lay on the ML and it's not magically popping up in -next branches either
<aka_[m]> Is this "universal" issue?
<aka_[m]> Such regmapping seems to occur on some other socs too
<aka_[m]> i havent tested if its erroring on 8953
<jhugo> QFPROM could either be actual bits, or it could present a unified interface, sometimes those options are configured via multiple mechanisms (GPIO, efuses, etc), and so to make the bootloader simple, the QFPROM collects and ranks those various inputs to provide a final answer for the bootloader
<jhugo> regarding the SSC series, I'm guessing it was jsut bad timing since there was just a merge window. My default advise would be to rebase it onto -rc1, and resend
<Mis012[m]> jhugo: am I missing some partition for sdcard boot
<jhugo> I expect most maintainers would be accepting code now
<jhugo> I don't know about the partition table. Frankly, that output looks insane to me. Thats like 50 parittions where 3 would easily suffice
<Mis012[m]> well, wanted to be on the safe side :P
<Mis012[m]> jhugo: I now wonder if `pmic_a` is read by the PBL and that's how it knows which supplies are needed for UFS...
<Mis012[m]> and if I therefore need to edit that in order for the sdcard to get powered
jhovold has quit [Ping timeout: 480 seconds]
<Mis012[m]> doesn't really look like it...
<aka_[m]> uh
<aka_[m]> booting on 8953 is meh
<aka_[m]> oh not this room,
<aka_[m]> I wonder, is there any way to make q6afe clks to output real clock values?
<aka_[m]> Now they are all exposed as 19200000.
<aka_[m]> i know they are votes so its not that easy
<Mis012[m]> well, if there are MND registers or some other way to set the clock, then it depends on whether Linux can read those registers (or whether the sw interface to LPASS fw has a command to get the clocks)
<Mis012[m]> if there are no registers to set the clock, then it's clearly fixed :P
<aka_[m]> uh i think i found one
<aka_[m]> CLK_DIV BIT[24:16]
<aka_[m]> but im not sure is base clock always same?
<Mis012[m]> ok, then you also need to know what the parent clock is
<aka_[m]> yea
<Mis012[m]> can it be set?
<Mis012[m]> even if so, I guess the FLAT doesn't tell you what clocks the parent clock options actually correspond to
<aka_[m]> i assume its internal vs external clock
<aka_[m]> ext i think is when it comes from PM/PMI
<aka_[m]> on most pmics its comming when you set gpio1 of PM to FUNC1 then rpmcc div2 clock gets somehow routed
<aka_[m]> Mis012: oh lol
<aka_[m]> these can be written too
<Mis012[m]> well, "somehow", you would need a wire
<Mis012[m]> aka_[m]: by Linux?
<aka_[m]> well RW i assume its writable by linux
<Mis012[m]> no
<Mis012[m]> RW means writable in general
<aka_[m]> well alteast readable?
<Mis012[m]> depends on SMMU and XPU settings
<aka_[m]> well we write these things in machine driver
<aka_[m]> not exactly clock ones
<aka_[m]> but under same block
<Mis012[m]> the easiest way to know if it's readable/writable by Linux is to try :P
<aka_[m]> or we can use lk2nd
<Mis012[m]> well, it's the same permissions
<aka_[m]> yea
<Mis012[m]> IF it's RW by Linux (which I doubt it will be in your case), you could just make an LPASSCC driver
<aka_[m]> R is enought
<aka_[m]> so i can try to understand whats going on
<Mis012[m]> well, it would sure be better than nothing :P
<Mis012[m]> but still not too optimistic
<Mis012[m]> jhugo: well, thanks for help, I guess I should be connecting SWD to see what's going on but ironically that would make it impossible to test sd card booting :P
<Mis012[m]> maybe it's also possible that the XBL on this device is not built with SD card boot support
<Mis012[m]> don't recall if it can be compiled out