| 08:53 | vpeter | jnettlet: I'm wiling to try almost anything now. |
| 09:03 | jnettlet | vpeter, so you are currently at the point where you are just getting a white screen? |
| 09:06 | vpeter | jnettlet: Yes. And I was changing timings and other data. Just to see if there is any difference. And there is not any. I see the changes in fbset but that's it. Only thing I noticed with fbset is that geometry is both 800x480. With working kernel I have visible 800x480 but virtual (or whatever is called) 800x960. |
| 09:06 | jnettlet | that is only important for 3d pageflipping |
| 09:07 | vpeter | But why there is a difference anyway? |
| 09:08 | vpeter | Wondering why bigger display just works. Must compare both datasheets to see if there is some small difference. |
| 09:14 | jnettlet | vpeter, it sounds like the rgb layout or pixel format isn't correct for the 7" display |
| 09:15 | vpeter | But I'm using the same data on old kernel. And it's fine. |
| 09:17 | vpeter | confused |
| 09:19 | jnettlet | vpeter, you are making the assumption that the video driver hasn't changed between versions. I almost guaranty that isn't the case. |
| 09:22 | vpeter | Could be. What was your reference for kernel? It is working on imx_3.14.28_1.0.0_ga. |
| 09:23 | jnettlet | the linux-fsl kernel from yocto is based on that release from Freescale |
| 09:24 | jnettlet | sounds like it is a clock that got changed somewhere along the line. |
| 09:24 | jnettlet | Does your 800x480 timing work with your 15" lcd? |
| 09:30 | vpeter | didn't try with 15". For 15 using different data. But will do. |
| 09:31 | jnettlet | most LCD's are very forgiving with the timings they will handle. I will be curious how it behaves |
| 09:32 | vpeter | With luck I have maybe some smoke will see :-) |
| 09:34 | jnettlet | vpeter, not with LCDs (generally) used to be a big problem with old CRT's |
| 09:35 | jnettlet | generally if an LCD can't handle a signal it will just go black or white. |
| 18:42 | vpeter | jnettlet: so I tried 800x400 timing on 1266x768 display and display stays black. Even if I only changed clock-frequency. |
| 18:42 | jnettlet | vpeter, can you send me the timings you are using? |
| 18:45 | vpeter | https://github.com/UDOOboard/linux_kernel/blob/imx_3.14.28_1.0.0_ga_udoo/arch/arm/boot/dts/imx6q-udoo-7lvds.dts |
| 18:56 | vpeter | Ah, I think this problem is unsolvable :) |
| 19:01 | jnettlet | why is that? |
| 19:08 | mk01 | jnettlet: perhaps vpeter knows he cut the the data wire by accident few days ago :) |
| 19:10 | jnettlet | mk01, very possible. Most these lcd panels have very fragile lvds wiring |
| 19:11 | mk01 | I was that lucky too - so I was jocking from experience |
| 19:26 | vpeter | mk01: This happens on my smartphone - cable cut. But in this case the cables are very robust. And display is working. |
| 19:33 | jnettlet | vpeter, can you post the output of /sys/kernel/debug/clk/clk_summary for the working kernel? |
| 19:35 | vpeter | http://sprunge.us/cHJd |
| 19:37 | vpeter | Can I put timings somwhere in kernel? So there will be not in device tree. |
| 19:37 | jnettlet | vpeter, there is your problem. pll5 is being clocked differently |
| 19:37 | vpeter | Aha! |
| 19:38 | vpeter | And the solution? |
| 19:44 | jnettlet | vpeter, can you switch the crtc to the second ipu? crtc = "ipu2-di0"; |
| 19:46 | vpeter | Only this change? |
| 19:47 | vpeter | And I'm only testing one other solution too. |
| 19:47 | jnettlet | well for now. |
| 19:48 | jnettlet | I need to do some quick math to figure out the pixel clock running off the different clocks |
| 19:50 | vpeter | Success! With my change :) |
| 19:50 | vpeter | Let me show you what I did. Ok, copied :( |
| 19:51 | vpeter | I add this commit: https://github.com/UDOOboard/linux_kernel/commit/ca2363d6ae07289eb29ac0067a3164defb446f28 |
| 19:51 | vpeter | from udoo kernel. |
| 19:51 | vpeter | Today I did 2 great things :) One at work and one at home. |
| 19:54 | jnettlet | vpeter, can you post the clk_summary of the new kernel. |
| 19:54 | jnettlet | that should already be how the clock tree is setup. |
| 19:54 | vpeter | there is no such file now. |
| 19:54 | vpeter | Anything missing from kernel config? |
| 19:54 | jnettle | 19:54 * jnettlet raises eyebrow |
| 19:55 | jnettlet | you need debugfs enabled |
| 20:23 | jnettlet | mk01, when you get a chance can you test this patch to see if it fixes the problem where UHS cards wouldn't come up stable? http://fpaste.org/273767/72375314/ |
| 20:24 | jnettlet | I have been testing with this and a few other pin drive strength changes and it seems to have gotten rid of all my weird mmc errors using UHS |
| 20:30 | vpeter | jnettlet: clk_summary with this pll5 clk add http://sprunge.us/MbhC |
| 20:38 | jnettlet | vpeter, okay I see what is going on. Please try my suggestion and use ipu2-di0...that should clock this from ldb_di1 which can produce a closer pixel clock |
| 20:38 | jnettlet | we may need to tweak the video mode to match it better |
| 20:39 | vpeter | Ok, let me try and see. I'm open for suggestions. |
| 20:40 | vpeter | Another question: Can "regulator-fixed" with one gpio be turned off at shutdown? I'm asking this for lcd power and backlight. |
| 20:46 | vpeter | Mhm, I already have crtc = "ipu2-di0"; |
| 20:46 | vpeter | Just like hb2 device tree. |
| 20:47 | jnettlet | oh yes...sorry that was my mistake. |
| 20:47 | vpeter | Forgiven :) |
| 20:48 | jnettlet | oh I see the problem |
| 20:49 | jnettlet | try moving it to lvds-channel@1 |
| 20:51 | jnettlet | vpeter, the other option is we can reparent that clock in the device-tree file for this board. |
| 20:52 | jnettlet | does it have an HDMI output? |
| 20:52 | topi`_ | are the UART TX/RX pins of HB 3.3 volt like in Raspberry PI? |
| 20:53 | topi`_ | I need to hook it up to a STM32F103 microcontroller which most probably has 3.3 volt uarts |
| 20:53 | vpeter | jnettlet: Yes, I have HDMI too. But for openelec I'm using only one. |
| 20:54 | jnettlet | topi`_, yes all the pin signalling is 3.3v |
| 20:57 | jnettlet | vpeter, the configuration is just not very flexible with this setup. pll5 is clocked such that it can handle all the pixel clocks needed for CEA resolutions used by HDMI. |
| 20:57 | jnettlet | by reparenting LVDS over to it you are locking that clock down to limited rates. |
| 20:58 | jnettlet | I think it would make more sense to try and clock this panel from the second ldb channel. |
| 20:59 | vpeter | testing already. |
| 20:59 | topi`_ | interesting, the Hummingboard is now the basis of a touchscreen product: http://linuxgizmos.com/industrial-touch-panel-runs-linux-or-android-on-i-mx6/ |
| 21:00 | jnettlet | topi`_, yep and an awesome...revolutionary laser cutter. I literally spotted this randomly. |
| 21:01 | jnettlet | https://www.youtube.com/watch?v=0R3mMUsHFvU |
| 21:02 | topi`_ | I want my own 3D cutter :) |
| 21:05 | jnettlet | topi`_, if that cutter can pull off what they claim, then $2-3K is a steal. |
| 21:05 | jnettlet | still expensive, but they are doing features that $20k laser cutters don't have. |
| 21:06 | jnettle | 21:06 * jnettlet is wondering why he doesn't get one....since it is relying on his code :) |
| 21:13 | vpeter | jnettlet: You shouls ask for one nicely? Or someone else could send one nice email to them. |
| 21:13 | vpeter | lvds-channel@1 -> no change - white screen |
| 21:15 | jnettlet | clk_summary output pleaase |
| 21:16 | jnettlet | vpeter, although one question. with the clock patch, can you please plug in the hdmi output and see if it works? |
| 21:16 | vpeter | http://sprunge.us/PhcJ |
| 21:17 | vpeter | sure |
| 21:20 | jnettlet | hmmm...that last change should have worked. the ldb was clocked to a pixel clock of 33.52 Mhz vs 33.66 Mhz...that should be well within spec to drive the lcd |
| 21:20 | jnettlet | that is a really crap LCD panel if it needs to be driven at precisely the pixel clock |
| 21:25 | vpeter | lvds-channel@1 and my patch -> white screen too |
| 21:25 | vpeter | So only my patch works. |
| 21:26 | jnettlet | vpeter, yeah so your lcd screen is super particular about the pixel refresh rate.....I have never seen such a thing but okay that is just what we have. |
| 21:27 | jnettlet | so now let we want to not hard patch the clock source and use device-tree to fix this |
| 21:27 | vpeter | Ok, no problem. I can use this patch myself on my builds. |
| 21:27 | jnettlet | nope, we can fix this "properly" |
| 21:28 | vpeter | Oh, if there is better way I'm open for suggestions. |
| 21:40 | jnettlet | vpeter, give this a shot. http://pastebin.com/Gf1Uac1u |
| 21:46 | mk01 | jnettlet: by "come up stable" you now mean ultimate goal not to have single reset during it's init ? sure - I will test (because otherwise I no longer see (not single one) cases when init read -> error -> reset ->re-read ok wouldn't end up at proper 1.8v) |
| 21:47 | jnettlet | mk01, yes it should come up in 1.8v with UHS enabled |
| 21:47 | mk01 | ok |
| 21:48 | jnettlet | I had a card here that was giving random errors in the middle of reads, and this seems much better on it....although I have seen some docs where freescale suggests increasing the drive strength for all the mmc pins. |
| 21:48 | mk01 | will keep eye on it |
| 21:48 | jnettlet | thnx |
| 21:56 | vpeter | jnettlet: still white screen http://sprunge.us/CiGi |
| 21:57 | jnettlet | hmmm it didn't reparent properly. I wonder what I screwed up. |
| 21:58 | vpeter | Don't tell me you are making mistakes too? |
| 21:59 | jnettlet | it happens...we are all human |
| 21:59 | vpeter | Now I feel better. |
| 22:01 | vpeter | assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>; |
| 22:01 | vpeter | You missed _SEL |
| 22:01 | vpeter | It seems. Doublechecking now. |
| 22:03 | jnettlet | copy and paste is always my nemesis |
| 22:07 | vpeter | Congratulations! Seems you did it. I will rebuild everything tomorrow to confirm. I'm very grateful. |
| 22:11 | jnettlet | Great |
| 22:37 | flips | probably the wrong channel, but would buying an arm based chromebook of some sort and install debian or something be doable/viable? Would be nice to have arm hw for developing and building for the cubox ... |