| 00:08 | _rmk_ | finally! |
| 00:08 | _rmk_ | no guard band displayed on the screen |
| 00:08 | _rmk_ | it helps if workarounds are implemented correctly |
| 00:27 | _rmk_ | git tree updates pushed out |
| 12:32 | rabeeh | jnettlet: just saw the prompt on HDMI; bravo :) |
| 13:04 | _rmk_ | well, there's something really wrong with this hdmi/ipu stuff in v3.12 |
| 13:04 | _rmk_ | at 800x600, the hdmi clock is being modulated ! |
| 13:04 | _rmk_ | maybe a PLL isn't properly locked |
| 13:07 | jnettlet | rabeeh, yeah. usb keyboard should work also, but it only polls the irq so can be a bit laggy. |
| 13:07 | rabeeh | _rmk_: what do you mean? |
| 13:07 | rabeeh | where are you measuring? |
| 13:07 | rabeeh | jnettlet: i'm just reading about usb keyboard support |
| 13:08 | _rmk_ | one of the tmds clock pins on the hdmi connector - my scope probe is small enough to get on those pads |
| 13:08 | rabeeh | which one do you have? |
| 13:08 | rabeeh | btw - there is some sort of modulation. |
| 13:08 | rabeeh | i have spectrum analyzer and i can see two frequencies |
| 13:09 | rabeeh | for 1080p; i can see 148.5 and another one slightly less; i think that they are doing some sort of two pole spread spectrum |
| 13:09 | _rmk_ | I only have a 60MHz scope so I can't look at the higher res modes, but it should manage to cope with 800x600 @ 40MHz pixel clock |
| 13:09 | rabeeh | is it a differential scope? |
| 13:10 | _rmk_ | and at that resolution the tv just sits there saying "I'm buggered if I care about this signal" |
| 13:10 | rabeeh | i mean the probe |
| 13:10 | _rmk_ | unfortunately not, but that doesn't matter when you have 500mV of signal |
| 13:11 | _rmk_ | its quite a clean clock except for the frequency/phase modulation on it |
| 13:11 | rabeeh | _rmk_: hdmi standard can tolerate 0.5% error in clock frequency |
| 13:11 | rabeeh | shesselba_away is a hero when it comes to hdmi |
| 13:11 | _rmk_ | well, its more than .5% |
| 13:11 | rabeeh | he probably can confirm that |
| 13:11 | rabeeh | what are you seeing? |
| 13:11 | rabeeh | is it on the u-boot? |
| 13:12 | _rmk_ | no, v3.12-rc kernels |
| 13:12 | rabeeh | ok |
| 13:12 | rabeeh | i can measure now on u-boot if you want |
| 13:12 | _rmk_ | I can't hold the scope probe on and take a photo of the scope screen :p |
| 13:12 | rabee | 13:12 * rabeeh powers up his brand new used Agilent scope |
| 13:12 | rabeeh | haha |
| 13:13 | rabee | 13:13 * rabeeh hooks his ps/2 mouse |
| 13:16 | jnettlet | rabeeh, have you done the hdmi eye test on this board yet? |
| 13:19 | rabeeh | jnettlet: not yet |
| 13:19 | rabeeh | emi first |
| 13:19 | jnettlet | so the signal problems could just be the phy needs tweaking |
| 13:19 | rabeeh | jnettlet: i can see what _rmk_ is talking about |
| 13:20 | rabeeh | it's unrelated to eye pattern |
| 13:20 | rabeeh | i don't think so |
| 13:21 | jnettlet | rabeeh, do you see the same thing under u-boot? |
| 13:22 | rabeeh | yes |
| 13:22 | rabeeh | jnettlet: what is the u-boot resolution? |
| 13:22 | rabeeh | 640x480? |
| 13:22 | jnettlet | 1024x768 |
| 13:22 | rabeeh | 60hz? |
| 13:22 | jnettlet | yep |
| 13:22 | jnettlet | well no |
| 13:22 | _rmk_ | well, if I had a better camera than an ixus, I might be able to photograph it |
| 13:23 | jnettlet | it is supposed to be 60hz but seems to be generating 52 |
| 13:23 | jnettlet | it is on the list. |
| 13:23 | rabeeh | this should be 65MHz? |
| 13:23 | _rmk_ | but the ixus refuses to not use the flash (if I turn it off it extends the shutter time and gives a shake warning) |
| 13:23 | _rmk_ | and the flash completely obliterates the scope display |
| 13:23 | jnettlet | don't have a webcam? |
| 13:24 | rabeeh | _rmk_: i'm seeing some 56.5227 MHz clock and then an internal clock of >240MHz |
| 13:26 | rabeeh | but i'm looking into only one of the differential lines |
| 13:26 | rabeeh | i can get my hand on the differential lines all together |
| 13:28 | jnettlet | rabeeh, once you finish up helping _rmk_, if you have a bit of time I would love to chat with you about the clock gating in u-boot |
| 13:34 | _rmk_ | ok. I got it. |
| 13:35 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/IMG_1545-adj.JPG |
| 13:35 | _rmk_ | notice how the left and right are pretty stable but the middle is fuzzy like there's a phase shift |
| 13:36 | rabeeh | the first thing i noticed is your oldie scope dude |
| 13:36 | rabeeh | analog? |
| 13:36 | _rmk_ | yep :) |
| 13:36 | rabeeh | i think you are seeing the modulation since there is an extremely high frequency one. |
| 13:36 | _rmk_ | Tektronix 2213A :) |
| 13:36 | rabeeh | hold on; i'm connecting my scope |
| 13:37 | rabeeh | Rigol has 50MHz for 400$ |
| 13:39 | rabeeh | jnettlet: go ahead |
| 13:39 | _rmk_ | it does okay for most stuff I fiddle with, but is becoming more of a problem as clock rates get higher, or I fiddle with airband radios (at 120MHz or so) |
| 13:39 | rabeeh | jnettlet: btw - i'm measuring 380mA on the 5V rail on u-boot prompt |
| 13:41 | _rmk_ | rabeeh: the weird thing I'm seeing is that some resolutions work fine (eg, 720p) but higher res or lower res are a problem (I put up about it on g+ last night) |
| 13:42 | jnettlet | rabeeh, well the short of the problem is when setting the values you originally had in your u-boot release to CCM_CCGR[1-6] we were seeing hardware hangs during init. |
| 13:42 | _rmk_ | I did compare the settings for two of the hdmi registers between the 4.1.0 BSP and this driver, and there were some differences in register 9 and 14: |
| 13:42 | _rmk_ | - hdmi_phy_i2c_write(hdmi, 0x8009, 0x09); /* CKSYMTXCTRL */ |
| 13:42 | _rmk_ | + hdmi_phy_i2c_write(hdmi, 0x800d, 0x09); /* CKSYMTXCTRL */ |
| 13:42 | _rmk_ | - hdmi_phy_i2c_write(hdmi, 0x0210, 0x0E); /* VLEVCTRL */ |
| 13:42 | _rmk_ | + hdmi_phy_i2c_write(hdmi, 0x01ad, 0x0E); /* VLEVCTRL */ |
| 13:43 | _rmk_ | + = what I'm currently using and what's in the BSP. |
| 13:43 | jnettlet | reverting back to the "standard" ones used by the sabresd and nitrogen boards seems to have stabilized things. |
| 13:43 | _rmk_ | that's improved the 480p / 576p modes but I still get speckles on the displayed image |
| 13:44 | _rmk_ | _and_ it's also stopped the tv blanking when I probe onto the tmds clock line. |
| 13:44 | _rmk_ | x10 probe btw. |
| 13:46 | _rmk | 13:46 * _rmk_ is getting to the point of saying "give me a TDA998x, all is forgiven" :) |
| 13:52 | _rmk_ | rabeeh: it may be useful if there's some pin I could probe (maybe on the other not fitted connectors) which would give me the pixel clock itself |
| 13:54 | rabeeh | _rmk_: there isn't |
| 13:54 | rabeeh | HDMI phy is part of the iMX and the trace lengths are minimalistic |
| 13:55 | _rmk_ | what I'm wondering is whether its the hdmi mpll which is causing this, or whether its also on the ipu clock. |
| 13:55 | _rmk_ | maybe if I also enabled the lvds output? |
| 13:56 | _rmk_ | anyway, I gotta run, have lunch and then spend the afternoon at the eye hospital again. |
| 13:56 | rabeeh | _rmk_: will get you a picture |
| 13:57 | rabeeh | my scope isn't connected so i'm not able to get a picture out of it |
| 13:57 | rabeeh | (and i don't have a 3.5" floopy anymore) |
| 14:24 | _rmk_ | rabeeh: I don't have any 8" disks, but I do have some 5.25" and some drives too :) |
| 14:37 | _rmk_ | interesting. if I set 800x600 on the lvds channel and turn hdmi off (in xrandr) then I get a nice clean clock on the hdmi tmds channel, even though I end up with a multicoloured mess displayed |
| 14:37 | _rmk_ | but the clock is squeeky clean. |
| 14:38 | _rmk_ | if I then set 800x600 on hdmi, the clock is the same frequency but gains this modulation. |
| 14:38 | _rmk_ | now if only I could set both at the same time. maybe I need to set the lvds to 24 bit instead of 18 bit |
| 14:47 | _rmk_ | right, back later, maybe in 2-3 hours |
| 15:24 | dv_ | "No such IOCTL, cmd is 22032" anybody else seen this? |
| 15:34 | jnettlet | dv_, on the Carrier-1? |
| 15:35 | dv_ | currently no. but on other imx6 devices |
| 15:35 | jnettlet | haven't seen it |
| 15:35 | jnettlet | which kernel? |
| 16:14 | rabeeh | _rmk_: i'm getting a clear clock now |
| 16:15 | rabeeh | i must have shorted the clock with the tmds :) |
| 16:15 | rabeeh | that's why i got two clocks; anyhow 1024x768 with jnettlet u-boot shows 56.6027 mhz |
| 16:16 | jnettlet | hmmm my monitor reports 52mhz |
| 16:18 | rabeeh | yeah |
| 16:18 | rabeeh | my monitor shows the same |
| 16:18 | rabeeh | let me zoom in |
| 16:19 | rabeeh | this is definintely not 52MHz |
| 16:19 | rabeeh | 56.6xx mhz |
| 16:20 | rabeeh | http://tinyvga.com/vga-timing |
| 16:20 | rabeeh | doesn't have both for 1024x768 |
| 16:22 | rabeeh | my monitor says that the resolution is 1024x768@52hz |
| 16:22 | rabeeh | jnettlet: it's 52 hz refresh rate and not 52mhz pixel clock rate |
| 16:23 | jnettlet | rabeeh, sorry, didn't know you were reporting pixel_clock |
| 16:23 | rabeeh | any idea if u-boot does edid detection? |
| 16:25 | jnettlet | it has some basic edid support |
| 16:26 | jnettlet | I haven't setup any of the I2C support on the board yet. |
| 16:27 | rabeeh | the WP signal is wrong too |
| 16:27 | rabeeh | (write protect) |
| 16:27 | rabeeh | you can't do saveenv |
| 16:29 | _rmk_ | back... in record time. :) |
| 16:30 | jnettlet | rabeeh, it just isn't picked up. if you pop the card and put it back in you still can't write but it doesn't say the card is locked. |
| 16:30 | jnettlet | storing the env is a wip |
| 16:31 | _rmk_ | jnettlet: is it the card refusing the write or the controller? |
| 16:31 | _rmk_ | jnettlet: remember, the card has no idea about the WP switch :) |
| 16:31 | jnettlet | _rmk_, haven't even looked it to tell you the truth |
| 16:31 | rabeeh | micro SD doesn't have WP |
| 16:31 | _rmk_ | also true :) |
| 16:31 | rabeeh | btw - it was the same problem with my u-boot |
| 16:32 | rabeeh | but i hacked it in my case |
| 16:32 | _rmk_ | yet the kernel is fine with it even v3.12-rc |
| 16:33 | _rmk_ | GPIO2 in my case is setup as GPIO rather than a WP signal, meaning that there's no WP signal routed to usdhc2 |
| 16:35 | rabeeh | MX6_PAD_GPIO_2__USDHC2_WP | MUX_PAD_CTRL(USDHC_PAD_GPIO_CTRL), |
| 16:35 | rabeeh | ? |
| 16:35 | rabeeh | maybe that's the offending one? |
| 16:35 | rabee | 16:35 * rabeeh trying |
| 16:37 | rabeeh | doesn't work |
| 16:37 | _rmk_ | well, GPIO2 you've routed to the Ir receiver |
| 16:38 | rabeeh | what is the difference between locked and write protected SD? |
| 16:38 | rabeeh | oh; working now |
| 16:38 | _rmk_ | so you definitely don't want to tell it that it's routed to USDHC2_WP |
| 16:38 | rabeeh | this is something unclear on i.MX6 |
| 16:38 | rabeeh | of you soft boot the machine; it keeps the same io-mux configs |
| 16:39 | rabeeh | i had to power cycle it |
| 16:40 | jnettlet | _rmk_, well of your races. The v4 code only needs patches 4, 5, and 6. |
| 16:44 | _rmk_ | rabeeh: ok, monitoring the tmds clock using a frequency counter, [email protected], I see anything from 31.9 to 32.3MHz on it. |
| 16:45 | _rmk_ | that's with a short sampling interval |
| 16:45 | _rmk_ | I'll just check 720p@60 |
| 16:48 | _rmk_ | 75.4234MHz and stable |
| 16:48 | _rmk_ | I'll just re-check [email protected] |
| 16:51 | _rmk_ | helps to get on the clock rather than the data line :) |
| 16:51 | _rmk_ | 40.0985MHz |
| 17:03 | rabeeh | jnettlet: sent you WP fix |
| 17:03 | rabeeh | _rmk_: i missed your last lines |
| 17:09 | dv_ | jnettlet: what about the uboot voltage levels? |
| 17:10 | _rmk_ | ok, 720p@60 gives me a TMDS clock of 75.4234MHz, [email protected] gives 40.0985MHz |
| 17:10 | dv_ | jnettlet: I mean this commit you reverted : https://github.com/linux4kix/u-boot/commit/534b810c93d8617089ace430cc01bc1099e1be66 |
| 17:10 | dv_ | you wanted to ask something about that? |
| 17:12 | rabeeh | dv_ / jnettlet - i'v used whatever sabresd board had |
| 17:12 | dv_ | rabeeh: jnettlet had to revert this commit, since with it, uboot wouldnt boot |
| 17:13 | dv_ | wouldnt print anything on the console even |
| 17:13 | rabeeh | maybe the uart module is being clocked on |
| 17:13 | rabeeh | uart2 |
| 17:13 | rabeeh | let me check |
| 17:16 | rabeeh | wife calling; need to shoot |
| 17:16 | rabeeh | ttyl |
| 17:16 | _rmk_ | ok, this is silly. |
| 17:16 | rabeeh | will review it later |
| 17:16 | _rmk_ | if I set 800x600 on HDMI, tv blanks. if I set 800x600 on LVDS1, it unblanks and displays a correct picture |
| 17:52 | _rmk_ | ok, between a working 800x600 and a non-working 800x600, there's very little difference in the overall programming on the hdmi part, but I've yet to check the i2c-accessed hdmi phy regs yet |
| 18:00 | jnettlet | rabeeh, sorry had to run out. |
| 18:00 | jnettlet | rabeeh, okay well I am using whatever is being used for almost all the mx6 chips now. |
| 18:02 | jnettlet | _rmk_, oh earlier I read an errata that you sometimes needed to set some hdmi registers multiple times to get them to set things up properly. I was out and about so just breezed through it and was going to look at it later. |
| 18:02 | _rmk_ | yea, already found that one and fixed it in this driver |
| 18:02 | _rmk_ | ok, now dumping out the phy settings too |
| 18:03 | _rmk_ | which show......... no difference |
| 18:03 | _rmk_ | so it's an ipu level breakage |
| 18:56 | _rmk_ | I think I've found it at last |
| 18:56 | _rmk_ | wrong clocking mode on the IPU DI |
| 18:56 | jnettle | 18:56 * jnettlet is listening |
| 18:59 | _rmk_ | ... maybe |
| 19:05 | _rmk_ | well, at least 1920x1080 @25Hz now works |
| 19:06 | _rmk_ | tv says 25Hz Xorg says 50Hz |
| 19:06 | _rmk_ | 1280x1024 doesn't |
| 19:06 | _rmk_ | 1366x768 doesn't |
| 19:06 | _rmk_ | 1280x720p does |
| 19:06 | _rmk_ | at both 60 and 50Hz |
| 19:07 | _rmk_ | 1024x768 doesn't |
| 19:07 | _rmk_ | 800x600 doesn't |
| 19:07 | _rmk_ | 720x576 does |
| 19:07 | _rmk_ | 848x480 doesn't |
| 19:07 | jnettlet | sounds like CEA modes are working and VESA are not. |
| 19:08 | _rmk_ | 720x480 doesn't (that's another CEA mode) |
| 19:08 | _rmk_ | 640x480 doesn't either |
| 19:08 | _rmk_ | supper time :) |
| 19:09 | jnettlet | but those modes might need to have the pixel doubling enabled. |
| 19:09 | jnettlet | yep. chili is cooking |
| 19:32 | _rmk_ | 720x480 is a no pixel doubling mdoe |
| 19:35 | _rmk_ | ok, I think it's time to dump the DI registers too |