| 04:14 | dbsx | Does anyone have a Cubox pro that they can test the DT memory ? |
| 11:32 | dbsx | shesselba,w25q32 vs n25q032 does not seem to matter much, someone with pro needs to test the memory and what/where do I find info on the gpio workaround. |
| 11:59 | _rmk_ | dbsx: its already in mainline |
| 12:08 | dbsx | So thatjust leaves the Cubox pro to be checked. |
| 12:17 | TrevorH1 | dbsx: I have a 2GB pro running a 3.10 ml kernel, what did you want checked? |
| 12:19 | jnettlet_ | Is everyone just running an upstream 3.10 kernel at this point? |
| 12:19 | jnettlet_ | well minus kernel hackers |
| 12:22 | dbsx | TrevorH1: see http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=1454 |
| 12:22 | dbsx | just see if the pro shows up 2G of memory |
| 12:40 | dbsx | Yet another question: in my 3.11-rc7 dmesg I get - |
| 12:40 | dbsx | sdhci-pltfm: SDHCI platform and OF driver helper |
| 12:40 | dbsx | mmc0: no vqmmc regulator found |
| 12:40 | dbsx | mmc0: no vmmc regulator found |
| 12:40 | dbsx | mmc0: new high speed SDHC card at address b368 |
| 12:40 | dbsx | Is this expected and/or is it harmless |
| 12:43 | TrevorH1 | dbsx: `free -m` shows 2024MB visible. Not sure if I have the options you want turned on - anything I should look for in /proc/config/gz in particular? |
| 12:45 | dbsx | TrevorH1: one minute |
| 12:54 | dbsx | can you try # hd /proc/device-tree/memory/reg |
| 12:56 | TrevorH1 | 00000000 00 00 00 00 40 00 00 00 40 00 00 00 40 00 00 00 |....@...@...@...| |
| 12:57 | dbsx | hd /proc/device-tree/memory/reg |
| 12:57 | dbsx | 00000000 00 00 00 00 20 00 00 00 20 00 00 00 20 00 00 00 |.... ... ... ...| |
| 12:59 | dbsx | So I guess your device tree is different to mine. Do you have the dove-cubox.dts ? |
| 13:13 | TrevorH1 | isn't that difference exactly what you'd expect from 1GB vs 2GB? |
| 13:33 | dbsx | yes |
| 13:33 | dbsx | It means no problem if your source DT says 1G |
| 13:35 | TrevorH1 | the dts file just says the same thing: reg = <0x00000000 0x40000000>; |
| 13:43 | dbsx | perfect that is one gig. So the kernel is smart enough to grow that number to 2G. Hence we do not need a separate DTS for the Pro |
| 15:03 | lubiana | moin |
| 15:12 | shesselba | dbsx: the kernel isn't smart enough to grow it, it is too dumb to parse it from DT. we are still in progress of moving to full DT, mem size is still parsed from internal registers |
| 15:13 | dbsx | ok, thanks |
| 16:35 | _rmk_ | shesselba: looks like there's a mistake with the tda998x patches... |
| 16:35 | _rmk_ | case DRM_MODE_DPMS_OFF: |
| 16:35 | _rmk_ | /* disable audio and video ports */ |
| 16:35 | _rmk_ | reg_write(encoder, REG_ENA_AP, 0x00); |
| 16:36 | _rmk_ | that register write should've been deleted, otherwise on the first dpms-off event, we disable audio never to have it re-enabled |
| 16:40 | _rmk_ | yep, I had that write commented out in my patches |
| 17:27 | shesselba | _rmk_: mea culpa, I must have messed it up. sorry |
| 20:08 | _rmk_ | shesselba: probably explains why I had no audio when I tried to get 48kHz stuff working too :( |
| 20:09 | shesselba | _rmk_: yeah, looks like I messed it up when I rebased them. Sorry for the extra work |
| 20:09 | _rmk_ | as far as kirkwood audio stuff... I can't see this making any progress anytime soon. |
| 20:10 | shesselba | yeah, I am reading the discussion. |
| 20:10 | shesselba | ridiculous |
| 20:13 | _rmk_ | I'm thinking we need a tree which tracks mainline which we can push this stuff into, thereby making these issues irrelevant. |
| 20:14 | shesselba | yeah, dove's testbed is currently mainline (or rabeeh's tree if you are with cubox) |
| 20:18 | shesselba | you have something in mind? |
| 20:24 | _rmk_ | only in so far as cloning mainline and then dumping the DRM and the audio stuff into it for now |
| 20:26 | _rmk_ | it'll need to be "as best mainline-quality as we can manage" though to stop it turning into just another git tree |
| 20:30 | shesselba | ok |
| 20:45 | dv_ | _rmk_: are others agreeing with your view? |
| 20:46 | dv_ | is it a situation where one person is simply refusing to acknowledge evidence? |
| 20:49 | _rmk_ | unfortunately, the only people who I'm aware have been working on this stuff are shesselba, Jean-Fran?ois and myself - everyone else doesn't care about it, so they're not going to say anything. |
| 20:50 | _rmk_ | Liam seems to be too busy to look at anything - he was saying he'd finish off that DPCM driver "in a week" back in May and afaik its still not finished. |
| 20:50 | _rmk_ | I don't know about Lars-Peter yet |
| 20:51 | _rmk_ | I suspect as Mark is replying, he'll just ignore it |
| 20:55 | _rmk_ | in the mean time, I've dismantled my spdif-to-rca box, and I've been modifying the output filters: I took the caps off the subwoofer channel (all output channels are identical) so I could measure them and worked out the filter characteristic... eww. |
| 20:55 | _rmk_ | not only do they give a 1V p-p signal 8.2dB of gain, but they roll it off at around 10kHz |
| 20:57 | _rmk_ | and the output opamps run off a single +5v supply. |
| 20:58 | _rmk_ | 0dBFS clips solidly, as does anything down to somewhere around -18dBFS |
| 20:58 | _rmk_ | no, -8dBFS sorry |
| 21:00 | jnettlet_ | _rmk_: I agree with a "branched" kernel tree. I want to have a branch tracking master as well as a 3.10.y branch for less adventurous applications. |
| 21:00 | jnettlet_ | I have been sorting through OLPC patches the last few days trying to sort out the same thing |
| 21:00 | _rmk_ | changing one component (actually, soldering a resistor over the top of another resistor) has resulted in me giving two of the channels a gain of 0.1dBFS and a cut-off of around 25kHz |
| 21:01 | _rmk_ | err, gain of 0.1dBFS? no, just 0.1dB ! |
| 21:03 | _rmk_ | jnettlet: I did mention to Mark that OLPC had problems. Don't quote me on this, but I think he claimed that he looked but couldn't see anything, and concluded it must all be userspace problems. |
| 21:04 | jnettlet_ | _rmk_: yeah the email that got forwarded to the devel list was something along those lines. |
| 21:05 | jnettlet_ | He didn't like that we ended up minimizing controls in the asoc driver instead of userspace, yet couldn't explain why when we didn't do this we got unexplained knob twiddling in the codec that led to no sound. |
| 21:05 | _rmk_ | "< broonie> Looking at the OLPC code AFAICT their problems have mostly been userspace tooling; looks like the sort of things people did on smartphones years ago." |
| 21:06 | jnettlet_ | after many dev hours we decided to carve it up because we had a product to ship. |
| 21:06 | jnettlet_ | they are angry because we don't use pulseaudio |
| 21:08 | jnettlet_ | which was another problem that never got resolved as we brought our evidence about high cpu usage and got stuck between the alsa kernel devs refusing to fix it because it was an alsa userspace problem, and the alsa people saying it was a kernel problem. |
| 21:08 | jnettlet_ | since the XO used to be pretty self contained we just dumped pulseaudio and went on our merry way. |
| 21:09 | _rmk_ | yea, I see some unfortunate cpu usage with pulseaudio on the cubox too - especially if it starts doing sample rate conversion |
| 21:09 | _rmk_ | I have to set vlc to use alsa directly, otherwise it talks to pulse, sets a sample rate of 48kHz, and pulse then down-samples it to 44.1kHz |
| 21:11 | jnettlet_ | just one of the many idiosyncracies. That would actually benefit from libspeex being compiled with iwmmxt support. |
| 21:11 | _rmk_ | I also had another case of no audio today, the alsa device just wasn't even being opened - pkill pulseaudio sorted it. |
| 21:12 | jnettlet_ | I am not in front of my notes, but I think it uses MMX intrinsics so doesn't need any patches |
| 21:13 | _rmk_ | that was after a lot of sox use generating various wave patterns |
| 21:14 | jnettlet_ | I wonder if it was a specific audio rate that gummed up the works. |
| 21:14 | _rmk_ | sox was talking direct to alsa |
| 21:15 | jnettlet_ | through the pulse alsa plugin or direct to hardware? |
| 21:15 | _rmk_ | direct to hardware |
| 21:15 | _rmk_ | a bit of this: while :; do play -r96000 -c2 -b16 -n synth 60 sine 100/32000; done :) |
| 21:16 | jnettlet_ | yeah that makes pulse pretty upset. If something grabs the hardware when pulse expects to do something it pretty much losses its mind in my experience |
| 21:20 | jnettlet_ | Do we think a marvell-kernel account on github would be useful to track our outlying hackery? Seems if it ain't omap/tegra/snapdragon there isn't much love to be had. |
| 21:24 | jnettlet | 21:24 * jnettlet_ bbl |
| 23:29 | shesselba | _rmk_: I can think of a DT representation that will allow you to know if there is one or two codecs and on what interface the codec is |
| 23:30 | shesselba | but as Mark is circling around my suggestions while ACKing the same suggestions from Lars, I simply lost interest in repeating it over and over |
| 23:32 | _rmk_ | I have my own thoughts why that is - I think he's doing the same thing to me as well |
| 23:34 | shesselba | I have no clue how ASoC is supposed to work, but assuming you always use that DPCM (if it will ever work) |
| 23:34 | shesselba | can you link any number of BE codecs? |
| 23:34 | _rmk_ | my understanding is you can, because the links between them are just DAPM routes and widgets. |
| 23:35 | _rmk_ | you can even put a DAPM mux in there which select a backend codec under alsa mixer control |
| 23:35 | shesselba | ok, so the dummy codec is what allows you to mux/copy one single stream to one or more codecs |
| 23:36 | shesselba | if you have that audio-codecs/audio-codec-names (or call them link/link-names) properties, you can determine how many codecs are connected and where they are connected |
| 23:36 | _rmk_ | from what I can gather reading the code, the reason for splitting them in the 1 FE 1 BE case is to get rid of the automatic routing which the ASoC core sets up |
| 23:36 | shesselba | that is what larsc refers to when he is talking about "xlate support" |
| 23:37 | shesselba | hrr |