| 00:00 | _rmk_ | and someone really must teach Rudi the kernel coding style and slap his wrists every time he invents his won |
| 00:00 | _rmk_ | own |
| 00:00 | dv_ | hehe |
| 00:00 | _rmk_ | it is not... |
| 00:00 | _rmk_ | + for (i=0; i |
| 00:00 | _rmk_ | + { |
| 00:01 | _rmk_ | but |
| 00:01 | _rmk_ | for (i = 0; i < num; i++) { |
| 00:01 | dv_ | hmm arent there any git hooks for that? |
| 00:01 | dv_ | gstreamer has some, for example. if the syntax check fails, the commit is rejected |
| 00:02 | _rmk_ | well, there's checkpatch.pl to validate the style, but no one enforces that through the git hooks in kernel land |
| 00:02 | _rmk_ | I'm just looking at the i2c commit in Rabeeh's tree and wondering what it's trying to do... whether its trying to fix the same problem I discovered but totally weirdly |
| 00:03 | _rmk_ | and while there undoing some of the changes which have happened in mainline (like the module_platform_driver() thing) |
| 00:04 | _rmk_ | well, I think this "Added combined access to i2c controller" commit is misleading and probably wrong. |
| 00:05 | _rmk | 00:05 * _rmk_ frowns... |
| 00:05 | _rmk_ | + if (msg->flags & I2C_M_REV_DIR_ADDR) |
| 00:05 | _rmk_ | + dir ^= 1; |
| 00:06 | dv_ | unfortunately, I do not have the time to try out these patches right now :| |
| 00:06 | _rmk_ | umm, no, that's not going to work... this smart^wdumb i2c controller reads that bit and uses it to decide what state to transition to after the address has been sent - whether to go into read mode or write mode. |
| 00:09 | _rmk_ | good, davem just applied my ethernet fix |
| 00:10 | dv_ | so the controller doesnt actually send the read bit? |
| 00:10 | dv_ | just does an internal state transition? |
| 00:15 | _rmk_ | the controller detects the lsb of the address, which is the r/w bit, and transitions its internal state machine accordingly |
| 00:16 | _rmk_ | so you can't transmit a '1' in the r/w bit and then transmit another byte, because the interface will transition into read mode. |
| 00:17 | _rmk_ | ah, combined mode is what Marvell call the standard restart in I2C parlence. that's what Rudi's referring to, and the driver already has it but very buggily |
| 00:18 | _rmk_ | I guess Marvell want to avoid I2C parlence because that involves patent licenses |
| 00:33 | _rmk_ | dv_: btw, to try the drm stuff, you also need the Xorg driver side as well |
| 01:59 | DHowett | So you're gonna get our niche mainline, yea? ;) |
| 10:41 | _rmk_ | DHowett: there's lots of changes that will be needed to do that, including API changes to the way the vmeta stuff works |
| 10:41 | _rmk_ | DHowett: UIO-based vmeta has already been rejected by GregKH as an abuse of the UIO subsystem |
| 10:43 | DHowett | aww :( |
| 10:43 | _rmk_ | that's not really a big problem because I already have those changes in my kernel |
| 10:44 | _rmk_ | the biggest problem will be the vivante gpu stuff, which really needs to move into userspace only |
| 10:46 | _rmk_ | the other problem which needs attention is that the new drm based tda19988 driver doesn't work with interlaced displays, whereas the NXP one does. I haven't worked that one out yet. |
| 10:47 | _rmk_ | and I still need to get to the bottom of the sync polarity issue - what the tda19988 needs vs what's required to get the right polarity seen by the display. |
| 10:47 | _rmk_ | as no one can answer my questions on that, I'm going to have to dismantle my cubox so I can probe the sync issues. |
| 10:48 | _rmk_ | err, sync signals. |
| 10:48 | _rmk_ | ETOOEARLY :) |
| 11:41 | frilled | _rmk_, that you on phoronix? :) |
| 11:44 | DHowett | vivante stuff :( ouch |
| 11:44 | DHowett | I'm happy to live without HDMI and Graphics, but I'm a crazy sort ;P |
| 11:45 | dv_ | the vivante headers are funny |
| 11:45 | dv_ | the undefine X11 macros |
| 11:45 | dv_ | *they |
| 11:45 | _rmk_ | frilled: looks like it |
| 11:46 | frilled | ^_^ |
| 11:47 | _rmk_ | dv: and the xserver-xorg-video-dove-0.1.0 source is incompatible with later Xorg servers because it has its own conflicting list implementation using list_entry etc, which is now provided by Xorg itself |
| 11:47 | dv_ | explains the compilation errors I've seen |
| 11:47 | dv_ | ah, found it: eglplatform.h |
| 11:47 | dv_ | #undef Status and #undef Always |
| 11:48 | dv_ | this caused lots of headache :) |
| 11:48 | _rmk_ | I sorted that out with sed -i s/list_entry/mrvl_list_entry/ src/*.[ch] in the xorg dove driver :) |
| 11:48 | dv_ | _rmk_: some of the marvell stuff also have really broken makefiles |
| 11:48 | _rmk_ | but that was a looooonnnnggg time ago |
| 11:49 | dv_ | but currently, my main problem with the xorg driver is the missing galcore HAL header symbols |
| 11:50 | dv_ | gcvHARDWARE_2D to be exact. I got this error: http://pastie.org/private/9ofhxmdjh68yv8iijsts7g |
| 11:50 | _rmk_ | yea, as my kernel galcore is really quite different in a number of areas, I've been debating about giving it a major cleanup |
| 11:50 | dv_ | the problem is: I only have the headers from the solidrun site |
| 11:51 | dv_ | http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-libgfx/ these |
| 11:51 | _rmk_ | yea, when I moved to ubuntu 12.04 armhf, I had quite a problem - ended up cobbling stuff together which seems to work. |
| 11:51 | dv_ | this is actually what is keeping me from moving my openembedded cubox layer to the latest yocto |
| 11:52 | dv_ | some newer headers would be nice *hint* *rabeeh* *hint* :) |
| 11:53 | _rmk_ | the headers I'm using came from gc3184-gcc-4.6-armv7-hard_release |
| 11:53 | dv_ | ah, okay |
| 11:54 | dv_ | thanks, will try when I have time again. which means, not before monday :/ |
| 11:54 | _rmk_ | but... between what Rabeeh used to ship as a 3.5 kernel and that, there's a user/kernel API change |
| 11:54 | _rmk_ | so you need to ensure that the kernel side is also compatible |
| 11:54 | _rmk_ | there's no checking of the compatibility by this code :( |
| 11:55 | dv_ | :| |
| 11:55 | _rmk_ | if you have rabeeh's latest kernel, he's updated that to 3184 |
| 11:55 | dv_ | https://github.com/rabeeh/linux <- this one? |
| 11:55 | _rmk_ | yea |
| 11:55 | dv_ | yes, I am using this one |
| 11:55 | _rmk_ | for mine, I just added the additional struct fields making them dependent on VIVANTE_ABI >= 3184 :) |
| 11:56 | _rmk_ | a symbol I invented in case I wanted to go back to the older armel stuff |
| 11:56 | dv_ | ah, yes, speaking about armel |
| 11:57 | dv_ | several openembedded guys consider hardfp to be pointless most of the time |
| 11:59 | dbsx | As a kernel user, can someone answer : If we assume that the DRM graphics driver will soon be perfect, does that just leave fdt, libgfx and galcore as the main issues? |
| 11:59 | dv_ | I think I asked this before, but I cannot look up the log right now. softfp vs. hardfp, can one expect a significant performance benefit from using hardfp? |
| 12:00 | dv_ | dbsx: there is also vmeta |
| 12:00 | dv_ | (afaik it has a kernel part) |
| 12:04 | dbsx | dv_: I have a lot of stuff using luajit and hardfp gives my apps. a significant improvement in performance. For interpreters that are double/float based improvement can be expected. Some float/double ops are the same speed as integer ops. |
| 12:04 | _rmk_ | dbsx: libgfx is one area I haven't put any work into because I don't wish to be accused of reverse engineering against the license terms. |
| 12:04 | dv_ | _rmk_: also, this part is covered by etnaviv |
| 12:05 | dv_ | dbsx: interesting. in a company project we have been using softfp so far. I wonder what it would be like with hardfp. |
| 12:05 | _rmk_ | galcore, I've been working on in bits, but really it needs to be rewritten so that most of that stuff is in userspace, so that the DRM driver basically just does the submission of a buffer to the vivante GPU. |
| 12:05 | dv_ | (running on a cortex-A8) |
| 12:05 | _rmk_ | fdt... umm, yes :) |
| 12:06 | _rmk_ | dv_: well, armhf if you have FP hardware should be a lot faster across function calls, because the floating point args remain in the floating point registers rather than being moved back and forth between them and the integer registers |
| 12:07 | dbsx | I note that cbxbiker has some new fdt patches for cubox with his build of 3.9.2 |
| 12:07 | _rmk_ | as for hardfp vs softfp, bear in mind that older ARM CPUs did not have FP hardware, and for those softfp makes sense. But modern ARMs all have hardware FP, so hardfp is the place to go |
| 12:08 | _rmk_ | unfortunately, I think the hard vs soft fp thing has really become something of a religion in itself with people quoting beliefs :( |
| 12:08 | _rmk_ | so softfp is likely to be slower on ARMv6+ CPUs |
| 12:08 | dv_ | _rmk_: using cortex-A8 in the company project, and the cubox as a hobby. and well, you know the cubox |
| 12:09 | _rmk_ | cortex-A8 is armv7 so will have VFP support |
| 12:09 | dv_ | yeah |
| 12:09 | _rmk_ | so... has hardware FP |
| 12:10 | dv_ | I recall some problems with the pipelines in A8 though , related to FP |
| 12:10 | DHowett | how could it possibly have become a religious war? hardware floating point really sounds like the superior move given that it's all-but required on modern ARM chips |
| 12:10 | dv_ | or was it neon specific |
| 12:10 | dv_ | ah, its a long time ago |
| 12:10 | DHowett | I can somewhat understand cargo-culting softfp because that's what they've always done, but man, to actively decry the future? :P |
| 12:10 | _rmk_ | dv: there were issues with the exception handling, which I eventually fixed after I got hold of a cubox :) |
| 12:10 | dv_ | DHowett: such things can spawn a life of their own |
| 12:10 | DHowett | indeed so |
| 12:11 | dv_ | DHowett: for example, I guess softfp is default in OE since they also need to support armv5 for example |
| 12:11 | _rmk_ | indeed... mainly because we used to do kernel-side emulation of FPA (the predecessor to VFP) |
| 12:11 | dv_ | then perhaps somebody misunderstood that, and thought that softfp is default because hardfp isnt worth it |
| 12:12 | DHowett | they only 'need' to support armv5 if there's a single be-all end-all OE distribution - which, given the diverse scope of SoCs is already not possible. |
| 12:12 | _rmk_ | if they care about performance on armv5 without vfp (there are some armv5 with vfp) then they will need to be softfp |
| 12:12 | DHowett | makes sense though |
| 12:13 | dv_ | ah, found it: http://permalink.gmane.org/gmane.comp.handhelds.openembedded/57365 |
| 12:13 | dv_ | "And furthermore, there is no real world performance difference between the default (softfp) and hardfloat." |
| 12:13 | DHowett | wellp, time to get my bikeshedding helmet on :) |
| 12:13 | dv_ | :) |
| 12:13 | DHowett | thanks dv ;) |
| 12:14 | dv_ | hardfp is relevant for me though because I may have to use double precision floating point in a crossover filter |
| 12:14 | dv_ | otherwise numerical issues cause bizarro artifacts in the sound output |
| 12:15 | _rmk_ | I suspect there will still be those saying softfp is better than hardfp in 10 years time when we're all using 64-bit ARMs :) |
| 12:16 | dv_ | right, ARM too moved to 64 Bit. I always forget that |
| 12:16 | DHowett | _rmk_: oh you mean softcplx and hardcplx ;) |
| 12:16 | DHowett | everybody needs hardware support for imaginaries. |
| 12:16 | dbsx | No religion here. A hardfp cubox stopped a customer complaining about performance. Hence goodbye softfp |
| 12:16 | _rmk_ | dhowett: lol. :) |
| 12:29 | _rmk_ | at the moment, the diff between what I run and v3.9 looks like... |
| 12:29 | _rmk_ | 193 files changed, 111836 insertions(+), 284 deletions(-) |
| 12:29 | _rmk_ | huge :( |
| 12:38 | punkt | [M |
| 12:38 | punkt | L[M# |
| 12:39 | punkt | sorry for the noise, my tmux is flacky |
| 12:48 | jnettlet | softfp vs hardfp performance is really more about what you are doing. If you doing lots of multimedia then hardfp is going to make a big difference. Not so much on a fileserver. |
| 12:49 | jnettlet | Really the big performance gain is getting iWMMXt enabled. Up to 70% speed up depending on the operation. |
| 13:00 | dbsx | jnettlet: iWMMXt , is there any support in gcc? and can you tell gcc to use it? or is it all application assembler? |
| 13:01 | _rmk_ | yes there is |
| 13:01 | jnettlet | dbsx, Marvell with the help of OLPC got the patches merged in gcc 4.7. Although there seem to be some other bugs that got fixed in gcc 4.8 |
| 13:02 | jnettlet | We still need to get the patch to enable the tunings for the chipsets though. That is wallowing in my todo list I can't get finished. |
| 13:04 | jnettlet | Matt Turner working for OLPC implemented pixman optimizations for it. I also have a set of libvpx patches that need to be ported to the newest version. Other than that anything that usings MMX intrinsics should get some performance gains. |
| 13:06 | jnettlet | _rmk_, are you using gcc 4.8? |
| 13:11 | dbsx | jnettlet: thanks |
| 13:13 | jnettlet | luckily after this move I will have a couple of free weeks, so will hopefully finish off this work. Depends how stubborn SMP support for the XO-4 will be. |
| 13:22 | dbsx | so do we just add -march=iwmmxt to a gcc compile? |
| 13:27 | jnettlet | dbsx, which version of gcc are you using? |
| 13:28 | dbsx | 4.7 |
| 13:31 | jnettlet | dbsx, so my explanation was kind of confusing. Working iwmmxt doesn't ship in default gcc 4.7. The patchset was based on 4.7. gcc 4.8 has support by default. |
| 13:31 | jnettle | 13:31 * jnettlet apologizes |
| 13:32 | dbsx | thanks, time for me to learn something new. |
| 15:51 | troulouliou_dev | hi is it possible to have flash player under ubuntu on cuubox ? |
| 15:52 | troulouliou_dev | or do i need to use androif for this |
| 17:17 | frilled | android does no longer support fl*sh |
| 17:18 | frilled | only if you got it prior to being non-downloadable |
| 17:24 | troulouliou_dev | frilled, and the chrome based plugin ? |
| 17:25 | frilled | on android? |
| 17:26 | frilled | pepper is x86/64 only afaik |
| 18:24 | _rmk_ | well, I've just spent the day trying to work out how to properly deal with adding SPDIF support to kirkwood-i2s, and even after Mark Brown has given suggestions, I still can't work out the pile of shite called ASoC, which seems for ever to be a complete abortion from top to bottom. |
| 18:24 | _rmk_ | so I'm adding that as something that I can't mainline. |
| 18:25 | _rmk_ | the issue is that at the moment, we hack it on the cubox so we just enable i2s and spdif outputs irrespective of whether they're used |
| 18:25 | _rmk_ | to do this correctly needs the front-end and back-end DAI support |
| 18:25 | _rmk_ | but how you use that stuff is _far_ from clear especially as there's no examples in the kernel |
| 18:26 | _rmk_ | and its also far from clear what the effect would be of one of the front-end DAIs coming online while the back-end is already active |
| 18:26 | _rmk_ | (which can't be handled by the kirkwood engine, because it requires I2S_EN and SPDIF_EN to be set or cleared together if dual operation is required) |
| 18:43 | jnettlet | _rmk_, I think the samsung's soc code supports I2S and spdif dai's |
| 18:43 | jnettlet | if it isn't mainline, then it is definitely in the chromeos kernel |
| 18:43 | _rmk_ | jnettlet: broonie says there's no examples yet |
| 18:44 | _rmk_ | I've just sent broonie and Liam (who seems to be the creator of the FE/BE stuff) a mail about this |
| 18:44 | _rmk_ | well, I would have if Liam's address didn't bounce |
| 18:46 | _rmk_ | found his new address. |
| 18:55 | jnettlet | _rmk_, good luck. Do you have a "going upstream" tree published anywhere; or do you plan to publish one anywhere? |
| 18:56 | _rmk_ | not at present |
| 18:56 | _rmk_ | though, the ethernet fix was applied by davem yesterday |
| 18:57 | _rmk_ | and the i2c fix for interruptible waits too |