Incorrect timing when using 240p 15khz (NTSC) modes #58
Comments
|
Right now we don't do pixel doubling. If you're interested in looking into it, PV_CONTROL bits 4-5 get the number of pixels repeated minus one. |
|
Did some hacking on this. Fixed setting low HDMI clock rates in clk-bcm2835.c. Fixed interlaced mode. Fixed timeouts in transition to HDMI mode. Pixel repeat's not quite there. One problem is that I'm missing the HDMI infoframe, and another is that I need to be doubling the timings, not just the pixel clock. |
|
I've got double-clocked modes mostly scanning out now. There's some under/overscan going on, but I don't think that's specific to this (my double-clocked modes are all interlaced). Code is up at https://github.com/anholt/linux/tree/drm-vc4-next-doubleclock Now for another cup of coffee and definitely not thinking about modesetting for the rest of the day. |
|
Any chance you could try out that branch? |
|
Yes, I got a chance to try it yesterday. I was on the 4.4.y branch before though - lots has changed since (bcm2710->bcm2835, also no 32 bit kernel for pi3). Once I get all that sorted, I'll let you know what timings I measure (including on doubled resolutions - in theory 1920x240 shouldn't be doubled because it's >25MHz) |
|
There have been a few more clocking fixes since then. As far as I know this is fixed -- particularly try out the rpi-4.9.y branch if you've been using downstream kernels. Closing, feel free to reopen if you find problems on 4.9+. |
commit 8ee9fdb upstream. On a ppc64 system, executing generic/256 test with 32k block size gives the following call trace, XFS: Assertion failed: args->maxlen > 0, file: /root/repos/linux/fs/xfs/libxfs/xfs_alloc.c, line: 2026 kernel BUG at /root/repos/linux/fs/xfs/xfs_message.c:113! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: CPU: 2 PID: 19361 Comm: mkdir Not tainted 4.10.0-rc5 #58 task: c000000102606d80 task.stack: c0000001026b8000 NIP: c0000000004ef798 LR: c0000000004ef798 CTR: c00000000082b290 REGS: c0000001026bb090 TRAP: 0700 Not tainted (4.10.0-rc5) MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28004428 XER: 00000000 CFAR: c0000000004ef180 SOFTE: 1 GPR00: c0000000004ef798 c0000001026bb310 c000000001157300 ffffffffffffffea GPR04: 000000000000000a c0000001026bb130 0000000000000000 ffffffffffffffc0 GPR08: 00000000000000d1 0000000000000021 00000000ffffffd1 c000000000dd4990 GPR12: 0000000022004444 c00000000fe00800 0000000020000000 0000000000000000 GPR16: 0000000000000000 0000000043a606fc 0000000043a76c08 0000000043a1b3d0 GPR20: 000001002a35cd60 c0000001026bbb80 0000000000000000 0000000000000001 GPR24: 0000000000000240 0000000000000004 c00000062dc55000 0000000000000000 GPR28: 0000000000000004 c00000062ecd9200 0000000000000000 c0000001026bb6c0 NIP [c0000000004ef798] .assfail+0x28/0x30 LR [c0000000004ef798] .assfail+0x28/0x30 Call Trace: [c0000001026bb310] [c0000000004ef798] .assfail+0x28/0x30 (unreliable) [c0000001026bb380] [c000000000455d74] .xfs_alloc_space_available+0x194/0x1b0 [c0000001026bb410] [c00000000045b914] .xfs_alloc_fix_freelist+0x144/0x480 [c0000001026bb580] [c00000000045c368] .xfs_alloc_vextent+0x698/0xa90 [c0000001026bb650] [c0000000004a6200] .xfs_ialloc_ag_alloc+0x170/0x820 [c0000001026bb7c0] [c0000000004a9098] .xfs_dialloc+0x158/0x320 [c0000001026bb8a0] [c0000000004e628c] .xfs_ialloc+0x7c/0x610 [c0000001026bb990] [c0000000004e8138] .xfs_dir_ialloc+0xa8/0x2f0 [c0000001026bbaa0] [c0000000004e8814] .xfs_create+0x494/0x790 [c0000001026bbbf0] [c0000000004e5ebc] .xfs_generic_create+0x2bc/0x410 [c0000001026bbce0] [c0000000002b4a34] .vfs_mkdir+0x154/0x230 [c0000001026bbd70] [c0000000002bc444] .SyS_mkdirat+0x94/0x120 [c0000001026bbe30] [c00000000000b760] system_call+0x38/0xfc Instruction dump: 4e800020 60000000 7c0802a6 7c862378 3c82ffca 7ca72b78 38841c18 7c651b7 38600000 f8010010 f821ff91 4bfff94d <0fe00000> 60000000 7c0802a6 7c892378 When block size is larger than inode cluster size, the call to XFS_B_TO_FSBT(mp, mp->m_inode_cluster_size) returns 0. Also, mkfs.xfs would have set xfs_sb->sb_inoalignmt to 0. This causes xfs_ialloc_cluster_alignment() to return 0. Due to this args.minalignslop (in xfs_ialloc_ag_alloc()) gets the unsigned equivalent of -1 assigned to it. This later causes alloc_len in xfs_alloc_space_available() to have a value of 0. In such a scenario when args.total is also 0, the assert statement "ASSERT(args->maxlen > 0);" fails. This commit fixes the bug by replacing the call to XFS_B_TO_FSBT() in xfs_ialloc_cluster_alignment() with a call to xfs_icluster_size_fsb(). Suggested-by: Darrick J. Wong <[email protected]> Signed-off-by: Chandan Rajendra <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The bo->resv pointer could be NULL, leading to kernel oopses like the one below. This patch ensures that bo->resv is always set in vc4_create_object ensuring that it is never NULL. Thanks to Eric Anholt for pointing to the correct solution. [ 19.738487] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 19.746805] pgd = ffff8000275fc000 [ 19.750319] [00000000] *pgd=0000000000000000 [ 19.754715] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 19.760369] Modules linked in: smsc95xx usbnet vc4 drm_kms_helper drm pwm_bcm2835 i2c_bcm2835 bcm2835_rng rng_core bcm2835_dma virt_dma [ 19.772767] CPU: 0 PID: 1297 Comm: Xorg Not tainted 4.12.0-rc1-rpi3 #58 [ 19.779476] Hardware name: Raspberry Pi 3 Model B (DT) [ 19.784688] task: ffff800028268000 task.stack: ffff800026c08000 [ 19.790705] PC is at ww_mutex_lock_interruptible+0x14/0xc0 [ 19.796329] LR is at vc4_submit_cl_ioctl+0x4fc/0x998 [vc4] ... [ 20.240855] [<ffff0000088975f4>] ww_mutex_lock_interruptible+0x14/0xc0 [ 20.247528] [<ffff0000009b3ea4>] vc4_submit_cl_ioctl+0x4fc/0x998 [vc4] [ 20.254372] [<ffff0000008f75f8>] drm_ioctl+0x180/0x438 [drm] [ 20.260120] [<ffff00000821383c>] do_vfs_ioctl+0xa4/0x7d0 [ 20.265510] [<ffff000008213fe4>] SyS_ioctl+0x7c/0x98 [ 20.270550] [<ffff000008082f30>] el0_svc_naked+0x24/0x28 [ 20.275941] Code: d2800002 d5384103 910003fd f9800011 (c85ffc04) [ 20.282527] ---[ end trace 1f6bd640ff32ae12 ]--- Signed-off-by: Hans Verkuil <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
When using 15kHz modes (which are supported on the blob firmware via hdmi_mode=8), the actual timing differs. I've created an edid for 1920x240 (hdmi_mode=8 uses 720x240 with pixel doubling). The horizontal scan should be about 15.7kHz and vertical is about 60Hz. Actual measured timings are 12.85kHz and 50.8Hz.
The next step is probably to dump the registers and figure out where the math has gone wrong.
1920x240.zip
The text was updated successfully, but these errors were encountered: