<bgamari->
What is the default behavior without cpufreq?
<bgamari->
I'm skeptical that the cores are running at their specified clockrate
<bgamari->
javier__, It doesn't look like this set was ever reviewed
<bgamari->
What was holding up merging this set?
<javier__>
bgamari-: IIRC, Bart posted patches for CPUFreq support for Exynos4412, 5250 and 5420
<javier__>
and at the same time, the operating-points-v2 work was being made
<javier__>
so after months, the CPUFreq maintainer told him to rework his patches and use opp v2 instead
<javier__>
Bart was not happy about having that feedback after months he posted the patches but did the rework for 4412 and 5250
<bgamari->
I see
<javier__>
but I think never had time to do the same for 5420... I don't know what is needed though
<bgamari->
Alright; that doesn't sound like such a hard task
<javier__>
I didn't follow the discussion to closely
<bgamari->
given that in principle there is a model for the refactoring necessary to move to OPPv2
<javier__>
bgamari-: yeah, maybe the needed changes are small but I don't know tbh
<bgamari->
sure; I'll have a look next weekend
<bgamari->
javier__, when the chip comes up it should be clocked at ~1.8 GHz, correct?
<bgamari->
lacking cpufreq
<javier__>
bgamari-: that would be awesome, I have that on my TODO list as well but for had for a long time
<javier__>
bgamari-: I believe so but it depends whether the bootloader changes the clock freq
<bgamari->
right
<bgamari->
javier__, what list did that patch set go to?
<bgamari->
I'm having trouble finding it locally
<javier__>
bgamari-: mmm, I also don't have v2 locally indeed
<javier__>
ah no, I do. linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org and linux-pm@vger.kernel.org
<bgamari->
hmm
<bgamari->
ahh, I think I found it
<bgamari->
it ought to be possible to implement cpufreq without committing to implementing cpuidle, correct?
<bgamari->
the thread from August "CPUIdle for Exynos5422 Odroid-XU3/XU4 boards." suggests that they are related
<bgamari->
hopefully cpuidle depends upon cpufreq and not vice-versa
<javier__>
bgamari-: they are separate but my understanding is that for boards with broken firmware (i.e: odroids) the system may hang when trying to set lower frequencies
<javier__>
just like for CPUidle, it hangs when trying to enter into deep sleep states
<javier__>
bgamari-: but it should just be a matter fo defining the valid OPPs for that board
<javier__>
that is what's missing in mainline to support higher freqs
<daniels>
javier__: oh, that makes a _lot_ of sense
<sjoerd>
javier__: ah right that was it
Zotan has quit [*.net *.split]
gordan has joined #linux-exynos
gordan has quit [Ping timeout: 260 seconds]
_anomaly_ has quit [Ping timeout: 260 seconds]
_anomaly_ has joined #linux-exynos
masta has joined #linux-exynos
ssvb has joined #linux-exynos
gordan has joined #linux-exynos
Zotan has joined #linux-exynos
<bgamari->
javier__, where does the firmware run?
<bgamari->
daniels, I'm on an XU4
<bgamari->
javier__, I guess there's a Cortex for power management on the die like the OMAPs?
<bgamari->
javier__, In what way is the Odroid's firmware broken?
<bgamari->
and is it possible to update?
* bgamari-
is using this device as a build-bot so I wouldn't mind some a few more clock cycles if the device stability weren't compromised
<javier__>
bgamari-: AFAICT is more as how the first stage bootloaer left things
<javier__>
for example in the case of CPUidle, CCI is left in a mode that can't be managed by the MCPM framework in the kernel
<javier__>
and there are things that can be updated (i.e: first stage bootloader) but requires hardkernel to sign the binary
<javier__>
and other stuff can't be updated AFAIU
<bgamari->
I see
zombah has quit [Quit: Leaving]
gordan has quit [Remote host closed the connection]
gordan has joined #linux-exynos
gordan has quit [Ping timeout: 250 seconds]
gordan has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa>
hi all
<Wizzup>
hi
<Tenkawa>
anyone had any luck/tried getting 4.2 kernel booting on the xe303c12
<Tenkawa>
hey Wizzup
<Tenkawa>
i dont need x.. just want to get this kernel working
<Wizzup>
I think I have it running on snow
<Tenkawa>
i have to be missing something simple like the right dtb
<Tenkawa>
I create the kernel (using vbutil still)
<Tenkawa>
and it just blank screens on booyt
<Tenkawa>
er boot
<Tenkawa>
go back to my old kernel (3.19.0-next something) and its just fine
<Wizzup>
Why not give 4.3 or 4.4 a try?
<Wizzup>
with exynos_defconfig
<Tenkawa>
good point
<Tenkawa>
let me try
<Wizzup>
(suggest 4.3)
gordan has quit [Quit: Konversation terminated!]
gordan has joined #linux-exynos
<Tenkawa>
especially since i know I have a fallback
<Tenkawa>
I'm trying to get everything up to date so i can use this laptop to develop for my arm socs more
<Tenkawa>
using an x86 to build with has been "interesting"
<Tenkawa>
especially with one that is a bit crash friendly atm
<Tenkawa>
Wizzup: which dtb should i use?
<Tenkawa>
4.3 is compiling now
<Wizzup>
the dtb for your board? :)
<Wizzup>
What do you mean
<Tenkawa>
yeah.. which one does that model chromebook use?
<gordan>
Tenkawa, I haven't tried it on my Snow (Presumably that is what you have), but have 4.3 (and had 4.1) working on the Peach Pi.
<gordan>
The same kernel should work on both.
<Tenkawa>
yeah mine is snow
<gordan>
Are you using u-boot?
<Tenkawa>
no
<Tenkawa>
I'm signing the kernels with vboot still
<gordan>
You probably should. I had various problems with vboot/kernel combinations.
<Tenkawa>
uboot and me have not been friends
<Tenkawa>
on any of my boxes heheh
<gordan>
Annoyingly, I left my Snow at home this week (brought the AC100 with me to get my distro working on that with a fresh kernel/u-boot).
<Tenkawa>
heeheheh
<gordan>
But if you are booting off a uSD card testing u-boot should be quite easy.
<Tenkawa>
good point
<Tenkawa>
for now i need the kernel to build
<Tenkawa>
that will take a while
<gordan>
If you are around after about 20:00-20:30-ish tonight, I can probably build a mainline u-boot binary for you to try.
<gordan>
Kernel doesn't take long to build using the defconfig.
<Tenkawa>
I wont be here.. i will be here tomorrow though
<Tenkawa>
thanks though
<gordan>
No worries.
<gordan>
I was finding that u-boot and ChromiumOS kernels really, really do not play together at all.
<Tenkawa>
this defconfig build is moving nicely
<gordan>
I couldn't get a ChromiumOS patched kernel to boot via u-boot no matter what I did.
<Tenkawa>
speedwise anyway
<gordan>
Yeah, it should be good enough to test with.
<Tenkawa>
gordan: yeah thats why i'm trying to use mainline
<gordan>
Audio is still broken, though, on all the Samsung Chromebooks.
<Tenkawa>
i like those better anyway
<gordan>
Fair enough.
<Tenkawa>
gordan: dont need it
<Tenkawa>
this is just to use for devel for my sbcs
<gordan>
I had 4.1.x working fine on the Peach Pi, and that is a LT kernel.
<gordan>
So you may want to stick with that, at least until the sound is fixed and upstreamed, to justify using a bleeding edge non-LT kernel.
<Tenkawa>
heheh
<Wizzup>
gordan: 4.1 doesn't have working sound on peach pi
<Tenkawa>
I'm using 4.2 on everything else (x86 and arm_
<Tenkawa>
er )
<Tenkawa>
wow this compile is running very nicely
<Tenkawa>
lot faster than i remembered
<gordan>
Wizzup: Sound doesn't work at all for me on 4.3.0 either. :p
<gordan>
Tenkawa: Personally I'm still sticking to 3.18.x LT on everything where I can at all help it. If 3.10.x is workable, I'm sticking to that since it's what EL7 ships with (and I'm one of the RedSleeve maintainers, which is ARM port of EL6 and EL7).
<Tenkawa>
ahh
<gordan>
Tenkawa: You should be aware that the defconfig kernel is _minimalist_.
<Wizzup>
it is what you need to get it to work :)
<Tenkawa>
gordan: yes.. i would rather it be and me add to it
<gordan>
By the time I enabled some of the other options in the build, the build time went up by a factor of about 5x.
<Tenkawa>
instead of these ones that try to compile everything
<Tenkawa>
gordan: thats fine.. once i know it works i'll setup scheduler builds
<gordan>
Tenkawa: I find that I end up needing many of the features of the "build everything" kernel.
<Tenkawa>
i will too.. however i want it to just boot first heehee
<gordan>
By the time I enabled a few extra drivers (e.g. various USB stuff), fanotify, various things that ZFS needs, etc, you end up with an awful lot.
<gordan>
But yes, getting something to boot is an important starting point. :)
<Tenkawa>
yep
<gordan>
Wizzup: If you happen to have a howto on how to get anything sound related working, I'd love to see it.
<gordan>
Wizzup: I should really try headphones on mine, I seem to recall you suggested it last week.
<Tenkawa>
and I really like having my external usb card to use as my test kernel
<gordan>
Tenkawa: I'm currently runing RSEL7 with mainline 4.3.0 kernel and mainline u-boot on the Peach Pi.
<Tenkawa>
if i oops.. just reboot and ctrl d
<Tenkawa>
heehee
<gordan>
Works really well, ZFS rootfs, too.
<Tenkawa>
gordan: thats a cb 2 right?
<gordan>
And I'm finding that ZoL kernel level ZFS works really good.
<gordan>
Yes, Peach Pi is the CB2 13" with the 1080 screen.
<Tenkawa>
yep.. i have the 11.6 cb 1
<Wizzup>
gordan: it will still run too fast
<gordan>
I have one of those, too, but the wife claimed it so I'm not allowed to leave it broken any more. :p
<Tenkawa>
kernel is almost done :)
<Tenkawa>
gordan: haahaa
<gordan>
Wizzup: Too fast is better than not at all.
<javier__>
Wizzup, gordan: I compared the downstream and mainline ASoC machine drivers and found two interesting things
<gordan>
javier__: Do tell
<javier__>
1) there is no hw_params handler in mainline while there is one in the downstream tree
<gordan>
That sounds pretty important...
<Tenkawa>
indeed
<javier__>
2) the clock hierarchy is much more complicated in downstream than in mainline
<javier__>
in mainline there is a single composite mux clock (XCLKOUT) whose output goes to the codec's master clock
<gordan>
I take it just copying the driver .c file into the mainline won't work...
<javier__>
no, the clock drivers are quite different so a blind copy & paste won't work
<javier__>
(and I don't like to do such things since I prefer to understand what's going on :) )
<gordan>
Wizzup: I know this is lame from the kernel point of view, but would it not be possible to set up something in userspace to be transcoding in realtime from whatever the source is at to 48KHz?
<gordan>
javier__: I totally understand the preference for knowing what is going on.
<Wizzup>
gordan: eh, that is not preferrably at all
<javier__>
gordan: I'm also wondering now why there is a specific ASoC machine driver for Snow/Peachs and the simple-audio-card can't be used
<javier__>
since I see that is used by a lot of boards (including the Odroid XU3)
<gordan>
Wizzup: I get that, just trying to come up with a way to get it working right now as opposed to right.
<javier__>
but I'm not really familiar with sound in general to tell...
<javier__>
so I asked in the ML to Alim who was the last posting a patch related to peach sound to see if he has an idea of what's missing
<Wizzup>
javier__: that is good to hear @ ML
<Tenkawa>
ok here goes a new attempt
Tenkawa has quit [Quit: leaving]
<Tenkawa>
bbiaf
<gordan>
javier__: Very much looking forward to hearing what Alim says on the subject.
<gordan>
Once sound is working the only remaining things will be the MALI driver. Annoyingly, it's binary only at the moment, which is a real PITA for me since I need the soft-float version which I'm probably not going to get. >:-(
<Wizzup>
I just don't use 3d
<javier__>
gordan: yeah, I don't believe there is a soft float version of the mali blobs
<javier__>
in fact, most people are just using hard float by now for everything
<javier__>
gordan: but we alreay had this conversation before :)
<gordan>
We did.
<gordan>
CentOS 7 armv7hl isn't released yet, so it's either my RSEL 7 or bust, sadly.
<Wizzup>
or use a more recent distro :)
<gordan>
EL7 is the latest EL.
<gordan>
Plus the fact that if I find something is badly broken I'm more motivated to fix the root cause if it's the distro I'm maintaining.
Tenkawa has joined #linux-exynos
<Tenkawa>
success!!
<Tenkawa>
4.3.0 is up and running
<Tenkawa>
recompiling now with tweaks
<gordan>
Yeah, it took me 3-4 builds to get to the point where everything I needed worked.
<Tenkawa>
i'm just glad to see its booting now and i'm on the network