| 12:24 | _rmk | 12:24 * _rmk_ notes a single patch for drm-plane support for imx-drm has been merged via staging into mainline |
| 12:27 | _rmk_ | so I can now merge that stuff into my cubox-i branch, which gets us overlay support |
| 12:28 | _rmk_ | I think I'll cherry-pick it rather than merging it, because there's loads of other unrelated stuff before it. |
| 12:29 | _rmk_ | of course, once -rc1 is out and pull this stuff forward, those commits will vanish. |
| 12:33 | jnettlet | does that mean I should stop merging your enormous patchset into my tree, or continue? |
| 12:33 | jnettle | 12:33 * jnettlet has to get dv_ something to play with for the weekend. |
| 12:35 | _rmk_ | continue for the time being... I doubt this is going to be finished today |
| 12:35 | jnettlet | ok |
| 12:38 | _rmk_ | there's quite a number of patches to the imx-drm stuff - 11 of them are from that series you pointed me at, others are a result of some of my own bug reports, others are stuff that various static checker projects have found |
| 13:28 | _rmk_ | ok, that's the tree reorganised with imx-drm stuff in a separate branch to the cubox-i stuff, so there's now independence between the two :) |
| 13:29 | _rmk_ | and it seems to boot, but how stable is it... that's the question... |
| 13:36 | rabeeh | svere: got C1? |
| 13:37 | svere | svere: that's why i'm here (still at work) |
| 13:37 | svere | gna |
| 13:37 | svere | rabeeh: nope still at customs |
| 13:37 | svere | rabeeh: i sent you an email |
| 13:37 | Bluerise | heh |
| 13:37 | Bluerise | German customs... |
| 13:38 | rabeeh | Bluerise: i think we had customs issue with you too? |
| 13:39 | rabeeh | what was the magic that Riki did to get it out? |
| 13:39 | Bluerise | Yes |
| 13:39 | Bluerise | Nothing |
| 13:39 | Bluerise | I sent them a link to a raspberry pi and told them "it's similar to that one" |
| 13:39 | rabeeh | hehe |
| 13:39 | Bluerise | and, I sent a like to the carrier one blog entr |
| 13:39 | svere | rabeeh: for german customs the best would be to declare value of the shipping as e.g.50$ |
| 13:39 | Bluerise | y |
| 13:39 | Bluerise | yeah |
| 13:39 | Bluerise | Customs said "there's no way this is $0.01" |
| 13:40 | Bluerise | they wanted to see a _real_ order |
| 13:40 | svere | rabeeh: customs suspects that the value is higher than 10cent and keeps the parcel |
| 13:40 | Bluerise | yeah. |
| 13:40 | Bluerise | I messaged you, rabeeh, but you weren't there. :/ |
| 13:41 | svere | if you send them a value declaration of $50 (just like the similar cubox-i solo) |
| 13:41 | Bluerise | So, I sent them the links (carrier-one and raspberry), said it's similar, and then it went through |
| 13:41 | Bluerise | was like 10-25 euros customs (I don't remember anymore) |
| 13:42 | svere | Bluerise: its just dhl, customs should have been zero |
| 13:42 | Bluerise | hm? |
| 13:42 | Bluerise | maybe |
| 13:42 | Bluerise | not sure.. |
| 13:42 | svere | in germany and EU the duty free limit is 150EUR including shipping |
| 13:42 | Bluerise | that's how they make money ;) |
| 13:43 | Bluerise | Israel and EU? |
| 13:43 | svere | if solidrun declares the value as $50 + shipping the parcel gets through and you pay nothing |
| 13:43 | Bluerise | Hmm |
| 13:43 | svere | Bluerise: non-EU --> EU |
| 13:43 | Bluerise | Ok. |
| 13:43 | Bluerise | Well, I paid it, I have it, that's all that matters for me currently. |
| 13:44 | _rmk_ | rabeeh: is there a reason why the method to reflash the cubox without needing to fiddle with power or buttons isn't public knowledge? |
| 13:44 | svere | had a longer chat with the guy handling this here in the company ;-) |
| 13:44 | rabeeh | _rmk_: no. |
| 13:44 | rabeeh | no reason |
| 13:44 | svere | Bluerise: i wish i were in that state already |
| 13:44 | rabeeh | it's what we do for manufacturing; but looks lots of people are stuck with this |
| 13:44 | Bluerise | svere: Heh. |
| 13:45 | rabeeh | on the v1 version the mechanism wasn't there; but was added on v2 version |
| 13:45 | rabeeh | _rmk_: anyhow i prepared an installer for taz so he won't be bugging people on the channel again |
| 13:46 | _rmk_ | yea. my problem is that when people don't get responses from other places they tend to start bugging me directly |
| 13:47 | Bluerise | _rmk_: Did you hear back from the FDT GPL/BSD license thing? |
| 13:47 | Bluerise | not trying to be penetrant, just interested in updates. :) |
| 13:47 | rabeeh | _rmk_: just redirect back to me; i'll take care of them. |
| 13:47 | rabeeh | i'll ask taz next time on irc to take it easy... |
| 13:48 | _rmk_ | no - Grant's still rather busy, he's only just published initial proceedings from the arm mini-summit yesterday |
| 13:48 | Bluerise | ok |
| 13:48 | Bluerise | http://lists.denx.de/pipermail/u-boot/2013-November/166521.html |
| 13:50 | _rmk_ | rabeeh: that wasn't specific to here, it's just what generally happens. For instance, I have someone with some NOR flash problem who's been trying to get a response on the linux-mtd list... he's now turned to mailing me privately about it despite I've never responded (because my knowledge of NOR flash has been swapped out from my brain!) |
| 13:52 | svere | _rmk_: you should upgrade your memory capacity... ;-) |
| 13:52 | sver | 13:52 * svere runs and hides |
| 13:53 | _rmk_ | svere: heh. rmk clones would help. |
| 13:54 | _rmk_ | SMRs - symetric multi-rmks |
| 13:55 | _rmk_ | then I could work on the omap dma driver and imx-drm at the same time without having to schedule between them. :) |
| 13:56 | rabeeh | _rmk_: i see it more like hyperthreading rather than smr |
| 13:57 | rabeeh | i can image that you are taking the extra few seconds on building the omap dma to hack the imx-drm |
| 13:57 | rabeeh | i mean the extra few seconds waiting for the build to complete to hack the imx-drm |
| 14:07 | svere | _rmk_: just out of curiosity how fast are your context-switches? |
| 14:27 | _rmk_ | not always as fast as I'd like :p |
| 14:29 | _rmk_ | $ git log --pretty=oneline origin..cubox-i|wc -l |
| 14:29 | _rmk_ | 91 |
| 14:34 | _rmk_ | Grant's now published his writeup from the ARM minisummit |
| 14:35 | _rmk_ | its on lakml and will probably hit lwn soon. |
| 15:54 | lioka | rabeeh: btw, what's with hdmi-cec pin on c1 ? when c1 is plugged into tv or hdmi receiver, even not powered, cec stops working on every connected device. |
| 15:57 | _rmk_ | that sounds pretty annoying |
| 15:57 | lioka | oh, that's not just me, right ? |
| 15:57 | _rmk_ | I've not looked at cec stuff yet |
| 15:58 | _rmk_ | when I get a moment, I'll stick a scope on that hdmi pin and see what it's doing |
| 16:09 | jnettlet | lioka, does it do that if the board is just booted to u-boot? |
| 16:09 | lioka | jnettlet: 'even not powered' |
| 16:09 | jnettlet | lioka, not powered? that seems not possible. |
| 16:10 | jnettlet | but we should figure out what is going on so rabeeh can fix it if it is a hardware issue |
| 16:11 | lioka | i've lost all my precious devices from tv menu, and tried to get back for half hour maybe, until plugged off c1 from hdmi input |
| 16:15 | _rmk_ | lioka: note that plugged-in-but-powered-off can be different from plugged-in-but-not-driving-the-signal |
| 16:19 | _rmk_ | if I had to guess, that guess would be that when the c1 is plugged in but powered off, it ends up pulling the CEC line low through the ESD diodes in the SoC. |
| 16:20 | _rmk_ | so powering it up yet not having the line driven should make things work again, so jnettlet's suggestion is a good one to check |
| 16:25 | liok | 16:25 * lioka still at work, will try in few hours |
| 17:56 | jnettlet | _rmk_, /soc/aips-bus@02000000/hdmi@0120000: could not get #crtc-cells for /soc/ipu@02400000 |
| 17:56 | jnettlet | imx-drm imx-drm: failed to bind 120000.hdmi (ops hdmi_ops): -22 |
| 17:59 | _rmk_ | hmm |
| 18:00 | jnettle | 18:00 * jnettlet has added more debug output. at first I thought it was the audio drivers fighting each other. |
| 18:02 | _rmk_ | which kernel are you porting this onto? |
| 18:02 | jnettlet | 3.10 |
| 18:02 | jnettlet | there must be a patch upstream that defaults that to 1 |
| 18:07 | _rmk_ | and at the bottom of arch/arm/boot/dts/imx6qdl.dtsi, where ipu1 is defined, do you have #crtc-cells = <1>; ? |
| 18:08 | _rmk_ | I don't see anything between v3.10 and latest |
| 18:09 | jnettlet | _rmk_, never mind. One of the freescale guys has a patch here that completely screws that part of device-tree |
| 18:09 | _rmk_ | heh |
| 18:16 | jnettlet | a littler further. imx-drm imx-drm: failed to bind 120000.hdmi (ops hdmi_ops): -517 |
| 18:16 | jnettlet | it keeps getting a probe deferral |
| 18:21 | lioka | yep. c1 blocks cec, no matter, powered on or off. |
| 18:21 | jnettlet | _rmk_, your hdmi audio driver requires CONFIG_SND_SOC |
| 18:26 | _rmk_ | why do you think that? |
| 18:33 | jnettlet | it needs snd_pcm_new |
| 18:33 | jnettlet | and snd_pcm_set_ops |
| 18:34 | _rmk_ | both of those are ALSA functions, not ASoC functions |
| 18:36 | _rmk_ | ah, I may be missing a select on SND_PCM |
| 18:37 | jnettlet | but I had SND_PCM selected and they came up unresolved. I wonder if the ARCH is arm they are ignored |
| 18:37 | _rmk_ | how did you end up with SND_PCM selected? |
| 18:38 | jnettlet | it was default for this config |
| 18:39 | _rmk_ | does it stay on in your .config? I suspect its turned itself off |
| 18:39 | jnettlet | I bet CONFIG_SND_ARM=y is what short circuits CONFIG_SND_PCM |
| 18:39 | jnettlet | nope it is on |
| 18:40 | _rmk_ | CONFIG_SND_PCM=y builds snd-pcm, which is made up from pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o and pcm_memory.o |
| 18:40 | _rmk_ | snd_pcm_set_ops is provided by pcm_lib.c |
| 18:40 | jnettlet | yep, but it isn't linking in properly. |
| 18:40 | _rmk_ | snd_pcm_new is provided by pcm.c |
| 18:40 | jnettlet | maybe there was something that was fixed between 3.10 and 3.12 |
| 18:41 | _rmk_ | Maybe SND_PCM=m ? |
| 18:41 | jnettlet | prepare for the scroll spam. |
| 18:41 | jnettlet | This is my .config SND chunk. |
| 18:41 | jnettlet | CONFIG_SOUND=y |
| 18:41 | jnettlet | # CONFIG_SOUND_OSS_CORE is not set |
| 18:41 | jnettlet | CONFIG_SND=y |
| 18:41 | jnettlet | CONFIG_SND_TIMER=m |
| 18:41 | jnettlet | CONFIG_SND_PCM=m |
| 18:41 | jnettlet | CONFIG_SND_HWDEP=m |
| 18:41 | jnettlet | CONFIG_SND_RAWMIDI=m |
| 18:41 | jnettlet | # CONFIG_SND_SEQUENCER is not set |
| 18:41 | jnettlet | # CONFIG_SND_MIXER_OSS is not set |
| 18:41 | jnettlet | # CONFIG_SND_PCM_OSS is not set |
| 18:41 | jnettlet | # CONFIG_SND_HRTIMER is not set |
| 18:41 | jnettlet | # CONFIG_SND_DYNAMIC_MINORS is not set |
| 18:41 | jnettlet | CONFIG_SND_SUPPORT_OLD_API=y |
| 18:42 | jnettlet | CONFIG_SND_VERBOSE_PROCFS=y |
| 18:42 | jnettlet | # CONFIG_SND_VERBOSE_PRINTK is not set |
| 18:42 | jnettlet | # CONFIG_SND_DEBUG is not set |
| 18:42 | jnettlet | # CONFIG_SND_RAWMIDI_SEQ is not set |
| 18:42 | jnettlet | # CONFIG_SND_OPL3_LIB_SEQ is not set |
| 18:42 | jnettlet | # CONFIG_SND_OPL4_LIB_SEQ is not set |
| 18:42 | jnettlet | # CONFIG_SND_SBAWE_SEQ is not set |
| 18:42 | jnettlet | # CONFIG_SND_EMU10K1_SEQ is not set |
| 18:42 | jnettlet | CONFIG_SND_DRIVERS=y |
| 18:42 | jnettlet | # CONFIG_SND_DUMMY is not set |
| 18:42 | jnettlet | # CONFIG_SND_ALOOP is not set |
| 18:42 | jnettlet | # CONFIG_SND_MTPAV is not set |
| 18:42 | jnettlet | # CONFIG_SND_SERIAL_U16550 is not set |
| 18:42 | jnettlet | # CONFIG_SND_MPU401 is not set |
| 18:42 | jnettlet | # CONFIG_SND_ARM is not set |
| 18:42 | _rmk_ | >>>CONFIG_SND_PCM=m<<< |
| 18:42 | jnettlet | CONFIG_SND_SPI=y |
| 18:42 | jnettlet | CONFIG_SND_USB=y |
| 18:42 | jnettlet | CONFIG_SND_USB_AUDIO=m |
| 18:42 | jnettlet | # CONFIG_SND_USB_UA101 is not set |
| 18:42 | jnettlet | # CONFIG_SND_USB_CAIAQ is not set |
| 18:42 | jnettlet | # CONFIG_SND_USB_6FIRE is not set |
| 18:42 | jnettlet | # CONFIG_SND_SOC is not set |
| 18:42 | jnettlet | # CONFIG_SOUND_PRIME is not set |
| 18:42 | jnettlet | that gives unresolved symbols for snd_pcm* |
| 18:43 | _rmk_ | yea, it needs CONFIG_SND_PCM=y |
| 18:43 | jnettlet | ah okay. |
| 18:43 | jnettlet | sorry |
| 18:44 | jnettlet | it won't build with =y |
| 18:44 | jnettlet | keeps kicking back to =m |
| 18:46 | jnettlet | that is why I was so confused. I was thinking I already changed CONFIG_SND_PCM=y |
| 18:55 | neofob_home | jnettlet: please pastebin |
| 18:55 | jnettlet | neofob_home, yes I know this was just a quick one off |
| 18:56 | neofob_home | just want to help ;) |
| 18:56 | jnettlet | it was _rmk_ and myself just chatting and wouldn't interrupt anyone elses conversations |
| 19:10 | lioka | jnettlet: CONFIG_SND_TIMER, _HWDEP, _RAWMIDI, _COMPRESS_OFFLOAD -- i've set them all to =y, few hours earlier and by same reason :] |
| 19:12 | jnettlet | _rmk_, okay your patches are merged and working. Although the FSL tree has an entirely different IPU driver that was conflicting. It is going to take some sorting out before I can sort this mess out. |
| 19:13 | jnettle | 19:13 * jnettlet shakes his head. duh. sorting out before I can publish this mess |
| 19:13 | jnettlet | :-) |
| 19:13 | jnettlet | dv_, ^^ sorry nothing yet, maybe in the morning. |
| 19:14 | dv_ | np, busy with other things atm anyway |
| 20:40 | _rmk_ | ok, let me probe what's going on with the CEC line |
| 20:42 | _rmk_ | hmm, it's low. |
| 20:43 | _rmk_ | I wonder which pad it's routed to on the boards |
| 20:46 | _rmk_ | hmm, I think its EIM_A25 |
| 20:47 | _rmk_ | there's two possibilities. Either EIM_A25 or KEY_ROW2. |
| 20:48 | _rmk_ | Rabeeh's original patches show KEY_ROW2 connected to CAN1_RXCAN, which I'm also reflecting, and that's an input, so it wouldn't drag the pin down. |
| 20:48 | rabeeh | _rmk_: KEY_ROW2 |
| 20:48 | rabeeh | and SD3_CLK / SD3_CMD now holds the flex can signals |
| 20:48 | lioka | is it low or total zero ? |
| 20:49 | _rmk_ | lioka: its not 0v, it's less than .5v tho |
| 20:49 | rabeeh | that's the fix !! |
| 20:49 | rabeeh | guys - you are wasting your time on this; just ask what the issue is and i will tell |
| 20:50 | liok | 20:50 * lioka tought that line grouned accidentally |
| 20:50 | rabeeh | it is |
| 20:50 | lioka | rabeeh: i'm allears |
| 20:50 | _rmk_ | rabeeh: or, if you have a spreadsheet with the pin usage :) |
| 20:50 | rabeeh | ok |
| 20:50 | rabeeh | aaargh |
| 20:50 | _rmk_ | heh |
| 20:50 | rabeeh | you remind me i need to kick some butt around here for the imx6 som user manual |
| 20:50 | rabeeh | .pdf |
| 20:51 | rabeeh | anyhow; the issue is as follows - |
| 20:53 | rabeeh | the CEC line was mistakenly hooked to HDMI_TX_DDC_CEC |
| 20:53 | rabeeh | the pad name is HDMI_DDCCEC |
| 20:53 | rabeeh | now the mistake (that probably every one did; including utility and others) is hooking to this signals; since it's name is - |
| 20:53 | rabeeh | hdmi, tx (transmitter) ddc cec |
| 20:54 | rabeeh | now turns out that the reference design from freescale had a resistor on that line that you can either choose to ground it or hook it to the real CEC line |
| 20:54 | rabeeh | bottom line is that all the hardware manufacturers; including freescale R&D team did the same mistake once, and then fixed it to use KEY_ROW2 |
| 20:56 | _rmk_ | ok, lets see if that fixes it, then I'll fix it properly when I return from the pub later this evening |
| 20:57 | rabeeh | potentially if you would really really want to use CEC; you can remove the trace that comes into the CEC line and rewire it to the flex can rx that is on the 8pin header board |
| 20:58 | rabeeh | but i doubt someone on channel #cubox can do this since it requires surgeon hands |
| 20:59 | liok | 20:59 * lioka looks around for scalpel |
| 21:00 | lioka | which pin # is that ? |
| 21:00 | rabeeh | lioka: if your hands are really good i can send you a picture |
| 21:00 | _rmk_ | oh, so there's no point me changing the pinmux because it's wired wrong on our boards? |
| 21:01 | rabeeh | yes |
| 21:01 | rabeeh | you need to cut a wire; really really tiny one and then rewire the hdmi connector to the 8 pin header ! |
| 21:01 | Bluerise | and everyone did it wrong? |
| 21:01 | rabeeh | rewiret the hdmi connector CEC line to the 8 pin header |
| 21:01 | rabeeh | yes |
| 21:02 | _rmk_ | if you send photos then I can do that. |
| 21:02 | Bluerise | that's the funniest thing I read today |
| 21:02 | lioka | rabeeh: well, it would be good enough for me just not interfere with cec from other devices |
| 21:02 | rabeeh | Stephan got most of the imx6 boards around trying to get xbmc on |
| 21:02 | rabeeh | he told all of them got it wrong; and was fixed in the second step of the boards |
| 21:02 | _rmk_ | right, off to the pub. :) |
| 21:03 | rabeeh | _rmk_: if you do it, we will rename the c1 board after your name |
| 21:03 | rabeeh | :) |
| 21:03 | Bluerise | The _rmk_ ? |
| 21:03 | Bluerise | harhar. |
| 21:03 | _rmk_ | I suspect it'll need the microsom popped off to cut the track... |
| 21:03 | rabeeh | yes |
| 21:04 | _rmk_ | while I can reach down there with the scope probe, cutting a track is a different matter altogether |
| 21:04 | _rmk_ | well, cutting a track is the easy bit. the hard bit is to avoid cutting other tracks :) |
| 21:05 | lioka | exactly :] |
| 21:05 | rabeeh | _rmk_: the even harder part is rewiring |
| 21:05 | rabeeh | i'll send you a picture where it would be easiest to cut |
| 21:05 | _rmk_ | back in about 3ish hours |
| 21:05 | rabeeh | enjoy |
| 21:05 | _rmk_ | thanks |
| 21:06 | neofob_home | _rmk_: have some real ale! |
| 21:06 | rabeeh | just don't get drunk and cut your hand |
| 21:06 | rabeeh | your hands are precious to the whole community |
| 21:06 | Bluerise | I wonder if his hands are better when he's drunk.. |
| 21:06 | rabeeh | Bluerise: oh; that's a good one |
| 21:06 | rabeeh | like surgeon with tourette syndrome |
| 21:07 | Bluerise | yeah |
| 21:07 | Bluerise | I guess I couldn't cut that. |
| 21:07 | Bluerise | or rewire it. |
| 21:12 | rabeeh | http://dl.dropboxusercontent.com/u/72661517/tbr/hdmi-tx-ddccec.jpg |
| 21:12 | rabeeh | _rmk_: so above is the link |