TheSeven has quit [Disconnected by services]
[7] has joined #linux-exynos
isaque has quit [Quit: isaque]
bgamari has quit [Ping timeout: 265 seconds]
bgamari has joined #linux-exynos
bgamari has quit [Max SendQ exceeded]
bgamari has joined #linux-exynos
amitk has joined #linux-exynos
masta has quit [Ping timeout: 250 seconds]
krzk has joined #linux-exynos
isaque has joined #linux-exynos
paulk-leonov has joined #linux-exynos
paulk-leonov has quit [Remote host closed the connection]
paulk-leonov has joined #linux-exynos
prahal has joined #linux-exynos
paulk-leonov has quit [Ping timeout: 250 seconds]
nashpa has quit [Quit: Going away]
nashpa has joined #linux-exynos
masta has joined #linux-exynos
prahal has quit [Ping timeout: 260 seconds]
prahal has joined #linux-exynos
afaerber has quit [Quit: Ex-Chat]
afaerber has joined #linux-exynos
afaerber has quit [Ping timeout: 250 seconds]
masta has quit [Ping timeout: 260 seconds]
paulk-leonov has joined #linux-exynos
Vasco_O is now known as Vasco
afaerber has joined #linux-exynos
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
masta has joined #linux-exynos
gordan has joined #linux-exynos
isaque has quit [Remote host closed the connection]
isaque has joined #linux-exynos
gordan has left #linux-exynos ["Konversation terminated!"]
wwilly has joined #linux-exynos
masta has quit [Ping timeout: 250 seconds]
paulk-leonov has quit [Ping timeout: 240 seconds]
krzk_ has joined #linux-exynos
masta has joined #linux-exynos
paulk-collins has joined #linux-exynos
prahal has quit [Remote host closed the connection]
prahal has joined #linux-exynos
prahal has quit [Quit: prahal]
<wwilly> hi, when you cross compile, all the tools and script producing an ELF binary are compiled for the target, or for the source?
<wwilly> I cross compile my kernel for arm, but I get an error "-bash: ./dtc: cannot execute binary file: Exec format error" when I launch it one the board
<krzk_> wwilly: scripts not, they stay at host format
<wwilly> I cross compile from a x86_64 computer
<krzk_> so your dtc is for host
<wwilly> uhm ok
<krzk_> wwilly: tools... I don't remember, they are not compiled by default
<wwilly> I want to add pmc counter for the 5422, they are not present for now
<wwilly> or I do mistake?
<krzk_> PMC? eh? You mean performance management counter?
<wwilly> yes
<wwilly> monitor
<wwilly> to use by perf tools
<krzk_> I got it. For dtc - what does the 'file' say?
<wwilly> nothing for now, I need to recompile the tool
<krzk_> eh? There is no need...
<wwilly> I suppose I should compile one the board to overload>
<krzk_> dtc is in many linux distros
<wwilly> ?
<wwilly> ah yeah ok
<krzk_> And usually you run DTC on the host, when building kernel (make; make dtbs; etc)
<krzk_> it is uncommon to launch it on the board itself
<wwilly> uhm ok
<wwilly> I want to know, for having a good setup to trick the kernel
<wwilly> when you change a dts, you test your thing on the board?
<krzk_> wwilly: Yes. Whenever I change kernel or dts I build everything (on the host) and deliver it to the board. When changing DTS you don't have to rebuild the kernel (unless DTB is appended to the kernel but it is not so common).
<wwilly> if I understand well, device tree is the way to describe a hardware, instead of change a small thing and booting your new kernel on the target hardware, you can overload the description in live
<krzk_> wwilly: no, not entirely. You could do this with overlays for DTS, but not with new DTS
<krzk_> and actually this is for adding new stuff (like shields on Arduino) not for replacing existing DTB/DTS.
<krzk_> The drivers already probed from existing DTB so replacing it won't affect anything (you would have to unbind/rebind)... that is quite unusual approach :)
<krzk_> so in general: you have to reboot :)
<wwilly> uhm ok
<wwilly> is not what I've understand from "overloading"
<wwilly> what I've understand is that you can change any entry of a dtb/dts in live, so you can change something, add new stuff or something
<krzk_> Probably the overloading here (I don't know where you got it) means to overload some DT nodes from some source by another source... like inheritance/overload in C++. But then you compile everything
<wwilly> like PMC in my case
<krzk_> and flat structure is produced
<wwilly> uhm ok
<krzk_> in your case you should get the sources (kernel+DTS are in the same place), change them and build new thing
<wwilly> also I don't read it as a book, I simply read too much in diagonal for now
<wwilly> and then reboot with new kernel
<wwilly> ?
<wwilly> pfiou quite long to tweak this small thing :/
<krzk_> Yes. Usually new kernel and new DTB... but the kernel does not have to be new. But you still have to restart system so it will boot from new DTB.
<wwilly> I see something about kexec, I never tried it, nor read a documentation properly, you can't use that to change a kernel in live, with its DTB?
<krzk_> if you have everything ready (like sources of existing kernel) this is small thing: just change DTS, make dtbs, upload new dtb to device, reboot
<wwilly> yeah I have everything on the board now, just want to add PMC, an odroidxu3 with exynos5422 (a7 and a15)
<wwilly> I try to add this one from Hardkernel, http://odroid.com/dokuwiki/doku.php?id=en:odroid_linux_performance_counter
<krzk_> Oh, that would be interesting. In some aspects it might work... but in other aspects it probably won't. Kernel drivers expect to initialize the hardware... but the hardware was initialized but existing (already running) kernel...
<wwilly> and it don't work correctly, one of the cluster don't boot
<wwilly> by regarding the patch from the website, http://odroid.com/dokuwiki/doku.php?id=en:odroid_linux_performance_counter
<wwilly> you can guess if is correct at the first look?
<wwilly> * if you correct ompatible with compatible
<krzk_> At first look it seems okay... but I don't know these DT bindings.They prepared the patch for their kernel which is 3.10 I guess
<krzk_> on mainline this might be different
<wwilly> uhm ok
<krzk_> what kernel are you running?
<wwilly> why this is not booting properly
<krzk_> does it boot without your changes?
<javier__> wwilly: that page says that perf counters for the A7 cores is supported but no for the A15
<javier__> (I wonder if that's true for mainline)
<javier__> wwilly: also, you probably should disable the b.L switcher
<krzk_> so you are running mainline kernel... the DT patch from odroid might be completely bogus. You would have to check in kernel sources.
<wwilly> and it's working correctly, after few test, 8 cores, and I add myself mali gpu with the tizen source you point me krzk_
<wwilly> javier__, yep, b.L switcher disabled
<wwilly> ok, I guess I couldn't stole like that pmu things from other board?
<javier__> wwilly: what krzk_ said, DTS snippets from hardkernel may not be aplicable to mainline, you should double check if those are correct
<wwilly> I'm newbie about that, so, I kind of test by brute force... naively... stupidly I could say?
<wwilly> just at the first search, maybe I completely don't understand the thing
<javier__> wwilly: the interrupts used are SoC specific
<javier__> so you can't just take the node from another board
<wwilly> ok, it will not be funny without that :)
<wwilly> and in which sense it is buggy the patch from hardkernel?
LiquidAcid has joined #linux-exynos
<javier__> wwilly: there is a contract/interface between the kernel and the DTS, those are known as DT bindings and are documented in Documentation/devicetree/bindings/
<javier__> that's an ABI so new kernels should always work with an old DTB
<javier__> wwilly: but a vendor is free to change that interface at will so you can't trust that a downstream DTS will work with a mainline kernel
<javier__> wwilly: I also wonder if perf counters will work in b.L systems at all
<javier__> since the problem is not only related to the switcher, nothing prevents a process to migrate from between big and LITTLE cores
<wwilly> it is the scheduler who decide that, and we can force the id core to run on
<javier__> wwilly: yes, you can use for example sched_setaffinity() from user-space to define that policy but I mean in general
<wwilly> yes ok
<javier__> I remember that was an issue in the past at least but I don't know if that was fixed in the meantime
<javier__> wwilly: not wanting to discourage you but just pointing out some possible issues ;)
<wwilly> ok
<wwilly> I suppose at the begnning I can just take this patch, or with only small change
<wwilly> because I just want this pmc for my project
<ndufresne> javier__: btw, I'm quite near to my goal now, but I'm hitting this crash, I wanted to know if that felt familiar, https://paste.fedoraproject.org/366299/22188146/
<wwilly> but the interrupts used are SoC specific you said, so it will not change regarding the kernel version
<ndufresne> javier__: I've just rebase on final 4.6 now (I was at rc5 iirc), so it might be an rc regression, but otherwise this could easily be a bug on v4l side
<ndufresne> I mean still have to test final 4.6
<ndufresne> javier__: I think I'll check what params we pass to the map functions too
<javier__> ndufresne: that error doesn't ring a bell to me, better to ask in #v4l
<ndufresne> ok
<javier__> wwilly: yes, it won't change but it can change how you address the interrupts
<javier__> for example, if <0 192 4> really maps to the HW interrupt you want since the GIC DT binding can be different in hardkernel and mainline
<javier__> I haven't checked, just mentioning why you can't blindly trust a downstream DTS
<javier__> wwilly: the A15 IRQs seems to be correct, the A7 no AFAICT should be:
<javier__> interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>, <0 161 IRQ_TYPE_LEVEL_HIGH>, <0 192 IRQ_TYPE_LEVEL_HIGH>, <0 193 IRQ_TYPE_LEVEL_HIGH>;
<javier__> ups, sorry I meant:
<javier__> interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>, <0 161 IRQ_TYPE_LEVEL_HIGH>, <0 162 IRQ_TYPE_LEVEL_HIGH>, <0 163 IRQ_TYPE_LEVEL_HIGH>;
<javier__> wwilly: but if you look at your 2 examples, you can see that the the .dtsi only has A7's core
<javier__> IOW, those are not b.L systems
<wwilly> ok, <javier__> IOW, those are not b.L systems; you mean that I should disable b.L systems? this is ok
<javier__> wwilly: no, I meant that the examples you have shown are for SoC whose cores are all the same
<LiquidAcid> ndufresne, i see you're making progress :)
<javier__> wwilly: you can't disable b.L (unless you remove the A15 or A7 cpu nodes from the DT), what you can enable or disable is the b.L switcher that groups different cores as a virtual CPU
<wwilly> this patch is intended to work under the 3.10 with HMP scheduler support, and this scheduler don't use b.L switcher if I understand well
<javier__> wwilly: my point is that you should check if perf counters are expected to work on b.L systems at all or not before attempting to enable in your board
<javier__> the patch is for the hardkernel 3.10 branch, but I don't know what they could have on top of mainline 3.10
<wwilly> :(
<wwilly> quite depressive...
<wwilly> where do you find this information? interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>, <0 161 IRQ_TYPE_LEVEL_HIGH>, <0 162 IRQ_TYPE_LEVEL_HIGH>, <0 163 IRQ_TYPE_LEVEL_HIGH>;
<javier__> wwilly: I checked in the documentation I've access to
<wwilly> and I could have access to or is it private?
<ndufresne> LiquidAcid: yes, I'm re-implemented everything using the modifiers now, implement support for that in exynos_drm and lifted the restrictions in the core drm code
<ndufresne> works if I allocate dummy buffer, but crashes when I pass dmabufs
<javier__> wwilly: sorry, is not public
<wwilly> ... ok
<ndufresne> LiquidAcid: the crash seems unrelated to my code though
<LiquidAcid> ndufresne, you mean when you import dmabufs in the drm?
<ndufresne> That makes me think, I can use vivid to check that
<wwilly> so is like I'm kind of fucked up to have PMC working for this board?
<ndufresne> LiquidAcid: yes, then the exynos_drm maps the dmabuf, it crash, the backtrace only contains core code, so it's hard to figure-out what is wrong
<wwilly> or just waiting for you to implement it for me?
<LiquidAcid> ndufresne, and does it work the other way round? creating a buffer with the drm, exporting and importing it into v4l?
<ndufresne> the HW decoder does not support the importer role
<LiquidAcid> hmm, wasn't there a patch for this somewhere?
<javier__> wwilly: I don't know if is possible currently in mainline or not, that's why I told you to check the state of PMU for b.L
<ndufresne> and it's not implemented by the gstreamer kmssink atm
<javier__> wwilly: I've in my TODO to look at this but honestly I don't think I'll have time in the short term
<javier__> wwilly: sorry, too busy with other stuff
<LiquidAcid> ndufresne, i was thinking of that one, not sure if it does what i think it does
<wwilly> :'(
<ndufresne> LiquidAcid: that will make it worst, since with iommu, the 4412 does not even boot
<LiquidAcid> ndufresne, hmm strange, my 4412 boots fine with iommu
<ndufresne> actually, the patch properly compile it out without iommu
<ndufresne> LiquidAcid: with 4.6 ?
<LiquidAcid> ndufresne, haven't checked 4.6 yet, but it does with 4.5
<ndufresne> it remains that it should work without that
<LiquidAcid> ndufresne, so you getting a iommu pagefault early?
<ndufresne> no, iommu isn't used, the memory is from a reserved cma region
<LiquidAcid> ndufresne, sure, but i suspect that nobody ever tested that you can import a "foreign" dmabuf into the drm
<ndufresne> that's why a page fault is strange
<LiquidAcid> ndufresne, and it's not the fimd/bootloader issue?
<ndufresne> LiquidAcid: I'm sure daniels tested that on older kernels
afaerber has quit [Quit: Ex-Chat]
<ndufresne> since on Wayland you can only do that
<ndufresne> and with GL it is the same, though that goes through the mali driver
<ndufresne> LiquidAcid: how would that be related ? (fimd/bootloader)
<LiquidAcid> ndufresne, i don't thin dmabuf importing works for the mali in the 4412
<LiquidAcid> *think
<ndufresne> it does now
<LiquidAcid> which driver version is that?
<daniels> ndufresne: never on a 4412 ... :\
<ndufresne> daniels: but it could, I don't think it was related to the 4412 as much as the broken driver
<LiquidAcid> daniels, yeah, never on utgard i think
<LiquidAcid> ndufresne, iirc it was first implemented for mitgard
<ndufresne> anyway, it's implemented, we should fix it then
<daniels> ndufresne: i also haven't tried exynos at all in months tbh - the driver has had a lot of changes since then, and i got tired of fixing the constant breakage
<ndufresne> It's a CMA buffer that is being passed, it's the simpliest thing that can be imported
<LiquidAcid> ndufresne, the kernel driver however can in principle import dmabufs, but the userspace blob doesn't export the functionality through its GL impl
* ndufresne is a bit frustrated to ear that, since so much energy was put to encourage us to focus on sending dmabuf to GFX and not doing the opposite
<LiquidAcid> ndufresne, in fact i've spend some time on patching the r5p0 fbdev blob provided by hardkernel to allow dmabuf importing via userspace
<LiquidAcid> ndufresne, https://github.com/tobiasjakobi/mali-fbdev-ioctl, it's just a bunch of hacks though
<ndufresne> yeah, remains the mali stuff isn't my goal right now, I want to render to the display using the VideoProcessor, and next the GScale
<ndufresne> and that over mainline kernel
<ndufresne> and then I'll set that up into our CI system, so I can detect mainline regressions
<LiquidAcid> ndufresne, does GScale also output directly to display?
<LiquidAcid> ndufresne, i thought it's similar to the FIMC on the 4412
<ndufresne> according to the spec, it can stream YUV444 to the display
<ndufresne> just like the VideoProcesor did
<LiquidAcid> is yuv444 = nv12?
<LiquidAcid> (i never can memorize these formats...)
<ndufresne> the signal between IP blocks in Exynos is in YUV444
<LiquidAcid> but the VP only does NV12/NV21 and its tiled variants
<LiquidAcid> or are i missing something here?
<ndufresne> VP at least input NV12/NV21 and NV12_64Z32/NV21_64Z32
<ndufresne> and will output YCbCr 444 to the display
<ndufresne> it's hardwired to the display, you cannot detach that
<LiquidAcid> yes, but the list of input formats is complete
<ndufresne> see s5p-tv for everthing it supports
<ndufresne> LiquidAcid: what do you mean by "is complete"
<LiquidAcid> ndufresne, i mean that these four formats you listed are the only ones supported
<LiquidAcid> *supported by the VP
<ndufresne> I confirm, well it supports one form of interelaced data too, it's just a flag like the tiling mode
<ndufresne> so you could say 6 formats, but all from the NV12 and NV21 family
<LiquidAcid> yes, and for everything else you need FIMC
<LiquidAcid> everything non-video at least
<ndufresne> and the spec says "it produces YCbCr 4:4:4 to help to blend video and graphics"
<ndufresne> LiquidAcid: that is exact
<LiquidAcid> yeah, but you can't have to scanout from a buffer with that format
<ndufresne> with what format ?
<LiquidAcid> if you have a buffer with pixel format YCbCr 4:4:4, then you can't scanout from this buffer with either mixer or VP
amitk has quit [Quit: leaving]
<ndufresne> no you can't
<LiquidAcid> <ndufresne> according to the spec, it can stream YUV444 to the display
<LiquidAcid> <ndufresne> just like the VideoProcesor did
<ndufresne> that's where the design sucks
<ndufresne> since you can't hook an FIMC to scanout on the videomixer video plane
<LiquidAcid> that was my point, because the VP can't stream that format to display
<ndufresne> LiquidAcid: streaming to the display is what you describe as sanning out
<LiquidAcid> yes, but the VP is unable to do so
<LiquidAcid> i was just wondering if the GScaler is better in this regard
<ndufresne> the GScale is better because it can be used without the display
<LiquidAcid> so it does m2m?
<LiquidAcid> but it can also directly output to a mixer plane?
<ndufresne> and then you can hook other IP blocks directly tot he display/VideoMixer
<ndufresne> I should always say VideoMixer here, sorry for the confusion
<ndufresne> LiquidAcid: yes, GScale has a memory interface on both side
<ndufresne> it's implemented by the v4l2 driver atm
<LiquidAcid> sounds like a more flexible version of the FIMC
<ndufresne> the FIMC also works in m2m, but has less features
<ndufresne> and because the VP is hardwired, you cannot connect it directly to the VideoMixer
<ndufresne> so in 4412, you have to do something like, camif -> fimc -> mem/NV12 -> VP -> VideoMixer -> FIMD
<LiquidAcid> yeah, it's more like VP and mixer are one single block
<ndufresne> which means the CPU need to work
<ndufresne> on Exynos 5+, you can do camif -> GSacle -> VideoMixer...
<ndufresne> now, this is the theory, the problem is that this is cross-domain in the linux kernel
<ndufresne> and so far, we have copy pasted drivers from v4l2 to drm, and a mutual exclusion
<ndufresne> I think pinchartl idea was to move everything to drm, and expose V4L2 frontend to some of it
<ndufresne> or create some intermediate objects, but those would fall into the no-mans land
<LiquidAcid> so what is left in v4l2 that is not in drm?
<LiquidAcid> isn't that just the mfc?
<ndufresne> camif, mfc
<ndufresne> and on drm side it's often incomplete, and it expose custom ioctl
<ndufresne> usually, I use FIMC from v4l2, it's much better
<LiquidAcid> yeah, marek was trying to clean up the ipp system
<LiquidAcid> but i don't think his approach was good, it was doing to much automagic behind the scenes
<LiquidAcid> but i think there was some interest from rockchip (?) developers to have some common infrastructure for this
<ndufresne> I think the v4l2 infrastructure is better suited
<ndufresne> see the VP stuff in Renesas
<ndufresne> what we're missing is the API to connect a v4l2 node to the display, for that we just need a v4l2-subdev frontend on drm
<ndufresne> and then it can be wired up using Media Controller
<ndufresne> (which was I believe what Laurent Pinchart presented at Plumbers in Seattle)
<ndufresne> in the end, the IPP API in exynos drm is pretty much a subset of the v4l2 one
<LiquidAcid> i've never worked with v4l2, so no idea there -- ipp is pretty much broken anyway, and the terminology is "odd"
<ndufresne> goot talk by the way, there is a clear spot here that need to be thinked through
<ndufresne> let's get back to reality meanwhile, let's see if I can find some detail about this crahs
<LiquidAcid> good luck with that
krzk_ has quit [Quit: leaving]
<ndufresne> and that's probably what I need
<ndufresne> at least I know it can worked, as it worked before with s5p-tv
LiquidAcid has quit [Quit: Leaving]
wwilly has quit [Quit: Leaving]
afaerber has joined #linux-exynos
masta has quit [Ping timeout: 260 seconds]
masta has joined #linux-exynos
masta has quit [Ping timeout: 276 seconds]
paulk-collins has quit [Quit: Leaving]
<ndufresne> still broken on 4.6 final
<ndufresne> but fimc works now
prahal has joined #linux-exynos
Vasco is now known as Vasco_O
wwilly has joined #linux-exynos
wwilly has quit [Quit: Leaving]