<lumag>
aka_[m], if I understand correctly, mem-acc exists only for the GFX CPR
<lumag>
APC0/APC1 do not have mem-acc at all
<lumag>
Also, you have probably noticed, there are slightly different tables in msm8976-v1.1.dtsi. By default we provide support only for the latest&greatest CPU revision (as it's the one which usually goes to public).
<lumag>
If required (e.g. because some fine manufacturer used ES revision), this should be a separate, non-default compat entry.
<aka_[m]>
<lumag> "Also, you have probably noticed,..." <- on 8976/8956 majority of devices(10 in total i guess?) runs on v1.1 bin
<aka_[m]>
tho gcc now is set to v1
<aka_[m]>
<lumag> "APC0/APC1 do not have mem-acc at..." <- fields exist
<aka_[m]>
similar to ramp controller
<aka_[m]>
msm8953/msm8976 have these fields yet 8976 program them to something else what reset value
<aka_[m]>
i would probably need to guard mem_acc codes in cpr to ignore NULL data
<lumag>
Hmm. I'd wonder how the mem-acc is programmed, as the cpr device doesn't have mem-acc-supply.
<lumag>
Maybe it is done via some other ways (RPM, SPM, whatever)?
<lumag>
I think, you can just have 0 as mem_acc_desc in cpr2 driver, all mem-acc programming will be skipped
<lumag>
yep. later generations have separate LDOs, so that APC CPR can switch between main supply and per-cluster LDO. But I don't think it's the case for 8976
<lumag>
As for the gcc/mmcc compatibility.
<aka_[m]>
hmm
<aka_[m]>
no idea how that works
<aka_[m]>
is cpu always supplied from apc regulator?
<aka_[m]>
regardless of pll driving it
<aka_[m]>
now i think a bit on testing with acc = NULL
<aka_[m]>
would that work you say?
<aka_[m]>
i wanted to also copy sr_pll_configure or something from clk-pll to clk-hfpll so i can configure
<aka_[m]>
and maybe instead of using low_vco provide vco_table
<lumag>
I think gcc only changes the sdcc1 table (and only changes the source for the high frequencies frequencies). MMCC v1 vs v1.1 only changes DSI1 programming (while almost everybody sane uses DSI0 in their hardware).
<aka_[m]>
8976 is bit funky there because when switching to 692-900 range on a53 pll we also need to reprogram config_reg and not user_reg alone
<aka_[m]>
lumag: yup sdc and dsi plls
<aka_[m]>
like v1 has only single pll
<lumag>
So you can fix that or ignore that.
<aka_[m]>
i hardly know any user of dsi1
<aka_[m]>
maybe some samsung tablet if they ship mhl/slimport
<lumag>
mhl/slimport should be HDMI
<aka_[m]>
8976 has no hdmi hardware
<aka_[m]>
could use anx
<lumag>
Ah.
<aka_[m]>
anx wasn't DSI->HDMI bridge
<aka_[m]>
?
<lumag>
I think there were HDMI->MHL bridges
<lumag>
But I just don't know about DSI -> MHL (never actually looked into that direction).
<lumag>
The only actual MHL device I know is 8064-based, which has proper native HDMI
<konradybcio>
mhl is a standard of pushing hdmi through microusb
<konradybcio>
used in 8974-8994 era
<konradybcio>
not at all sure if it uses the on-soc hdmi though
<lumag>
konradybcio, it does on 8064
<lumag>
aka_[m], as for the mem-acc question, I do not know for sure, but at least I don't see it being programmed directly
<lumag>
What is the full address of the reg? You gave only in-address-space offset
<aka_[m]>
lumag: appears to be under tcsr: syscon@1937000
<lumag>
so, is it 0x193b140?
<aka_[m]>
google says 0x1937000 + 0xB140 =0x1942140
<lumag>
what is the base address in your file with regs definitions
<lumag>
note: 0x01944130 - GFX mem-acc address
<minecrell>
lumag: Do you know what mem-acc actually does? Some commit says it controls "memory delays" but the way it's used is totally weird.
<aka_[m]>
minecrell: maybe its somehow related to l2-latency stuff they tends to do on ds
<lumag>
minecrell, as far as I understand, it fixes memory timing programming for the higher / lower voltage swing
<lumag>
like higher voltage => longer to get it to the full range