Hi Eric,
On 05/28/2014 04:03 PM, Eric Nelson wrote: > Thanks Peter, > > On 05/27/2014 11:51 PM, Peter Bergin wrote: >> Hi Eric, >> >> On 05/27/2014 11:11 PM, Eric Nelson wrote: >>> Hi Peter, >>> >>> On 05/25/2014 11:43 PM, Peter Bergin wrote: >>>> Hi Eric, >>>> >>>> <snip> >>>> >>>> In order to understand more what happens during the process I have >>>> enabled dynamic debug in the kernel and turned on messages from mxc_hdmi >>>> and mxc_ipu. I have attached my /var/log/messages if someone more >>>> familiar with the drivers can have a look. >>>> >>> Thanks for the detailed information. >>> >>>> IPU_INT_STAT_5 is classed as Error Interrupts in the Reference Manual. >>>> >>>> May 26 06:02:30 nitrogen6x user.warn kernel: imx-ipuv3 2400000.ipu: IPU >>>> Warning - IPU_INT_STAT_5 = 0x00800000 >>>> >>>> This seems to be a IMDAC_NFB4EOF_ERR_x. NFB4EOF - New-frame before >>>> end-of-frame. >>>> >>>> How can I get more understanding what's wrong in the IPU? Any ideas? >>>> >>> Nothing concrete. Perhaps the Freescaler's have some idea. >>> >>> The only time I've seen the NFB4EOF error has been when I've >>> had a bug (in a camera driver). I believe it means that there's >>> an initialization problem. >>> >>> >>> I've been trying to compare against what I see here, >>> and the two primary suspects are: >>> >>> - some quirk of your EDID >>> - the fact that you're running an older processor revision >>> (TO 1.0). >>> >>> I haven't yet found a TO 1.0 board to test against. >> I have previously have the Nitrogen board running against this monitor >> and also other boards such as cgtqmx6. Your thought about silicon >> revision could be the case and the cause why we do not see the same >> behavior. Can someone at Freescale give us a hint if there are anything >> changed in this region that can cause this and if this is a valid guess? >> >> If the "old revision" guess is a probable one we don't need to spend >> more time on this (from my point of view). >> > I'd certainly like to know, since we have lots of other customers with > TO.1.0 silicon. > > With this information and your EDID blob, I should be able to reproduce > things, and I'm sure I have an older board around somewhere. > >>> I also notice in your output that you're running without the >>> "only_cea" flag, and you are getting a non-CEA mode: >>> >>> mxc_hdmi_setup: mxc_hdmi 20e0000.hdmi_video: mxc_hdmi_setup DVI mode >>> >> I do running with only_cea flag. I think my kernel command line was cut >> in the log-file for some reason. My kernel command line looks like this: >> >> root@nitrogen6x:~# cat /proc/cmdline >> enable_wait_mode=off video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 >> video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=28M >> dyndbg="module mxc_hdmi +pf;module mxc_hdmi_core +pf;module mxc_ipu >> +pf;module mxc_ipuv3_fb +pf" console=ttymxc1,115200 vmalloc=400M >> consoleblank=0 rootwait root=/dev/mmcblk0p2 mxc_hdmi.only_cea=1 >> >> When looking in the driver code what the only_cea mode flag does is that >> it will only add CEA modes to the mode list. This is the cause why in >> the first case had 15 "standard" timings but in the second run after >> enabling the only_cea flag only have 8. >> > Okay. I'm still confused about why the kernel decided to use > "DVI" mode. > > Because of this, the kernel didn't configure an audio channel > as shown in my equivalent output: > > nitrogen6x user.debug kernel: mxc_hdmi_setup: mxc_hdmi > 20e0000.hdmi_video: mxc_hdmi_setup CEA mode > nitrogen6x user.debug kernel: hdmi_set_clk_regenerator: > hdmi_set_clk_regenerator: samplerate=48000 ratio=100 > pixelclk=148500000 N=6144 cts=148500 > nitrogen6x user.debug kernel: hdmi_enable_audio_clk: mxc_hdmi > 20e0000.hdmi_video: hdmi_enable_audio_clk > nitrogen6x user.debug kernel: hdmi_config_AVI: mxc_hdmi > 20e0000.hdmi_video: set up AVI frame > nitrogen6x user.debug kernel: mxc_hdmi_setup: mxc_hdmi > 20e0000.hdmi_video: mxc_hdmi_setup exit The reason for DVI mode and no audio is that I am using a HDMI to DVI cable to the monitor. >>>> I have also checked /sys/class/graphics/fb0 and made some tests. >>>> >>>> root@nitrogen6x:~# cat /sys/class/graphics/fb0/mode >>>> D:1920x1080p-60 >>> This is really odd, because you're not seeing all of the >>> modes that are reported from U-Boot (e.g. 800x600@60): >>> >>>> root@nitrogen6x:~# cat /sys/class/graphics/fb0/modes >>>> D:720x480p-59 >>>> D:720x576p-50 >>>> D:1280x720p-50 >>>> D:1280x720p-60 >>>> D:1920x1080p-50 >>>> V:640x480p-60 >>>> D:1920x1080p-60 >>>> V:640x480p-60 >>>> >>> In your post on i.MX Community, you showed 15 "standard" timings: >>> >>> https://community.freescale.com/thread/324175 >>> >>> Can you forward a hex-dump of your EDID settings from >>> U-Boot? >>> >>> U-Boot > i2c dev 1 >>> U-Boot > i2c md 50 0.1 200 >>> 0000: 00 ff ff ff ff ff ff 00 1e 6d fb 56 01 01 01 01 .........m.V.... >>> 0010: 03 13 01 03 80 33 1d 78 0a ae c5 a2 57 4a 9c 25 .....3.x....WJ.% >>> 0020: 12 50 54 a7 6b 80 b3 00 81 8f 81 80 71 4f 01 01 .PT.k.......qO.. >>> 0030: 01 01 01 01 01 01 1a 36 80 a0 70 38 1f 40 30 20 .......6..p8.@0 >>> 0040: 35 00 fe 22 11 00 00 1e 02 3a 80 18 71 38 2d 40 5..".....:..q8-@ >>> 0050: 53 2c 45 00 fe 22 11 00 00 1e 00 00 00 fd 00 38 S,E..".........8 >>> 0060: 3d 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc =.S... .... >>> 0070: 00 57 32 33 36 31 0a 20 20 20 20 20 20 20 01 61 .W2361. .a >>> 0080: 02 03 21 f1 4e 90 04 03 01 14 12 05 1f 10 13 00 ..!.N........... >>> 0090: 00 00 00 23 09 07 07 83 01 00 00 65 03 0c 00 10 ...#.......e.... >>> 00a0: 00 02 3a 80 18 71 38 2d 40 58 2c 45 00 fe 22 11 ..:..q8-@X,E..". >>> 00b0: 00 00 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 fe .......q.. X,%.. >>> 00c0: 22 11 00 00 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 ".......rQ.. n(U >>> 00d0: 00 fe 22 11 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 .."........ .-.. >>> 00e0: 3e 96 00 fe 22 11 00 00 18 00 00 00 00 00 00 00 >..."........... >>> 00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 de ................ >>> >>> >>> This might help narrow things down. We can fake the >>> EDID blob from there and see if we can reproduce >>> your symptoms. >> Here is a dump of EDID from my monitor. It is a Samsung SyncMaster B2440. >> > Thanks. This is helpful. > >> U-Boot > i2c dev 1 >> Setting bus to 1 >> U-Boot > i2c md 50 0.1 200 >> 0000: 00 ff ff ff ff ff ff 00 4c 2d 9f 06 34 32 42 43 ........L-..42BC >> 0010: 2c 14 01 03 80 34 1d 78 2a ee d1 a5 55 48 9b 26 ,....4.x*...UH.& >> 0020: 12 50 54 bf ef 80 81 00 81 40 81 80 95 00 a9 40 .PT......@.....@ >> 0030: b3 00 71 4f 95 0f 02 3a 80 18 71 38 2d 40 58 2c ..qO...:..q8-@X, >> 0040: 45 00 09 25 21 00 00 1e 00 00 00 fd 00 38 4b 1e E..%!........8K. >> 0050: 51 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 Q... .....S >> 0060: 4d 42 32 34 34 30 4c 0a 20 20 20 20 00 00 00 ff MB2440L. .... >> 0070: 00 48 39 58 5a 42 30 30 34 37 35 0a 20 20 01 a1 .H9XZB00475. .. >> 0080: 02 01 04 00 02 3a 80 d0 72 38 2d 40 10 2c 45 80 .....:..r8-@.,E. >> 0090: 09 25 21 00 00 1e 01 1d 00 72 51 d0 1e 20 6e 28 .%!......rQ.. n( >> 00a0: 55 00 09 25 21 00 00 1e 01 1d 00 bc 52 d0 1e 20 U..%!.......R.. >> 00b0: b8 28 55 40 09 25 21 00 00 1e 8c 0a d0 90 20 40 .(U@.%!....... @ >> 00c0: 31 20 0c 40 55 00 09 25 21 00 00 18 8c 0a d0 8a 1 .@U..%!....... >> 00d0: 20 e0 2d 10 10 3e 96 00 09 25 21 00 00 18 00 00 .-..>...%!..... >> 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> 00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5e ...............^ >> 0100: 00 ff ff ff ff ff ff 00 4c 2d 9f 06 34 32 42 43 ........L-..42BC >> 0110: 2c 14 01 03 80 34 1d 78 2a ee d1 a5 55 48 9b 26 ,....4.x*...UH.& >> 0120: 12 50 54 bf ef 80 81 00 81 40 81 80 95 00 a9 40 .PT......@.....@ >> 0130: b3 00 71 4f 95 0f 02 3a 80 18 71 38 2d 40 58 2c ..qO...:..q8-@X, >> 0140: 45 00 09 25 21 00 00 1e 00 00 00 fd 00 38 4b 1e E..%!........8K. >> 0150: 51 11 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 Q... .....S >> 0160: 4d 42 32 34 34 30 4c 0a 20 20 20 20 00 00 00 ff MB2440L. .... >> 0170: 00 48 39 58 5a 42 30 30 34 37 35 0a 20 20 01 a1 .H9XZB00475. .. >> 0180: 02 01 04 00 02 3a 80 d0 72 38 2d 40 10 2c 45 80 .....:..r8-@.,E. >> 0190: 09 25 21 00 00 1e 01 1d 00 72 51 d0 1e 20 6e 28 .%!......rQ.. n( >> 01a0: 55 00 09 25 21 00 00 1e 01 1d 00 bc 52 d0 1e 20 U..%!.......R.. >> 01b0: b8 28 55 40 09 25 21 00 00 1e 8c 0a d0 90 20 40 .(U@.%!....... @ >> 01c0: 31 20 0c 40 55 00 09 25 21 00 00 18 8c 0a d0 8a 1 .@U..%!....... >> 01d0: 20 e0 2d 10 10 3e 96 00 09 25 21 00 00 18 00 00 .-..>...%!..... >> 01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> 01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5e ...............^ >> U-Boot > >> >> >>>> I have tried to set all of the above listed resolutions in modes. The >>>> only resolution that works is V:640x480p-60. With this resolution set I >>>> get signal on HDMI and the display shows my screen. >>>> >> One further observation I have done is regarding the clock source in the >> IPU. When running the working 640x480 resolution the IPU clock is >> internal but when running other non-working resolution the clock source >> is external (PLL5 ?). Could this be something that cause my problem? >> > Perhaps, but the clock divisors appeared to be the same as what > I saw in a working unit. > > Regards, > > > Eric > Regards, /Peter -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
