| 11:19 | Catastrophe | Hi |
| 11:52 | _rmk | 11:52 * _rmk_ notes someone privmsg'd me... and typed a message longer than the irc limit (so it got chopped) :p |
| 11:55 | _rmk_ | the bit which got chopped was "I don't check IR" maybe the next character was C? |
| 11:59 | jnettle | 11:59 * jnettlet is unable to string together thoughts that long, so doubts it was him. |
| 12:03 | _rmk_ | jnettlet: I think I have unbind and rebind of imx-drm working... provided CMA plays ball. |
| 12:05 | _rmk_ | and all the driver gets initialised in the right order in the right place where DRM expects it to be. |
| 12:05 | jnettlet | _rmk_, great! a couple of days ago I shifted gears on how to "share" your vivante acceleration backend among the drivers. |
| 12:06 | _rmk_ | it still has a down-side: unbinding the component drivers are still problematical and will lead to crashes... but if you unbind the main device first, it tears everything down as best DRM can do at the moment. |
| 12:06 | _rmk_ | then you can unbind the component drivers safely |
| 12:06 | jnettlet | did you fix this at the drm level, or the imx driver level? |
| 12:07 | _rmk_ | it's a separate stub on the side of imx-drm which isn't imx-drm specific - though it is drm specific and can only cope (at the moment) with one instance of this sillyness |
| 12:08 | _rmk_ | it basically collects a set of struct devices in a sorted order, along with a couple of bind/unbind ops, and calls the bind on each device at the appropriate moment |
| 12:09 | _rmk_ | I've been trying to work out how to commit this code, because it's quite a radical change to imx-drm |
| 12:09 | _rmk_ | the changes to existing files alone looks like this: |
| 12:09 | _rmk_ | 10 files changed, 324 insertions(+), 686 deletions(-) |
| 12:09 | _rmk_ | the biggest one being: |
| 12:11 | jnettlet | If it is sane and doesn't look like it will break anything then GregKH may just take it as one patch. I have seen many monstrous patches like that during the evolution of KMS |
| 12:13 | jnettlet | _rmk_, any chance you have libdrm-armada changes hanging out that aren't pushed to the repo? |
| 12:13 | _rmk_ | libdrm-armada should be up to date |
| 12:14 | jnettlet | Is it the new kernel patches that are different. I am looking for DRM_IOCTL_VIVANTE_GEM_CREATE_PHYS |
| 12:15 | jnettlet | that should be ARMADA |
| 12:15 | _rmk_ | ah, no it isn't |
| 12:19 | jnettlet | So my thought is to turn Vivante acceleration into an Xorg extension. It doesn't really fit the PRIME model because there are no ctrcs or outputs. So we could create dummy ones to get around this, but even then you are stuck with needing to export DRM_PRIME=1 and in a lot of cases use a compositing manager. |
| 12:20 | jnettlet | As an extension we can have various KMS/FBDEV ddx drivers load the extension and then initialize a screen for the acceleration architecture, passing in a wait_for_vblank function and export buffers for the front and back screen buffers. |
| 12:22 | _rmk_ | you shouldn't need crtcs etc in drm. |
| 12:22 | _rmk_ | it has the idea of rendering only drivers - but as there's almost none written like that yet, there may be bugs :) |
| 12:22 | jnettlet | you don't for drm which is what I am doing. Basically just creating a dumb vivante driver that does MM for now. |
| 12:22 | _rmk_ | ok, libdrm-armada updated |
| 12:23 | jnettlet | great |
| 12:23 | jnettlet | But xrandr which manages the prime interfaces needs crtcs and outputs |
| 12:24 | _rmk_ | I've started a while back pulling the generic kms bits of my armada xorg driver out so there's a separation of that stuff... I did it for the connectors but crtcs needs a little more work |
| 12:28 | _rmk_ | also xf86-video-armada updated |
| 12:29 | _rmk_ | I guess as the driver is going in to the kernel, I should sort out the damn version numbers and tag it as an official release |
| 12:31 | _rmk_ | however, I'll wait until it actually hits mainline before doing that. |
| 12:32 | _rmk_ | I should've kept libdrm-armada as version 0.0.0 :) |
| 12:36 | _rmk_ | on the carrier-1, once I've got imx-drm sorted out, I guess the next thing is to get hdmi audio working |
| 12:36 | _rmk_ | given the way the hardware is setup, that means integrating imx-hdmi with asoc |
| 12:37 | jnettlet | of course :-) |
| 12:37 | _rmk_ | or using mfd |
| 12:37 | jnettlet | but you are the asoc master now I assume. |
| 12:37 | jnettlet | the 3.10 fsl kernel uses mfd I believe. althought it doesn't work. |
| 12:37 | _rmk_ | heh |
| 12:38 | jnettlet | but I haven't put any time into actually looking at it. |
| 12:38 | _rmk_ | imx-hdmi 120000.hdmi: drm: adding component (ops hdmi_ops) |
| 12:38 | _rmk_ | imx-ipuv3 2400000.ipu: IPUv3H probed |
| 12:38 | _rmk_ | imx-ipuv3-crtc imx-ipuv3-crtc.0: drm: adding component (ops ipu_crtc_ops) |
| 12:38 | _rmk_ | imx-ipuv3-crtc imx-ipuv3-crtc.1: drm: adding component (ops ipu_crtc_ops) |
| 12:39 | _rmk_ | ^^^ that's the component drivers finding their devices |
| 12:39 | _rmk_ | then the real imx-drm device gets probed... |
| 12:39 | _rmk_ | [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). |
| 12:39 | _rmk_ | [drm] No driver support for vblank timestamp query. |
| 12:39 | _rmk_ | imx-drm imx-drm: binding imx-ipuv3-crtc.0 (ops ipu_crtc_ops) |
| 12:39 | _rmk_ | imx-drm imx-drm: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops) |
| 12:39 | _rmk_ | imx-drm imx-drm: binding imx-ipuv3-crtc.1 (ops ipu_crtc_ops) |
| 12:39 | _rmk_ | imx-drm imx-drm: bound imx-ipuv3-crtc.1 (ops ipu_crtc_ops) |
| 12:39 | _rmk_ | imx-drm imx-drm: binding 120000.hdmi (ops hdmi_ops) |
| 12:39 | _rmk_ | imx-hdmi 120000.hdmi: Detected HDMI controller 0x13:0x1a:0xa0:0xc1 |
| 12:39 | _rmk_ | imx-drm imx-drm: bound 120000.hdmi (ops hdmi_ops) |
| 12:39 | _rmk_ | Console: switching to colour frame buffer device 240x67 |
| 12:39 | _rmk_ | imx-drm imx-drm: fb0: frame buffer device |
| 12:40 | _rmk_ | imx-drm imx-drm: registered panic notifier |
| 12:40 | _rmk_ | [drm] Initialized imx-drm 1.0.0 20120507 on minor 0 |
| 12:40 | jnettlet | wow, it actually looks sane |
| 12:40 | _rmk_ | I'm going to drop some of those kernel messages down to debug level... |
| 12:41 | _rmk_ | but yes, all the component drivers probe/remove functions are basically just this: |
| 12:41 | jnettlet | good idea. the bound and binding are a bit much |
| 12:41 | _rmk_ | +static int imx_pd_probe(struct platform_device *pdev) |
| 12:41 | _rmk_ | +{ |
| 12:41 | _rmk_ | + return component_add(&imx_pd_ops, &pdev->dev); |
| 12:41 | _rmk_ | +} |
| 12:41 | _rmk_ | +static int imx_pd_remove(struct platform_device *pdev) |
| 12:41 | _rmk_ | +{ |
| 12:41 | _rmk_ | + component_del(&imx_pd_ops, &pdev->dev); |
| 12:41 | _rmk_ | return 0; |
| 12:41 | _rmk_ | } |
| 12:43 | jnettlet | _rmk_, has your C1 been stable since you updated u-boot? |
| 12:43 | _rmk_ | the bind/unbind ops get called with the drm_device pointer that they're being bound to, so there's no need for them to deal with imx-drm-core for initialising the encoder/connector stuff |
| 12:44 | _rmk_ | jnettlet: it seems fine, but then it seemed fine before |
| 12:45 | jnettlet | so imx-drm-core is parsing the device-tree and then probing components based on what it finds? |
| 12:46 | jnettlet | trying to get a mental map of the flow |
| 12:48 | _rmk_ | its still basically the same as it was at the moment. |
| 12:49 | _rmk_ | the difference is that we bundle up all the drm driver init and tear down to the correct place |
| 12:49 | _rmk_ | its not yet bullet proof |
| 12:49 | jnettlet | ah okay that helps. |
| 12:50 | _rmk_ | but it's better than what was there before, and as stuff is grouped up, it can be properly torn down appropriately |
| 12:50 | _rmk_ | it also means that the fbhelper late initcall is gone too, which is the cause of much of the problems |
| 12:50 | _rmk_ | imx-fbdev.c almost doesn't exist (except to provide a module command option) |
| 12:51 | _rmk_ | I might kill that file off completely today |
| 12:53 | dv | 12:53 * dv_ just discovered inside imx-vpu that the weird fixed buffer pool logic is apparently implemented in the VPU itself, not just in the library |
| 12:53 | dv_ | which makes me a sad panda |
| 12:54 | dv_ | also, the imx-vpu library directly writes to some registers. that does not sound like something that should be done in userspace. |
| 12:54 | jnettlet | well that is what vmeta does as well |
| 12:55 | jnettlet | we can thank Android for that bit of wonderful. |
| 12:56 | dv_ | yeah, but at least, vmeta does not expect you to write a list of allocated DMA buffers to a register |
| 12:56 | dv_ | my hope is that this can be done more than once |
| 12:56 | dv_ | otherwise the fixed allocation at startup is there to stay |
| 12:58 | dv_ | gstreamer h264 vpu encoder element works now btw. and indeed the VPU only produces baseline h264 |
| 12:58 | jnettlet | just looking at the kernel side of that driver. It looks like we should be able to switch it to use CMA so it doesn't waste memory when it isn't being used. |
| 12:59 | dv_ | yeah that part should be doable |
| 12:59 | dv_ | all the VPU needs is a physically contiguous memory block |
| 12:59 | dv_ | not something special |
| 13:00 | jnettlet | We will just need to check if the userspace calls, VPU_IOC_IRAM_SETTING before doing any operations. If that is the case we will have to figure out what it is trying to figure out and fake the driver |
| 13:01 | dv_ | hmm |
| 13:01 | dv_ | CMA gives you dmabuf FDs, right? not just a pair of physical&virtual addresses ? |
| 13:01 | jnettlet | It would be nice if all these interfaces could do a handshake like, client->I want X amount of contig memory, server -> not happening you can have X, client adjusts settings, or fails. |
| 13:02 | jnettlet | CMA is just the backing. You can just use dma_alloc_coherent, or dma_alloc_writecombine. |
| 13:02 | dv_ | using one allocator certainly is cleaner than what I am currently doing (VPU encoder, decoder, IPU alloc) |
| 13:03 | dv_ | oh writecombine? sweet! that is what is missing in the VPU allocators |
| 13:03 | dv_ | leading to bizarre slowdowns if an application draws directly into a DMA buffer, and the write activity is not sequential like a memcpy |
| 13:03 | jnettlet | dma_alloc_writecombine will allocate from the CMA pool allocated at boot, specified by the kernel config or kernel commandline |
| 13:04 | dv_ | and applications can then chip away from that pool |
| 13:05 | jnettlet | devices can alloc as possible, with the win being that if memory is low and nobody is using the pool then the kernel can dip into it as well. |
| 13:06 | jnettlet | Then if memory is requested it will compress/dump pages to clear it back out for device allocations |
| 13:06 | dv_ | can applications specify details about the intended usage? something like writecombine/cached/uncached, readonly/readwrite/writeonly .. ? |
| 13:07 | jnettlet | assuming you have setup your application to do that via IOCTL's to a kernel driver. This isn't exposed to userspace. For direct userspace interaction you need dmabuf/ion/pmem |
| 13:08 | jnettlet | any modern implementation is going to be either dmabuf for linuxy things and ion for androidy things |
| 13:08 | dv_ | yes |
| 13:08 | jnettlet | but I believe there is a dmabuf module for ion now. |
| 13:09 | dv_ | unfortunately, the vpu stuff expects virtual and physical addresses, so I'd need something to get these out of the dmabuf FDs |
| 13:09 | jnettlet | ion definitely has options to specify the type of memory you want, and fetches it accordingly |
| 13:10 | jnettlet | dv_, dmabuf won't let you do that and the kernel maintainers are pretty strict about it. I would use ION and then use a custom IOCTL that passes that back, like I did for vmeta |
| 13:10 | jnettlet | we can probably just rename my patch from being mmp specific to something more generic. |
| 13:11 | jnettle | 13:11 * jnettlet wonders if you should just use the libphycontmem which we can then back with either ION/PMEM or BMM |
| 13:12 | jnettlet | not that we want to support companies continually requiring physical addresses in userspace, but.... |
| 13:12 | _rmk_ | that's the problem |
| 13:13 | jnettlet | either nonfunctional hardware, or continued bad practices |
| 13:13 | dv_ | well I guess it makes it easier for them to keep things OS independent |
| 13:14 | dv_ | they can argue that stuff like this is then shielded from lower level userspace runtimes |
| 13:14 | dv_ | s/from/by/ |
| 13:14 | dv_ | so high-level applications cannot get at it, and have to use the provided APIs |
| 13:15 | _rmk_ | still doesn't stop you bypassing all the system security though |
| 13:16 | dv_ | probably, yeah. these calls arent ioctls. these are register writes. |
| 13:16 | _rmk_ | quite, so imagine this: an attacker works out you can use a userspace mapped device to copy data around. |
| 13:17 | _rmk_ | they hack into an application, and then read /proc/self/maps to work out where in userspace the device is mapped |
| 13:17 | dv_ | although, to be able to use them, you need to get the register base address by mmap'ing /dev/mxcvpu |
| 13:17 | _rmk_ | they then poke directly at the device registers after calling a few API calls to place the hardware in the state they need |
| 13:17 | dv_ | heh, true |
| 13:18 | _rmk_ | dv: if its already mapped, you can find that address by simply reading /proc/self/maps and looking for /dev/mxcvpu to pick out the correct mapping |
| 13:18 | dv_ | the ugly solution is to hack your system to not provide anything from /proc to non-root processes for example |
| 13:19 | dv_ | but then you are starting to break compatibility with a lot of things |
| 13:19 | dv_ | which is what android does |
| 13:19 | jnettlet | _rmk_, wouldn't this partially be helped with the work you were doing marking sections of memory as "non-executable" |
| 13:19 | _rmk_ | information hiding != security :) |
| 13:20 | _rmk_ | jnettlet: that just makes it harder to exploit applications/kernel. |
| 13:20 | jnettlet | I said partially helped by :-) |
| 13:20 | dv_ | so, the proper solution (= use dmabuf) is the inherently secure one, but is less appealing to hw vendors |
| 13:20 | jnettlet | it is linux specific |
| 13:21 | jnettlet | and has been a moving target for almost 2 years now |
| 13:21 | dv_ | well, replace dmabuf with whatever OS specific equivalent there is |
| 13:21 | _rmk_ | dmabuf is inherently secure from userspace because its about not exposing hardware addresses into userland |
| 13:21 | dv_ | the hack solution is to just expose all that stuff to userspace and let the platform makers worry about security |
| 13:22 | _rmk_ | s/worry about security/have no security/ |
| 13:22 | dv_ | ok, "worry about security" on paper |
| 13:22 | dv_ | who knows, maybe the NSA does not want you to use dmabuf :P |
| 13:23 | _rmk_ | I'm sure they have easier and many other ways to get into devices |
| 13:24 | _rmk_ | anyway, I gotta finish off omap-dma.c this weekend, so c1/cubox stuff is going to have to wait a while. |
| 13:24 | jnettlet | and they will always have that, as the mobile radios all have to be black boxes to pass certification |
| 13:25 | jnettle | 13:25 * jnettlet has to start his Dakdoritang for dinner and then get back to the vivante-accel extension |
| 16:06 | shesselba | _rmk_: when I get "BUG: not creating mapping for ..." while booting an ARMv7 kernel, where should I look at for debugging? |
| 16:08 | _rmk_ | shesselba: no idea; but what I can tell you is that's produced by something trying to setup a kernel mapping in _userspace_ |
| 16:09 | _rmk_ | so something is calling create_mapping() with a virtual address in userspace |
| 16:09 | _rmk_ | you could add a WARN_ON(1) just after that in create_mapping() to get a backtrace |
| 16:10 | shesselba | It's from mapping MT_MEMORY.. and I suspect that my CONFIG_DEBUG_UART_VIRT may be wrong |
| 16:10 | _rmk_ | what value do you have for that? |
| 16:11 | _rmk_ | also, the message does give you the phys and virt addresses |
| 16:11 | shesselba | CONFIG_DEBUG_UART_PHY = CONFIG_DEBUG_UART_VIRT = 0xf7fc9000 |
| 16:11 | _rmk_ | that's unlikely to be it |
| 16:12 | shesselba | BUG: not creating mapping for 0x00000000 at 0xb8000000 in user region |
| 16:13 | _rmk_ | you haven't got the kernel at some weirdo offset in RAM? |
| 16:13 | _rmk_ | compared to the RAM stuff you're passing via DT? |
| 16:13 | shesselba | well, let me double check.. |
| 16:14 | _rmk_ | remember, the decompressor works out the base of physical RAM by taking the address that it's running at and masking it with 0xf8000000 |
| 16:15 | shesselba | ok, I have AUTO_ZRELADDR=y and I am booting dtb appended zImage |
| 16:16 | shesselba | loading it from 0x08000000 hangs |
| 16:16 | _rmk_ | ok, and what is your description of memory in DT |
| 16:17 | shesselba | reg = <0x00000000 0x20000000>; |
| 16:17 | shesselba | 512M |
| 16:17 | _rmk_ | right, |
| 16:17 | _rmk_ | so if you load it at 0x08000000, the decompressor then believes that physical memory starts at 0x08000000. |
| 16:17 | _rmk_ | so it moves the compressed data out of the way, and decompresses the kernel to 0x08008000 |
| 16:18 | _rmk_ | when the kernel gets called... at 0x08008000, it calculates PHYS_OFFSET as 0x08000000 with PAGE_OFFSET as 0xc0000000 |
| 16:18 | _rmk_ | it then parses the DT stuff, which says there's memory at 0x00000000. |
| 16:18 | jnettle | 16:18 * jnettlet is content with #cubox we have such a nice productive ARM community here. |
| 16:18 | _rmk_ | phys_to_virt(0) then gives 0xb8000000 |
| 16:18 | _rmk_ | and things rightly explode. |
| 16:19 | _rmk_ | the answer is: always load the kernel within 128MB of the start of memory. |
| 16:19 | _rmk_ | OR don't use any of the single zImage stuff |
| 16:19 | jnettlet | shesselba, is that on the C1 or other hardware? |
| 16:20 | shesselba | chromecast |
| 16:20 | jnettlet | ah. can't help you. |
| 16:20 | jnettlet | depending on the age of the u-boot it may support loading the .dtb right from nand |
| 16:21 | shesselba | jnettlet: that's the trick. prepare a usb image that will load a development kernel right from a partition after it |
| 16:21 | _rmk_ | without AUTO_ZRELADDR and ARM_PATCH_PHYS_VIRT, we know where physical memory starts, as those are provided on a per-platform basis by mach/memory.h and mach-*/Makefile.boot |
| 16:21 | _rmk_ | with single zImage, you can't do that - you're forced into guessing where physical memory starts. |
| 16:22 | _rmk_ | ... because we can't parse the DT blob from assembly code |
| 16:23 | _rmk_ | the mask of 0xf8000000 was chosen fairly arbitarily, and it's a balance between how many physical bits are really used on platforms to define where physical memory starts, and what offsets into physical memory people are allowed to use. |
| 16:23 | _rmk_ | the more one bits, the smaller the offsets and the more machines we can include in single zImage... the less bits, the opposite is true. |
| 16:24 | _rmk_ | quite simply, it's one of the compromises that we're having to pay to satisfy those who want to have a single zImage |
| 16:24 | shesselba | dammit, I had it booting.. now I broke it |
| 16:26 | _rmk_ | I know the shmobile and xilinx people are unhappy with this - I spent quite some time showing the xilinx guy at the ARM summit why this is such a problem, I ended up having to draw maps of physical memory about it, and how there's virtually nothing we can do to fix this with single zImage |
| 16:27 | _rmk_ | my answer is very simple: "if this causes you a problem, you can't be part of single zImage" |
| 16:28 | shesselba | _rmk_: I have the same kernel booting just fine on Armada 1500.. |
| 16:28 | shesselba | I messed it up somewhere |
| 16:28 | _rmk_ | you probably aren't loading it outside of the first 128MB of memory |
| 16:29 | _rmk_ | since all the mach/memory.h and mach-*/Makefile.boot files have been deleted, its no longer possible to easily grep for the start of physical memory across all platforms anymore |
| 16:29 | shesselba | _rmk_: argh, load the zImage _outside_ of 128M? |
| 16:29 | _rmk_ | no, load it inside the first 128M of RAM |
| 16:29 | _rmk_ | and for anything that's been merged since single zImage, even I don't have any idea where physical memory starts on those platforms |
| 16:30 | _rmk_ | so it's extremely dangerous to touch that 0xf8000000 constant. |
| 16:43 | _rmk_ | shesselba: why are you loading it above 128MB in the first place? |
| 16:44 | shesselba | _rmk_: because I had it running, then it failed.. so I tried different mem locations, and ended up with one above 128M where it at least booted |
| 16:44 | shesselba | I am rebuilding without DEBUG_LL |
| 16:44 | _rmk_ | shesselba: I'm just wondering whether we should truncate the start of memory resources if we hit this situation |
| 16:45 | shesselba | _rmk_: let's just start with fixing my brain for now :P |
| 16:46 | shesselba | erm.. |
| 16:48 | _rmk_ | if you want to try a solution to the problem I described above... http://www.home.arm.linux.org.uk/~rmk/misc/truncate-start-phys-mem.diff |
| 16:58 | sam_nazarko | hello everyone |
| 17:19 | shesselba | _rmk_: marvell's chromecast kernel sets CONFIG_PHYS_OFFSET=0x01000000 |
| 17:21 | shesselba | could be, that something is messing with low mem |
| 17:21 | shesselba | but I can write it and read it again |
| 18:25 | shesselba | _rmk_: using your patch above (adapted to v3.12-rc4) booting works from zImage loaded at 0x12000000 |
| 18:25 | shesselba | leaves 256M usable memory |
| 18:25 | shesselba | anyway, I rather check if MC has some weird offsets set |
| 18:26 | _rmk_ | ok, thanks. I've also sent that patch to Michal Simek of Xilinx |
| 18:56 | shesselba | _rmk_: what is a sane value for CONFIG_PAGE_OFFSET? |
| 18:56 | _rmk_ | 0xc0000000 |
| 18:57 | shesselba | hmm |