<javier__>
had no answer yet, let's see what mark and others say
<javier__>
but there is something fishy with the memory in the exynos chromebooks
<steev>
i saw that
<javier__>
steev: oh, sorry for the noise then
<steev>
javier__: oh no, i appreciate it
<steev>
always better to be in the know :)
<javier__>
:)
<issoeocio_>
javier__, some days ago you help me to setup the touchpad in the snow board with atmel touchpad. The only feature left was audio. I tried to copy and past some other configs but I was unable to get the sound working. If I change max98095 ti max98090 I get the card recognized by the kernel, but no sound is produced.
<Wizzup>
I think on snow that card is already recognized by the kernel
<Wizzup>
ah, like you said, no sound
<Wizzup>
(and it runs at triple speed)
<Wizzup>
also, you DO need to set the right also switches
<Wizzup>
at least for speakers
<Wizzup>
(left|right) speaker (left|right) DAC (all four permutations)
<issoeocio_>
the board only get recognized with the changes I made in the dts. There is a (treated by google as) rev5 of that board with the touchpad and the sound board changed
<Wizzup>
for me, sound on my snow is detected, just gives me actual output (but runs at triple speed)
<Wizzup>
I recall got some output either on peachpi or snow but that didn't sound well and also ran too fast
<issoeocio_>
max98095?
<javier__>
issoeocio_: it seems sound on Snow still depends on setup made by the bootloader
<javier__>
so depending of what u-boot you are using, you may get sound working or not
<javier__>
issoeocio_: your changes look right although I didn't looked at the ChromiumOS 3.8 DTS to see if the values are correct
<javier__>
I'm very deep looking at the ARM MMU code now to context switch
<Wizzup>
issoeocio_: yes
<issoeocio_>
I compiled the uboot with snow_defconfig with CONFIG_SOUND_MAX98090=y
<issoeocio_>
but maybe I have made some mistake. I will try to recompile the uboot
<javier__>
steev: probably you will read my answer in the thread anyways but if anyone finds the same issue, v4.1 boot hang using FIT is fixed by this patch from Laura Abbot https://lkml.org/lkml/2015/6/4/606
<steev>
javier__: interesting
<javier__>
steev: my theory is that the problem is that since the non-pmd-aligned memory block is the start of the very big ~2GiB mem block, the memblock.current_limit was the first 30MiB and was never updated to arm_lowmem_limit again so the system only had 30MiB of ZONE_NORMAL
<javier__>
steev: so it was a corner case of a very strange partition layout made by he RO u-boot
<javier__>
30MiB following by a gap and then ~2GiB but not 2GiB so it the memory block was not aligned
<javier__>
the mainline u-boot has a single correctly aligned 1.5GiB memory block
<javier__>
but Laura patch restore the memblock.current_limit to arm_lowmem_limit after map_lowmem() has completed all the lowmem mapping so allocations can happen from the non-pmd-aligned section again
zombah has joined #linux-exynos
issoeocio_ has quit [Quit: Leaving]
aballier has quit [Quit: leaving]
aballier has joined #linux-exynos
javier__ has quit [Ping timeout: 252 seconds]
javier__ has joined #linux-exynos
javier__ has quit [Quit: leaving]
javier__ has joined #linux-exynos
afaerber__ is now known as afaerber
_whitelogger has joined #linux-exynos
zombah has quit [Quit: Leaving]
dizus has joined #linux-exynos
zombah has joined #linux-exynos
<steev>
javier__: hmm, i'll have to look at that one
<steev>
i pulled it in, but
<steev>
oh, stupid thing
<steev>
i have no idea why a wget of the patch file always puts a space after the --
<steev>
and patch always bitches, maybe i should start telling patch to ignore whitespace errors
dizus is now known as dizzus
dizzus is now known as dsfsdfsdfsdfsd
dsfsdfsdfsdfsd is now known as dizus
dizus is now known as dizzuhen
dizzuhen is now known as dizzus
dizzus is now known as dizus
dizus is now known as dizzuhen
<javier__>
steev: you should use pwclient and patchwork
<javier__>
steev: i.e, to apply laura's patch in a git tree $ pwclient git-am 6549731
<javier__>
steev: you can also search for patches in different patchwork projects and use different filters, i.e:
<javier__>
$ pwclient list -p linux-arm-kernel -w "Laura Abbot"
<steev>
oh wow
<javier__>
or just download the patch instead of apply it directly:
<steev>
javier__: wait, does that mean the linux-exynos patchwerk has been cleaned up?
<javier__>
$ pwclient get 6549731
<steev>
last time i looked at it there were like thousands of patches
<javier__>
steev: you mean by changing the state of the patches? no but the patches are there and you can use pwclient to get them
<javier__>
you just can't use pwclient -s <state> option since everything is 'New' :P
<steev>
javier__: yeah... i meant cleaned up so if you go to the web interface it doesn't seem abandoned
<javier__>
steev: well, although it would be nice to change the patch status to 'Accepted', etc I still think is a great tool to parse the patches from mailing list and store there
<javier__>
I mean, much better than using wget / curl for sure
<steev>
javier__: oh i mean the patchwork site itself
<steev>
not using pwclient to set them - but that would be nice, i just mean, clean it up so it looks like the tegra patchwork site
<steev>
so it's much easier to tell where the dangling fruit is
<javier__>
steev: oh, no it is unders development. In fact there are new features like counting the s-o-b, acked-by, reviewed-by tags, etc
<steev>
can't just archive it since there's a newer version?
dizus has joined #linux-exynos
<javier__>
steev: right but you have to do it manually since is hard to check what a newer version is
<javier__>
i.e: the diff and patch subject could change, there could be a completely different patch series that supersedes an older one, etc
<javier__>
steev: I believe there is a way to archive automatically if a patch landed and the diff is exactly the same so probably it should be easy to clean up most of the patches though