| 00:12 | pepedog | Rabeeh here? |
| 00:13 | pepedog | Ahh, it's Friday evening |
| 00:14 | cbxbiker61 | pepedog, he hasn't been talking much here for a while, i'm sure he is busy getting other things done |
| 00:14 | pepedog | Like deleting spam? |
| 00:15 | cbxbiker61 | i'm sure cubox-i is a priority |
| 00:15 | pepedog | Got arch running on my carrier |
| 00:16 | cbxbiker61 | which kernel are you running? |
| 00:16 | pepedog | It's faster boot than quad core utilite on ssd |
| 00:16 | pepedog | Leming did package, let me look |
| 00:19 | pepedog | Wait, I'm thinking of utilite kernel, I did c1, not as pkg, had to makeconfig to keep systemd happy. Same source as Rabeeh |
| 01:01 | _rmk_ | okay, I think I'm down to just one or two res which don't work. |
| 01:02 | ojn | _rmk_: looks like i'll wait until i'm back from europe to hook up the cubox-i here to the test farm |
| 01:03 | _rmk_ | ojn: I suspect a lot of my changes to get this working aren't mainline-able in their current state. |
| 01:04 | ojn | _rmk_: the basics should be though (usb, network, serial)? No reason to not upstream those pieces as they get ready |
| 01:04 | _rmk_ | I've had to hack the imx6 clock tree, changing the flags on a bunch of clocks to let clk_set_rate get propagated up |
| 01:04 | _rmk_ | yea, usb net and serial are fine and that's just a matter of the right DT description |
| 01:04 | ojn | yeah |
| 01:04 | _rmk_ | and a small bit of code |
| 01:06 | _rmk_ | most of the basic stuff is here: http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/log/?h=unstable/cubox-i |
| 01:07 | _rmk_ | I may re-order those commits after the KS |
| 01:08 | _rmk_ | I'll probably be bringing my cubox |
| 01:08 | ojn | I'm not bringing any hardware but I've got easy access from remote to the stuff i have here |
| 01:08 | ojn | i just hooked up an APC (apc.io) 8750 board that I need to enable, and I've got some allwinner work to do |
| 01:09 | ojn | (the apc has one of the worst taglines i've heard in a while, "A bicycle for your mind") |
| 09:36 | rabeeh | jnettlet / dv_: i'v added a comment on the clock gating issues - |
| 09:36 | rabeeh | https://github.com/linux4kix/u-boot/commit/534b810c93d8617089ace430cc01bc1099e1be66#commitcomment-4374279 |
| 09:37 | rabeeh | i haven't seen any difference in power consumption when enabling / disabling those; but then i'm using a 5V current source with two digits accuracy (i.e. i won't notice anything <10mA). |
| 09:40 | jnettlet | rabeeh, oh excellent! |
| 09:41 | jnettlet | I will merge that. |
| 09:41 | rabeeh | jnettlet: you also removed the clock for the USB OTG; where the USB can be used in u-boot |
| 09:41 | rabeeh | jnettlet: in my mind; if you keep it out then it would be best since USB OTG can be used; and SPI can be used (on the 26pin header) |
| 09:42 | rabeeh | now i'm looking into the pixclk of the HDMI; although the calculation of the pixclk seems fine (i.e. 15385 ps) but it's being configured to something else |
| 09:42 | rabeeh | i'm diving deep now into that |
| 09:43 | rabeeh | maybe it's the same issue like _rmk_; the hdmi clock in u-boot is being taken from the ipg |
| 09:43 | rabeeh | ipg clock |
| 09:43 | jnettlet | rabeeh, yeah I need to add USB OTG support in one big patch. Right now it looks like u-boot only supports a single usb hub device. Hopefully there will be time this weekend to dig into that. |
| 09:44 | rabeeh | jnettlet: by usb otg i mean the usb host side only |
| 09:44 | jnettlet | rabeeh, yep. |
| 09:44 | rabeeh | btw - it is possible to use a device side too; but that requires a special host to host usb cable |
| 09:44 | rabeeh | i.e. something that will not blow your computer's USB fuses |
| 09:44 | jnettlet | it is? aren't there missing pins? |
| 09:45 | rabeeh | are you referring to the ID pin? |
| 09:45 | jnettlet | yep |
| 09:45 | rabeeh | it won't be an auto detect thing; you will need to decide either use device or host |
| 09:46 | rabeeh | we have removed that usb otg auto detect full function for favor to get a standard usb host connection |
| 09:46 | rabeeh | i mean it's mandatory for CuBox-i; but not mandatory for C1 |
| 09:47 | rabeeh | welcome svere |
| 09:47 | jnettlet | with the removable sdhc card as the only storage I don't see how useful it would be to put the port in device-mode. |
| 09:48 | jnettlet | really that is only a useful feature if you have some onboard storage that you would want to copy data from. |
| 09:48 | jnettlet | rabeeh, are you seeing erratic usb keyboard input as well? |
| 09:49 | rabeeh | i'm not using a usb keyboard yet |
| 09:49 | sleipnir | hey rabeeh. just a second i need to boot up the laptop... ;) |
| 09:49 | rabeeh | should i just plug one? is the support already enabled? |
| 09:50 | jnettlet | rabeeh, there is not hotplug after boot, but if you boot with one plugged in it will be detected. |
| 09:50 | jnettlet | the usb stack in u-boot is very simplistic |
| 09:50 | rabeeh | jnettlet: works :) |
| 09:51 | jnettlet | not sluggish and missing keys? Could be only a problem with my wireless usb receiever then. |
| 09:51 | rabeeh | nop; not slugish |
| 09:52 | rabeeh | and tried all a..z keys they all work |
| 09:52 | jnettlet | great! |
| 09:52 | rabeeh | and i'm using direct connection; i.e. not an RF kbd |
| 09:52 | jnettlet | yeah I was wondering if that would help. |
| 09:54 | rabeeh | jnettlet: just connected an RF keyboard (Logitech); it's not slugish but most of the letters are printed twice |
| 09:54 | jnettlet | when we are past major development phase we should be able to switch on a splash screen that you can escape out of to get access to U-boot |
| 09:54 | rabeeh | which reminds me that we need to prepare a high quality logo |
| 09:54 | rabeeh | png format? |
| 09:54 | jnettlet | rabeeh, okay that is the opposite of my keyboard. I have to press most the letters twice to catch one. |
| 09:55 | jnettlet | it needs to be color indexed and not more than 256 colors. |
| 09:56 | jnettlet | I don't know the max resolution. Most the included ones are about the same as the current logo I created. |
| 09:57 | jnettlet | we can fetch the image off the sdcard if that is better than embedding it. |
| 10:00 | svere | rabeeh: here we go |
| 10:01 | jnettlet | rabeeh, Anish got his Carrier-1 today. Just in time for the Conference this weekend. Thanks a lot. |
| 10:01 | rabeeh | jnettlet: great |
| 10:01 | rabeeh | svere: please go ahead; i'll be back in 5m |
| 10:01 | jnettle | 10:01 * jnettlet is going to walk the dogs now |
| 10:10 | _rmk | 10:10 * _rmk_ noticed last night that IMX does the clock API wrong: clk_set_rate() doesn't wait for the PLL to lock |
| 10:11 | _rmk_ | and the IMX6 must not have devices running off an unlocked PLL otherwise they tend to stop working |
| 10:12 | _rmk_ | which explains why I had to add a mdelay(5) after my clk_set_rate() |
| 10:27 | rabeeh | _rmk_: that's understandable |
| 10:27 | rabeeh | otherwise it might create a glitch that can lock the unit that is using that clock |
| 10:28 | rabeeh | mdelay(5) though is too big; and looking at the pll's there is a locked bit (bit 31) that shows when the pll is locked |
| 10:28 | rabeeh | _rmk_: are you still using ipg clock? or switched to another? |
| 10:28 | rabeeh | the dedicated pll for video is better since i need the ipg clock to generate mdc clock for the ethernet phy |
| 11:03 | _rmk_ | rabeeh: yes, the mdelay(5) was just to get it working last night and to test the theory |
| 11:03 | _rmk_ | rabeeh: I've just implemented this: |
| 11:04 | _rmk_ | 1. put the PLL in bypass mode |
| 11:04 | _rmk_ | 2. set new frequency |
| 11:04 | _rmk_ | 3. poll the lock bit for up to 10ms |
| 11:04 | _rmk_ | 4. if the lock bit doesn't set, bail out leaving PLL in bypass, return error |
| 11:04 | _rmk_ | 5. restore PLL bypass setting |
| 11:05 | _rmk_ | which should give us a fast turnaround if it locks quickly |
| 11:05 | _rmk_ | with HZ=100, the wait will actually be up to 20ms (remember, msecs_to_jiffies rounds up) |
| 11:05 | _rmk_ | HZ=1000, it'll be in the range of 11-12ms |
| 11:06 | _rmk_ | but it stops waiting as soon as it sees the lock bit |
| 11:06 | _rmk_ | I use either clock for the DI - if the 198MHz can be used to generate the pixclock within 2% then we use that, otherwise we use PLL5 |
| 11:08 | rabeeh | _rmk_: i would add usleep(1) before going into msleep up to 10ms |
| 11:09 | rabeeh | or maybe usleep(10); just give it 1-10uSec before sleeping |
| 11:11 | _rmk_ | they already have code to poll it in the prepare callback, I'm just using that |
| 11:11 | rabeeh | ok. |
| 11:12 | rabeeh | according to the documentation; the system pll should take the longest to long since it has spread spectrum in it |
| 11:12 | rabeeh | they don't give numbers though |
| 11:14 | _rmk_ | indeed - they miss quite a bit of useful (and in some cases key) information in the manual |
| 11:14 | _rmk_ | such as the HDMI phy stuff, they just refer you to the phy datasheet... which is a designware thing but they don't tell you where that is, and of course designware needs you to sign up or something (I didn't investigate further than that) |
| 11:16 | _rmk_ | I assume we have the spread spectrum stuff enabled? |
| 11:18 | rabeeh | _rmk_: i have no idea |
| 11:19 | rabeeh | i think so actually; but i haven't investigated |
| 11:20 | rabeeh | the reason i'm saying maybe since i'v seen two frequencies on my spectrum analyzer when looking deep around the 148.5 mhz (1080p60 freq) |
| 11:22 | _rmk_ | rabeeh: that may also be that fractional divisor |
| 11:22 | _rmk_ | if you have devmem2, read 0x2640004 |
| 11:22 | _rmk_ | if bits 0-3 are non-zero, the DI is using a fractional pulse-skipping divisor prior to the HDMI clock PLL |
| 11:26 | jnettlet | _rmk_, I would love your input if you have two seconds. |
| 11:27 | _rmk_ | hmm? |
| 11:28 | jnettlet | Unlike Freescale's implementation Marvell is handling all the GPU clocks through a single register. I am trying to figure out a way in common clock to distinguish between the 2d core and the 3d core. |
| 11:28 | shesselba | _rmk_: great CLK_SET_RATE_PARENT did the trick, I'd love to discuss this in general with mturquette: there should be a way to claim the way up to a pll |
| 11:28 | shesselba | i.e. you want video to set the pll but not audio to re-set it again |
| 11:28 | shesselba | but derive its clock from it |
| 11:29 | shesselba | given the complex clocking tree in imx, and the possibly vast number of boards with different use-cases, this is something that shouldn't sit in DT |
| 11:30 | shesselba | in clk-si5351, I put that into DT, but it is only two plls and three clk outputs |
| 11:31 | _rmk_ | jnettlet: yes, I noticed that IMX has separate 2d and 3d clocks. well, we could distinguish between the two setups via the compatible string, because they are different things if Marvell added a register for this. |
| 11:32 | jnettlet | well I am going to have to add compile time paths to either choose Marvell compatible or IMX compatible as the userspace libraries are different. |
| 11:32 | jnettlet | and Freescale's EULA says their binaries can only be used on IMX hardware |
| 11:33 | _rmk_ | and what does Marvell's license say? :) |
| 11:33 | jnettlet | better. Free to use and distribute as long as they are unmodified |
| 11:34 | _rmk_ | so the obvious question then arises - can we use the marvell libs on imx? :) |
| 11:34 | jnettlet | _rmk_, theoretically yes, but the imx libraries are newer and seem to be better supported. |
| 11:35 | jnettlet | they also include libGAL compiled for X11, FB, and Wayland |
| 11:35 | _rmk | 11:35 * _rmk_ discovers something about this PLL. It fails to lock if its in bypass mode. So the documentation says: either move everything off a PLL when changing its frequency or set it to bypass while it relocks... |
| 11:43 | svere | hey guy, i would like to help with the graphics stack. Where is the work spend best currently? |
| 11:47 | _rmk_ | nope, definitely doesn't report locked when bypass is selected, which seems to be against what the docs and diagrams suggest |
| 11:48 | _rmk | 11:48 * _rmk_ tries a slightly different approach |
| 11:51 | _rmk_ | oh, hang on, it's powered down... |
| 12:03 | rabeeh | svere: on cubox-i? |
| 12:03 | rabeeh | i mean for the imx6 device? |
| 12:06 | _rmk_ | ok, I've lost 640x480, 800x600 and 848x480 but I think the rest are fine. |
| 12:06 | _rmk_ | hmm, 1024x768 too |
| 12:07 | svere | rabeeh: yes. i will probably receive my c1 during the next week... |
| 12:08 | _rmk_ | hmm, no, we must have glitched and knocked out the clock tree/DI |
| 12:08 | _rmk_ | damn it |
| 12:08 | svere | would be nice if i could learn do something meaningfull in the meantime (reading some docs, code etc) |
| 12:09 | _rmk_ | so... switching the PLL to bypass mode can cause glitches :( |
| 12:12 | jnettlet | _rmk_, there is a patch for that somewhere |
| 12:15 | _rmk_ | I probably ought to check for any errata for this |
| 12:17 | jnettle | 12:17 * jnettlet thinks he saw it in a forum. but can't dig it up right now |
| 12:19 | _rmk_ | don't see anything in there |
| 12:39 | _rmk_ | I wonder if the problem is: if you set bypass mode and then clear it, you end up glitching the clock |
| 12:45 | _rmk_ | ok, I think this is going to take digging into the fsl bsp kernel |
| 12:54 | rabeeh | svere: are you interested more on the 2D or 3D side? |
| 12:54 | rabeeh | svere: there are lots of documentation online about imx6 |
| 12:55 | rabeeh | there is a basic wiki on imx.solid-run.com to look at for source code |
| 12:56 | _rmk_ | ah, that works. helps if the clock prepare function doesn't unset bypass before the PLL has locked ! |
| 12:56 | jnettlet | :-) |
| 12:58 | _rmk_ | but... in theory the output is disabled. |
| 12:59 | _rmk | 12:59 * _rmk_ runs it through the test again just to be sure this works |
| 13:18 | _rmk_ | ok, my theory is this about the imx PLLs: in order to change the rate, you must bypass it while the PLL is unlocked, even if the output is disabled. Otherwise it glitches and then you can't re-enable the output until after the next reset |
| 13:19 | _rmk_ | also that applies if you just power the thing down and back up again |
| 13:20 | svere | rabeeh: my first target is to start a X session, so its unaccel 2D |
| 13:20 | rabeeh | which OS? |
| 13:20 | rabeeh | which distro? |
| 13:21 | svere | rabeeh: dunno probably i'll try to get arch running |
| 13:22 | svere | rabeeh: IIRC _rmk_ wrote somewhere he has got an ubuntu running with X |
| 13:22 | svere | so would be good to get that as a starting point |
| 13:24 | rabeeh | he is still running with fbdev though |
| 13:25 | _rmk_ | I'm using imx-drm, not fbdev :) |
| 13:25 | svere | if i understand the current work of _rmk_ correctly he is using imx-drm in staging |
| 13:25 | _rmk_ | with a few hacks to my armada/dove drm xorg driver |
| 13:25 | svere | _rmk_: good :-) |
| 13:26 | svere | _rmk_: can i find it somewhere? |
| 13:27 | _rmk_ | I haven't pushed out the userspace hacks because really they're just to let me test this out, but the standard driver is... I'll need to dig out the git urls tho |
| 13:28 | _rmk_ | I've been quite occupied over the last week fairly solidly trying to get hdmi output anywhere close to "working" |
| 13:29 | _rmk_ | lost in the depths of very poor documentation, which has lead to numerous attempts just trying things to solve each problem |
| 13:29 | svere | _rmk_: yeah i follow your work since some days. currently trying to make sense of the clock generation myself |
| 13:29 | svere | however, i'm lost in the felt 20 levels of indirection... :-( |
| 13:30 | _rmk_ | that's how I feel most of the time while looking at this too :p |
| 13:31 | _rmk_ | tbh, I much prefer marvell dove... that's a lot easier to hack on than this. |
| 13:31 | _rmk_ | bbiab. |
| 13:31 | svere | _rmk_: is my understanding correct that currently the hdmi is driven with an incorrect freq for some resolutions due to fractional divisors? |
| 14:07 | rabeeh | svere: i think _rmk_ is battling with it since he choose wrong pll |
| 14:07 | rabeeh | _rmk_ ? |
| 14:11 | _rmk_ | I didn't choose the PLL, the code forces the use of the IPU clock which is derived from PLL2. |
| 14:12 | _rmk_ | the imx-drm code seems very restrictive |
| 14:12 | _rmk_ | and as the PLL code is also quite broken... |
| 14:13 | _rmk_ | what also doesn't help is that the DI clock is routed via the LDB paths, and I've yet to work out how to get around that with the CCF. |
| 14:14 | _rmk_ | I'd summerise IMX in mainline as "a complete and utter shambles" |
| 14:23 | svere | _rmk_: i'm still in the very beginning of reading the clock section but shouldn't pll5 be used for video? |
| 14:27 | svere | _rmk_: I saw your mail on linux-arm... so should be pll5. |
| 14:28 | rabeeh | _rmk_: are you familiar with pengutronix git tree? |
| 14:28 | svere | _rmk_: could you point me to your kernel git tree to match your code against the doc!?!? |
| 14:32 | rabeeh | _rmk_: pengutronix where previously maintaining the older imx6 series on mainline |
| 14:32 | rabeeh | and now they are porting the imx6 upstream; maybe they have done things differently when it comes to the plls |
| 14:36 | jnettlet | rabeeh, you are using a 25Mhz crystal as the reference clock? |
| 14:54 | jnettlet | _rmk_, yeah, I think you are shaving a serious yak. The clock code in the 3.10 boundary tree looks far more sensible. |
| 14:55 | jnettlet | It is driving the ipu off pll5...which is actually named pll5_video |
| 14:56 | jnettlet | static const char *ldb_di_sels[] = { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", }; |
| 14:56 | jnettlet | static const char *ipu_di_pre_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", }; |
| 14:59 | jnettlet | sorry that was the 3.5 alpha tree. the 3.10 tree gets even more complex. |
| 14:59 | jnettlet | wow this is annoying |
| 15:03 | dv_ | _rmk_: pengutronix where previously maintaining the older imx6 series on mainline <- the older imx6? |
| 15:04 | dv_ | ah. misread. nevermind. |
| 15:06 | jnettlet | yeah the mainline code is way out of date. |
| 15:07 | jnettlet | oh no there it is. stupid windows all look the same. |
| 15:10 | dv_ | as I mentioned several days ago, to me, this is a good example of why you should not keep your open source contributions by yourself for too long |
| 15:10 | _rmk_ | err, let's correct something... |
| 15:11 | _rmk_ | the core of the IPU runs off the IPU clock, which can't be muxed to PLL5 at all. |
| 15:12 | _rmk_ | the display interfaces (DIs) can run off several clocks, amongst those are clocks generated from the same source as the IPU, the LDB clocks or PLL5 |
| 15:12 | svere | _rmk_: regarding your patch on arm-lkml |
| 15:13 | _rmk_ | so the IPU (which includes all the fetching of framebuffer data) runs in one clock domain which can be completely different to the pixel clock |
| 15:13 | _rmk_ | svere: I assume you mean the one I've just sent, yes? |
| 15:13 | svere | _rmk_: yes. in case of a pll lock you overwrite the lock flag |
| 15:13 | svere | writel_relaxed(newval, pll->base) |
| 15:13 | _rmk_ | the lock flag is read only |
| 15:14 | svere | oh i see |
| 15:14 | _rmk_ | it's a status flag which ignores writes :) |
| 15:14 | svere | but wouldn't it better to read the values again before writing? or can we be sure nothing else changed during the locking phase? |
| 15:15 | svere | I'm asking because end of p.511 the manual says that the pll is gated off during the locking phase |
| 15:15 | _rmk_ | if something else changes the register values then the code is racy... provided the code in this file is the only thing accessing the registers, we're fine because the CCF provides the necessary serialisation |
| 15:16 | svere | ok i see |
| 15:18 | svere | _rmk_: could you please tell me where to find your git tree!? |
| 15:19 | jnettlet | _rmk_, this is the boundary IPU clock initialization for the imx6q. http://fpaste.org/47967/38218868/ |
| 15:34 | _rmk_ | svere: git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git unstable/cubox-i is the kernel: please only pull that into a tree which already has v3.12-rc4 in, don't clone it (the machine won't take a clone as generating a full pack from the massive kernel history is massively heavy on the machines resources) |
| 15:37 | _rmk_ | jnettlet: looks like that's all missing... the problem this presents is whether putting any of that stuff into mainline will break anything |
| 15:38 | jnettlet | _rmk_, there is actually one more piece I found. |
| 15:38 | jnettlet | if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) || cpu_is_imx6dl()) { |
| 15:38 | jnettlet | clk_set_parent(clk[ldb_di0_sel], clk[pll5_video_div]); |
| 15:38 | jnettlet | clk_set_parent(clk[ldb_di1_sel], clk[pll5_video_div]); |
| 15:38 | jnettlet | } |
| 15:39 | jnettlet | actually let me see if there is a documented commit for these. |
| 15:41 | jnettlet | _rmk_, there is actually a string of relevant clock commits to their tree since about July. Almost all related to audio and video fixes |
| 15:43 | jnettlet | starts with. commit 1805080b60b284b04e4d2b6f23bd403396578239 |
| 15:43 | jnettlet | Author: Shawn Guo |
| 15:43 | jnettlet | Date: Tue Jul 23 22:49:03 2013 +0800 |
| 15:43 | jnettlet | ENGR00240987: ARM: imx6q: initialize clocks for IPU |
| 15:43 | _rmk_ | sounds like something I need to tackle them about next week |
| 15:44 | jnettlet | well this is in their 3.10 "alpha" branch. |
| 15:44 | jnettlet | I wonder if they don't push upstream until the branch is officially supported |
| 15:49 | _rmk_ | just starting to commit all this stuff from the last week |
| 15:49 | jnettlet | oh good timing. I was just about to pull your repo. will wait |
| 15:49 | _rmk_ | btw, Tony Prisk posted another HDMI driver, which I haven't tried yet |
| 15:59 | jnettlet | _rmk_, have you seen this. Not HDMI related, but imx-drm related. http://www.mail-archive.com/[email protected]/msg02822.html |
| 15:59 | _rmk_ | no but prime support = good :) |
| 15:59 | _rmk_ | one less hack for my xorg part |
| 16:09 | _rmk_ | damn, while writing that commit log, I've had it fail on 1920x1080 and not recover |
| 16:10 | svere | _rmk_: while reading ipu_di_clk_calc_div() I wonder if div should be divided by 16 gain before returning because otherwise the resulting rate is too small |
| 16:10 | jnettlet | well I will pull your changes into the boundary 3.10 branch and see how that works |
| 16:11 | _rmk_ | you may remember that I said last night I'd rearrange the commit order... |
| 16:11 | svere | _rmk_: in clk_di_round_rate() div is multiplied by 16 but in clk_di_set_rate() this is not the case |
| 16:13 | _rmk_ | take a peek at ipu_di_clk_calc_div |
| 16:13 | _rmk_ | that's where the * 16 is |
| 16:13 | _rmk_ | that's because the resulting divisor has 4 LSB bits of fractional value |
| 16:14 | _rmk_ | so it does fixed_point_divisor = int(parent_rate * 16 / desired_rate) |
| 16:17 | svere | yeah i got that one, but why is the div with the 4bit fraction directly written with ipu_di_write(di, clkgen0 | div, DI_BS_CLKGEN0); in clk_di_set_rate()? |
| 16:18 | _rmk_ | okay, pushed out... its still "unstable" |
| 16:20 | _rmk_ | jnettlet: shame mail-archive doesn't let you download messages raw |
| 16:22 | jnettlet | _rmk_, the were sent to dri-devel should be able to find them on marc if you don't subscribe to that list. |
| 16:39 | svere | _rmk_: are you aware of the engineering bulletin EB790? it describes how to generate safe outputs with PFDs from PLLs |
| 16:40 | svere | _rmk_: if you are not using this init sequence PFDs have a chance to not output a clock at all |
| 16:41 | jnettlet | _rmk_, I am receiving this trying to fetch from your server. Cannot obtain needed commit 14f213cde7a3dfb7ee089097e0a983a2b91681e2 |
| 16:43 | _rmk_ | I also don't have that commit either |
| 16:43 | jnettlet | it is DRM: Armada: support for dma_buf import into gem that is requiring it |
| 16:43 | jnettlet | 841bd962eeea |
| 16:44 | _rmk_ | jnettlet: are you pulling the unstable/cubox-i branch? |
| 16:45 | _rmk_ | svere: I can find no reference to EB790 in google |
| 16:45 | svere | _rmk_: just a second |
| 16:45 | svere | _rmk_: http://cache.freescale.com/files/32bit/doc/eng_bulletin/EB790.pdf?fsrch=1&sr=1 |
| 16:46 | svere | _rmk_: you have to search in the freescale site. it's not indexed |
| 16:46 | _rmk_ | ah. well, that's to do with PLL2/3 which we're not changing |
| 16:46 | svere | this bulletin is referenced in the reference manual |
| 16:46 | _rmk_ | PLL5 doesn't have any PFDs |
| 16:47 | svere | _rmk_: i see |
| 16:48 | jnettlet | _rmk_, never mind that was my fault. |
| 16:53 | _rmk_ | ok, I don't know what's causing the output to end up being killed. Just scoping the TMDS clock line, it seems fine, and measures the right frequency. The tmds data seems to have data on it, but it doesn't look like it carries any image data |
| 16:54 | _rmk_ | in other words, there isn't enough "noise" on it like I see when it's working properly |
| 16:55 | _rmk_ | I think I'm going to give Troy's driver a go next, but first I need to rearrange the commits a bit more |
| 17:15 | _rmk_ | nooooo. |
| 17:15 | _rmk_ | Tony's patch is whitespace damaged |
| 17:31 | jnettlet | _rmk_, are you appending the dtb file to the end of your uImage or letting u-boot load it from the sdhc card? |
| 17:31 | _rmk_ | the former at the moment |
| 17:32 | _rmk | 17:32 * _rmk_ thinks he introduced a last minute compile bug into that... pixclock |
| 17:33 | _rmk_ | gah, Tony's suffers from the same array overrun as fabio's |
| 17:37 | jnettlet | _rmk_, yep just a debug statement |
| 17:44 | _rmk_ | Tony's driver doesn't work very well either |
| 17:45 | _rmk_ | worse than Fabio's |
| 17:47 | _rmk_ | wrong sync delays |
| 17:51 | _rmk_ | oh and it also has the magenta line too |
| 17:55 | _rmk_ | ok, feedback sent on Tony's driver |
| 18:05 | svere | _rmk_: one more thing. ipu_di_init() is called with ipu_base + devtype->disp{0,1}_ofs |
| 18:09 | svere | and .disp0_ofs = 0x00240000, for imx6, but the reference manual says the offset for DI0_GENERAL_REGISTER is 0x02640000 |
| 18:09 | svere | _rmk_: arghhhh, probably ipu-base is 0x02400000 |
| 18:09 | svere | forget about it :-S |
| 18:12 | _rmk_ | yep, they do something weird with the first 2MB |
| 18:14 | _rmk_ | see page 2661 in the 6s/dl manual |
| 18:46 | _rmk_ | once I've finished this bit of hacking, I'm going to pull out the clk API usage for that clk_di_pixel clock. It serves no purpose for ipu-di to export the GI_GENERAL clock settings into CCF, to only then have the same driver exclusively control it. |
| 18:46 | _rmk_ | its pure obfuscation, nothing more. |
| 20:16 | svere | _rmk_: why is pll defined in imx_clk_pllv3() but only free'd when failing to register the clk? What am I missing? |
| 20:20 | svere | _rmk_: forget about my question... i think i have to learn a hell lot more about the kernel and container_of |
| 20:50 | _rmk | 20:50 * _rmk_ wonders why 848x480 doesn't seem to work |
| 21:37 | purch | argh, they sent first the 5V USB-UART TTL cable |
| 21:39 | purch | waiting sux |
| 22:15 | dxtr | So |
| 22:15 | dxtr | I was wondering.. I'm running geexbox (installed from the cubox installer) and everything lags. A lot |
| 22:16 | dxtr | Can't even watch a youtube video :( |
| 22:42 | dv__ | dxtr: check the CPU usage |