On Tue, 8 Apr 2014 08:21:34 -0700 (PDT)
Juan Font <juanfontalo...@gmail.com> wrote:

> Hi, 
> 
> some days ago, nove linked at the IRC channel a new armel release of 
> libcedarv 
> (http://dl.cubieboard.org/software/common/linux-codec-release-V1.2.rar) for 
> Android and Sunxi kernels, along with some example code and doc. He also 
> found an armhf version 
> (http://dl.cubieboard.org/software/common/linux_codec_gnueabihf_20140327.tar.gz)
>  
> for Android (it requires the ION memory allocator). Today I emailed Huang 
> Benn from Cubietech asking for the sunxi-armhf version of libcedarv. He 
> kindly sent me it (http://dl.cubieboard.org/software/common/A20-sunxi.rar), 
> clarifying that it requires the 'sunxi-mem' driver from an Allwinner 
> engineer. 
> 
> I found sunxi_mem here 
> https://github.com/cubieboard2/linux-sunxi/tree/sunxi-3.3-cb2/drivers/char/sunxi_mem.
>  
> It seems to be GPLv2+ code. I've ported it almost directly here 
> https://github.com/juanfont/linux-sunxi/commit/e8937b50bc749cf1069b6881e0189831381d342b.
>  
> 
> I've tested it with the encoding examples from the linux-codec-release-V1.2 
> package and, although there are some color issues, the encoder appears to 
> work. 

Thanks for sharing this information. Could you please add a short guide
about using this video encoder to the linux-sunxi wiki? So that the
other people could easily reproduce your test results.

> Is this code acceptable in the sunxi-3.4 branch? Should I proceed with a 
> pull request?  

I'm afraid that this driver is still not good enough to be taken as-is.

The most serious problem is that it assumes that it has a certain
hardcoded range of physical addresses available for its disposal:

+#define        BUFFER_PADDR                    SW_VE_MEM_BASE
+#define        BUFFER_VADDR                    BUFFER_PADDR
+#define        BUFFER_SIZE                     SW_VE_MEM_SIZE

However the sunxi-3.4 kernel does is not hardcoding these addresses
anymore. With CMA disabled, the memory for VE is reserved early at
boot time, with the buffer address and size getting assigned
dynamically (no magic constants). And if CMA is enabled, then this
early reservation for VE does not even exist at all, and the cedar
driver is allocating memory using dma_alloc_*/dma_free_* functions.

I suggest to modify this driver to strictly depend on CMA and make
use of dma_alloc_*/dma_free_* functions too.

Without these changes, this sunxi_mem driver just corrupts memory
and may take down your system any time.

-- 
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 linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to