| 11:09 | _rmk_ | jnettlet: do you know which (if any) bmm calls the flash plugin requires? |
| 11:10 | _rmk_ | dv_: which bmm calls do you require for gstreamer? |
| 11:17 | jnettlet_ | _rmk_, it is done through libphycontmem, and it is the standard process. phy_cont_malloc, phy_cont_free, phy_cont_getpa, phy_cont_getva |
| 11:17 | jnettlet_ | it doesn't use any of the cache flushing that I remember. |
| 11:23 | jnettlet_ | _rmk_, oh happy happy joy joy. The final builds that they sent us took my advice and removed the direct access to phycontmem. They are just accessing things through libvmeta and libcodecvmetadec |
| 11:25 | jnettlet_ | so maybe we can just migrate this all into libvmeta |
| 11:43 | dv_ | _rmk_: just allocate and free calls. allocate calls should offer me to allocate writecombine, cached, or uncached buffers |
| 11:43 | dv_ | I also need a way to get a virtual address |
| 11:43 | dv_ | but if I get this by mmap'ing a physical address thats okay |
| 11:44 | dv_ | but I thought bmm/ion shall go through jnettlet_'s libphycontmem ? |
| 11:45 | jnettlet_ | dv_, sorry you missed that part yesterday. We are most likely removing that abstraction. |
| 11:46 | dv_ | because ? |
| 11:47 | jnettlet_ | we are using all dmabuf's instead. |
| 11:47 | _rmk_ | dv_: so you're not using the vmeta allocation/free calls - vdec_os_api_dma_alloc() etc? |
| 11:47 | jnettlet_ | then leaving it up to the device drivers to pass back physical address's to userspace |
| 11:47 | dv_ | _rmk_: oh, misread that. yes, I use these in the gst-vmeta plugins. |
| 11:48 | dv_ | jnettlet_: okay, but how can this work for the VPU? |
| 11:48 | dv_ | the imx VPU and IPU I mean |
| 11:48 | dv_ | my knowledge of their kernel parts is a little fuzzy |
| 11:49 | dv_ | but in the VPU case, userspace actually uses VPU registers directly |
| 11:49 | jnettlet_ | that is why it might make sense to keep bmm as a separate module |
| 11:50 | dv_ | hm. okay by me. the allocators are clearly defined for vmeta. (= just use vdec_*alloc) |
| 11:50 | dv_ | its imx where there are three sets of allocators, two of them unnecessarily requiring me to initialize the VPU |
| 11:50 | _rmk_ | dv: the idea is to turn bmm into a provider of dma-bufs. they then get imported into vmeta (or imx vpu), and that's where we have the hack to get the physical address of them |
| 11:50 | jnettlet_ | that is where your input is useful, as you are doing lots of hands on at the user level |
| 11:51 | dv_ | hm. |
| 11:51 | _rmk_ | dv: it means you can import other dma-bufs into the vmeta stuff - eg, for encoding, direct from the camera driver |
| 11:51 | dv_ | I suppose an ioctl that translates dmabuf to physical addresses would work. |
| 11:51 | jnettlet_ | that is the idea |
| 11:51 | _rmk_ | I'm thinking for efficiency "import this dmabuf and give me the phys address" in one go - not much point it being two ioctls :) |
| 11:51 | dv_ | actually, that sounds pretty nifty, when I think about it |
| 11:51 | dv_ | since gstreamer has support for dmabuf |
| 11:52 | dv_ | _rmk_: you mean the communication with vmeta and vpu? |
| 11:52 | jnettlet_ | _rmk_, and use the check for a physical address as a success/failure test? I like it |
| 11:53 | jnettlet_ | dv_, and with bmm backed with CMA the allocations are all at runtime |
| 11:53 | dv_ | so, no more fixed maximum |
| 11:53 | dv_ | nice |
| 11:54 | jnettlet_ | well there is a fixed maximum, but you can work around that by setting up a large CMA allocation and not having it completely off limits for other system processes if you aren't doing anything with it. |
| 11:55 | dv_ | yeah I meant the old maximum which is also the exclusively reserved vmeta ram |
| 11:56 | jnettlet_ | Setting up a 256MB allocation and then using something like zram swap should give a pretty lenient memory infrastructure. |
| 11:57 | dv_ | but this "import dmabuf" part, import where exactly? sounds to me like you want to change the vmeta API to accept dmabuf fds instead of physical addresses |
| 11:57 | jnettlet_ | what will BMM stand for? Buffer Memory Manager? |
| 11:58 | dv_ | ah no, I think I get it. I saw it from the other side. |
| 11:59 | dv_ | you mean, the vmeta library shall internally import dmabuf and extract a physical address out of it, which is then given to me. |
| 11:59 | dv_ | right? |
| 11:59 | _rmk_ | yes |
| 11:59 | dv_ | I tend to look at it the other way round, as the user of the vmeta api :) |
| 12:00 | _rmk_ | libvmeta would hide this from you and you'd see the same old allocation functions working as before |
| 12:00 | dv_ | yes, this makes a lot of sense. and for vmeta , it is certainly doable. |
| 12:00 | dv_ | imx will be more difficult I think, but not impossible. |
| 12:00 | _rmk_ | I think we pretty much _have_ to guarantee that, because libvmeta is the interface into all the closed source stuff |
| 12:00 | dv_ | on the other hand, there is no closed source lib for imx |
| 12:00 | dv_ | its all open |
| 12:01 | _rmk_ | there's only one issue I'm aware of here: the gstreamer 0.10 bmmxvimagesink makes direct references to libbmm functions |
| 12:01 | dv_ | right. the hack to get physical addresses. |
| 12:02 | _rmk_ | bmm_get_paddr() |
| 12:02 | dv_ | fortunately I was able to avoid that in my 1.0 stuff |
| 12:02 | dv_ | but the 0.10 plugins have this problem, yes |
| 12:02 | dv_ | perhaps it is possible to add a stub called bmm_get_paddr() ? |
| 12:03 | _rmk_ | I think it's avoidable in 0.10 as well if the appropriate codec data is passed with the gst buffer |
| 12:03 | dv_ | the problem in 0.10 is that it is tricky to pass around physical addresses |
| 12:03 | dv_ | you need to do more or less ugly hacks, like abusing private reserved fields |
| 12:04 | dv_ | but I think I remember the vmeta decoder putting the physical address somewhere |
| 12:04 | _rmk_ | its actually already got support in there for passing a whole load of information, but that's not used on dove - the field is used purely to communicate whether its interlaced or not |
| 12:04 | dv_ | yeah but that area is ill-defined for memory regions, which is why 1.0 introduced allocators and metadata structures |
| 12:05 | _rmk_ | depends whether KeepDecFrameLayout is set or not |
| 12:05 | dv_ | still, in theory, bmmxvimagesink only has to check for the address in that part of the gstbuffer, and if its nonzero, hooray its a physical address |
| 12:05 | dv_ | ah yes, what is that good for? |
| 12:06 | dv_ | I didnt use it in 1.0 |
| 12:06 | dv_ | didnt see an immediate need for it |
| 12:06 | dv | 12:06 * dv_ looks up that source again ... its been a while |
| 12:07 | _rmk_ | if set, it passes a structure downstream instead (which includes the phys address) instead of just a flag for interlace |
| 12:09 | dv_ | right. got it. IPPGST_BUFFER_CUSTOMDATA() |
| 12:10 | dv_ | #define IPPGST_BUFFER_CUSTOMDATA(buf) (((GstBuffer*)buf)->_gst_reserved[sizeof(((GstBuffer*)buf)->_gst_reserved)/sizeof(((GstBuffer*)buf)->_gst_reserved[0]) - 1]) |
| 12:10 | dv_ | .... ugh. |
| 12:11 | dv_ | well, without a given physical address, you need some way to get it from the virtual one. perhaps it is possible to retain this function in libbmm somehow? |
| 12:12 | dv_ | I am thinking of a libbmm which deals with dmabuf FDs and also provides bmm_get_paddr() . usually, client code does not touch BMM directly, instead using it through libvmeta etc. but in the bmmxvimagesink case, it is linked against directly. |
| 12:12 | dv_ | this gives you full backwards compatibility. |
| 12:13 | _rmk_ | silly question... |
| 12:13 | _rmk_ | GstBufferPrivate *priv; |
| 12:13 | _rmk_ | who is that private to? the element which created the buffer? |
| 12:13 | _rmk_ | or the buffer allocator itself? |
| 12:13 | dv_ | the gstbuffer implementation |
| 12:14 | dv_ | outside code must not ever touch this |
| 12:14 | dv_ | so, yeah, the allocator |
| 12:18 | dv_ | _rmk_: your view on my backwards compatibility idea? |
| 12:19 | _rmk_ | it'll mean moving bmm_get_paddr() into libvmeta |
| 12:21 | _rmk_ | the only thing my present bmmxvimagesink uses it for (which isn't going to be much longer) is to detect if its coming from vmetadec for the interlace info |
| 12:21 | dv_ | uh, no? |
| 12:21 | dv_ | ah |
| 12:22 | dv_ | I was speaking of the original marvell bmmxvimagesink |
| 12:22 | dv_ | so, you have deinterlacing support? how? |
| 12:23 | _rmk_ | I don't - I've just kept that code for the time being which just forwards it via an xv attribute |
| 12:23 | dv_ | also, why not keep bmm_get_paddr in libnmm and link bmmxvimagesink against libbmm? then you dont have to move anything into libvmeta |
| 12:23 | dv_ | I see. I always wondered why it was there since I didnt see deinterlacing functionality in the xv hack |
| 12:23 | _rmk_ | because with this, libbmm isn't going to know the physical address |
| 12:23 | _rmk_ | all that libbmm will know is the virtual address and the dmabuf fd |
| 12:24 | dv_ | ah. I thought bmm knows this part and vmeta just takes it and passes it around. okay. |
| 12:24 | _rmk_ | also, bear in mind that the original marvell bmmxvimagesink involves the X server hack which we really should kill |
| 12:25 | dv_ | well, whats the alternative? we need a way to show frames without copying them somehow |
| 12:25 | _rmk_ | which my bmmxvimagesink, X server and now mainlined DRM supports |
| 12:25 | dv_ | I tried to use the vivante 2d api directly, but that wont work, since the association of gal2d surfaces with x windows is done in the driver |
| 12:25 | dv_ | okay |
| 12:26 | dv_ | ah thats the extension which actually allows one to detect if it is present or not? |
| 12:26 | _rmk_ | bmmxvimagesink sees XVBO in the formats accepted by the X server, which allows it to pass a DRM named object for display on the overlay plane |
| 12:27 | dv_ | yes. nice. I'll try to add support for this in my 1.0 code. |
| 12:27 | _rmk_ | and the XVBO format which is passed to the X server consists of two words: one is the X servers fourcc format code which is already in its advertised list of supported formats, and the other is the DRM name for the object |
| 12:30 | _rmk_ | dv_: have a look at the X server DDX side: http://ftp.arm.linux.org.uk/cgit/xf86-video-armada.git/tree/src/armada_drm_xv.c around lines 500 and 650 |
| 12:31 | dv_ | nice. that looks clean, unlike the marvell hack |
| 12:32 | _rmk_ | any format in the table at line 291 can be passed through that - provided the DRM kernel driver supports it (the list of advertised formats is edited according to the kernels support) |
| 12:33 | _rmk_ | what I think I'm going to do today is clean up my bmmxvimagesink and upload it :) |
| 12:36 | dv_ | I think requiring a modified bmmxvimagesink isnt unreasonable |
| 12:37 | dv_ | that marvell stuff is very old anyway, and there hasnt been any update from them |
| 12:38 | _rmk_ | I think I'll also strip the package containing this right down to its minimum |
| 12:39 | _rmk_ | no point it also containing the v4l and ximage stuff too when the only thing we're interested in is xvimage |
| 12:41 | dv_ | true |
| 12:41 | dv_ | using ximage for video output is not that efficient anyway |
| 12:52 | purch | weee, C1 console online |
| 12:53 | _rmk_ | dv_: is there a proper way to determine whether bmmxvimagesink is connected to vmetadec? |
| 12:53 | _rmk_ | dv_: what I'm thinking is that bmmxvimagesink should just defer to xvimagesink if the decoder is not vmetadec |
| 12:53 | purch | 6,8,10 pins connected and Tx, Rx needed a switch |
| 12:54 | purch | had to test pin setup with RPi |
| 12:54 | dv_ | _rmk_: in general it is not possible |
| 12:54 | dv_ | because elements may get (re)connected at runtime |
| 12:55 | dv_ | you'd need to catch cases where this happens. so, okay, it _may_ be possible, but its not trivial. plus, it is highly discouraged to establish such dependencies. |
| 12:55 | dv_ | I had similar ideas in the past for the 1.0 stuff, to make the code smaller |
| 12:55 | _rmk_ | yea, I can see why it could be a problem here too |
| 12:55 | dv_ | prior to 1.2, you are out of luck: you must provide a fallback in your sink |
| 12:56 | _rmk_ | since this is the element which creates the X window for display |
| 12:56 | dv_ | starting at 1.2, caps can contain features, like "this sink's sinkpad expects buffers which contain DMA memory" |
| 12:56 | _rmk_ | okay, that's bmm_get_paddr() gone from my bmmxvimagesink when the legacy marvell passing is disabled :) |
| 12:57 | _rmk_ | the xserver marvell passing that is |
| 12:57 | dv_ | yay |
| 12:57 | dv_ | as said, I think we should not try to shoehorn backwards compatibility here |
| 12:58 | dv_ | I'll update my yocto meta-cubox layer to use your driver and modified bmmxvimagesink, and will adapt my 1.0 sink code |
| 12:58 | _rmk_ | well, the nice thing is, I can just delete the legacy code between the ifdefs and it will be gone :) |
| 12:59 | dv_ | purch: tx and rx often need to be switched, since what tx and what rx is depends on your point of view |
| 13:00 | dv_ | _rmk_: the x driver uses gal2d to draw everything, right? |
| 13:01 | purch | dv_: yeah, this document helped a lot http://elinux.org/RPi_Serial_Connection |
| 13:02 | _rmk_ | dv: yea, as much as possible. There's a few more bits I should probably sort in addition. |
| 13:02 | dv_ | did you see anything about deinterlacing anywhere? |
| 13:05 | purch | are these good bootargs for U-Boot 2013.10-rc4-00023-g5d1c16a-dirty (Oct 20 2013 - 18:42:09) http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel#Booting_the_kernel |
| 13:07 | _rmk_ | dv: deinterlacing is something I've not looked at - I think I briefly had a look at the fb driver a while back but I don't recall |
| 13:08 | dv_ | is there a document for the v2 2D api somewhere? I know of the v4 one from freescale |
| 13:10 | dv_ | hmm. at least in v4 I dont see anything about deinterlacing. |
| 13:10 | dv_ | anyway, going for lunch. ttyl |
| 13:25 | purch | I wonder where that SD card reader is ::think |
| 13:26 | purch | I got blame that two year old rascal that is too interested of these small electronic gadgets :) |
| 13:28 | purch | well wife's laptop (win8.1) with integrated SD card reader and lubuntu in virtualbox have cope with that |
| 14:40 | xraxor | hi |
| 15:11 | jnettlet_ | dv_, you probably know but the gstreamer conference 2013 videos are now all up. http://gstconf.ubicast.tv/channels/#gstreamer-conference-2013 |
| 16:12 | capitano_ | hi |
| 16:19 | capitano_ | I am trying installed geexbox and ubuntu 13.04 (with cubox installer) but in both cases I cannot able to make start X |
| 16:19 | capitano_ | X -configure say not available drivers |
| 17:39 | jnettlet_ | great every time we wake the Vivante GPU up from sleep, we rerun the detect hardware routine to verify the gpu is preset and hasn't changed? Seems a little unnecessary |
| 17:39 | jnettlet_ | especially considering it is a SOC. |
| 17:41 | _rmk_ | jnettlet: it has to be done because a neutrino may reconfigure your GPU. :) |
| 17:44 | jnettlet_ | :) |
| 17:45 | jas-hacks_ | longer term the CPU may suffer from dementia :) |
| 17:45 | jnettlet_ | also found another place where irqs were just being enabled and disabled with no locks or state. hurray |
| 17:46 | jnettlet_ | it is my own fault for actually fixing irq handling. This wasn't a problem for them because they were fulling releasing the irq when the GPU was suspended |
| 17:46 | jnettlet_ | really painful. |
| 17:47 | jnettlet_ | how dare you make things work properly? That will break everything! |
| 17:49 | jas-hacks_ | jnettlet_: Are you reworking the vivante kernel driver? |
| 17:51 | jnettlet_ | jas-hacks_, again yes. |
| 17:58 | jas-hacks_ | Hopefully there should be a beta 3.10 kernel released soon |
| 17:58 | _rmk_ | well... bmm_drv is getting smaller... |
| 17:58 | _rmk_ | 2 files changed, 124 insertions(+), 482 deletions(-) |
| 18:05 | jnettlet_ | ah I think I have finally found some of the slowness. SUSPEND when idle is failing which can be long enough so then the idle timer gets hit and powers off the GPU completely so everything needs to be re-inited. |
| 19:55 | purch | what is the current standing of drivers and ubuntu distributions for C1? |
| 19:57 | purch | jnettlet_: btw, why would one need uart console anymore, hdmi works? |
| 20:39 | xraxor | rabeeh: what about the update about the orders and shipments? seen some guys are in the edge of quitting buying a cubox-i |
| 20:49 | purch | yeah, life is too sort to wait for few days |
| 20:50 | xraxor | purch: is that directed to me? |
| 20:50 | purch | to "some guys" |
| 20:52 | xraxor | sometimes its hard, all this 'not knowing' is harming SolidRun. im waiting for mine, wont change my mind and want the device be popular :) |
| 21:50 | rabeeh | http://imx.solid-run.com/forums/viewtopic.php?f=2&t=279 |
| 21:50 | rabeeh | well.. xraxor left |
| 21:51 | _rmk_ | aww |
| 21:52 | rabeeh | few have a week or so delay |
| 21:52 | rabeeh | production ramp issues with the manufacturers |
| 21:55 | bencoh | hmm, I didn't think it was released already :) |
| 21:55 | bencoh | good to know |
| 22:02 | _rmk_ | *gah* |
| 22:02 | rabeeh | bencoh: we started shipping cubox-i1 and i2 on time; but then we had a dip i2ultra and i4pro |
| 22:02 | _rmk_ | okay, getting CMA working on the cubox is far from easy... why do we have a 2GB max zone order... |
| 23:17 | purch | hmm, I have too many uSD cards |
| 23:18 | purch | howto clean wnadboard u-boot from c1? =) |
| 23:18 | purch | wandboard |
| 23:44 | _rmk_ | okay, CMA version now working :) |