HcE has quit [Ping timeout: 265 seconds]
HcE has joined #linux-exynos
dlan has quit [Ping timeout: 252 seconds]
dlan has joined #linux-exynos
ssvb has quit [Ping timeout: 256 seconds]
dlezcano has quit [Ping timeout: 246 seconds]
<javier__> Wizzup, si1v3r: I notice that not all the patches ended in linux-next yet, so if you are trying -next please let me know and I'll tell you what's missing
<javier__> si1v3r: wifi is working with -next + some posted patches, audio is not working yet
afaerber has joined #linux-exynos
prahal has joined #linux-exynos
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
sjoerd has quit [Ping timeout: 265 seconds]
ojn has quit [*.net *.split]
ojn has joined #linux-exynos
prahal has quit [Ping timeout: 246 seconds]
prahal has joined #linux-exynos
sjoerd has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> Anyone running a newer kernel than 3.8.11 on a first gen chromebook without using nv-uboot?
<Wizzup> I think that should definitely be possible, with outh nv-uboot that is
<Tenkawa> cool
<Tenkawa> wow the kernel tree's are old in chromium's git repo
<Tenkawa> thanks for the info though.. time to reboot to a few changes
<Tenkawa> bbl
Tenkawa has quit [Quit: leaving]
<sjoerd> nv-uboot really doesn't make a difference. maybe unless you use the simplefb driver, but then again you don't really want that one anyway
ssvb has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> Wizzup: well I got 3.18 to boot on the chromebook however no video output even console
<Tenkawa> does the console= have a different name/dts address that needs to be passed
<Tenkawa> I can type/login/reboot just fine... just no vid
<Tenkawa> I really don't need anything outside of text either
<Tenkawa> testing a theory.. brb
Tenkawa has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
<Tenkawa> well it definitely appears to be dts relaed
<Tenkawa> er related
<Tenkawa> it doesnt appear to push the output the panel
<Tenkawa> or actually possibly a regulator entry
<javier__> Tenkawa: which tree are you testing?
<Tenkawa> 3.18
<Tenkawa> it boots just fine... just no outut
<Tenkawa> er output
<Tenkawa> I can type/interact. I just want simple text without using nv-uboot
<javier__> Tenkawa: which 3.18? plain mainline?
<Tenkawa> yeah
<javier__> Tenkawa: snow, peach pit or pi? does your u-boot support simplefb?
<Tenkawa> snow
<Tenkawa> not really sure.. I had been using the 3.8.11 setup just fine
<javier__> Tenkawa: 3.18 without simplefb won't give you any output since doesn't have the needed patches nor the needed config changes in exynos_defconfig
<Tenkawa> I compiled simplefb in (its in the tree)
<javier__> Tenkawa: I meant, without simplefb in your nv-uboot
<Tenkawa> I think the kernel is fine.. I think its dts/dtb related
<Tenkawa> my screen blinks
<Tenkawa> javier__: I dont use nv-uboot
<Tenkawa> Is there "no" way not to
<Tenkawa> ?
<javier__> Tenkawa: then you won't have any display output since the RO firmware doesn't mangle the DTB to add the simplefb device node
<Tenkawa> well darn
<javier__> unless you use a kernel that already has proper DRM/KMS support for Snow
<sjoerd> javier__: did all the patches needd to light up on snow land in linux-next ?
<sjoerd> or is something still missing?
<Tenkawa> so close....
<javier__> sjoerd: Kukjin just picked the DTS patches from Ajay series yesterday so it doesn't show on the latest linux-next (not updated in a few days)
<javier__> sjoerd: also linux-next has some clock issues that sboyd, mike and tomeu are sorting it out now
<sjoerd> fun
<sjoerd> However, that does mean things should finally work with 3.20 out of the box
<javier__> sjoerd: yeah, or at the very least 3.21 since kukjin already sent his pull request for 3.20
<javier__> unless he has time to sent another pull request but I believe arm-soc only are wary to take patches close to the merge window
<javier__> s/only/
<Tenkawa> brb
Tenkawa has quit [Quit: leaving]
<sjoerd> javier__: I believe some tweaks did make it later
<sjoerd> last round at least
<javier__> sjoerd: indeed
Tenkawa has joined #linux-exynos
<Tenkawa> guess I'll try nv-uboot
<Tenkawa> here goes "something"
Tenkawa has quit [Quit: leaving]
liquidAcid has joined #linux-exynos
indy has quit [Ping timeout: 256 seconds]
rextc has quit [Ping timeout: 256 seconds]
rextc has joined #linux-exynos
indy has joined #linux-exynos
dlezcano has joined #linux-exynos
Tenkawa has joined #linux-exynos
<Tenkawa> javier__: what LOADADDR should I specify when I make uImage ?
<Tenkawa> for exynos5250-snow
<javier__> Tenkawa: 0x40008000
<Tenkawa> It did try to boot the kernel but it immediately panics
<Tenkawa> thanks
<Tenkawa> that darn env.txt is rather annoying with parsing
<Tenkawa> hehehe
<Tenkawa> gets way too easy to make one tiny hiccup and have it cascade
<Tenkawa> bbl... time to try the next compile
<Tenkawa> heheheh
Tenkawa has quit [Quit: leaving]
dlezcano has quit [Ping timeout: 255 seconds]
<prahal> dma burst size is variable size , is not it ? on Odroid U2 with pl330 dmac
aballier has quit [Quit: leaving]
Tenkawa has joined #linux-exynos
<Tenkawa> getting close
<Tenkawa> it errors on the fdt with 3.18.5
<Tenkawa> that may have been a typo on my part
<Tenkawa> brb
Tenkawa has quit [Client Quit]
<liquidAcid> prahal, you there?
<prahal> liquidAcid: indeed
<prahal> how are you ?
<liquidAcid> prahal, good, still a lot of work to do -- relieved that the semester is over and i can get some real work done now :)
<liquidAcid> prahal, anyway, i was wondering about this one here: https://github.com/tobiasjakobi/linux-odroid/commit/d2e4bb53c2baa481be492f1d79535060680b0904
<liquidAcid> why the OR in userptr | size ?
<prahal> I forgot . checking notes right now
<prahal> the comment hints that it was to check both start and size alignment , though a few more lines would not have hurt
<liquidAcid> it's probably something obvious, i'm just not seeing it, and i wanted to insert a short comment
<prahal> drivers/iommu/iommu.c has the same construct twice (and it turns as back then I tested the exynos iommu patchset .
<prahal> makes sense in that if we need only tests the lower bits , and size should not be introduce any of those lower ones to the userptr value : check of the lower bits of the OR of both is an optimzation. I felt it was more obvious back then.
prahal_ has joined #linux-exynos
prahal has quit [Ping timeout: 245 seconds]
afaerber has quit [Quit: Verlassend]