| 02:41 | Coburn | Well, gotta say I like using a CuBox as a NAS |
| 02:42 | Coburn | 1TB HDD attached to it, rolled out Debian + SAMBA |
| 02:42 | Coburn | Better than buying some chinese stuff that would have a backdoor in the Web UI |
| 03:48 | dbsx | Hey Coburn, I am starting to like cubox as 1) with awesome 2) with xbmc 3) NAS |
| 06:21 | Coburn | dbsx: I will say XBMC rocks the CuBox's socks off |
| 06:21 | Coburn | There's some lag between the transtitions on the screen, but that's understandable since we've got only 800Mhz Single Core to play with |
| 06:23 | Coburn | by 'with awesome', you mean it's awesome in general or 'awesome' as in the window manager :P |
| 06:41 | dbsx | awesome the window manager |
| 08:59 | Coburn | Ah, I think I've used that window manager |
| 08:59 | Coburn | I think |
| 09:35 | rabeeh | Coburn: awesome is really good, and fast |
| 09:35 | rabeeh | profiling X on ubuntu shows libpixman as biggest CPU consumer (when moving window) |
| 09:56 | suihkulokki | rabeeh: pixman has some neon/sse optimisations, doing them over to iwmmx might help |
| 10:30 | rabeeh | suihkulokki: olpc already did something similar |
| 10:30 | rabeeh | for mmp2 device (iwmmxt) |
| 10:34 | suihkulokki | seems to be upstream already, but not on the debian packages |
| 10:36 | suihkulokki | the other possibility if pixman is highly visible in profiler, is that xorg/drm are not doing a good job managing buffers |
| 11:03 | rabee | 11:03 * rabeeh doesn't have drm :( |
| 11:03 | rabeeh | but yes; pixman is on the top of the list |
| 13:17 | _rmk_ | shesselba: are you getting any mail from lakml or only stuff cc'd/to you? |
| 13:18 | shesselba | _rmk_: I am subscribed to lakml but sometimes I am not able to read through all the stuff.. has there already been a discussion about drm + DT? |
| 13:19 | _rmk_ | no, the reason I'm asking is that since 2am +0100, I've not had any mail from the lists, neither has my local archive |
| 13:20 | _rmk_ | I think infradead might have broken, or it's unsubscribed both me and the archive at the same time |
| 13:20 | shesselba | no |
| 13:20 | shesselba | I didn't get any too |
| 13:20 | _rmk_ | okay, probably an infradead problem then. :( Will have to wait for dwmw2 to surface. |
| 13:20 | shesselba | 01.33AM last mail, git pull omap2+ |
| 13:23 | _rmk_ | I've now removed all the dummy mode/connector unknown status from the driver... and then had great fun with Xorg yesterday. |
| 13:23 | _rmk_ | it's not good when your GPU fills physical address 0, thinking its a 2048x2048 screen with black, wiping out your kernel. |
| 13:24 | shesselba | WTF? |
| 13:25 | shesselba | that's the mem bug you were talking about yesterday? |
| 13:25 | _rmk_ | I was allocating the initial framebuffer in X (which will be the max res - 2048x2048) before I know whether I'm using the GPU. If I'm not using the GPU, then I don't set the pixmap's physical address, so that ends up being 0. |
| 13:26 | _rmk_ | when there's a connector present, X will then re-set the framebuffer according to the desired resolution, which reallocates it. At that time, it does know it's using the GPU, so sets the phys address... |
| 13:27 | _rmk_ | however, with nothing connected, that reallocation never occurs, so when X decides to clear the screen using the GPU, it hits the initial one which didn't have the phys address set, and clears the kernel out :( |
| 13:27 | shesselba | ouch |
| 13:28 | _rmk_ | the driver now has that fixed, and an assert(bo->phys != 0); just before we pass any address to the GPU... better to kill the X server than the machine. |
| 13:30 | _rmk_ | on the i2c thing... yes I can see that's a problem, and that's something I think which also needs sorting with Francisco Jerez and/or David Airlie. Francisco seems to be the author of the slave encoder stuff |
| 13:31 | _rmk_ | but not sure if Francisco would be interested; this code dates from 2009 apparantly |
| 13:32 | shesselba | hehe |
| 13:34 | shesselba | I guess it is difficult, while SoCs connect them to "global" i2c adapters, PC graphics cards will have them connected to some private i2c that is never exposed |
| 13:34 | _rmk_ | btw, v4l2 also suffers from this same problem |
| 13:34 | _rmk_ | drivers/media/v4l2-core/v4l2-common.c:v4l2_i2c_new_subdev_board |
| 13:35 | _rmk_ | the pattern generally adopted by the PC "add-in card" model is that the driver for the card knows about the devices on the card |
| 13:35 | _rmk_ | and that stuff isn't described by DT |
| 13:35 | shesselba | which is a reasonable for an add-in-card |
| 13:36 | shesselba | but for SoCs it isn't anymore.. |
| 13:36 | shesselba | or it will lead to e.g. asoc having a new card for every SoC<->codec combination |
| 13:40 | _rmk_ | looking at omap dss, they suffer from the same problem with i2c - take a peek at drivers/video/omap2/displays/panel-picodlp.c:picodlp_panel_probe |
| 13:40 | shesselba | gimme a sec, have to buy a new phone ;) |
| 13:57 | shesselba | yeah, as you already noticed, there is a lot sub-APIs suffering from this |
| 14:07 | suihkulokki | rabeeh: gcc 4.6 is apperently too old for ixmmx + hardfp |
| 14:09 | suihkulokki | rabeeh: and gcc-4.8 won't do iwmmx + thumb2, but with -marm pixman will compile with iwmmx code |
| 18:08 | dv_ | suihkulokki: gcc 4.8 supposedly got a new -march=marvell-pj4 switch |
| 19:04 | _rmk_ | shesselba: as far as the clock divider goes... I just found this comment: |
| 19:04 | _rmk_ | For example, to obtain 80 MHz, this register should be set to (83-80)/83 = |
| 19:04 | _rmk_ | 0x094. |
| 19:05 | _rmk_ | In this example, three clocks are suppressed, 80 clocks are used, and the duty |
| 19:05 | _rmk_ | cycle is not 50%. |
| 19:17 | shesselba | _rmk_: yeah, I read this, but never thought they would really suppress output clocks but input clocks.. implementing a digital sigma-delta clock divider isn't that hard ;) |
| 19:19 | shesselba | it would still be a high-jitter clock, but suppress a whole output clock just makes it unusable for contiguous video |
| 19:32 | _rmk_ | shesselba: so, is making use of the AXI or PLL clocks basically a bad idea? |
| 19:33 | shesselba | hmm.. that is what you have to rely on when there is no extclk available.. but their capabilities are limited |
| 19:33 | shesselba | axiclk is 333MHz by default |
| 19:34 | shesselba | pllclk is 2000MHz/N or 2000MHz/(N+0.5) with N >= 5 and N <= 32 IIRC |
| 19:35 | shesselba | Hard to hit one of the common 50/60Hz pixclk freqencies |
| 19:37 | shesselba | not a big deal if you use Dove as computer replacement with VESA mode, but for HDTV the internal clocks are useless |
| 19:39 | shesselba | _rmk_: there is a patch for clk_mux to select the best parent clock for a requested rate.. that should solve the "get best available clock" issue |
| 19:39 | _rmk_ | ah, is that available somewhere? |
| 19:39 | shesselba | mom |
| 19:41 | shesselba | https://lkml.org/lkml/2013/5/20/315 |
| 19:42 | dv_ | okay, so much to catch up. many new packages. |
| 19:43 | dv_ | the stuff you guys are doing, are you using a public repo for it that I can integrate into openembedded recipes? I want to update my meta-cubox layer |
| 19:43 | shesselba | _rmk_: but using this will make re-probing for external clocks a lot more complicated |
| 19:48 | _rmk_ | ah, so that's being done in the clk layer |
| 19:49 | shesselba | _rmk_: I am not yet so sure it is a good idea to mux on rate change |
| 19:50 | _rmk_ | and I'm not so sure that this is the best way to sort out the clock setting: |
| 19:50 | _rmk_ | rate = adj->clock * 1000; |
| 19:50 | _rmk_ | clk_set_rate(dcrtc->clk, rate); |
| 19:50 | _rmk_ | ref = clk_get_rate(dcrtc->clk); |
| 19:50 | _rmk_ | div = DIV_ROUND_UP(ref, rate); |
| 19:50 | _rmk_ | if (div < 1) |
| 19:50 | _rmk_ | div = 1; |
| 19:50 | _rmk_ | because... that will result in a slow clock rate being set before the divider gets used |
| 19:50 | shesselba | that's your code ;) |
| 19:51 | _rmk_ | yea, which is the same as the dovefb method |
| 19:51 | shesselba | I guess, having a clock for the divider itself is not a bad idea |
| 19:52 | _rmk_ | really what we want to know is: is there a combination of divider and clock rate which results in something reasonably close to the desired rate after dividing |
| 19:53 | shesselba | you just clk_set_rate to it here and it should find the best parent clock that provides it |
| 19:53 | shesselba | it can also re-probe for extclk |
| 19:54 | dv_ | _rmk_: you told me that the xorg dovefb driver doesnt work with newer xorg servers because it redefines modeline stuff internally |
| 19:54 | dv_ | were you talking about the marvell release, or this: http://dev.laptop.org/git/projects/xf86-video-dove/ |
| 19:56 | _rmk_ | I was talking about the original for the cubox |
| 20:06 | dv_ | okay, then perhaps this one will work. lets see. |
| 20:45 | _rmk_ | shesselba: do we know of any other SoCs with this LCD controller in? |
| 20:45 | shesselba | officially? |
| 20:46 | shesselba | its in some pxa, let me check the number |
| 20:55 | shesselba | _rmk_: Armada/PXA16x |
| 20:56 | shesselba | and I wouldn't be surprised to also find it in Armada 600, 1000, 1500 |
| 21:03 | _rmk_ | hmm, there's subtle differences in the clock register between the two |
| 21:03 | shesselba | yes |
| 21:04 | _rmk_ | and on the fractional divider field... "Due to clock jitter added by fractional divider, use of this field is limited to smart panel device which has its own pixel clock source." |
| 21:04 | _rmk_ | :) |
| 21:06 | _rmk_ | and I notice... no dcon on this device |
| 21:06 | _rmk_ | just a single lcd controller (which is what I've already said in an email I've prepared...) |
| 21:09 | _rmk_ | I think what I'm going to do about this at the crtc level is have the crtc call a method in the main dev_private structure which provides the clock divisor, and let that method decide which clock to use and what divider values to use. |
| 21:10 | shesselba | yeah, move the clock to driver level and just pass a single clk to crtc |
| 21:10 | _rmk_ | not even thinking about passing a clk to the crtc - though the crtc should remember which clk it's currently using, but all that can be handled in the method |
| 21:11 | _rmk_ | I'm also thinking that this should probably not be called "dove" but "armada" |
| 21:11 | shesselba | yep |
| 21:13 | dv_ | isnt armada the marketing name for the dove platform? |
| 21:13 | _rmk_ | PXA16x is also known as Armada 16x |
| 21:14 | _rmk_ | not sure if that can be classified as "dove" tho |
| 21:14 | dv_ | hmm. perhaps "dove" is limited to the armada 500 series |
| 21:14 | shesselba | PXA, Armada, MV88AP, almost interchangeable .. marvell numbering is a mess |
| 21:15 | shesselba | Dove = 88AP510 aka Armada 510 aka PXA510 (sometimes) |
| 21:15 | dv_ | i wonder how such overcomplicated numbering schemes come to be |
| 21:15 | dv_ | who thinks this is a good idea? |
| 21:16 | shesselba | I guess Dove is some internal SoC/Project name |
| 21:16 | shesselba | 88AP510 is the "technical" name |
| 21:17 | shesselba | PXA510 the old marketing name, Armada the new |
| 21:17 | shesselba | voila, you have 4 names ;) |
| 21:17 | _rmk_ | and the Armada 16x are 88AP16x |
| 21:18 | _rmk_ | and the Armada 16x "software manual" refers you to the "PXA16x Application Processor Family Hardware Manual" |
| 21:18 | _rmk_ | and it's soooooo tempting to keep typing ARMada :( |
| 21:19 | shesselba | funny isn't it ;) |
| 21:19 | dv_ | haha |
| 21:19 | _rmk_ | I'm sure they wanted to use that capitalization but the lawyers probably said no :) |
| 21:19 | dv_ | yes, it does remind me of the ARM naming and numbering scheme |
| 21:24 | rabeeh | 88AP510 is the part number |
| 21:24 | rabeeh | Armada is the family; Armada 510 is the mkt name of the chip |
| 21:24 | rabeeh | Dove is internal name |
| 21:24 | _rmk_ | rabeeh: do you know if Dove covers the 88AP16x as well? |
| 21:24 | rabeeh | nop |
| 21:25 | rabeeh | it doesn't cover |
| 21:25 | rabeeh | Dove is only 88AP510 |
| 21:25 | _rmk_ | okay, so calling this driver "armada" rather than "dove" seems more appropriate then as it's also found there |
| 21:25 | rabeeh | yes. |
| 21:25 | rabeeh | that's withregards combining the 88ap16x and 88ap510 clcd drivers? |
| 21:27 | _rmk_ | it's more a case of not creating something we're going to regret in the future, like naming all the DT stuff "dove" rather than "armada" if "armada" would be more appropriate |
| 21:27 | shesselba | yes, it is about renaming dove-drm to armada-drm early to show it will also work on 168 with some minor modifications |
| 21:37 | _rmk_ | right, willitboot :) |
| 21:39 | _rmk_ | I haven't booted it yet, but I thought I'd find a possibly appropriate image: http://cdn.memegenerator.net/instances/400x/33353668.jpg |
| 21:39 | dv_ | :) |
| 21:39 | dv_ | oh rabeeh, is there some kind of cubox logo, like the raspberrypi one? |
| 21:39 | dv_ | something that can be used for a splashscreen? |
| 21:40 | _rmk_ | well, it's booting... :) |
| 21:44 | _rmk_ | and it works... well, it would do if it selected 720p not 1080i with the drm/i2c/tda998x.c driver |
| 21:44 | rabeeh | dv_: there isn't |
| 21:44 | rabeeh | there is the solidrun logo |
| 21:49 | dv_ | _rmk_: what is the "UseGPU" code path in the dovefb driver? |
| 21:49 | dv_ | using GPU for what? |
| 21:49 | dv_ | is it drawing Xvideo overlays with pixel shaders? |
| 21:50 | rabeeh | xv extension |
| 21:50 | dv_ | okay, it doesnt work in the newest xorg drivers (from dev.laptop.org) due to missing Vivante symbols |
| 21:50 | dv_ | but with UseGPU=false, I get an image =) |
| 21:51 | _rmk_ | it also allows the driver to use the GPU for acceleration too using the Exa backend |
| 21:51 | rabeeh | dv_: btw - poky danny builds |
| 21:51 | dv_ | yay! |
| 21:51 | rabeeh | :) |
| 21:52 | dv_ | okay, the missing symbol is gcoHAL_QuerySeparated3D2D |
| 21:52 | dv_ | I am puzzled by all this. the dove Vivante stuff is missing that symbol and the gceHARDWARE_TYPE enum . freescale Vivante stuff has both. |
| 21:53 | _rmk_ | welcome to the world of changing APIs that is the Vivante GPU HAL :( |
| 21:53 | dv_ | oh, and rabeeh, try out gstreamer on it when you get the chance, to see if you can replicate my CPU% results with vmeta |
| 21:53 | rabeeh | the 11% ? |
| 21:53 | dv_ | _rmk_: yeah :| |
| 21:53 | dv_ | rabeeh: yes |
| 21:54 | dv_ | oh _rmk_, jnettlet told me about http://dev.laptop.org/git/users/dsd/libphycontmem/ , which seems to be some library for cacheable memory (?) |
| 21:59 | _rmk_ | oh no, not another contig kernel memory driver |
| 21:59 | _rmk_ | #define MARVELL_MEMDEV_NAME_CACHEBUFFERED"/dev/pmem"//cacheable & buffered |
| 21:59 | _rmk_ | #define MARVELL_MEMDEV_NAME_NONCACHED"/dev/pmem_adsp"//non-cacheable & non-buffered |
| 22:00 | _rmk_ | #define MARVELL_MEMDEV_NAME_WC"/dev/pmem_wc"//non-cacheable & buffered |
| 22:00 | _rmk_ | and why three char devs for that? |
| 22:00 | _rmk_ | at least bmm is way better than that. |
| 22:02 | dv_ | I do not know why this exists. |
| 22:02 | dv_ | perhaps bmm is being phased out? |
| 22:05 | _rmk_ | my libbmm: http://ftp.arm.linux.org.uk/git/gitweb.cgi?p=libbmm.git;a=tree |
| 22:13 | dv_ | alright, my oe layer works with the newest yocto now \o/ |