| 00:28 | _rmk_ | dv: I got to the bottom of it |
| 00:44 | _rmk_ | jnettlet: is the usual place updated with a uboot binary? |
| 05:31 | jnettlet | _rmk_, nope forgot to do that. Will push it now. |
| 08:17 | jnettle | 08:17 * jnettlet has added zImage support to the boot scripts as well. There is really no reason to use uImage's on this platform. |
| 08:17 | otavio | jnettlet: :-) |
| 11:35 | _rmk_ | ok, I've pushed out the mainline cubox-i kernel stuff to git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git unstable/cubox-i |
| 11:36 | _rmk_ | always pull into a tree already up to date with v3.12-rc4 to avoid pulling the entire tree from that machine please |
| 11:36 | _rmk_ | iow, don't clone from it. |
| 11:38 | _rmk_ | it should be treated as unstable as its not finalised work (certainly the bits about configuring DAT3 on the SDHCs needs reworking, and the HDMI output support is going to be reworked by Fabio |
| 11:39 | _rmk_ | but... at least this gives people something to play with on a modern kernel |
| 11:42 | _rmk_ | robclark: I see in my latest nightly build that .page_flip in drm_crtc_funcs has changed its type at some point |
| 11:42 | dv_ | _rmk_: yay! |
| 11:42 | cbxbiker61 | it's looking like my 5.25 volt usb power supply has fixed up the usb timeout issues on r-pi |
| 11:43 | dv_ | jnettlet: because uboot 2013 can load zImages? |
| 11:44 | dv_ | _rmk_: so this kernel of yours also includes your work on the display interface portion of the IPU ? |
| 11:45 | _rmk_ | dv: it gets HDMI output working with imx-drm |
| 11:46 | _rmk | 11:46 * _rmk_ sighs... why was this "flags" argument added to the page flip handler... i915 doesn't make any use of it (but does pass it around and then does nothing with it) |
| 11:47 | _rmk_ | from what I can see that's the same on every DRM driver: everyone ignores that new flags argument |
| 11:49 | _rmk_ | dv: ah, and thanks for reminding me about that bit :) |
| 11:49 | _rmk_ | no it doesn't because I haven't got an answer on exactly what's wrong |
| 11:49 | _rmk_ | I'll put a hack in to fix it though |
| 11:51 | _rmk_ | does now :) |
| 11:54 | _rmk_ | the next thing which needs sorting out is the audio stuff |
| 11:57 | dv_ | nice |
| 11:57 | _rmk_ | I suspect we're getting too close to Edinburgh for the imx folk to provide much help until afterwards |
| 11:57 | dv_ | too close to Edinburgh? |
| 11:58 | dv_ | ah is this where that conference will take place? |
| 11:58 | _rmk_ | yea, ARM meetup and kernel summit is next week |
| 11:58 | dv_ | okay |
| 11:58 | dv_ | I also have a wish list for them :) |
| 11:58 | _rmk_ | I'm flying up there on Monday afternoon |
| 11:59 | dv_ | have you seen the several DMA buffer allocation APIs? |
| 12:00 | dv_ | wish #1: all of this replaced by dmabuf |
| 12:00 | dv_ | (and the CMA) |
| 12:00 | cbxbiker61 | _rmk_, i just refreshed my tree and checked out unstable/cubox-i |
| 12:00 | cbxbiker61 | will give it a go |
| 12:01 | _rmk_ | dv: it looks like imx-drm doesn't yet support drm-prime (I should be able to fix that though) |
| 12:01 | _rmk_ | that's what drm calls the dmabuf import/export apis |
| 12:01 | _rmk_ | and yes, it does use CMA |
| 12:01 | _rmk_ | as jnettlet mentioned earlier, you will have to increase the CMA size |
| 12:02 | dv_ | as a kernel parameter? |
| 12:02 | _rmk_ | yes |
| 12:02 | dv_ | I'm curious how this is handled now, since I dont have to specify any alloc size for linux-imx |
| 12:03 | dv_ | perhaps there is a default in the kernel config for this modified kernel |
| 12:03 | dv_ | can the CMA size be expanded at runtime? |
| 12:04 | _rmk_ | coherent_pool=64M |
| 12:05 | dv_ | hm may not be enough for the VPU and h264 |
| 12:06 | _rmk_ | yea, and I thought the whole point of CMA was that you didn't have to configure such stuff |
| 12:06 | dv_ | thats why I ask about expansion |
| 12:06 | dv_ | otherwise it looks a lot like the vmeta thing |
| 12:06 | dv_ | with its vmalloc parameter |
| 12:07 | _rmk_ | I think it's different: the memory can be re-used by other stuff asking for "movable" pages |
| 12:07 | dv_ | oh thats much better, true |
| 12:08 | dv_ | ok I calculate ~50MB for 1080p playback and 17 frames backed up |
| 12:08 | dv_ | (which is what the VPU will require with h264 and picture reordering) |
| 12:10 | jnettlet | dv_, it can't be expanded at runtime, but if not used it will be re-allocated for other things and then reclaimed when needed. |
| 12:10 | jnettlet | so basically allocate big to begin with. |
| 12:12 | jnettlet | dv_, yes u-boot 2013 supports zImage you just need a different boot command. |
| 12:12 | jnettlet | Which reminds me. If anyone wants to go in and clean up my boot scripts I would really appreciate it. |
| 12:13 | jnettlet | I am just hacking things in for testing. |
| 12:18 | jnettlet | we should probably specify 128MB for the coherent_pool. That should be enough for 1080p output and multiple videos being decoded. |
| 12:22 | dv_ | yes |
| 12:23 | dv_ | also, I just noticed a detail in the IPU spec that I overlooked |
| 12:23 | dv_ | it says the deinterlacer can be used by only one video stream at the same time |
| 12:24 | dv_ | if this is global (that is, for all processes), then i do not see how this potential error could be caught |
| 12:27 | jnettlet | well that should be fixed, but luckily interlaced formats are dying quickly. |
| 12:27 | jnettle | 12:27 * jnettlet is happy that is one thing that has not hung around like an albatross. Unlike 44.1 audio |
| 12:28 | dv_ | true, the TV stations are experimenting with mixed formats |
| 12:28 | dv_ | so, slowly phasing it out |
| 12:28 | dv_ | and h265 wont have interlacing anymore. you can still mark the pictures as interlacing fields if you want, but thats it. |
| 12:28 | _rmk_ | afaik the freeview transmissions in the UK (mpeg2 for SD, h264 for HD) is all progressive |
| 12:30 | dv | 12:30 * dv_ never understood the appeal of interlacing |
| 12:31 | dv_ | the "increased" resolution is kinda offset by the unavoidable image quality reduction introduced by the deinterlacer |
| 12:31 | _rmk_ | for analog tv, it was sensible: it allowed an apparant increase in resolution without an increase in bandwidth. |
| 12:31 | cbxbiker61 | it was a bandwith reduction technique for analog tv |
| 12:32 | dv_ | true. I referred to the digital version though. |
| 12:32 | _rmk_ | old habbits die hard |
| 12:38 | jnettlet | have the new uboot changes behaved for everyone? |
| 12:38 | jnettlet | except _rmk_'s tv output. I haven't tackled that yet. |
| 12:39 | bencoh | dv_: there was no "deinterlacer" in analog tv (at least not in plain old customer TV set) |
| 12:40 | bencoh | btw, dvb-t transmissions in France are mostly interlaced |
| 12:40 | dv_ | there was one, actually. an implicit one, sort of: the phosphor mask |
| 12:41 | bencoh | "sortof", yeah |
| 12:41 | dv_ | it caused some form of color and intensity bleeding, washing out the mice teeth |
| 12:47 | _rmk_ | jnettlet: you mean the 52Hz as opposed to 60Hz? |
| 12:47 | jnettlet | _rmk_, yep |
| 14:06 | dv_ | jnettlet: updated my meta-fsl-arm-extra fork |
| 14:06 | dv_ | your uboot changes worked fine for me |
| 14:06 | jnettlet | great |
| 14:07 | _rmk_ | hmm. |
| 14:08 | _rmk_ | I think there's another bug in the imx-drm/hdmi stuff |
| 14:09 | _rmk_ | its not unblanking |
| 14:11 | robclark | _rmk_, the flags was from keithp for "async" (non vblank sync'd) page flip.. I would have assumed he at least implemented it in i915.. I didn't pay any attention since I don't think I can do a non vsync'd pageflip on any hw I have |
| 14:11 | _rmk_ | robclark: I went through i915, and although the flags are passed down to the 'queue flip' functions, none of them seem to use it |
| 14:12 | robclark | hmm.. maybe one of his patches got reverted or not applied? |
| 14:12 | _rmk_ | I've not investigated any further... it means I will have to change that patch you've already reviewed though... not a big problem, just a pain. |
| 14:14 | robclark | yeah, it looks like keithp originally had patches to enable it on sandybridge and ivybridge.. maybe those didn't get applied |
| 14:15 | robclark | no worries, it is just a trivial change, so no need to re-review |
| 14:15 | _rmk_ | looks like it was introduced by ed8d19756e80ec63003a93aa4d70406e6ba61522 and that's the only patch for it |
| 14:15 | robclark | https://lkml.org/lkml/2013/7/25/650 |
| 14:16 | _rmk_ | just slightly annoying because its a gratuitous change with no benefit but is disruptive to others |
| 14:16 | robclark | hmm, maybe the other changes where expected to be pulled in via i915 tree |
| 14:17 | robclark | hmm.. I suppose I could implement async pageflip in a couple drivers by iommu remapping |
| 14:17 | robclark | meh, I'll worry about that more when I have a gpu that can do thousands of fps |
| 14:19 | robclark | (although.. he really should have called the flag BENCHMARK_MODE :-P) |
| 14:23 | _rmk_ | jnettlet: err, CMA looks like its quite broken :( |
| 14:23 | _rmk_ | DMA: failed to allocate 65536 KiB pool for atomic coherent allocation |
| 14:23 | _rmk_ | and it's nice to see that everyone checks for failed allocations properly: |
| 14:23 | _rmk_ | Unable to handle kernel NULL pointer dereference at virtual address 00000028 |
| 14:23 | _rmk_ | PC is at usb_remove_hcd+0x10/0x150 |
| 14:24 | _rmk_ | LR is at host_stop+0x1c/0x3c |
| 14:24 | _rmk_ | (in the ci_hdrc stuff) |
| 14:31 | _rmk_ | damn, lost the oops off the scrollback |
| 14:34 | jnettlet | _rmk_, I wonder why that is failing. |
| 14:38 | jnettlet | _rmk_, you might want to enable CONFIG_CMA_DEBUG |
| 14:39 | _rmk_ | its failing because alloc_pages() is refusing to allocate such a large area |
| 14:40 | jnettlet | ;-\ |
| 14:40 | jnettlet | does it break after 32MB's? |
| 14:46 | _rmk_ | there is an upper limit on the order you can ask alloc_pages() for |
| 14:49 | jnettlet | yep. I am remembering now. There is a kernel config option to bump it. |
| 14:49 | _rmk_ | there is indeed but this should not be necessary |
| 14:49 | jnettlet | CONFIG_CMA_SIZE_MBYTES= |
| 14:56 | jnettlet | _rmk_, well the defaults are just too conservative for what CMA is generally used for. |
| 14:57 | _rmk_ | hmm, wonder where that is |
| 14:57 | _rmk_ | its not showing up in mainline |
| 14:57 | jnettlet | where it is used? |
| 14:57 | _rmk_ | and doesn't exist in my .config |
| 14:57 | _rmk_ | bah |
| 14:58 | jnettlet | did they remove it? |
| 14:58 | _rmk_ | imx v6_v7 defconfig doesn't set CMA |
| 14:58 | jnettlet | ah of course not. |
| 14:59 | _rmk_ | overridable with cma= |
| 15:01 | jnettlet | oh they finally added that. |
| 15:01 | jnettle | 15:01 * jnettlet still thinks it should be part of the device-tree, but the argument it doesn't describe the hardware |
| 15:02 | jnettlet | s/argument/argument is/g |
| 15:13 | _rmk | 15:13 * _rmk_ spots another HDMI bug |
| 15:14 | _rmk_ | I have a pink line down the LHS |
| 15:23 | jnettlet | pink line like from framebuffer, or like signal is offset |
| 15:25 | _rmk_ | no, it looks like the hsync is slightly out |
| 15:53 | _rmk_ | erm, this is screwed. its setting a total of 1780 pixel clocks per line on 720p 60Hz |
| 15:56 | _rmk_ | eww |
| 15:56 | _rmk_ | so imx-hdmi converts a drm_display_mode to a fb_videomode and then re-converts that to what's required to program the registers |
| 15:57 | jnettlet | rofl |
| 16:09 | _rmk_ | and yes, the problem is in the conversion |
| 16:24 | _rmk_ | willitwork |
| 16:26 | _rmk_ | gah |
| 16:26 | _rmk_ | that's not the bug, but its still a fix |
| 16:31 | _rmk_ | same bug at the DI level |
| 16:31 | jnettlet | now we know why this is still sitting in staging |
| 16:36 | _rmk_ | I feel that there's a technical term which applies to this :) |
| 16:36 | _rmk_ | of six letters beginning with f and ending in d |
| 17:53 | jnettlet | well somebody is paying attention either freescale or vivante has merged a bunch of my changes into this new driver. |
| 18:19 | _rmk_ | *GAH* found another cause of it |
| 18:19 | _rmk_ | fb_videomode has to die |
| 18:22 | jnettlet | why is that being used in the KMS driver? |
| 18:29 | _rmk_ | I think only their deity knows :) |
| 18:29 | _rmk_ | I'm soo going to kill it. |
| 18:37 | _rmk_ | another silly: |
| 18:37 | _rmk_ | if (mode->flags & DRM_MODE_FLAG_DBLSCAN) |
| 18:37 | _rmk_ | timing->vmode |= FB_VMODE_DOUBLE; |
| 18:37 | _rmk_ | timing is fb_videomode |
| 18:37 | _rmk_ | do they use FB_VMODE_DOUBLE in here? |
| 18:41 | jnettlet | oh I see what is going on here. They have used the exynos driver as a model and the exynos driver is actually just a KMS interface to the fbdev driver. |
| 18:45 | _rmk_ | *doh* where do they get these "initialization step"s from |
| 18:45 | _rmk_ | /* HDMI Initialization Step B.1 */ |
| 18:45 | _rmk_ | hdmi_av_composer(hdmi, mode); |
| 18:45 | _rmk_ | /* HDMI Initializateion Step B.2 */ |
| 18:45 | _rmk_ | ret = imx_hdmi_phy_init(hdmi); |
| 18:45 | _rmk_ | /* HDMI Initialization Step B.3 */ |
| 18:45 | _rmk_ | imx_hdmi_enable_video_path(hdmi); |
| 18:45 | _rmk_ | so far soo good but... B.4? |
| 18:46 | _rmk_ | /* HDMI Initialization Step B.4 */ |
| 18:46 | _rmk_ | static void imx_hdmi_enable_video_path(struct imx_hdmi *hdmi) |
| 18:46 | _rmk_ | so step B.3 is to call a function called imx_hdmi_enable_video_path() and step 4 is to actually do its implementation? |
| 18:47 | _rmk_ | and yes, even with corrected syncs, it's still wrong. |
| 19:03 | _rmk_ | right, mail sent to Fabio |
| 19:52 | _rmk_ | ok, I've come to the conclusion that it's an ordering issue between the IPU and HDMI layers |
| 19:57 | _rmk_ | 720x576 doesn't work properly |
| 20:03 | dv_ | _rmk_: the imx5/6 DRM drivers in mainline staging, are these the ones you are fixing right now? |
| 20:04 | _rmk_ | yea |
| 20:04 | _rmk_ | not sure about "fixing", more like "battling" |
| 20:04 | dv_ | I think pengutronix wrote these |
| 20:05 | dv_ | not sure though |
| 20:05 | _rmk_ | * Copyright (C) 2012 Sascha Hauer, Pengutronix |
| 20:05 | _rmk_ | * Based on Samsung Exynos code |
| 20:05 | _rmk_ | * Copyright (c) 2011 Samsung Electronics Co., Ltd. |
| 20:05 | dv_ | okay, that clarifies it :) thanks, I cannot access github atm, and here I have no local copy |
| 20:05 | _rmk_ | however, Fabio is a freescale guy |
| 20:06 | dv_ | I've been in contact with one of them (robert schwebel). they are the same company that is mainlining IPU and VPU. |
| 20:06 | dv_ | it seems they have a lot more patches they havent publicized (yet) |
| 20:07 | dv_ | for the "common display framework" for example |
| 20:08 | dv_ | he suggest to have a look at the Sascha Hauer's talk at the ELCE . might be relevant for us. |
| 20:09 | _rmk_ | looking at this: https://lwn.net/Articles/563157/ |
| 20:09 | _rmk_ | it looks like it's either something invented over fbdev, or it's something entirely new |
| 20:10 | dv_ | yeah |
| 20:11 | _rmk_ | that's probably not going to make many people happy |
| 20:11 | dv_ | the first version of that RFC explains the motivation behind this |
| 20:12 | dv_ | well it doesnt make me happy. more like confused. |
| 20:12 | dv_ | since now I dont know how much these guys already did. |
| 20:13 | dv_ | imagine this: feature X is finished, attempts at mainlining begin, then they publish their patch. |
| 20:13 | dv_ | out of the blue. |
| 20:17 | dv_ | I guess this is one more reason why "release early, release often" is a good idea if you want to contribute to an opensource project |
| 20:22 | _rmk | 20:22 * _rmk_ wishes Rob would finish the review of the armada drm stuff so it can make the next merge window. |
| 20:23 | _rmk_ | its getting really tight now with the KS next week. we're already at rc5 and at this rate its going to miss. |
| 20:26 | dv_ | _rmk_: why do you think this wont make many people happy? because it sort of looks like what asoc is doing for audio on SoCs? |
| 20:28 | _rmk_ | if its just a library of display panels and bridges then fine. if it's a replacement for kms, then no. |
| 20:29 | _rmk | 20:29 * _rmk_ should poke RobClark about armada drm again :) |
| 20:29 | robclark | _rmk_, oh, right.. sorry, got sidetracked.. |
| 20:30 | robclark | _rmk_, I'm pretty sure airlied will do a round of pulls after KS, fwiw |
| 20:33 | robclark | fwiw, CDF is at least envisioned as something below {kms,fbdev,v4l2}.. supposed to be something to share components between different userspace facing drivers. (That is the theory anyways, I'm a bit skeptical about introducing extra layers of frameworks..) |
| 20:36 | _rmk_ | robclark: yes, you're not the only one. Alan made a point of that when I was working on that serial_core stuff... by saying that frameworks and layers are almost never the answer, libraries are a much better approach. |
| 20:37 | _rmk_ | I kind'a regret not listening more to that back then. |
| 20:37 | robclark | yeah |
| 20:37 | robclark | that is my big fear w/ CDF |
| 21:28 | _rmk_ | dv: interesting... CDF may be partly defunct by a move by exynos in what seems to be a different direction |
| 21:28 | _rmk_ | Subject: [PATCH 0/7] video phy's adaptation to *generic phy framework* |
| 21:29 | _rmk_ | moves the exynos mipi csi/dsi stuff to be a phy instead |
| 21:51 | dv_ | ah, so it doesnt have momentum? |
| 21:52 | dv_ | and I agree on frameworks vs. libraries. I know this from the GUI toolkits that generate application code where you can only fill in your code in special locations |
| 21:53 | dv_ | game engines are also often like that. like a framework. its pretty annoying, how much freedom and flexibility it takes away. |