Hi all, I know that 3.4 kernel is rather old and not really interesting anymore, but I'm guessing there's quite some people out there still using it, since stuff like CSI or display engine are still not really usable on mainline or newer kernels. Therefore I wanted to share a problem with sunxi display driver that has been bugging me for quite some time.
It's mostly about using framebuffer (as in /dev/fb0) and display driver (/dev/disp) from two separate threads in userland. This is probably a recipe for disaster - most of the functions (let's say mid- to low- level - most with BSP_* prefix in their name) in sunxi display driver do not guard their resources with anything. And yet some are quite nicely shared between dev_fb.c (used by fbmem.c - main stuff for /dev/fbX is here) and dev_disp.c (display driver - /dev/disp). In turn this means we can''t safely use /dev/fbX from one thread (my example would be actually GUI Thread running Qt with Mali OpenGL ES acceleration), while using /dev/disp in the other (my example would be running video stream from CSI undeneath the fore-mentioned GUI). This setup is actually the basis of any camera-related project with any sunxi platform. And yes, it also cripples Mali, since Mali driver (mine is currently r3p2-01rel2) is directly using /dev/fbX to draw to screen. In my example I had to use digital zooming and the ioctl for setting scaler in display engine is DISP_CMD_LAYER_SET_SRC_WINDOW. The underlying function doing the work is BSP_disp_layer_set_src_window() located in disp_layer.c. This function is accessed from both /dev/fb (used for panning the framebuffer, an operation which for some reason is very frequent with my Qt/Mali setup) and /dev/disp drivers (as I said I'm using this for digital zoom) without guarding the resources, which breaks down after a while. How does it break down - for some reason video layer stays ok, while framebuffer layer is completely broken afterwards - refresh is not possible anymore (partially possible - it's working sometimes, sometimes it doesn't draw anymore) even after closing both /dev/fb and /dev/disp properly and starting the app again. The problem - sometimes it's working fine for more than an hour... Now I'm still not much of a linux kernel expert (not really so far down the internals to understand how threading under userland works), but I'm guessing that a mutex is really necessary here, since I do access the same function from two different threads and it seems to be quite a problem. Adding a simple mutex solves the problem. However, these functions are not really made for mutexing anything since they're all written very... basically and have multiple return paths. For me, a mutex lock after variables are declared and unlock on every exit point solves the problem, but I'd be very reluctant to officially submit such a patch. However, as I said - some people using /dev/disp might find this useful - if needed post back, I'll try to help if I can. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
