User:Rellla

From linux-sunxi.org
Jump to: navigation, search

Contents

Hardware

A10

A20

H3

H5

Software

The software i'm currently dealing with:

Projects

Server usage: Possible server scenarios:

  • MiniDLNA Server (Cubietruck)
  • Logitech Media Server (Cubietruck)
  • VDR Server (Cubietruck)
  • Git Server (Cubietruck)
  • Apache, PHP, MySQL, Samba (Cubietruck)
  • controlling a 5x relay board for multiroom audio via android clients
  • In-/ outside-temperature and humidity logger

Client usage (testing with Cubieboard2 and legacy kernel):

Todos

Notices

Sunxi display driver bugs collection:

Useful links

[DISP] not supported image0 pixel sequence

Sometimes we have some issues with the 3.4 display driver. dmesg is flooded with messages like:

[DISP] not supported image0 pixel sequence:208 in img_sw_para_to_reg

or

[DISP] not supported yuv channel pixel sequence:0 in img_sw_para_to_reg

I think, this can be tracked down to https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/video/sunxi/disp/disp_video.c#L388 Hal_Set_Frame executes https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/video/sunxi/disp/disp_video.c#L357 and https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/video/sunxi/disp/disp_video.c#L362 which could be both responsible for the dmesg output in case the parameters don't exist anymore in memory. This would explain the different and not-reasonable values. Hal_Set_Frame is executed during VBlanking, which would explain the massive flooding. This all can happen when ((g_video[sel][id].enable == TRUE) && (g_video[sel][id].have_got_frame == TRUE)), which is triggered by the DISP_CMD_VIDEO_START and DISP_CMD_VIDEO_SET_FB ioctl. Both are set false with DISP_CMD_VIDEO_STOP again.

So, in case we forget the DISP_CMD_VIDEO_STOP ioctl, we may run into some issues with faulty parameters in Hal_Set_Frame itself. To debug that kernel bug, we could set some logs into Hal_Set_Frame, to see what happens. Or simply try to consequently use DISP_CMD_VIDEO_STOP. I could see this issue sometimes, if i CTRL-C a running program (e.g. sth. with libvdpau-sunxi) and then do another CTRL-C. Maybe everything is killed but g_video[sel][id].enable isn't set to FALSE again, which keeps Hal_Set_Frame executed every VBlank.

I think it has nothing to do with the other ioctls which trigger the img_sw_para_to_reg function in the end because of the massive (most likely 50Hz) flood of dmesg. With this background, one maybe can reproduce the issue.

Personal tools
Namespaces

Variants
Actions
Navigation
Tools