libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-exynos
libv has quit [Ping timeout: 260 seconds]
_whitelogger has joined #linux-exynos
nighty-- has joined #linux-exynos
mszyprow has joined #linux-exynos
<forkbomb> mszyprow: do you know much about which parts of the firmware need to co-operate to support cpuidle on exynos4412? would it be possible to get cpuidle working with an odroid BL1?
<mszyprow> forkbomb: frankly I have no idea, I didn't touch cpuidle/suspend-resume code at all
afaerber has joined #linux-exynos
<forkbomb> ok, any suggestions on people who might be more knowledgable?
<mszyprow> forkbomb: you may ask krzk, but I doubt if he remember the details...
<forkbomb> ok
<mszyprow> forkbomb: I don't even know if odroid's bl1 have relevant code
<forkbomb> yeah, that's what i was wondering
<mszyprow> forkbomb: on the other hand suspend-resume works on Odroid X2/U3
<forkbomb> the datasheet i have is pretty light on details around firmware's aftr support
<krzk> forkbomb: mszyprow: the suspend and cpuidle path are almost the same on Exynos - in general they go through entire booting proces (IROM, BL1, BL2, u-boot, kernel)
<krzk> although at some point they skip some parts of initialization - usually depending on the values of INFORM/SPARE registers
<krzk> AFAIR, this was in U-Boot (but maybe in SPL part? I don't know)
<mszyprow> krzk: definitely SPL
<mszyprow> krzk: but SPL is not used since exynos4210
<krzk> Maybe BL1 is also aware of this - maybe it also has to do things differently (do not initialize all the hardware if it is booting from suspend/cpuidle).
<mszyprow> uboot spl
<javier__> at least for b.L SoCs (i.e: Exynos5420), the BL1 can break CPUidle support
<javier__> for example the Odroid BL1 leaves the CCI in secure mode so the kernel MCPM support can't be used
<krzk> then everything is hard-coded in BL1 and BL2 - both must support given mode to work
<javier__> since it can't properly manage CCI (IIRC), that's why we don't have CPUidle enabled by default in exynos_defconfig
<krzk> javier__: it would be weird if only CPUidle is broken and suspend is working
<krzk> I mean - for kernel in our mach-exynos code suspend is easier but for bootloader?
<mszyprow> javier__, krzk: now we are discussing exynos4412 (trats2/galaxy s3), so no b.L yet
<javier__> krzk: oh, probably S2R is also broken. But when enabling CPUidle the machine doesn't even boot (since the cores are entered in deep sleep states automatically)
<krzk> mszyprow: true
<javier__> mszyprow: nod, I just meant that sometimes the BL1 can affect CPUidle / S2R support (like is the case for b.L)
<javier__> so I wouldn't be surprised if that was the case for exynos4 as well
<forkbomb> ok, so it's impossible to have unsigned bl2 and cpuidle I guess.
<forkbomb> thanks
<krzk> forkbomb: if suspend to RAM is working, then cpuidle should also work
<krzk> so start from checking S2R
<forkbomb> ok
<mszyprow> krzk: s2r works on odroid u3, but coupled cpuidle not
nighty-- has quit [Quit: Disappears in a puff of smoke]
wwilly has joined #linux-exynos
paulk-gagarine-s has joined #linux-exynos
paulk-gagarine has quit [Ping timeout: 248 seconds]
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-exynos
mszyprow has quit [Ping timeout: 260 seconds]
wwilly has quit [Ping timeout: 248 seconds]
Vasco_O is now known as Vasco
wwilly has joined #linux-exynos
aalm has quit [Ping timeout: 248 seconds]
aalm has joined #linux-exynos
paulk-gagarine-s has quit [Ping timeout: 268 seconds]
f4bug has joined #linux-exynos
aalm has quit [Ping timeout: 248 seconds]
wwilly_ has joined #linux-exynos
wwilly has quit [Read error: Connection reset by peer]
<f4bug> Hi, I'm looking at a QEMU patch from krzk when he add the dw_mshc SD/eMMC host controller in the Exynos 4210
<f4bug> his specs say this devices implements the "SD Standard Host Specification Version 2.0"
<f4bug> and define the capabilities as:
<f4bug> #define EXYNOS4210_SDHCI_CAPABILITIES 0x05E80080
<f4bug> the bit 19 isn't specified in the Spec v2
<f4bug> I can not find this information in the Exynos_4_Dual_45nm_User_Manaul_Public_REV1.00-0.pdf
<f4bug> removing this unknow bit 19, the CAPAB register should be 0x05E00080
<f4bug> in the Spec v3 the standard defines the bit 19 as SDHC_CAPAB_EMBEDDED_8BIT
<f4bug> I don't want QEMU interpret this as the Embedded 8bit if it has other meaning for this SoC
<f4bug> Is there someone here with access to the Samsung specs able to check what is this bit?
aalm has joined #linux-exynos
Vasco is now known as Vasco_O
wwilly__ has joined #linux-exynos
wwilly_ has quit [Ping timeout: 256 seconds]
wwilly__ has quit [Quit: Leaving]
wwilly has joined #linux-exynos
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-exynos