| 10:25 | dv_ | oh great. more pecularities from libfslvpuwrap. |
| 10:25 | dv | 10:25 * dv_ will definitely redesign gstreamer-imx for the 1.1 release to use vpu-lib instead of libfslvpuwrap |
| 10:35 | jnettlet | hurray |
| 10:36 | jnettlet | vpu-lib and libphycontmem. maybe we should rename it phycontmem-lib...or pcm-lib, nope think that is taken. |
| 10:37 | jnettle | 10:37 * jnettlet shakes head...just got another article forwarded to him about some research team using speakers and microphone to pass data between machines. |
| 10:38 | jnettlet | I guess people don't remember you used to put your phone into an acoustic modem to connect computers remotely. |
| 10:39 | hste_ | jnettlet: wargames :) |
| 10:40 | jnettlet | now people think viruses are really going to jump around computers like this. Let the idiocracy grow. |
| 10:41 | jnettlet | hste_, you were correct about the winds. It is quite miserable here today. |
| 10:41 | hste_ | and hacking a systems password is just to push some few keys on the keyboard... :) |
| 10:42 | hste_ | dv_: allready planning for a 1.1 :) |
| 10:43 | dv_ | hste_: actually thats the plan |
| 10:43 | dv_ | 1.0 will be what I have plus bugfixes, 1.1 will ditch libfslvpuwrap |
| 10:43 | jnettlet | dv_, 1.1? You aren't jumping to 1.2 to match gstreamer? |
| 10:43 | hste_ | I like the idea of ditching that wrapper |
| 10:43 | dv_ | it just makes development harder, not easier. i will use it as a reference for imx specifics instead. |
| 10:43 | dv_ | no |
| 10:44 | jnettlet | dv_, which kernel are you working against right now? |
| 10:44 | dv_ | still th 3.0.35 one |
| 10:44 | dv_ | I want to move to beta status asap, so I dont have time to try others yet |
| 10:44 | dv_ | this will change today or tomorrow if things work out |
| 10:44 | jnettlet | okay. |
| 10:46 | jnettlet | with systems shipping I think we really need to get some links updated and dev work consolidated to not get an onslaught of harassing questions on #irc and google+ |
| 10:46 | dv_ | yeah |
| 10:47 | hste_ | dv_: do u think its hard to get vlc and mplayer to work with vpu? |
| 10:47 | dv_ | atm, you dont need to rush things for me. we can work on our stuff in parallel |
| 10:47 | dv_ | eventually, once you figure out the performance problems and/or I get a chance to try out kernel 3.10, we can start integrating libphycontmem |
| 10:48 | dv_ | hste_: I think there has been work done already to add vpu support to ffmpeg/libav |
| 10:48 | dv_ | no idea if this is mainlined though |
| 10:50 | hste_ | I guess it will not get long time before people are spamming for distros and kitkat etc... :) |
| 11:00 | dv_ | yeah |
| 11:00 | dv_ | jas-hacks is taking care of ubuntu afaik |
| 11:01 | dv_ | and I wrote some patches for meta-fsl-arm-extra to support the carrier one. I guess the cubox-i wont require many modifications |
| 11:02 | dv_ | archlinux, dont know. I heard someone mentioning carrier one support, but i dont know more. |
| 11:38 | hste_ | Distros without gpu/vpu is no problem. They work out of the box as long as you put uboot and right kernel on them |
| 11:39 | hste_ | But then you 'll get a lot of questions on why isn't flash working etc |
| 11:40 | jnettlet | hste_, well with 3.10 you need to provide the device-tree blob as well |
| 11:41 | yawniek | is there a android 4+ image for the original cubox around? |
| 11:45 | jnettlet | yawniek, as far as I know there was never an Android image released for it. |
| 12:05 | MarcusVinter | yawniek, What do you want that for anyway? lol |
| 12:13 | _rmk_ | jnettlet: di you have those ion patches for recent kernels? |
| 12:13 | _rmk_ | s/di/do/ |
| 12:13 | jnettlet | _rmk_, did I forget to send you the link? |
| 12:13 | _rmk_ | I don't think you forgot... I forgot I'm not logging the channel so couldn't find it |
| 12:14 | jnettlet | https://dl.dropboxusercontent.com/u/736509/ion-patchset.tar.bz2 |
| 12:14 | jnettlet | the vmeta changes are still buried in my tree awaiting cleanup. |
| 12:20 | hste_ | _rmk_: http://server.vijge.net/static/cubox/irclog/ |
| 12:21 | _rmk_ | jnettlet: hmm, interesting comment in patch 12... |
| 12:21 | _rmk_ | The implicit contract here is that |
| 12:21 | _rmk_ | + memory comming from the heaps is ready for dma, ie if it has a |
| 12:21 | _rmk_ | + cached mapping that mapping has been invalidated |
| 12:21 | _rmk_ | ... is false. |
| 12:24 | _rmk_ | jnettlet: have you run this with DMA_API_DEBUG enabled? |
| 12:24 | jnettlet | _rmk_, yes, but you also have to remember I only use this interface for CMA allocated DMA |
| 12:24 | jnettlet | I have not used it for scatter gather allocations |
| 12:25 | _rmk_ | hmm |
| 12:25 | _rmk_ | __dma_page_cpu_to_dev |
| 12:26 | _rmk_ | hate |
| 12:26 | _rmk_ | hate |
| 12:26 | _rmk_ | hate |
| 12:26 | _rmk_ | hate |
| 12:26 | _rmk_ | hate |
| 12:26 | _rmk_ | that's going to be a blocker for it to be merged |
| 12:26 | jnettlet | _rmk_, that is fixed in a later patch converting it to arm_dma_ops.sync_single_for_device |
| 12:26 | _rmk_ | that's also an implementation specific detail of our DMA support code on ARM which *NOTHING* apart from ARM arch code supporting the DMA API is to use. |
| 12:27 | _rmk_ | directly accessing arm_dma_ops is more or less the same problem though |
| 12:30 | jnettlet | is there any difference between arm_dma_ops.sync_single_for_device and just dma_sync_single_for_device? |
| 12:31 | jnettlet | the comment /* this is only being used to flush the page for dma, |
| 12:31 | jnettlet | this api is not really suitable for calling from a driver |
| 12:31 | jnettlet | but no better way to flush a page for dma exist at this time */ |
| 12:32 | _rmk_ | well, if you call dma_sync_single_for_device() without a preceding dma_map_*() call, the DMA API debugging will not be happy |
| 12:34 | _rmk_ | as for differences between dma_sync_single_for_device and arm_dma_ops.sync_single_for_device, I don't know without looking at the code since that's changed a lot since I last looked at it |
| 12:35 | _rmk | 12:35 * _rmk_ kicks off a grep for __dma_page_.*_to_ for drivers/ ... just in case there's any of this sillyness in the kernel already |
| 12:35 | jnettlet | Here is actually the roundtable discussion that just happened about ion and dmabuf a couple of months ago. http://www.youtube.com/watch?v=8okc75j5cKk |
| 12:38 | _rmk_ | ok, __dma_page_cpu_to_dev and __dma_page_dev_to_cpu are both static in mainline kernels, so can't be used by drivers :) |
| 12:43 | _rmk_ | ooh, patch 0036 is corrupt - both git and gnu patch complain about it |
| 12:45 | jnettlet | really. okay let me try and dump that from my tree again |
| 12:46 | _rmk_ | the patch header claims drivers/gpu/ion/ion_page_pool.c has 163 lines, it actually has 162 lines |
| 12:47 | _rmk_ | looks like your git may be buggy :p |
| 12:47 | jnettlet | hurray |
| 12:49 | jnettlet | _rmk_, https://dl.dropboxusercontent.com/u/736509/0001-gpu-ion-Add-ion_page_pool.patch |
| 12:51 | _rmk_ | ah, an extra newline :) |
| 12:51 | jnettlet | ah I thought I cleaned that. |
| 12:53 | jnettlet | oh I pulled that from my other repo. Must be something wrong with my "cleaned" repo. |
| 12:53 | _rmk_ | your last patch has two whitespace errors too :p |
| 12:53 | _rmk_ | .git/rebase-apply/patch:345: space before tab in indent. } |
| 12:53 | _rmk_ | .git/rebase-apply/patch:424: trailing whitespace. |
| 12:53 | _rmk_ | #define ION_FLAG_INSECURE 16 /* Use this flag to designate that |
| 12:57 | jnettlet | grrr. okay |
| 12:58 | _rmk_ | also, if you don't mind... |
| 12:59 | _rmk_ | - static on the insecure api probe/remove functions |
| 12:59 | _rmk_ | - does idev need to be a global? looks like it can be local to the probe function |
| 12:59 | _rmk_ | - insecure_uapi_user_mapper doesn't appear to be used |
| 13:00 | _rmk_ | - num_heaps and heaps - static, or maybe have a small struct to pass this info in addition to the ion_device between the probe/remove functions |
| 13:01 | _rmk_ | and I see you've fallen into the classic IS_ERR_OR_NULL() trap |
| 13:01 | _rmk_ | heaps[i] = ion_heap_create(heap_data); |
| 13:01 | _rmk_ | if (IS_ERR_OR_NULL(heaps[i])) { |
| 13:01 | _rmk_ | err = PTR_ERR(heaps[i]); |
| 13:01 | _rmk_ | goto err; |
| 13:01 | _rmk_ | } |
| 13:01 | _rmk_ | ... |
| 13:01 | _rmk_ | err: |
| 13:01 | _rmk_ | ... |
| 13:01 | _rmk_ | return err; |
| 13:02 | _rmk_ | so when heaps[i] = NULL, err is zero, and you return... success! |
| 13:02 | _rmk_ | IS_ERR_OR_NULL() is harmful for this very reason and shouldn't be used |
| 13:03 | _rmk_ | I have a patch around which caused IS_ERR_OR_NULL to issue deprecated warnings on build |
| 13:03 | jnettlet | that is more me being lazy than anything. This is all a google code that I built upon |
| 13:03 | _rmk_ | but its far too noisy - the general concensus is that macro does more harm than good :( |
| 13:11 | _rmk_ | also looks like your commits are missing your signed-off-by :) |
| 13:12 | jnettlet | well I didn't plan on this going upstream. |
| 13:12 | jnettlet | actually I know it won't as upstream will never accept passing physical addresses out to userspace |
| 13:21 | _rmk_ | yes, that statement above about "the implicit contract" is definitely false |
| 13:21 | _rmk_ | if you use the system heap allocator |
| 13:22 | dv_ | jnettlet: is it possible to factor out the physical address interfaces into a kernel module somehow? |
| 13:23 | _rmk_ | also, this is all going to fall apart with LPAE, because DMA addresses != physical addresses there, especially with some of those which place all their RAM above 4G phys |
| 13:23 | dv_ | a kernel with most of the armada&imx stuff mainlined and the problematic bits left as extra kernel modules sounds interesting to me |
| 13:23 | _rmk_ | dv: the insecure API is already separate :) |
| 13:24 | jnettlet | _rmk_, won't CMA take care of that for me theoretically? |
| 13:25 | _rmk_ | argh, no, this is crap |
| 13:25 | _rmk_ | info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle), 0); |
| 13:25 | _rmk_ | if (ion_cma_get_sgtable |
| 13:25 | _rmk_ | (dev, info->table, info->cpu_addr, info->handle, len)) |
| 13:25 | _rmk_ | and inside there... |
| 13:25 | _rmk_ | struct page *page = virt_to_page(cpu_addr); |
| 13:26 | _rmk_ | dma_alloc_coherent() doesn't _always_ return something that virt_to_page() will accept |
| 13:26 | _rmk | 13:26 * _rmk_ sighs... I'm thinking at this point BMM is soo much better :) |
| 13:26 | _rmk_ | or at least my BMM. |
| 13:32 | _rmk_ | what that also means is that we get the address to DMA effectively via: page_to_phys(virt_to_page(dma_alloc_coherent())) which is... well, things that I wouldn't touch with a bargepole would be more desirable than that |
| 13:32 | _rmk_ | what that also means is that we get the address to DMA effectively via: page_to_phys(virt_to_page(dma_alloc_coherent())) which is... well, things that I wouldn't touch with a bargepole would be more desirable than that |
| 13:39 | dv_ | ugh |
| 13:39 | dv_ | table after table |
| 13:43 | yawniek | MarcusVinter | yawniek, What do you want that for anyway? lol < trying out an air we have app. works nicely on the wandboard/android |
| 13:48 | jnettlet | _rmk_, where does the page_to_phys come into play? |
| 13:49 | jnettlet | ion_cma_heap passes back the physical address stored when dma_alloc_coherent is called and stored in info->handle. |
| 13:52 | jnettlet | if you are referring to using the dmabuf descriptor, I am quite sure that is what more PRIME implementations are using as well. |
| 14:17 | _rmk_ | jnettlet: see sg_phys() |
| 14:17 | _rmk_ | and... |
| 14:17 | _rmk_ | for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) |
| 14:17 | _rmk_ | sg_dma_address(sg) = sg_phys(sg); |
| 14:19 | _rmk_ | at the moment, ION offends me, and I'm not yet sure whether it can be reorganised such that it offends me less |
| 14:19 | _rmk_ | I'll dig deeper this afternoon and see whether some of this stuff can be fixed |
| 14:34 | purch_ | any updates to this recipe http://imx.solid-run.com/wiki/index.php?title=Building_Carrier-One_U-boot_and_Kernel |
| 15:01 | _rmk_ | jnettlet: suffering with problems due to the storm? |
| 15:05 | jnettlet | _rmk_, nope suffering with problems due to kernel upgrade :-) |
| 15:06 | jnettlet | The Chrome OS kernel just released a new set of patches supporting my logitech T651 trackpad that I wanted to merge and run. |
| 15:07 | jnettlet | it is running much better now, and since I was rebooting I did things like upgrade my nvidia drivers and various other things. The nvidia drivers should fix a problem I was having with my displayport losing sync |
| 15:08 | jnettlet | it looks like the worst of the storm has passed over now. |
| 15:14 | jnettlet | _rmk_, are you still interested in that last patch or are you good for now? |
| 15:19 | _rmk_ | jnettlet: well, I think I have two choices here - either ignore ION and favour my BMM implementation, or try and fix ION |
| 15:19 | _rmk_ | or a third choice: rewrite the thing from scratch |
| 15:20 | jnettlet | _rmk_, favouring your BMM implementation is fair enough. I can just add BMM support into libphycontmem and then we can keep transparency with userspace. |
| 15:24 | jnettlet | actually backing BMM with CMA would work just as well for me. My only preferences to ION was they (Linaro/Google) were working on mainstream inclusion, it allowed custom IOCTL's so we could provide the support to pass physical addresses to userspace., and I could back it with CMA so memory wasn't reserved just to playback videos all the time. |
| 15:26 | _rmk_ | okay, let me see about updating it a bit more so we can have DT and CMA support for BMM |
| 15:28 | jnettlet | I think I can just link to libbmm and expose everything through libphycontmem. I would like to keep that for userspace to use as the abstraction works for ION/PMEM and is based on libbmm's API. |
| 15:29 | jnettlet | then if ION does get merged at some point it will be less work. |
| 15:29 | _rmk_ | note that my libbmm has rbtree caching in it |
| 15:29 | jnettlet | is that exposed in the api? |
| 15:30 | _rmk_ | no - its used internally for the v <-> p translations |
| 15:30 | _rmk_ | old libbmm used to always call into the kernel for that, which is immensely wasteful |
| 15:31 | jnettlet | okay that should continue to work seamlessly. |
| 15:37 | jnettlet | hmmm....actually I should probably take that out of the libbmm implementation and move that to libphycontmem so that the library always uses that. |
| 18:41 | jnettlet | hste_, how are you surviving the storm? They are shutting down public services in Denmark now. |
| 18:41 | jnettlet | atleast here in Jutland |
| 18:44 | hste | jnettlet: its just starting here in Drammen, but on the westcoast they are closing down most things. and its flooding at the coastline |
| 19:40 | hste | aacdec missing in gst-fsl-plugin https://lists.yoctoproject.org/pipermail/meta-freescale/2013-December/005878.html |
| 20:41 | _rmk_ | hmm, wonder where jnettlet went |
| 20:42 | _rmk_ | btw, I've ended up adding umode g to my nick here |