| 03:08 | donovang | heyas - is anyone willing to answer questions about distributions on cubox? I have the cubox installer working and am trying to figure out what is the smallest distro to possibly use and still get X11 |
| 03:10 | Goophy | You can make any distro pretty minimal if you want to. |
| 03:10 | Goophy | But archlinux or debian is probably the easiest. |
| 03:11 | donovang | I tried out the debian from the installer and it would only bring a terminal up over the serial interface |
| 03:12 | donovang | Are there are a series of packages I can install under the headless debian to get it to output on the hdmi port ? |
| 03:13 | donovang | wow - the ubuntu installer just made it to a prompt asking if i'd like slim+awesome. pretty legit. ubuntu might work pretty well. |
| 03:13 | Goophy | You used the net-install? |
| 03:13 | donovang | Yeah |
| 03:13 | Goophy | Ubuntu is a huge monster and hell to clean up. |
| 03:14 | donovang | Yeah - it's pretty involved. I run Debian on my other machines and really like it - I've been wanting to move my cubox over to it |
| 03:14 | Goophy | The net-install is probably configured to be headless, there shouldn't be anything else than changing the boot arguments. |
| 03:14 | donovang | I've been running the shipped ubuntu on my cubox for a year, now. Very excited about upgrading. |
| 03:14 | donovang | Ah - awesome |
| 03:14 | donovang | Okay |
| 03:15 | donovang | So I should go hunt around on the debian wiki to find the correct boot options and then follow instructions on the cubox wiki to do the actual modification ? |
| 03:17 | donovang | eek - the ubuntu installation is currently unpacking kerberos, heimdal, etc. eek :) |
| 03:17 | Goophy | Check the cubox-wiki at least. |
| 03:17 | donovang | K |
| 03:17 | Goophy | I can't remember if you need to initialize the dove-driver for cubox or if hdmi is active from boot. |
| 03:26 | donovang | wow - lots of packages for ubuntu. still installing. |
| 03:50 | donovang | okay i'm an idiot. looks like the default boot parameters tell the cubox to emit 1080p and my cheap TV is only 720p |
| 03:50 | donovang | I guess I'll go mod that and see if i have any luck |
| 03:56 | donovang | it looks like there are two lcd parameter variables: lcd0 and lcd1 - - does this mean that there is some crazy way to do dual heads on cubox ? |
| 04:39 | donovang | HA - got it. had to compile a new boot.scr |
| 04:40 | donovang | Does anyone know what the lcd1 variables are for in contrast to the lcd0 variables in the boot.scr ? |
| 06:11 | dbsx | _rmk_: I have been reading some mail at patchwork, I begin to see the problem. What is the age of those involved? |
| 06:13 | _rmk_ | dbsx: surprise, I'm awake at this unearthly hour probably because of the stress of dealing with this |
| 06:14 | _rmk_ | I've no idea, but it seems like they may as well be single-digit ages |
| 06:31 | _rmk_ | I also have IRC logs which show Mark agreeing to this approach, which makes his statement against my latest set of patches soo idiotic its untrue |
| 06:44 | _rmk_ | 16:34 < broonie> Do things not hang together if ou create the links like he has |
| 06:44 | _rmk_ | in haswell_dais? |
| 06:44 | _rmk_ | 16:35 < broonie> With the dummy CODEC on the FE and the dummy CPU on the BE? |
| 06:44 | _rmk_ | 16:35 < rmk> well, if I'm reading it correctly, it has multiple frontends connected to two backends and I can't work out how the frontends are connected backends |
| 06:44 | _rmk_ | 16:36 < broonie> Yes, that's what it should be doing. |
| 06:44 | _rmk_ | 16:37 < rmk> the problem I have is the same old problem: how do I know which backend(s) are active from the frontend's perspective? |
| 06:44 | _rmk_ | 16:37 < broonie> They're hooked in via the Playback VMixer AFAICT (I can't run this stuff obviously). |
| 06:44 | _rmk_ | 16:38 < broonie> I'd expect the BE to do the caring but I know you need to enable them simultaneously. |
| 06:44 | _rmk_ | 16:38 < broonie> So I'd have the BEs set flags prior to being powered |
| 06:45 | _rmk_ | 16:38 < broonie> Then check in the FE. |
| 06:45 | _rmk_ | ... |
| 06:45 | _rmk_ | 16:41 < rmk> so, I need to put two DAI drivers in the CPU level, a DAI link to setup the frontends, DAPM links to connect the front end streams to the back ends yes? |
| 06:45 | _rmk_ | 16:42 < broonie> Yes. |
| 06:45 | _rmk_ | 16:44 < rmk> and I can register the front end DAI driver separately from the two backends? |
| 06:45 | _rmk_ | 16:44 < rmk> via two snd_soc_register_component |
| 06:45 | _rmk_ | 16:45 < broonie> That should be possible, yes. |
| 06:45 | _rmk_ | 16:49 < rmk> oh, another question |
| 06:46 | _rmk_ | 16:49 < rmk> .dynamic in the dai link structure, that's for backends only, right? |
| 06:46 | _rmk_ | 16:50 < broonie> Think so, yes. |
| 06:46 | _rmk_ | (that turned out to be false) |
| 06:46 | _rmk_ | 17:53 < rmk> no, this can't work, all the DAI links have to be registered in one place and one place only. |
| 06:46 | _rmk_ | 17:53 < rmk> that's at the soc_card level |
| 06:47 | _rmk_ | that was from August 4th. |
| 06:55 | _rmk_ | oh, I missed this: |
| 06:55 | _rmk_ | 16:29 < broonie> I have a pretty good idea of how I'd expect to see the hardware represented - two BEs for the DAIs connected to a FE for the DMA. |
| 06:55 | _rmk_ | 16:29 < broonie> Probably just hard wired, or perhaps with a soft switch between the two. |
| 07:16 | dbsx | rmk: I read that. Again I sympathize. False assertions cost one ridiculous amounts of time. No info is better than false info. |
| 07:32 | _rmk_ | I quite agree, and I've wasted copious amounts of time on this |
| 09:46 | dv_ | _rmk_: you deserve a beer or smth for putting up with this :) |
| 09:53 | _rmk_ | dbsx & dv_: thanks for your positive comments. |
| 10:16 | jnettlet_ | does this mean there are is more drm nonsense going on? |
| 10:51 | _rmk_ | jnettlet_: no, this is the audio stuff |
| 10:54 | _rmk_ | jnettlet_: the continuing saga of asoc, the problems it has and that it doesn't seem to matter what I say about the technical details of our controller, it just goes in one ear and out the other, and then the same old statements get made which I've already explained why those statements can't be done. |
| 10:56 | _rmk_ | jnettlet_: that's been going on for four weeks now on the mailing lists, and some of my frustration with it comes from as far back as May when I started looking at getting this into upstream (which is where the "you want to use two CPU DAIs" "ok, now try using DPCM" stuff came from. |
| 10:56 | _rmk_ | I'm now being told to go back to the two CPU DAIs solution, which has no guarantee that we can enable both I2S and SPDIF simultaneously if we want that |
| 10:57 | _rmk_ | jnettlet_: I can quite see why you guys decided to throw in the towel with asoc and just hack your stuff out of mainline. |
| 10:59 | _rmk_ | having spent three months on and off with this, getting nowhere, with very little in the way of constructive help (more a case of a stream of false information) I think I'm at the point of doing the same. |
| 11:21 | dv_ | what did linus and andrew say? |
| 11:50 | _rmk_ | dv_: nothing. |
| 12:15 | jnettlet_ | _rmk_: I definitely feel your pain. It seems like a lot of the arm solutions are being derived from one or two SOC's implementations and then shoe horning the rest in around them. |
| 12:17 | jnettlet_ | One of our additional problems is that we don't want to expose every damn control a codec provides to us into userspace then let userspace sort it out. |
| 12:18 | dbsx | At < 3.5 the kernel worked on my Dreamplugs, 3.5, 3.9, 3.10 are a nogo unless I backstitch the old setup code. This means that there is something wrong in the DP device tree or the the DT startup code. So kernels work on DPs since 2.6.? and seem to be getting buggier since 3.1. |
| 12:19 | jnettlet_ | My decision for our hdmi audio is to make a completely separate PCM device. Internal Audio gets one PCM, hdmi gets one. |
| 12:20 | jnettlet_ | dbsx: this is quite timely for me thanks. I just started looking into putting a new kernel on my Verbatim Mediashare which uses a similar kirkwood soc |
| 12:25 | dbsx | jnettlet_: There are a stack of different hardware versions of the DP. I had them all (about 30 Dreamplugs) working on 3.18, for one reason or another the the comapny that uses them needed to upgrade the kernel for a new USB device. Some worked, some didn't I eventually got lucky with 3.9 and some random patches and hacking. It still needs to be tested on some of the more recent DPs. |
| 12:26 | dbsx | 3.1.8 |
| 12:51 | _rmk_ | dbsx: it's a shame more people aren't actively reporting problems like that |
| 12:52 | _rmk_ | I think there's the overall view that the transition to DT is going nice and smoothly, and there's very few problems with it. |
| 12:56 | dbsx | DT has not gone smoothly for this LBD. |
| 13:09 | jnettlet_ | dbsx: they are all kirkwood soc's though right? |
| 13:09 | dbsx | yes |
| 13:12 | jnettlet_ | This is what mine identifies as. CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053977 |
| 13:12 | jnettlet_ | Machine: Feroceon-KW |
| 13:13 | jnettlet | 13:13 * jnettlet_ wonders if there is a #marvell-soc channel |
| 13:14 | _rmk_ | well, that's a cubox kernel with dual dai's building |
| 13:15 | jnettlet_ | _rmk_: are you clocking them separately? |
| 13:15 | dbsx | DReamplugs: SoC: Kirkwood 88F6281_A0 |
| 13:15 | _rmk_ | jnettlet: the cubox doesn't use audio block 0 for anything |
| 13:16 | _rmk_ | what the ASoC people want is two DAIs for audio block 1, one for I2S the other for SPDIF |
| 13:16 | _rmk_ | which, in my mind, is totally broken |
| 13:16 | jnettlet_ | oh so this is just a cubox solution |
| 13:18 | _rmk_ | well, the other audio block is just a duplicate but without spdif |
| 13:18 | _rmk_ | in the case of dove. |
| 13:18 | jnettlet_ | dove doesn't use Marvell's wondrous sram implementation for any of the audio blocks? |
| 13:19 | jnettlet_ | I was thinking they were avoiding some pain. To be honest I have steered clear of the dove audio configs |
| 13:22 | jnettlet_ | _rmk_: just looked at the diagrams. I agree with you, two DAI's for a single audio block does seem completely broken. |
| 13:32 | _rmk_ | ... 2nd attempt |
| 13:34 | _rmk_ | Value at address 0xF10B5100 (0xb6ff9100): 0x11093 |
| 13:34 | _rmk_ | looks to be the right value in that register |
| 13:35 | _rmk_ | and it appears to produce audio |
| 22:14 | shesselba | dbsx: current mainline dts is based on CuBox ES which has w25q32, IIRC later ones have n25q032; also CuBox Pro have 2G. Also, non-ES have uSD card detect connected to correct mpp, no need for the gpio workaround |