ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
<naobsd> mmind00: is hdmi working?
<mmind00> naobsd: it was working before, so I'd assume it still does
<naobsd> I still have no idea why it doesn't work on my firefly... I should try somewhat-stable
<naobsd> (I don't have so much time for now...)
<pulser> mmind00, very nice - I'll test out mmc speeds tomorrow. One very quick (and basic) question - what's the best way to apply the patches from the mailing list? I was finding git-am rejecting a bit more than I expected, but don't recall a fuzzy option on it - just wondered if there is a "better" way I'm forgetting
<mmind00> naobsd: there isn't any difference concerning hdmi between mainline and my somewhat-stable
cristian_c has quit [Quit: Bye]
<mmind00> pulser: I normally just pull in the maintainer-tree's next/whatever branch to get up to date
<mmind00> pulser: sometimes I also simply edit the patch ;-)
<pulser> Ah OK, that's a better way actually
<pulser> I was using pwclient
<pulser> Heh, I managed to pull Linus' 4.3 over somewhat-stable as a test and it worked nicely
<pulser> That was just me doing a quick test to ensure I could merge things cleanly and get a working output - will have a look at your branches in the morning
<naobsd> mmind00: I see, thanks...
<kapouer> is "ARMSOCPrepareAccess: Failed to map buffer" something expected when running X ?
<kapouer> (i'm trying to run gnome-shell, but it does the same with lightdm)
kapouer has quit [Quit: kapouer]
cnxsoft has joined #linux-rockchip
sunilmohan_w has joined #linux-rockchip
kapouer has joined #linux-rockchip
diego71 has quit [Ping timeout: 252 seconds]
diego71 has joined #linux-rockchip
lerc has quit [Read error: Connection reset by peer]
nighty^ has joined #linux-rockchip
cristian_c has joined #linux-rockchip
<mmind00> kapouer: I generally don't know how X works, but that doesn't sound healthy
<kapouer> i wonder if it's something that can be fixed in armsoc or a more general problem
<cristian_c> hello
<mmind00> kapouer: interesting ... seems broken here too [with all the edp tests and stuff, I hadn't X running for some time now]
<mmind00> kapouer: probably some change in the DRM/KMS? I'll take a look
<kapouer> (fbdev is working)
<cristian_c> how could I add a new resolution not listed in 'modes' file?
<cristian_c> Any ideas?
<naobsd> does anyone have working HDMI on firefly/rock2 with linux-next?
<rperier> mhhh... I did not test recently... last time I tried I had a freeze but it was on my chromebook...
<rperier> also, it will probably don't help :p
<rperier> (it was something like 1 month ago...)
<sjoerd> naobsd: wfm
<sjoerd> though i know at least one fix is needed to get weston to not hang, but the console comes up just fine here
<naobsd> sjoerd: can I see kernel config and dmesg?
<naobsd> I tried multi_v7_defconfig with
<naobsd> CONFIG_DRM_ROCKCHIP=y
<naobsd> CONFIG_ROCKCHIP_DW_HDMI=y
<naobsd> CONFIG_ROCKCHIP_PM_DOMAINS=y
<sjoerd> naobsd: kernel config, just multi_v7 with my patches
<sjoerd> did you enable the iommu as well?
<naobsd> CONFIG_ROCKCHIP_IOMMU=y etc are enabled w/o patch
<naobsd> I cannot see anything related to rockchipdrm/hdmi in dmesg...
<sjoerd> [ 13.411193] rockchip-drm display-subsystem: bound ff980000.hdmi (ops dw_hdmi_rockchip_ops [dw_hdmi_rockchip])
<sjoerd> you'd need that at least
<sjoerd> curious i don't see it either in the kernelci logs ofr next
* sjoerd makes a note to check what landed in next thusfar
cristian_c has quit [Quit: Bye]
<sjoerd> Iirc my config patches were merged into the armsoc config branch
<naobsd> I'll check armsoc...
<sjoerd> i haven't tested with recent next or looked what was merged into 4.4 for rc1 just yet
<naobsd> sjoerd: https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/log/arch/arm/configs/multi_v7_defconfig?h=for-next patches committed around 2015-10-06 is already merged in linux-next too
<naobsd> sjoerd: which linux-next version are you using?
<naobsd> and which board/dts?
<naobsd> arm-soc?
<sjoerd> naobsd: rock2, https://git.collabora.com/cgit/user/sjoerd/linux.git/log/?h=combined/radxa-rock2 is my wip branch which is my current working branch
<sjoerd> i know hdmi works in that one at least ;)
<sjoerd> but i didn't htink there is anything in it wrt. hdmi that's not in next yet
cristian_c has joined #linux-rockchip
<mmind00> yep, that is what is puzzling me ... hdmi on the firefly is working since january (commit-date)
<pulser> kapouer: same issue here on booting the veyron-minnine in lightdm
<pulser> sorry, slightly different message: "Driver failed PrepareAccess on a pinned pixmap"
<pulser> and I get the failed to map buffer in X's log too
<kapouer> pulser: i'm seeing that message as well
<kapouer> so we can safely say it's the same error
<pulser> yes - am going back through the changes
<pulser> unfortunately I don't see any good errors in dmesg to chase down
<pulser> kapouer: one option is to bisect, and work back until it breaks, then narrow down the commit causing the issue
<kapouer> i can help with that, but i have yet to find a place where it works
<pulser> oh OK, you have not had display working yet?
<pulser> (even before mmind updated the branch last night?)
<kapouer> not with armsoc
<pulser> and you had tried a compiled kernel before last night?
<pulser> that is strange - it was working here on veyron-minnie fine
<kapouer> yes, but i had another issue with armsoc
<kapouer> i had to install xserver-xorg-legacy i think
<kapouer> then i didn't roll back to check with previous version
<pulser> OK right
<kapouer> xorg in debian is becoming less straightforward to launch ;)
<pulser> if you want to try the build I had working, build from commit 6509232 on branch somewhat-stable
<pulser> that should work fine (yay for git reflog)
<mmind00> yeah, it looks like some recent change to the drm/kms code introduced this ... there are no real rockchip-specific changes, so it seems to come from some more core part
<pulser> yeah - that would make sense - I had a look at rk related stuff and drew a blank
<pulser> if I was better at git-fu, I would try to filter it to retain only your rk changes on top of 4.3.0, but I know that's too naive on a project the size of the kernel!
<mmind00> as far as I got right now, the mmap of the drm-gem object in the xserver fails with ENXIO after the dumb-mapping itself
<pulser> OK, you got further than me in diagnosing this then :) I couldn't find any meaningful errors, but I didn't have time to try to trace deeper yet
<mmind00> I've just traced what armsoc does first ... with a big load of debug output :-)
<pulser> ah OK :) so you got further than me then, as I was still reading X logs
<mmind00> the issue might also come from the iommu, as this is involved in graphics-mem allocation ... all fields I haven't had much contact with yet [still looks like voodoo]
<pulser> 3d57b42 drm/vgem: Drop vgem_drm_gem_mmap
<pulser> that might be relevant (going by name)
cristian_c has quit [Quit: Bye]
<pulser> and similarly, https://github.com/mmind/linux-rockchip/commit/4e270f0 is changing the rockchip drm gem code by removing some stuff
<mmind00> I did try reverting that last commit ... no change
<mmind00> and we don't even build the vgem stuff ... which is for virtualized stuff if I remember correctly
<pulser> hmm right - the titles just jumped out at me :)
<pulser> https://github.com/mmind/linux-rockchip/commit/2225cfe is also interesting potentially, as it's touching the drm memory mapping (I think)
<pulser> another 2 ARM specific ones (no more, I promise!) - https://github.com/mmind/linux-rockchip/commit/371f0f0 and https://github.com/mmind/linux-rockchip/commit/7e31210 are looking at IOMMU stuff
<mmind00> that -ENXIO in 371f0f0 looks actually very intersting :-)
<pulser> yeah :)
<pulser> I am going for lunch now, or I'd have tried a build with a revert
steev_ has quit [Read error: Connection reset by peer]
nighty^_ has joined #linux-rockchip
AstralixNB has joined #linux-rockchip
<kapouer> i tried a build with 371f0f0 reverted - getting same result
cnxsoft has quit [Remote host closed the connection]
<pulser> mmind00: I can confirm that reverting https://github.com/mmind/linux-rockchip/commit/371f0f0 and https://github.com/mmind/linux-rockchip/commit/7e31210 works for me, and gives me X back
<pulser> gles2 is broken, but I need to now undo the other reverts I was trying, so I will update in a couple of minutes
<pulser> OK, es2gears remains "broken" - no display output
<pulser> A few new errors now in dmesg; one is "mali ffa30000.gpu: Reset interrupt didn't reach CPU. Check interrupt assignments." and the other is "mali ffa30000.gpu: AS_ACTIVE bit stuck"
<pulser> that error seems related to https://github.com/mmind/linux-rockchip/blob/devel/somewhat-stable/drivers/gpu/arm/midgard/backend/gpu/mali_kbase_mmu_hw_direct.c#L68, indicating we're waiting on the MMU to indicate no active command, but that's never getting reached
<pulser> there also seems to be a board-specific (?) regression, namely that battery status is no longer being reported correctly
<mmind00> pulser: nice find, now it's only to find what we need to fix ... the mali stuff _could_ be related to the new power-domains, but I'd think that the code I got from ChromeOS _should've_ set this up
<pulser> yep - I suspect you will know a lot more than me about this stuff - I only have passing familiarity with this stuff
<pulser> it COULD be powerdomains - if I get time I may try to revert... the battery status suggests there has been more changed than we realise :)
<pulser> mmind00: am I right in saying that the powerdomains changes may allow the device to sleep "deeper" (now you brought that from chromeos?)
<mmind00> pulser: nope ... the power-domains allow turning off stuff at runtime (like the gpu, video-encoder and some more) when it's not used
<mmind00> pulser: that is work of Caesar from Rockchip ... what I brought over from Chromeos is the mali kernel part ... but as Chromeos has power-domain support for a lot longer, I suppose it should handle them correctly already
<pulser> interesting - I felt (based purely on instinct/gut feel) that the non-chrome kernel drained more power in sleep, but perhaps that was "imagined"?
<pulser> yeah - that would be a reasonable assumption - I didn't see anything obvious in dmesg, but for power domains I guess it might just be sitting there "off"
<mmind00> again nope ... mainline is missing the actual deeper sleep ... so it will drain more
<pulser> that explains it, thanks :)
<pulser> (I am not familiar with sleep on Linux really)
<pulser> I had assumed you'd use power domains to shut things off, then sleep (I am more familiar with MCUs where you set registers to flag what can sleep and what can't)
<sjoerd> power domains can be used to shut of sections of the SoC
cosm has joined #linux-rockchip
<pulser> sounds similar to the sleep registers on an MCU then :)
<mmind00> I guess the newly added offset support to the dma-mapping area, might conflict with the "fake-offsets" drm/kms uses? [http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_gem.c#L424] ... but it would make me wonder if we were the only ones affected
<pulser> yeah - the fake offsets were the thing that initially made me wonder
<pulser> but as you said, surely that would affect a lot of other people?
<pulser> I'm not familiar with how heavily tested the master branch gets mid-merge cycle?
<mmind00> pulser: exynos_drm_gem.c line 318 :-)
<pulser> vma->vm_pgoff = 0;
<pulser> hmm, not sure if I'm missing something here - that's pretty old code... I guess it's something we are missing?
<mmind00> yep ... the mmap in rockchip only has the setting in the line above
<mmind00> the pgoff thingy is that offset setting
<pulser> yeah
<mmind00> and I also have X again :-D
<pulser> nice :)
<pulser> ah yes, you only have the "vma->vm_flags &= ~VM_PFNMAP;" in the RK drm
<pulser> so I guess you would add:
<pulser> vma->vm_pgoff = 0;
<pulser> vm_size = vma->vm_end - vma->vm_start;
<pulser> * check if user-requested size is valid. */
<pulser> if (vm_size > rk_obj->size)
<pulser> return -EINVAL;
<mmind00> not in one patch :-)
nighty^ has quit [Ping timeout: 246 seconds]
<pulser> heh indeed, but I am guessing the fix is along those lines?
<pulser> (I assume the "right" way to do it is to replicate the patches that exynos used, to get to that point)
nighty^ has joined #linux-rockchip
<pulser> looks like it might be a little more complex than that - https://github.com/mmind/linux-rockchip/commit/48cf53f4343ae12ddc1c60dbe116161ecf7a2885
<mmind00> pulser: yep, I had found that one too ... and adapted it to the Rockchip drm
<mmind00> the nice part is, that the structure between exynos and rockchip are quite similar in those areas :-)
<pulser> OK great - I will look into this again in the evening I guess, since you have a much better idea than I do :)
<pulser> even better!
<mmind00> pulser: the size-check is already done in http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_gem.c#L818
<mmind00> which gets called before the actual mapping
<pulser> ah right
nighty^ has quit [Ping timeout: 250 seconds]
AstralixNB has left #linux-rockchip [#linux-rockchip]
nighty^ has joined #linux-rockchip
markm has quit [Ping timeout: 252 seconds]
jas-hacks has joined #linux-rockchip
nighty^ has quit [Ping timeout: 240 seconds]
gb_master has joined #linux-rockchip
nighty^ has joined #linux-rockchip
<rperier> I have just discovered openhub... seriously.... it rocks :D
<rperier> It finds all your contributions... since the beginning ... everything! I have even forgot some of my contributions on some projects o_O
gb_master has quit [Remote host closed the connection]
markm has joined #linux-rockchip
nighty^ has quit [Ping timeout: 260 seconds]
Xeta has joined #linux-rockchip
<Xeta> Hi! Anyone here have experience installing a linux distribution on MK 902 II?
nighty^ has joined #linux-rockchip
maz has quit [Quit: Leaving]
cosm has left #linux-rockchip ["Leaving"]
<mmind00> btw. I've updated the branch and posted the drm patches
<pulser> mmind00: tested your 2 commits and they are working fine - giving X, without egl (same error as I was getting by reverting) - going to have a look at those errors now
<mmind00> pulser: I already forgot that there was also a mali problem :-) ... going to look at that too now
<pulser> heh no worries - your fix is much nicer than my random reverting!
<pulser> my initial findings were:
<pulser> <pulser> A few new errors now in dmesg; one is "mali ffa30000.gpu: Reset interrupt didn't reach CPU. Check interrupt assignments." and the other is "mali ffa30000.gpu: AS_ACTIVE bit stuck"
<pulser> <pulser> that error seems related to https://github.com/mmind/linux-rockchip/blob/devel/somewhat-stable/drivers/gpu/arm/midgard/backend/gpu/mali_kbase_mmu_hw_direct.c#L68, indicating we're waiting on the MMU to indicate no active command, but that's never getting reached
<pulser> mmind00: another one I am chasing down, is that there is no battery status showing (no BAT0/BAT1 in /sys/class/power_supply/) - I reverted the config line change making battery a module, but to no avail
edolnx has joined #linux-rockchip
<mmind00> pulser: hmm, on regular chromebooks I think the sbs battery is the correct one ... except for minnie
<pulser> OK interesting - let me investigate then
<pulser> I insmod'd it, and it hasn't appeared
nighty^ has quit [Ping timeout: 240 seconds]
jas-hacks has left #linux-rockchip [#linux-rockchip]
<mmind00> pulser: ok, it looks like we lost the sbs battery ... let's see where it ended up
<pulser> yeah - I'm grepping
<pulser> didn't see anything obvious in configs
<pulser> CONFIG_BATTERY_SBS=m is still set
nighty^ has joined #linux-rockchip
lerc has joined #linux-rockchip
Xeta has quit [Ping timeout: 246 seconds]
<pulser> mmind00: nothing grep -ri sbs_battery isn't finding anything that's changed
<mmind00> yep, that's puzzlinge me as well
<pulser> don't see anything in arch/arm related to {sS}{bB}{sS} that's changed
<mmind00> that's more a matter of mfd/cros_ec/... I think ... I don't think it has gone far ... it may very well just be us missing a merge [we are in the middle of the merge-window after all]
<pulser> ah yes
<pulser> cros_ec_i2c.c and cros_ec_spi.c appear to be recently changed - having a look trhough
<pulser> nothing major though
<edolnx> Greetings Everyone, I got a RK3386 based Uppel CX-R8 and I'm starting hacking on it. Good news: looks like it's got a userdebug boot loader on it, and UART pins exposed on the board. Bodes well for getting Debian amd64 installed at some point :D Any hints at SD bootloader would be appreciated!
Sadneophyte has joined #linux-rockchip
<edolnx> sorry, it's an RK3368 not at RK3386
Sadneophyte has quit [Quit: Leaving]
<mmind00> edolnx: on the rk3368 uart2 and the sd-controller share pins ... so you will either need to use a different uart, or some other boot-medium
lerc has quit [Remote host closed the connection]
lerc has joined #linux-rockchip
<naobsd> if CX-R8 is Hotack HTC-T052-V* which should be same board as MK68, there should be 4 holes. I guess it's UART2... i.e. only UART2 is available(easily accessible)
<naobsd> (I don't have it, not sure)
markm has quit [Ping timeout: 240 seconds]
<edolnx> mmind00, Yep, saw that in my research. I've got USB ports I can boot off of. Should be interesting. Just hoping I can get into uboot on the UART ports as it looks like there are at least two from the kernel messages in Android :D
<edolnx> I'm going to post some photos of the boards in a moment...
markm has joined #linux-rockchip
<edolnx> I'll try and get a better quailty picture later. It's not the greatest. I'm putting some headers on the UART pins so I can attach my FTDI cable and see the sights
gb_master has joined #linux-rockchip
<naobsd> hm, it's different to Hotack T052
<edolnx> and sadly all the traces for the SD card and the GPIO pins are on middle layers of the board so I can't follow them :(
<naobsd> but physical port locations are almost same, probably same external case can be used... so I cannot identify these 2 by looking port locations from outside ;)
<edolnx> The USB port next to the SD card _may_ be switchable between OTG and Host, since it's the only one directly wired to the SOC. The rest go through that USB HUB
<edolnx> naobsd, I have a couple of Rikomagic RKM MK68 boxes on the way as well, it will be interesting to see how they differ also.
<naobsd> RK u-boot for rk3368 should support boot(load kernel etc) from USB storage too, but I never tried yet
<naobsd> at least you should be able to use eMMC with UART2 console
<naobsd> SD will not work when UART2 wires are connected but it may work just pulling wires w/o reboot/reflash/etc
<naobsd> so you can try boot from SD then connect wires to UART2 after boot
<naobsd> well, boot from SD, pull SD, then connect UART2
<edolnx> I haven't had a chance to put together a SD card to boot from yet. It looks...complicated from the wiki :D
<naobsd> I'll put script with files to make bootable SD for RK3368
<edolnx> naobsd, Thanks! I've got access to Windows and Linux boxen to run that from, whichever is easier for you. I'm also planning on documenting a lot of what I'm doing and putting it on the wiki and my blog as I go
nighty^ has quit [Quit: Disappears in a puff of smoke]
<edolnx> This isn't my first rodeo hacking on strange hardware, but this is my first adventure into Rockchip ARM stuff :)
<naobsd> mkimage will be handy tool to make bootable SD for RK
<naobsd> but rk3036 support need to be merged to generate right header ;)
<naobsd> (mkimage in mainline u-boot)
naobsd has quit [Remote host closed the connection]
gb_master has quit [Quit: Leaving]
<edolnx> I assume that the default baud rate on these UART ports is 9600?
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-rockchip
<edolnx> Got a bunch of photos, screen grabs, and the dmesg from the stock Android install for reference here: http://edolnx-public.objects.dreamhost.com/CX-R8/index.html
<edolnx> OK, well, I found the serial port
<edolnx> well, the pinout I should say. Finding the port itself was easy :D
<edolnx> It's running at 115.2kbps