| 00:07 | _rmk_ | well, v3.11 is now out, so its going to be another three months |
| 01:07 | _rmk_ | shesselba: well, in my latest email, I've put in the diagram of how Liam's driver connects the CPU DAIs/Codecs up. |
| 01:07 | _rmk_ | I was trying trying to avoid that, but when Mark said "there's no mixer"... well, that seems to be a false statement. |
| 01:25 | _rmk_ | shesselba: I'd like to hear your thoughts on whether kirkwood-spdif.c (the 'card' level part) should be submitted. As far as I can see, it's redundant in a DT setup - there's nothing to create the platform device which it needs for the snd_card stuff |
| 10:09 | shesselba | _rmk_: that is what I keep telling, but Mark insists on having an extra sound card node. There is no single helpful answer from him. |
| 10:10 | shesselba | If you don't project ASoC on DT but the other way round, you would need no special node linking stuff together |
| 10:11 | shesselba | there needs to be some machine driver for DT too, but that could be parsed out of the audio-controller node |
| 10:12 | shesselba | IMHO, leave the patch set as small as possible, they all have no interest right now to get this any further |
| 10:22 | dv_ | shesselba: can you summarize the discussion a bit? I am kinda lost |
| 10:24 | shesselba | dv_: kirkwood/dove audio ip (one playback stream on two outputs) is not supported by ASoC architecture |
| 10:24 | shesselba | ASoC maintainer claims that there is some DPCM feature that *should* allow this |
| 10:26 | shesselba | but (a) DPCM is broken in mainline, (b) no one seems to use it, (c) no one really cares |
| 10:27 | dv_ | so ASoC expects one stream <-> one output? |
| 10:28 | dv_ | hmm that would not play nice with some of our stuff, which also has one stream on two outputs |
| 10:30 | shesselba | dv_: ASoC maintainer believes, that setup is very special - I can name _at least_ two IPs that behave like this |
| 10:31 | dv_ | would supporting this require major changes to the asoc design? |
| 10:31 | shesselba | according to the discussion, it's well tested and already in mainline |
| 10:32 | shesselba | given _rmk_'s mood, his experiences, and even my own little steps on it, it's neither documented nor working at all |
| 10:34 | shesselba | the changes *should* be fairly simple, fool ASoC by pretending the CPU DAI (kirkwood-dma) is connected to a virtual codec that itself is connected to either i2s, spdif, or both |
| 10:34 | dv_ | abstracting away the dual output |
| 10:34 | dv_ | so what are the arguments against? just that it is special? |
| 10:34 | dv_ | a special rare case? |
| 10:35 | shesselba | I'd call it fooling ASoC's inner layer |
| 10:35 | dv_ | seems to me that it is fairly straightforward to add this to asoc. one stream <-> one output then becomes just a special case. |
| 10:36 | shesselba | well, there are no arguments against - except that _rmk_ got mad at the maintainer ignorance after several non-sense answers |
| 10:36 | shesselba | now they are pissed |
| 10:37 | dv_ | *sigh* ... sounds like a Linus Torvalds Treatment is necessary here |
| 10:37 | dv_ | like what happened with the udev stuff |
| 11:09 | _rmk_ | shesselba: you have to wonder... if Liam's Haswell driver is still not in mainline (it was supposed to be in "this week" and that was May 22nd), is that because DPCM doesn't work, or... |
| 11:10 | jnettlet_ | shesselba: what is well tested and already in mainline? Kirkwood audio support? |
| 11:11 | jnettlet_ | sorry my IRC client didn't auto-scroll...I need to find something better. |
| 11:25 | _rmk_ | jnettlet: I think shesselba is referring to the view of the ASoC maintainers about DPCM |
| 11:27 | shesselba | jnettlet, _rmk_: [sarcasm on]yes[sarcasm off] |
| 11:31 | _rmk_ | shesselba: as the quality of their responses is no different to when I started on this, I don't think its got anything to do with "being pissed" |
| 11:31 | jnettlet_ | are there any drivers that demonstrate working DPCM? |
| 11:31 | _rmk_ | Mark is again displaying his lack of knowledge in this more civilised discussion, providing evidence that everything I said in August is correct |
| 11:32 | _rmk_ | jnettlet: as far as I'm aware, there are two: one of them is a horridly complex OMAP driver (which is not in mainline) and another is Liam's Haswell driver, which also is not in mainline, but he sent me the relevant parts to model my stuff against. |
| 11:33 | _rmk_ | whether they demonstrate working DPCM, I've no idea... what I do know is that the Haswell driver seems to indicate that Liam has other core asoc changes |
| 11:34 | _rmk_ | for instance, the Haswell driver has these in its snd_soc_dai_link structure: |
| 11:34 | jnettlet_ | can't wait to see them. Looks like I will need to use dpcm to merge my hdmi audio if/when the time comes |
| 11:34 | _rmk_ | .dpcm_playback = 1, |
| 11:34 | _rmk_ | .dpcm_capture = 1, |
| 11:35 | _rmk_ | and the mainline struct doesn't contain those members |
| 11:35 | jnettlet_ | nope, but for dpcm you would need those. |
| 11:36 | _rmk_ | if that was in mainline, and it does what I think it does, it could solve the problem I have with capture being published |
| 11:36 | _rmk_ | there's also this: |
| 11:36 | _rmk_ | .be_id = 1, |
| 11:38 | _rmk_ | and that is in mainline |
| 12:33 | _rmk_ | well, that was easy - merging v3.11 into the cubox tree |
| 12:33 | _rmk_ | only two minor conflicts |
| 12:34 | shesselba | _rmk_: "they" didn't include you, but Mark, Lars, and Liam |
| 12:35 | shesselba | what are the conflicts? |
| 12:36 | _rmk_ | arch/arm/mach-dove/common.h due to the reboot thing, and drivers/clk/clk-si5351.c - I think I left a blank line in with my 3.10 resolution just after the two register writes to set the disabled output levels to logic 0, which were removed between 3.10 and 3.11 |
| 12:36 | shesselba | ok |
| 12:47 | _rmk_ | right, that's v3.11 building |
| 12:50 | _rmk_ | and looking at v3.10..v3.11, there's no significant changes to asoc - its mostly fixing the wrapping of kernel messages, moving some code around, using kasprintf, and adding support for dapm switches |
| 13:10 | _rmk_ | Linux version 3.11.0+ ([email protected]) (gcc version 4.5.4 (GCC) ) #686 PREEMPT Tue Sep 3 11:55:15 BST 2013 |
| 13:12 | _rmk_ | hmm, looks like I'm missing a clock chip |
| 13:39 | _rmk_ | right, that does it, I'm not going to push this anymore. |
| 14:00 | _rmk_ | shesselba: there is something very evil which I could do to the asoc people: I could write my own ALSA SoC support which is better structured, with DT in mind, so its possible to specify widgets and the routing between them in DT. |
| 14:00 | _rmk_ | that'd probably make ASoC obsolete |
| 14:19 | jnettlet_ | _rmk_: that sounds like a brilliant idea to me :-) |
| 14:20 | jnettlet | 14:20 * jnettlet_ would just be happy with an sdhc card that had random write support that didn't completely blow. |
| 14:49 | troulouliou_dev | hi is there a driver for the gpu under linux ? |
| 14:49 | troulouliou_dev | or is it cpu only ? |
| 14:58 | dv_ | ? |
| 14:59 | dv_ | the gpu drivers are from vivante |
| 14:59 | dv_ | troulouliou_dev: http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-opengl/marvell-opengl-hardfp-light.zip if you use hardfp |
| 14:59 | dv_ | http://download.solid-run.com/pub/solidrun/cubox/packages/marvell-opengl/marvell-opengl-softfp-light.zip otherwise |
| 15:13 | troulouliou_dev | dv_, ok thanks |
| 15:13 | troulouliou_dev | it is laggy under linux ? |
| 15:14 | dv_ | didnt seem so to me |
| 15:14 | dv_ | it needs X11 though |
| 15:14 | troulouliou_dev | dv_, ok thanks |
| 15:48 | _rmk_ | shesselba: ah, that's why I have no clocks - the i2c device IDs got changed |
| 20:00 | shesselba | _rmk_: although I don't like Mark's non-sense, spare your time for something more useful |
| 20:00 | shesselba | you are still on non-DT? Who changed the device ID? |
| 20:05 | _rmk_ | guess... |
| 20:05 | _rmk_ | 9807362bfe1748d9bb48eecb9261f1b1aaafea1c |
| 20:06 | shesselba | ah, ok |
| 20:06 | shesselba | yes |
| 20:06 | shesselba | that is so useless |
| 20:08 | shesselba | the variant still has to be passed by platform_data (if there is no further patch to look at the i2c_id... |
| 20:26 | _rmk_ | shesselba: well, the new tv is amazing, I can see the last 100 pixels or so at each of the edges :) |
| 20:26 | shesselba | whoot! :) |
| 20:27 | shesselba | Back when they introduced HDTV in Germany, I remember they moved the score overlay (football) to the top-right corner |
| 20:27 | shesselba | causing _a lot_ of complains because CRT users couldn't see the score anymore ;) |
| 20:28 | shesselba | don't ask me why they fake this horrible overscan on panels |
| 20:34 | shesselba | _rmk_: now you can set BLANKCOLOR to non-black and see that I hopefully fixed tda998x input sync detection ;) |
| 20:38 | _rmk_ | haha, I just worked out the output mute circuit on this chinese spdif box... it's... rubbish and non-functional. |
| 20:42 | shesselba | analog mute or spdif mute? |
| 20:47 | _rmk_ | analog - on the output. it works as far as activating clamps on the outputs on power down or power up |
| 20:48 | _rmk_ | but it's also fed with a signal from the decoder chip which goes low when there's no valid input... which does nothing because it just reverse biases a PNP transistor - turning it "more off" than it already was. |
| 20:55 | shesselba | well, you cannot be sure enough :) |
| 21:38 | shesselba | _rmk_: you want on Cc for the si5351 follow-up patch? |
| 21:47 | _rmk_ | oh, are you reverting that commit? yes please. :) |
| 21:48 | shesselba | no, removing .variant |
| 21:48 | shesselba | from platform_data |
| 21:48 | shesselba | to make the original commit of any use at all |
| 21:50 | _rmk_ | yea, let me have it then I can be prepared for the change, thanks |
| 22:00 | _rmk_ | looks good. |