_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
_whitelogger has joined #linux-exynos
mszyprow has quit [Ping timeout: 250 seconds]
<wwilly> hi, I would like to add pmu for the cci400 for the exynos5422, is anybody from samsung with the magical secret datasheet could help me? see https://pastebin.com/8vwvGPmn basically I miss the right revision, reg and interrupts
<wwilly> could anybody provide me the right thing to do a patch?
<krzk> wwilly: On Monday I can take a look :)
<wwilly> arf, is already too late for today? :)
<krzk> I have a beer in 10 minutes :)
<wwilly> arf.... :( ... I pay you two beers?
<krzk> wwilly: the cci node should be already in DTSI. It's address is 0x10d2 0000... but you need the PMU for it?
<wwilly> yes, just the pmu
<wwilly> see the pastebin link, there is a suggestion of what we should add to the cci node
<wwilly> by guessing regarding other dtsi having this
<krzk> so interrupts might be: CNT0 176 ... CNT3 179, CNT_OVF 180
<krzk> There is also CCI_NERR interrupt, I don't know which exactly you need
<krzk> The problem is that CCI is a generic ARM block so there is no documentation about it in Samsung :)
<wwilly> I don't know either to be honest
<wwilly> awh uhm, so this interrupts numbers need to be provided by ARM directly?
<wwilly> I don't know how this thing is working to honest...
<krzk> no, the IRQ numbers might be specific to Exynos but many other data - not necessarily. There are PMU interrupts mentioned in data sheet but only for EAGLE, KFC and MCU
<krzk> Since cci address is the same in your example DTS as in real Exynos, therefore the PMU reg might be the same as well
<krzk> because the regs are offsets from main register... and these offsets are parts of reference block (CCI block)
<wwilly> ok, in the pastebin post, it's simply a copy from the vexpress dtsi ...
<krzk> I see, but it is still reasonable. The cci address is the same.
<krzk> Btw, good example is the vendor opensource code
<krzk> you might find it there
<wwilly> uhm, where is that source code?
<krzk> opensource.samsung.com - everything is there, you just need to know the proper model (gsmarena...)
<krzk> I store for myself here:
<krzk> you can also try hardkernel vendor kernel - I made a copy here:
<krzk> but they have github so you can look at them directly
<wwilly> they don't have the pmu enabled
<wwilly> ok, I will try to use those definition from the vexpress board
<wwilly> if it's working, will do a proper patch
<wwilly> have a nice beer :)
<wwilly> just want to know, do you have the right revision indicated in the manual? which cci400 revision?
<wwilly> [ 4.552001] ARM-CCI PMU 10d20000.cci:pmu@9000: invalid resource
<wwilly> :/
aalm has quit [Ping timeout: 250 seconds]
aalm has joined #linux-exynos
<krzk> wwilly: what do you mean revision? In general, there is absolutely no documentation for CCI and PMU in manual
<krzk> wwilly: only address of entire block and the interrupt numbers
<krzk> invalid resource - it looks like different problem... I mean, the SoC should allow to map 0x10d29000 even if it is not valid address
<krzk> so this looks like a driver/double mapping problem. Maybe in double mapping the error would be different.
<wwilly> you have r0 or r1
<wwilly> because they have different features, and internal stuff I guess
<krzk> I see
<wwilly> I tried both, same result
<krzk> This part I do not know, you could look for other A15 or big-little examples. About the error, how does your code look like?
<wwilly> I try to trace the driver/bus/arm-cci.c, but the platform probe function return 0
<wwilly> it fail later, during main probing loop stuff
<krzk> you know that there is cci node in exynos5420.dtsi?
<krzk> you should extend it as in example from bindings
<wwilly> yep, it's this one where I had the code in the pastebin earlier
<wwilly> the added pmu is in the file arch/arm/boot/dts/exynos5420.dtsi
<krzk> Ah, I understand now
<wwilly> yes is not a proper patch... :)
<krzk> try to use shorter length, so 0x9000 0x1000 (although it is just a guess)
<krzk> and narrow the error to spwcific line
<krzk> because to my knowledge and understanding, your code is pretty okay (maybe except interrupts)
<krzk> also have in mind that certain parts - like PMU... (or entire CCI in case of Exynos5410 or Exynos5420) - might be locked by Trusted Firmware
<wwilly> oh...
<wwilly> didn't know that
<krzk> which is the reason while Arndale Octa (Exynos5420) requires special hacks to have big-little online (and in mainline it is just one cluster)
<krzk> but usually the errors are different in such case
<krzk> usually it is imprecise abort + full BUG() :), not invalid resource
<wwilly> ok, I hope is not that then
<wwilly> don't know how to dig that invalid resource...
<wwilly> you suggest reg = <0x9000 0x5000>; -> reg = <0x9000 0x1000>; ?
<krzk> the simplest - add pr_err("%s:%d\n", __func__, __LINE__) everywhere :)
<krzk> so you will see which kernel code does it
<wwilly> yep I did that on the arm-cci.c
<krzk> yes, I suggest to try but it does not look reasonable :)
<krzk> just try
<wwilly> and all seems fine
<krzk> You can also try dynamic debug with a pattern for entire directory
<wwilly> all return 0, and no early return with -E...
<krzk> invalid resources looks like devm_ioremap-family of calls
<krzk> which might be in different driver than arm-cci!
<krzk> it might be the PMU driver
<krzk> I am going, have a nice weekend!
<wwilly> ok
<wwilly> I'm going too, have fun during your weekend
<wwilly> thanks for your help :)
mszyprow|home has joined #linux-exynos
mszyprow|home has quit [Ping timeout: 250 seconds]
wwilly_ has joined #linux-exynos
decay_ has joined #linux-exynos
wwilly has quit [Ping timeout: 255 seconds]
javier__ has quit [Ping timeout: 255 seconds]
decay has quit [Ping timeout: 246 seconds]
javier___ has joined #linux-exynos
javier___ has quit [Quit: leaving]
javier__ has joined #linux-exynos
javier__ has quit [Client Quit]
javier__ has joined #linux-exynos
_whitelogger has joined #linux-exynos