ansiwon has quit [Read error: Connection reset by peer]
ansiwon has joined #linux-exynos
ansiwon has quit [Read error: Connection reset by peer]
ansiwon has joined #linux-exynos
ansiwon has quit [Read error: Connection reset by peer]
dlezcano has quit [Remote host closed the connection]
ansiwon has joined #linux-exynos
ansiwon has quit [Read error: Connection reset by peer]
ansiwon has joined #linux-exynos
dlezcano has joined #linux-exynos
wwilly has joined #linux-exynos
<krzk_>
wwilly, hey, you mean cldemo works only as root?
<krzk_>
there was a /dev/mali node... maybe it need different permissions (udev rules?)
<krzk_>
also SMACK might me preventing access. Fixing this would be more difficult. Workaround: enable in kernel config permissive mode.
prahal has quit [Ping timeout: 260 seconds]
<wwilly>
hi
<wwilly>
/dev/mali0 node is root:root yes
<wwilly>
I understand that during my sleep... yeah too much geeking about that ahha
<wwilly>
I need to change it as video group or something
<wwilly>
I don't know what is SMACK
<krzk_>
SMACK is like Selinux (but not done by NSA ;) ). It is a implementation of Mandatory Access control so it governs over all accesses to files and other devices
<wwilly>
uhm ok
<wwilly>
change the group of the node solve it
<wwilly>
many thanks :)
<wwilly>
it is a minimal and "old" driver
<wwilly>
the driver from HardKernel has more feature, but it's based on an older kernel :/
wwilly has quit [Quit: Leaving]
[7] has quit [Remote host closed the connection]
TheSeven has joined #linux-exynos
TheSeven has quit [Remote host closed the connection]
TheSeven has joined #linux-exynos
<ndufresne>
javier__: what happen if your CMA reservation overlap with your DT image or your initrd image ?
isaque has joined #linux-exynos
prahal has joined #linux-exynos
prahal has quit [Ping timeout: 246 seconds]
<ndufresne>
ok got a real question
<ndufresne>
on 4412, I know the mixer supports NV12 in 64x32 tiles (what the decoder produce), because it's implemented in S5P-TV driver, any hints how to expose this in the mixer in the DRM driver ?
<javier__>
ndufresne: sorry, I missed your message
wwilly has joined #linux-exynos
<ndufresne>
javier__: the one about cma is not relevent anymore, it was just me doing silly thing
<javier__>
ndufresne: about the CMA and DT / initrd overlapping, I don't know tbh. I *think* it doesn't matter since that is just where u-boot places the DT and initrd for the kernel to get it but after boot things the relocated
<javier__>
ndufresne: ah, Ok
<ndufresne>
and got fooled the the DTs flipping right and left
<ndufresne>
in the original MFC code, left was placed first in memory
<ndufresne>
and left is where you allocate the Y planes
<ndufresne>
still the case, though left and right have been flipped order
<javier__>
but I thought it was correct since all the other Exynos DTS used 8 MiB and also in the ChromiumOS tree
<ndufresne>
On Chromebook two you had the IOMMU patchset, so I believe it was unused
<ndufresne>
(and the peach is Exynos 5
<javier__>
ndufresne: yes, quite likely is because as you said the ChromiumOS kernel uses with IOMMU enabled so that DTS snippet was not used
<javier__>
and probably just copy & pasted from a vendor DTS
<javier__>
ndufresne: btw, for DRM and exynos4412, you can ask LiquidAcid since he hacks on the Exynos DRM on that platform
<ndufresne>
for now I'd focus on the updating the exynos 4, as clearly IOMMU works for Exynos 5 and you have clear goal to get that merged
<ndufresne>
javier__: nod, thanks
<javier__>
ndufresne: yes, although I've been distracted with other internal stuff for the last couple of days
<javier__>
but Marek said he will rebase and re-post his IOMMU patches soon
<ndufresne>
is the mixer driver exactly the same for both Exynos 4 and 5, I can't see any specific code in there ...
<javier__>
ndufresne: is the same driver (drivers/gpu/drm/exynos/exynos_mixer.c) but I see some differences for exynos4 and exynos5
<javier__>
not much though
<javier__>
s/exynos4 and exynos5/different SoC versions
<ndufresne>
ok, I'm wondering if the 64x32 tile format exist on Exynos5
<ndufresne>
because I should expose that conditionnally if it doesn't
<ndufresne>
javier__: from spec, the Ex4 has Video Processor, and this is wired to the VideoPlane, while they say the GScaler replaces that part in Ex5
<ndufresne>
hmm, VideoProcessor can deinterlace
<ndufresne>
hmm, and GScaler don't support that, it does 16x16 linear tiles, and something called vithar tiles, 16x16 Y tiles, and 16x8 UV tiles
<wwilly>
hi, on arm-soc for-next, for the 5422, it's voluntary to not allowing performance counters?
<wwilly>
uhm forget to add it on the kernel config
<ndufresne>
(the fault is a bit minimalist)
<ndufresne>
javier__: ok, I got it, the NV12/NV21 is table for the VP (video processor) only, which is not on Exynos5, so it's already made conditionnal for me, I think I really just have to add he format
amitk has quit [Quit: leaving]
Putti has joined #linux-exynos
<javier__>
ndufresne: Ok
<ndufresne>
any idea how one can connect the gscaler to the mixer ?
<ndufresne>
is it through the ipp.set_addr() function ?
<javier__>
ndufresne: no idea sorry, I'm really ignorant about graphics in general
<ndufresne>
ok, nod
<ndufresne>
it's weird, since there is a certain conflict between v4l2 m2m and some of the stuff in the drm driver
<ndufresne>
drm does not seem to implement interlacing, but yet control the blocks that can handle it
<javier__>
ndufresne: yes, there is indeed some overlapping between the media platform drivers and the DRM one
<javier__>
since both drivers try to manage the same HW blocks
<javier__>
I mean DRM_EXYNOS_GSC and VIDEO_SAMSUNG_EXYNOS_GSC
<ndufresne>
depending which one you use, you loose features ...
<javier__>
yeah...
<ndufresne>
there must be a way to allow both long term, pinchatl propose to start creating v4l2 front end to certain drm plane in Renesas R-CAR familiy
<ndufresne>
* pinchartl proposed
<ndufresne>
(if I understood what he said at Plumbers last year)
<javier__>
ndufresne: how that would work? something like what DRM does for fbdev emulation?
<ndufresne>
I don't know, probably more like G2D DRM code is doing, but with a videobuf queue rather then a custom queue API
<javier__>
I see
<ndufresne>
videobuf is already being generalized
<ndufresne>
but I'd need to see how he do that, and what are the corner cases
<ndufresne>
we could remove a lot of duplication
<javier__>
ndufresne: btw, don't you need V4L2_MEMORY_DMABUF support in s5p-mfc for zero copy?
<ndufresne>
yes, it's already there
<ndufresne>
javier__: oh wait, you got it wrong
<ndufresne>
we need expbuf
<ndufresne>
V4L2_MEMORY_DMABUF is for importer role
<ndufresne>
the DRM driver will be the importer here
<javier__>
ndufresne: oh right, sorry
<javier__>
and videobuf2 already has dma-buf export so you have it for free then, right?
<ndufresne>
(the VP alignment requirement is smaller then the decoder)
<ndufresne>
javier__: yes, well there is a flag, but that has worked in MFC for a long time now
<javier__>
ndufresne: Ok, thanks for the clarification
<ndufresne>
we use to do that in a previous project, but the MALI part wasn't shipped on time, so we given up, v4l2videoNdec capture-io-mode=dmabuf ! v4l2videoNtransform output-io-mode=dmabuf-import capture-io-mode=dmabuf ! glimagesink
<javier__>
ndufresne: still grasping all this concepts so sorry for the stupid questions :)
<javier__>
*these
<ndufresne>
Which basically mean, we where exporting from MFC to FIMC, and then importing into GL space for rendering
<ndufresne>
latest Mali drivers should support that by now
<javier__>
cool and yes I remember that you had some special EGL blobs with dma-buf support
<ndufresne>
also got an hacky version for clutter, upstream was recently reworking it
<ndufresne>
(upstream clutter, but that is less active now)
<ndufresne>
at some point it will just work, and not having this will be story of the past
<javier__>
yeah
Vasco_O is now known as Vasco
Vasco is now known as Vasco_O
Vasco_O is now known as Vasco
wwilly has quit [Quit: Leaving]
<ndufresne>
javier__: hmm, unfortunatly, the MOD_ format is unmappable to user space, it's not fourcc
<ndufresne>
I'd have to duplicate that format and give it a proper fourcc to make it work
<javier__>
ndufresne: Ok
krzk_ has quit [Quit: Ex-Chat]
steev has quit [Remote host closed the connection]
<ndufresne>
javier__: I'll hack something quick to see if I can get that working, and will probably send a RFQ to gather people opinion on how such format would be intergrated
steev has joined #linux-exynos
prahal has joined #linux-exynos
prahal has quit [Remote host closed the connection]