<Wizzup> steev: if you want I can give you my exact commit hash tomorrow, plus config and wifi version
<Wizzup> for pi though
<steev> I think I have pi
<steev> The 13.3" WiFi only
<WarheadsSE> always get which is which confused on pi v pit
<steev> 90% postiive this is pi, and 11" is pit
<si1v3r> Wizzup: thanks
tilmann has joined #linux-exynos
<sjoerd> steev: 13" is pi and 11 is pit indeed
<steev> sjoerd: :)
<steev> i'm definitely digging the 13"
<Wizzup> si1v3r: \o/
<tilmann> steev: is the 13" the 5800 based one?
<sjoerd> tilmann: yes
<tilmann> do you know whether hardware performance counters work on that one? :)
<tilmann> e.g. the perf tool
<sjoerd> Probably depends on what kernel you're using
<sjoerd> but perf top seemed to work ok on mine
<tilmann> nice!
<tilmann> do you have it running right now?
<sjoerd> i do
<tilmann> could you please do a 'perf stat ls' for me and paste the output? :)
<sjoerd> looks like my kernel is missing some bits still
<tilmann> yeah
<tilmann> the thing is the hardware performance counters need to be enabled from outside of the CPU
<tilmann> and the interesting question is whether the necessary information to do that on the 5800 is publicly available
<tilmann> e.g. for the 5420 it's not known and because of that you can't use the hardware performance counters on the Arndale Octa
<sjoerd> I see
<sjoerd> I thought there was a common PMU on arm
<sjoerd> or am i just thinking about something different
<tilmann> yes that's correct
<tilmann> however apparently how to enable the PMU is still implementation-defined
<tilmann> and that's where the problem starts :)
<tilmann> (if you don't have the documentation of the SoC)
<tilmann> I think you can always read the cycle counter
<tilmann> but the others you need to configure properly
<sjoerd> ah right
<sjoerd> [ 0.044534] EXYNOS: PMU not supported
<sjoerd> I however seee that there is a patch floating around for enabling the 5420 though
<tilmann> actually the message you are seeing there is for a different PMU :)
<tilmann> that's the Power Management Unit
<sjoerd> oh sigh
<tilmann> (yes very confusing :) )
<tilmann> i think all the recent changes were just about power
<sjoerd> indeed nothing sets up the arm-pmu under mach-exynos
<sjoerd> Indeed
<tilmann> :(
<sjoerd> Worth checking the chromeos kernel though
<sjoerd> To see if they have patches for it there
<tilmann> yeah
<sjoerd> odd though i have used perf on exynos 4 a while ago and i'm sure the other bits did work
<sjoerd> Ah, need to be in the dts now
dlezcano has joined #linux-exynos
<tilmann> sjoerd: yes i think the counters work fine on the Exynos 4
<sjoerd> Nod, there are dts entries for it
<tilmann> but so far I haven't seen a positive report on the Exynos 5
<sjoerd> I was confused as i was using the counters on a pre-dts odroid kernel so things moved around
<tilmann> i see
<tfiga> I don't think you need anything other than a DT node to get PMU running
<sjoerd> Nod, they just aren't there for all supported exynos soc's
<tfiga> The only platform specific bit is the interrupt
<tfiga> But should be just a matter of specifying it correctly in that node
<sjoerd> It's defined for exynos5250 and exynos5440, but not exynos5420 and 5800
<sjoerd> So just a matter of someone with the manual to dig up the right values i guess :)
<tfiga> I don't have the manual right now so can't look this up at the moment
<tfiga> But doesn't it work already on chromium kernel?
<sjoerd> I'm using a 3.16 based kernel on my chromebook, but i did not see a dtsi entry in my chromeos kernel checkout
<tfiga> Might be still handled by some legacy code in older kernels
<tfiga> I'd just post this issue to linux-samsung-soc ML
<sjoerd> sure we were just having a random chat really :)
<tfiga> Adding Chromium guys on Cc and also Samsung people who worked on support for 5800
<steev> ugh
<steev> wtf kernel do they actually release
<steev> because the one from the firmware commit doesn't have the dtbs for the peach
<steev> it would be really nice if they'd actually commit the peach stuff to the chromiumos overlay as well
<tilmann> tfiga: yeah i think it's just a matter of hooking up the interrupt properly
<tilmann> i think the kernel i'm running actually has the DT node
<tilmann> (3.15 linaro kernel)
<tilmann> tfiga: do you have access to the Exynos 5420 manual?
<tilmann> i actually work in the Samsung Open Source Group (on LLVM rather than kernel stuff though) and I'm trying to get access to it internally
<tfiga> tilmann: yes, I managed to obtain it, although it wasn't easy and it's still some old version
<tilmann> tfiga: awesome :)
<tfiga> I work for Samsung R&D Institute Poland, though
<tilmann> oh cool :)
<tilmann> i'd really like to get this working on the Arndale Octa
<tilmann> i'm happy to help in any way i can to debug/test this
<tilmann> tfiga: so to get this going i should just go ahead and report this on linux-samsung-soc?
<tfiga> tilmann: I think so
<tfiga> there were several people involved in mainlining 5420/5800, so they should at least have access to the documentation
<tilmann> tfiga: i spoke with the manager SR India on Friday and he hold me that they have stopped their upstream activity
<tilmann> +in
<tilmann> (apparently part of the Samsung Linaro team)
<tfiga> well, I wouldn't really believe in that
<tilmann> basically the conclusion was that I can try to implement it myself and I could ask questions
<tilmann> but they are focusing on different things now :)
<tfiga> there have been similar statements several times and you still can see patches from some India R&D
<tilmann> probably there are other teams still contributing though
<tfiga> the best way is to go about open source code is to just post to the MLs
<tilmann> yeah
<tfiga> for brave and impatient souls there might be another solution though, as there must be a vendor tree somewhere
<tilmann> you mean i should try to use an internal samsung tree?
<tfiga> and there you might find (or actually reverse engineer) necessary information
<tfiga> not really internal, but rather downstream
<tilmann> i see
afaerber has joined #linux-exynos
<tomeu`> amazing
* sjoerd makes a note to check if his snow has that particular firmware version
<tomeu`> one knows something must be really wrong when there's more comments than code
<tilmann> tfiga: any vendor trees in particular which you would recommend looking into?
<tfiga> tilmann: hard to say where to look for them in case of 5420/5800
<tfiga> afaik there is a 5420-based SGS5
<javier__> tilmann: I would go with the chrome os 3.8 kernel tree since that has support for the peach pit (exynos5420) and pi (5422/5800)
<javier__> tilmann: or did you already check that one and didn't find what you were looking for? (sorry if I missed from the backlog)
<tfiga> javier__: apparently there is no DT entry for ARM PMU in related dts files in chromeos-3.8 tree
<tilmann> thanks for the pointers, i will have a look :)
<tomeu`> tfiga: what's the status of s2r on the exynos4?
<tomeu`> (in mainline, of course)
<tfiga> tomeu`: SoC-wise it should work after applying the patches I sent some time ago
<tfiga> boards might need specific fixup depending on design
<tfiga> unfortunately getting something merged through Samsung SoC tree can be quite hard, so they missed this merge window and are delayed for 3.18
<javier__> tfiga, tilmann: right, I just looked at the chrome os 3.8 kernel and I don't see that an "arm-pmu" is registered as a platform device neither
<tomeu`> tfiga: do you have a rough idea of when those were sent?
<tomeu`> in weeks is fine
<tomeu`> ah, thought they were more recent, thanks
<javier__> tfiga, tilmann: so I was looking at adding the needed PMU nodes for 5420 but I've some questions since I don't see other big.LITTLE platform on mainline that has their PMU defined
<javier__> now it seems that the a15 and a7 cores interrupts are hooked differently
<javier__> the a7 pmu have a combiner irq type while the a15 are just gic spi irqs
<javier__> tfiga: does that mean that I should add 2 arm-pmu dev nodes?
* javier__ wonders how that works when the bL switches is not enabled
<tfiga> javier__: to be honest, I have no idea
<tfiga> but interrupts shouldn't matter here
<tfiga> I mean, you could just use interrupts-extended or interrupt-map to specifiy interrupts with different parents
<javier__> tfiga: right, I complete forgot about interrupts-extended
<javier__> that was my question indeed since to use the exynos combiner I needed to define interrupt-parent = <&combiner>;
<javier__> tfiga: thanks for the pointer
<tfiga> but I wonder whether there aren't in fact two different PMU units
<tfiga> one per cluster
<tfiga> clearly I don't know too much about ARM PMU
<javier__> yeah me neither, I'm just trying to help since I've access to the docs
<javier__> but seems to not be as trivial as I thought
<javier__> tfiga: there is also the question about the compatible string, by looking at arch/arm/kernel/perf_event_cpu.c I see that the pmu init function is passed in of_id->data
<javier__> tfiga: so I don't think that the driver supports to init pmu units for different cpuid parts
<tfiga> this might be a suggestion that you indeed need two separate nodes for both clusters
<javier__> nod
<javier__> hence my question what happens when you don't enable the bL switcher and just let the scheduler to manage all the cores
<tfiga> although I wonder if this driver supports such cases
<tfiga> apparently it doesn't
<javier__> tilmann ^ may not be that trivial to enable the PMU for big.LITTLE machines
<javier__> tilmann: better to ask on linux-samsung-soc for someone who has more experience with this
<tfiga> well, at least if you require support for all cores
<tfiga> it might not be that hard to fix the driver, though
<tfiga> AFAICT the biggest issue is that it always sets things up for all possible CPUs, not a subset of them
<javier__> tfiga: right, I guess it shouldn't be that hard to fix
<javier__> although is more complex that just adding a DTS node as I originally thought :)
<javier__> I'll add it to my TODO anyways for when I've more time to look at it in more detail
<tfiga> javier__: tilmann: it looks like there is some ongoing work
<tfiga> that series is just preparation, though
<javier__> indeed, thanks for the info
<tilmann> javier__: tfiga my understanding is that there is one PMU per CPU (e.g. two on Exynos 5420)
<tilmann> so it sounds like there's no pmu code for big.LITTLE machines at all?
<tilmann> to be honest at this point in time i'd be happy if it works just on the Cortex-A15 cores (the Cortex-A7 cores don't even boot on the Arndale Octa)
<javier__> tilmann: are may try this DTS snippet (completely untested but afaiu has the right IRQs from the doc): http://paste.debian.net/plain/114859
<tilmann> that looks like what's missing!
<javier__> tilmann: ups you also need to include <dt-bindings/interrupt-controller/arm-gic.h>
<tilmann> let me check what's in the kernel i'm using right now
<javier__> tilmann: ok
<javier__> tilmann: btw, for the a7 cores should be http://paste.debian.net/plain/114862
<tilmann> javier__: those are the messages i'm getting in dmesg maybe that also gives you a hint: http://paste.debian.net/114864/
<tilmann> javier__: yeah, there are no arm-pmu entries in the linaro 3.15 dts
<tilmann> javier__: i'll give your patch a try, need to figure out how to build my own kernel first though :)
<javier__> tilmann: sorry, got the offset wrong, instead of 192-195 can you try 160-163?
<tfiga> javier__: have you read the right column in the docs? I remember two different IDs being listed there
<tfiga> ahh
<javier__> tfiga: yes I did....
<tilmann> ok will try with 160-163
<javier__> tfiga: I mean, I didn't read the right column :)
<tfiga> hehe
<tfiga> this was quite confusing for me too when I first looked at it
<javier__> indeed
tilmann has quit [Quit: leaving]
liquidAcid has joined #linux-exynos
liquidAcid has quit [Ping timeout: 255 seconds]
dlezcano has quit [Ping timeout: 255 seconds]
dlezcano has joined #linux-exynos
afaerber has quit [Quit: Verlassend]
<steev> How is mainline doing on the chromebook2? Still no wifis?
<Wizzup> I have not tried in one or two weeks
<Wizzup> I was going to sleep now though
<Wizzup> if your wifi is still meh, do you have thr right firmware?
<Wizzup> when I had diff (newer) firmware it'd die in seconds
<Wizzup> javier__: I can create wiki accounts now btw, iirc you'd like one right?