On Tuesday, February 11, 2014 2:11:59 PM UTC-5, Siarhei Siamashka wrote:
>
> The commit 1e205f75658cb0cf3addc28ddaa9912ca9ce14e8 happened to 
> break broken CedarX media players on the systems with 2GB of RAM 
> (Cubietruck). The problem is that some CedarX userland code (used 
> in VLC and XBMC together with proprietary blobs) already feeds 
> bus addresses to the sunxi disp ioctls, while physical addresses 
> are expected there. The open source libvdpau-sunxi does not have 
> such bugs. 
>
> This patch avoids phys->bus conversion if the address passed to 
> the __phys_to_bus macro is already obviously a bus address. 
>
> While the right solution would be to hunt down and fix all the 
> userland offenders, this may be difficult in practice. For example 
> when dealing with Android images and trying to provide a drop-in 
> kernel replacement for them. 
>
> Signed-off-by: Siarhei Siamashka <[email protected] <javascript:>> 
> --- 
>  arch/arm/plat-sunxi/include/plat/memory.h | 18 +++++++++++++++++- 
>  1 file changed, 17 insertions(+), 1 deletion(-) 
>
> diff --git a/arch/arm/plat-sunxi/include/plat/memory.h 
> b/arch/arm/plat-sunxi/include/plat/memory.h 
> index 42a4afa..3a94fe6 100644 
> --- a/arch/arm/plat-sunxi/include/plat/memory.h 
> +++ b/arch/arm/plat-sunxi/include/plat/memory.h 
> @@ -30,7 +30,23 @@ 
>  /* default ATAG_MEM size */ 
>  #define MEM_SIZE        (512*1024*1024) 
>   
> -#define __phys_to_bus(x) ((x) - PLAT_PHYS_OFFSET) 
> +/* 
> + * HACK: if 'x' argument is lower than PLAT_PHYS_OFFSET in the 
> '__phys_to_bus' 
> + *       macro (which is incorrect by itself), then we know that 
> something is 
> + *       wrong. Most likely 'x' is already a bus address (result of a 
> conversion 
> + *       of some physical address belonging to the first 1GB of DRAM). 
> Not much 
> + *       harm is done if we just keep it as-is instead of wrapping around 
> into 
> + *       the 0xC0000000-0xFFFFFFFF range. The typical offenders are the 
> CedarX 
> + *       userland wrappers around proprietary blobs, which mess up the 
> address 
> + *       arithmetics and may introduce an arbitrary address offset (this 
> offset 
> + *       is a multiple of 0x40000000). As we have little control over the 
> blobs 
> + *       used in Android, this hack may workaround some issues for the 
> users 
> + *       of the systems with 2GB of RAM (the adverse effects of a 
> multiple of 
> + *       0x40000000 address calculation bugs only show up on such 
> systems). 
> + */ 
> + 
> +#define __phys_to_bus(x) ((u32)(x) < PLAT_PHYS_OFFSET ? (x) : \ 
> +                                                        (x) - 
> PLAT_PHYS_OFFSET) 
>  #define __bus_to_phys(x) ((x) + PLAT_PHYS_OFFSET) 
>   
>  #endif 
> -- 
> 1.8.3.2 
>
> Works for me on a 2GB CT.

Acked-by: Patrick Wood <[email protected]>

-- 
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/groups/opt_out.

Reply via email to