_valle_ has quit [Remote host closed the connection]
diego_r has joined #imx6-dev
dv_ has quit [Ping timeout: 240 seconds]
dv__ has joined #imx6-dev
dv__ has quit [Ping timeout: 250 seconds]
dv_ has joined #imx6-dev
dv_ has quit [Ping timeout: 245 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
dv_ has joined #imx6-dev
cnxsoft has joined #imx6-dev
dv_ has quit [Ping timeout: 240 seconds]
dv_ has joined #imx6-dev
dv_ has quit [Ping timeout: 258 seconds]
dv_ has joined #imx6-dev
dv_ has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Ping timeout: 245 seconds]
cnxsoft has joined #imx6-dev
codinho_ has joined #imx6-dev
Guest55789 has joined #imx6-dev
jas-hacks has joined #imx6-dev
jas-hacks has left #imx6-dev [#imx6-dev]
Guest55789 has quit [Ping timeout: 240 seconds]
fossxplorer has joined #imx6-dev
dv_ has joined #imx6-dev
malik has joined #imx6-dev
fenrig has joined #imx6-dev
fenrig has quit [Quit: Page closed]
marcin has joined #imx6-dev
<dv_>
WarheadsSE: so how did the workshop go?
fenrig has joined #imx6-dev
<fenrig>
Hi
<fenrig>
I have some questions regarding the I.MX6 (Quad) and it's ability to use dma on usb (as host)
<fenrig>
I'm writing a kernel module for a usb webcam
<fenrig>
and it has to use dma for it's transfers
<fenrig>
but I'm unable to find much information about dma and how it works with usb on the imx6 system
<malik>
i think the part about usb is pretty massive in the reference manual
<malik>
i cannot imagine you have to know a lot about this for writing a webcam driver... but well, i never did it, so...
<fenrig>
malik: that's what I'm trying to figure out, though I need to know what sort of memory pointers I have to pass to my USB controller
<malik>
you should not have to work on this level... we are not bare metal here
<malik>
the usb controller driver worries about things like that
<malik>
as a driver author, you should just be able to use the linux usb framework
<malik>
that is kind of the magic of an operating system :)
<fenrig>
I understand that
<fenrig>
so every usb driver should be able to use (generic kernel api) dma on almost all the platforms (if DMA is supported)
<malik>
yes, i would assume that
<fenrig>
"The first question that must be answered before attempting DMA is whether the given device is capable of such an operation on the current host. Many devices are limited in the range of memory they can address, for a number of reasons. By default, the kernel assumes that your device can perform DMA to any 32-bit address. If this is not the case, you should inform the kernel of that fact with a call to:"
<fenrig>
I have this from linux device drivers (3)
<fenrig>
so I need to know how DMA is able to adress my physical memory :/
<fenrig>
allright :D
<fenrig>
just found in the reference note, usb has a integrated dma controller :) (wasn't entirely sure)
<malik>
well... just look at the usb camera drivers
<malik>
there is no switch() case imx6: case exynos etc
<fenrig>
malik: I thought so too, but I did read into the issue. And in the kernel there are some problems with hooking the board description with DMA information
<fenrig>
and then getting that information into the drivers :)
<fenrig>
but you'll probably be right that I don't have to do anything special but to use the kernel api for dma :/
ortogonal has quit [Read error: Operation timed out]
ortogonal has joined #imx6-dev
cnxsoft has quit [Quit: cnxsoft]
Guest55789 has joined #imx6-dev
<malik>
fenrig: the way i see it, no usb camera driver calls those functions
<WarheadsSE>
dv_: very fast, she had a lot of content for the hour, and I would bet that the uninitiated to yocto glassed over at least a few times
jas-hacks has joined #imx6-dev
diego_r has quit [Quit: Konversation terminated!]
fenrig has quit [Quit: Page closed]
<dv_>
jas-hacks: awesome demo !
<dv_>
WarheadsSE: she? daiane?
<dv_>
jas-hacks: how did you modify the ipusink?
<WarheadsSE>
lauren I think, post?
<dv_>
ah
<jas-hacks>
dv_: thanks, I didn't modify the ipusink in the end. The trick was to run X on the FG buffer because ipusink uses the BG buffer and then call the fb iotcls to set the color key.
<dv_>
heh, nice trick
<jas-hacks>
dv_: it would be useful to add property on ipusink to set which fb we want to use.
<dv_>
hmm perhaps
<dv_>
I did not pay much attention to ipusink because (a) it did not work well with compositing servers like wayland (b) is slower than the eglvivsink (c) doesnt run if the video resolution is the same as the screen one
<dv_>
the last one is a driver bug , which may have been fixed in 3.10
<jas-hacks>
I was also wondering whether it would be possible to set a viewport on the ipusink so it doesn't use the whole screen
<dv_>
in theory this is possible. I did not add it though
<dv_>
ideally it would implement the GstVideooverlay interfae
<dv_>
the numbers you mention make sense, no nasty surprises
<dv_>
the clockoverlay composes with the CPU, so the higher figures are logical
<dv_>
I was thinking of some kind of "composite" metadata that describes the position, scale etc. of multiple video streams , so that in the end, the sink composes them together, with the GPU for example
<jas-hacks>
yes was wondering how we could workaround clockoverlay and I'm not sure how it would end up the h264 stream for file?
<jas-hacks>
/s/up/up in
<dv_>
true, that would require an offscreen GLES context
<dv_>
somehow rendering with a framebuffer object to a direct texture that is bound to a DMA buffer
<dv_>
or perhaps with the IPU
<dv_>
with the IPU it would be easier, although the GPU appears to be faster, and also allows for much more advanced techniques
<unsolo>
so anyone online that has the gpu working on a vanilla kernel > 3.13
<jas-hacks>
unsolo: I think not
<dv_>
nobody I know. getting all of this stuff to 3.10 was already a lot of work
<unsolo>
i keep hitting some problems with the recursive locking going on in the driver as my vanilla kernel doesnt really like that..
<dv_>
unsolo: I can only repeat myself: talk to rmk and/or jnettlet :)
<unsolo>
;)
<unsolo>
if i simply "disable" the first mutex lock deadlock.
<unsolo>
(im on a solo so its fine)
<unsolo>
the kernel boots up properly..
<jas-hacks>
unsolo: what's wrong with 3.10?
<unsolo>
if i ignore the errors (eg disable the lock recursive warning) it deadlocks
<unsolo>
jas-hacks: is it a vanilla 3.10 ?
<malik>
unsolo: did you have a look at this etna viv stuff?
<unsolo>
malik: not yet..
<jas-hacks>
unsolo: nope
<unsolo>
jas-hacks: then a lot of things
<malik>
unsolo: i heard people even ran qt5 on it, so perhaps this is an option
<dv_>
malik: etnaviv is awesome, but it is not a drop-in replacement for the vivante drivers yet
jnettlet has joined #imx6-dev
<dv_>
it lacks finished mesa integration & an x11 driver
<malik>
ok
<malik>
personally i do not use x11 on imx6, so that is no issue for me
<dv_>
but the core driver is pretty far already
<dv_>
unsolo: what 3.10 kernels did you look at?
<jnettlet>
there will be a very exciting announcement in the next 10 days regarding etnaviv
<dv_>
ohh teasers
<malik>
:)
<unsolo>
dv_: if there was a gpu only patch to 3.10 i might consider that as a starting base ;)
<dv_>
jnettlet: unsolo is trying to get the galcore stuff to work on 3.13
<jnettlet>
well more about iMX6 graphics than etnaviv specific, but that of course includes etnaviv
<unsolo>
anyhow the whole DRM + gpu thing should be ok on 3.13
<unsolo>
it doesnt have that many hooks
<unsolo>
etnaviv looks interesting and may be an alternative but it still uses galcore unless i am mistaken
<dv_>
yeah but it is not a hard dependency
<dv_>
its just that this is the only available thing so far
<dv_>
anyway, can you summarize your lock problem?
<unsolo>
dv_: guess thats true. imho galcore is a mess and should have remaind a ko outside the kernel..
<jnettlet>
unsolo, it hasn't been accepted upstream so is outside of the kernel.
<malik>
unsolo: ah ... seems your right... so that is not a solution... mh
<malik>
you're
<jnettlet>
first don't use the FSL galcore driver. Use the one that is in either my or SolidRun's fork of my kernel.
<dv_>
unsolo: are you referring to the FB_MULTI_BUFFER=2 thing?
<jnettlet>
but again back to the problems. What are we trying to achieve here? Video playback?
<jnettlet>
dv_, I assume so
<unsolo>
so if you run qt with drm on the imx6 staging it should just work ?
* dv_
is confused
<dv_>
what is your goal?
<dv_>
I thought you want to port galcore to 3.13
<unsolo>
run w/o X and w/o galcore if possible
<dv_>
and with what instead?
<unsolo>
just ipu no 3d required.
<jnettlet>
okay so you want QT to run in software rendering mode at 32bpp
<dv_>
uhh I would reconsider this
<dv_>
well okay if you dont want fancy graphics then it may work
<dv_>
but then why dont you just take the IPU stuff and try to port that?
<dv_>
why touch galcore at all?
<unsolo>
dv_: its already there .. i think
<unsolo>
because i dont know how ;)
<dv_>
hmm I think only the hdmi drm parts of the IPU are upstreamed
<malik>
yes, and its currently not in great shape
<dv_>
rmk would love to hear that :)
<jnettlet>
I don't think this is possible. QT needs something to draw the screen. Be it X11/DirectFB/EGL
<malik>
russell king has patches lined up, but it seems it will take a while till it is out of staging
<unsolo>
linuxfb ;)
<dv_>
jnettlet: it can draw with directfb, yes
<dv_>
also with regular FB, though this isnt exactly fast
<jnettlet>
dv_, LVDS is supported by KMS
<jnettlet>
dv_, Vivante ships a DirectFB 1.6 driver
<dv_>
which depends on galcore, hm?
<jnettlet>
and DirectFB can run on top of KMS
<jnettlet>
it does yes
<unsolo>
so the answer is i need galcore to achieve my goals.
<dv_>
well thats a compromise
<jnettlet>
or you need to run Xorg
<jnettlet>
with the baseline KMS modesetting driver
<dv_>
unsolo: in theory, the IPU can do simple 2D operations for qt
<jnettlet>
blech
<dv_>
but its not very practical
<dv_>
you'd have to implement a qt graphics backend for the IPU
<unsolo>
dv_: yes but everyone is so focused on the 3d part they completely forget the 2d as allways ;)
<dv_>
I wouldnt say that
<dv_>
its just that the two are very tied together
<jnettlet>
unsolo, not at all I am very focused on 2d acceleration
<jnettlet>
it is a lot more power efficient on the Vivante GPU's
<dv_>
galcore also has 2D APIs
<jnettlet>
and the higher end chipsets have separate cores for 2d/3d
<unsolo>
jnettlet: i did some 2d stuff for ps3 back in the old days ;)
<unsolo>
in linux before it was broken open..
<dv_>
yeah. the only reason why I use GLES in my eglvivsink is because there is no standard API that allows me to render a DMA framebuffer directly
<jnettlet>
unsolo, great you can help with the etnaviv 2d driver work then
<unsolo>
jnettlet: perhaps i could.. i have an nitrogen6 lite here ..
<dv_>
although it may be possible to write an extension in wayland for this..
<unsolo>
dv_: i think the ipu can do a lot of great stuff including composition etc..
<jnettlet>
dv_, yes but don't go there. remember announcement coming 8-10 days
<unsolo>
it can even do composition of an input onto output
<dv_>
it can, but it has its limitation
<dv_>
jnettlet: stop teasing me :P
<malik>
jnettlet: spill the beans already :)
<dv_>
unsolo: I know, I have been using it
<jnettlet>
sorry can't
<jas-hacks>
jnettlet: mesa backend?
<jnettlet>
mesa will be involved yes
<dv_>
unsolo: it is slower than the GPU for video output (though this might be because of the framebuffer) and the kernel driver is a huge mess
<dv_>
jnettlet: oh I have my suspicions what you are getting at
<dv_>
but i wont say anything :)
<jnettlet>
dv_, you should :-)
<jnettlet>
thanks
<dv_>
unsolo: it also has a particularly funny design flaw: you cannot simply blit 2d regions without transformation
<jnettlet>
dv_, but that is just a driver problem. I haven't seen anything in the docs that supports that.
<dv_>
so, if you dont resize, or convert colorspace, or deinterlace, rotate etc. and essentially just want to copy the pixels from A to B, the driver says "nope, error"
<unsolo>
anyhow conclusion is for proper framebuffer i need at least galcore + direcfb..
<dv_>
jnettlet: yes, but it is a serious problem if you base your software stack on it
<dv_>
it is one main reason why I did not developed the ipusink much further
<unsolo>
jnettlet: so you suggest i try porting the linaro mxc stuff instead of the stuff on boundary/freescale ? and that should fix my not properly implemented recursive mutex locking issues ?
<unsolo>
where you pointed me to look for a galcore driver
<jnettlet>
so that is the freescale (really Vivante driver with fsl hardware patches) with additional patches by rmk and myself
<unsolo>
ahh
<jnettlet>
unsolo, can I ask why you are so hell bent on 3.13?
<unsolo>
i like it bleeding edge
<dv_>
3.14 is bleeding edge :)
<jnettlet>
3.15 is bleeding edge
<unsolo>
well 3.13 or 3.14 shouldt be such a hard thing to achive..
<dv_>
right.
<jnettlet>
you would be surprised
<dv_>
yeah the minor revision increase is deceivin
<dv_>
*deceiving
<unsolo>
what annoys me the most is that this is all buildt into the kernel..
<jnettlet>
what is built into the kernel?
<unsolo>
galcore
<jnettlet>
build it as a module
<unsolo>
hehe :P
<jas-hacks>
jnettlet: back to the teaser ... so no more overriding/copying libs around?
<unsolo>
but it would be easier to maintain a version outside if its never going in imho
<malik>
i booted master a couple of days ago, got a lockdep spill at every 2nd boot
<malik>
reminds me, i wanted to look into it
<unsolo>
jas-hacks: im sure of it its an easter bunny ;)
<dv_>
unsolo: kinda hard if the APIs change
<unsolo>
dv_: depends on which api's
<jnettlet>
unsolo, we will be working on a proper drm driver eventually, but that won't be done until there is a proper userspace implementation of etnaviv
<jnettlet>
galcore will exist as a module outside the kernel soonish. it is on my list of things to do.
<unsolo>
jnettlet: does etnaviv replace the binary blob ?
<jnettlet>
and it can already be built outside the kernel
<unsolo>
that should make porting / cleaning it out easier
<jnettlet>
unsolo, yes etnaviv is a clean reverse engineered replacement for libGAL with a Mesa Gallium driver
<jnettlet>
which if you only want to run on a raw fbdev right now, should in theory run QT
<malik>
apparently the pengutronix guys had it in their booth at embedded world
<unsolo>
jnettlet: i know and i will probably change to it later on .. now im fighting galcore.
<dv_>
speaking of libGAL, with the newest libraries you indeed do not have to link libGAL explicitely . linking libEGL is enough now
drfu_ has joined #imx6-dev
<jas-hacks>
dv_: good to know that.
<unsolo>
jnettlet: did you remove a lot of code ?
<unsolo>
it at least looks that way for me
<unsolo>
no diffs on the mutex stuff...
<jnettlet>
unsolo, just cleaned a lot up. rmk added a handful of race patches that we worked out on the older driver and then I updated those and fixed a handful of other problems.
<jnettlet>
There may be one other patch I have hanging in my queue, but that only effects driver unload. So get started with what is there.
<unsolo>
the ipu stuff is the same right
<unsolo>
so basically its gpu-viv id want to copy and see if these recursive locks are gone..
<unsolo>
CONFIG_DEBUG_MUTEXES=y ;)
<unsolo>
did you add a galcore dependency on CMEM ?
<unsolo>
actually it should dep on a specific cmem size imho
<unsolo>
then again it should be replaced by something..
jas-hacks has left #imx6-dev [#imx6-dev]
<jnettlet>
unsolo, not at all. GALCORE now uses CMA to allocate memory. Just make sure to configure to kernel to allocate a large enough CMA block. I usually do 256MB's
<unsolo>
well i logged the galcore and it requests 132M at the first alloc at least.. 196 seems to work
<unsolo>
btw im hittin tons of compiler issues with the linaro-stable mxc/gpu-viv
<unsolo>
drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c: In function '_QueryProcessPageTable':
<unsolo>
include/linux/mm.h:1483:10: error: assignment from incompatible pointer type [-Werror] *(ptlp) = __ptl; \
<jnettlet>
unsolo, like I said jumping versions is not so easy. There will be changes to the api that will need to be patched
<unsolo>
im hacking about
<unsolo>
seems the spinlock_t should be a raw_spinlock_t
<jnettlet>
it is exactly why I am basing on a 3.10 LTS kernel. To give most users a stable kernel/driver without needing to mess around with galcore too much before we write a proper DRM driver
<unsolo>
jnettlet: well consider this something you can get another day ;)
<unsolo>
im suprised they mess this much about with these api's
<jnettlet>
why not? The only kernel rule is you don't break userspace
<unsolo>
jnettlet: thats true..
<jnettlet>
they can rightfully care less about kernel drivers outside the kernel.
<unsolo>
maybe not an error just me actvating some "spinlock checks" in kernel debug that triggered an error in all the casts from galcore..
peba has joined #imx6-dev
<unsolo>
some hacking and it at least buildt nicely
<unsolo>
hmm
<unsolo>
kernel booted same issue as the driver i hacked in from freescale..
<unsolo>
im thinking ill do the do not lock on that second one..
<unsolo>
and then do the same with the X11 driver once that fires up
<unsolo>
just to try ;)
<unsolo>
so linux boots fine with my no deadlock hack but once the X11 driver starts up this happens http://pastebin.com/gu16YZ7a (note this is both parts.)
<unsolo>
im thinking something is wrong with gckOS_AcquireMutex
peba has quit [Quit: Leaving]
drfu_ has quit [Quit: Page closed]
fossxplorer has quit [Remote host closed the connection]
bfederau has quit [Remote host closed the connection]