OMAPFB: use dma_alloc instead of omap's vram

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

...

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

Hi,

Quoted 6 lines · Tomi Valkeinen

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

Quoted 5 lines

...

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?

Quoted 2 lines

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

That's a significant change, you should update Documentation/ .

What about omapfb.vram, is it still there?

Perhaps we also need to select/depend on CMA?

Hi,

Quoted 11 lines · Tomi Valkeinen

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

...

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

Do at least OMAPFB_QUERY_MEM/OMAPFB_SETUP_MEM still work?

Quoted 2 lines

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

That's a significant change, you should update Documentation/ .

Hi,

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational.

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

Quoted 19 lines · Tomi Valkeinen

Hi,

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational.

Quoted 6 lines

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?

Feel free to add my Acked-by: Tony Lindgren <[email protected]> to the arch/arm/*omap*/* parts.

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

Quoted 6 lines · Tomi Valkeinen

I added your acks, and pushed:

git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion

It's based on -rc4 as my other branches are based on that.

OK thanks!

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

HI Tomi,
we need one rank of cma to allocate the memory for driver in kernel space .And the default CMA is for allocating memory frome usespace.So if we allocate the memory from the
default CMA zone ,there maybe introduce fragmention to the default CMA zone.The kernel space memory donot touch the memory from userspace

Quoted 1 line

How do you allocate CMA memory from userspace

Hi,

Quoted 6 lines · Jello huang

HI Tomi,
we need one rank of cma to allocate the memory for driver in kernel space .And the default CMA is for allocating memory frome usespace.So if we allocate the memory from the
default CMA zone ,there maybe introduce fragmention to the default CMA zone.The kernel space memory donot touch the memory from userspace

Can you elaborate a bit? I didn't understand your point. Are you saying each kernel driver that uses dma_alloc should have their own CMA zone? That doesn't make sense...

How do you allocate CMA memory from userspace?

Tomi

Quoted 23 lines · Tomi Valkeinen

Hi,

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational.

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

Quoted 2 lines

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?

Hi Tony,

Quoted 27 lines · Tony Lindgren

Quoted 25 lines · Tomi Valkeinen

Hi,

This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent.

However, note that using standard dma funcs causes the following downsides:

1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational.

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter.

Quoted 3 lines

Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?

Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also?

I have to say I don't know the details of the dma allocation, but afaik there are no drawbacks with CMA. Although it is still marked EXPERIMENTAL in the kconfig...

Quoted 2 lines

Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also?

Yes if that's now needed for DSS.