On Wed, 2 Apr 2014 03:00:15 -0700 (PDT) Ivan Kozic <[email protected]> wrote:
> On Monday, March 31, 2014 5:53:52 PM UTC+2, Siarhei Siamashka wrote: > > > > On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) > > Ivan Kozic <[email protected] <javascript:>> wrote: > > > > > Hi Luc, > > > > > > Found out why disp driver has choppy overlay - for me overlay comes > > through > > > DMA from memory. Funny thing - disp_malloc is fetching cached memory, so > > > choppiness or "trailing" is due to caching framebuffer protected memory. > > > Very silly - I found this out by changing caching method of ARM from > > > WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up > > :) > > > > > > The matter is solved by adding the following line to disp_mmap() > > function: > > > > > > vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > > > > > > Solved. Just wondering how people were using this before... > > > > As far as I know, nobody is using these bug ridden memory allocators > > that Allwinner has implemented in disp and g2d drivers. Except for > > maybe Allwinner itself in their Android code. > > Well, as far as I can see, the community is actively working on fixing > Sunxi kernel, although it seems that interest in 3.4 kernel is somehow > descending. The sunxi-3.4 kernel is still used for reverse engineering the undocumented graphics/multimedia hardware accelerators and prototyping the drivers for them. But I don't think that sunxi-3.4 will last more than 6-12 months even for this purpose. IMHO the end of life is very near. > Anyway, I thought that someone would use overlay from original disp driver, The disp layers are used by a number of sunxi related projects: https://github.com/linux-sunxi/libvdpau-sunxi https://github.com/ssvb/xf86-video-fbturbo http://linux-sunxi.org/XBMC http://linux-sunxi.org/VLC What I said is that disp and g2d memory allocators are not really used by anyone. The drivers from Allwinner lack any concept of security and are working with physical addresses. They accept these physical addresses from the userspace without any validation checks. Because every driver has full access to any location in physical memory (except for cedar, which can only address lowest 256MB of RAM), it is really irrelevant who has allocated/reserved any particular physically contiguous memory buffer. That's why xf86-video-fbturbo just uses the offscreen part of the framebuffer at the moment, and can use G2D to do some operations within it. And that's why libvdpau-sunxi uses the memory area allocated/reserved by the cedar driver for doing all video decoding in it and then just passes physical addresses to the disp driver to use them as overlays. No unnecessary memory copies are done (with or without DMA they would be just a waste of time and memory bandwidth). Anyway, the allocator integrated with the sunxi disp driver is so broken, that I have no non-swear words to express what I think about it. Assuming that you really need to allocate physically contiguous memory buffers for your purposes in sunxi-3.4, it would be probably better to forget about the half-baked buggy allocators in disp and g2d. And just implement a physically contiguous memory allocation in a separate small driver. So that no functionality is copy/pasted around with all the bugs and ugliness. Perhaps you could have a look at this 'sunxi_mem' thing together with Juan and try to make something usable out of it? https://www.mail-archive.com/[email protected]/msg03592.html > which is why I posted fixes for it - same goes for CSI. Maybe I have missed something. Where can we find the fixes? > As I said before, even though everything is dirty and buggy, abstraction > level is much easier to grasp in contrast with Freescale i.MX series > kernels, at least for beginner/intermediate in Linux programming... The extreme simplicity comes from totally ignoring security. This has both good and bad sides. > And honestly, it seems that A20 is suffering from much less HW bugs than > i.MX6, at least as far as I can see. Well, the kernel drivers got cleaned up a little bit and some bugs got ironed out. But it is still a mess. Especially in the parts of code, which are not really used by anyone. As for the HW bugs, I don't think that we have any public errata documents available for A20. But some HW related oddities exist. -- Best regards, Siarhei Siamashka -- 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.
