[PATCH 0/2] staging: ion: Add ion-physmem driver

From: Andrew Andrianov
Date: Mon Apr 06 2015 - 11:55:21 EST

Please do not merge the following patchset yet, it's only a very early
proof-of-concept and it needs cleanup, discussion and advice.
Since I'm quite new to ION, so I may be missing a few vital details.

The following ion driver implements a simple way to define ION heaps from a
devicetree description. e.g.

>From on-chip SRAM:
ion_im0: ion@00100000 {
compatible = "ion,physmem";
reg = <0x00100000 0x40000>;
reg-names = "memory";
ion-heap-id = <2>;
ion-heap-type = <ION_HEAP_TYPE_DMA>;
ion-heap-align = <0x10>;
ion-heap-name = "IM0";

ion_crv: ion@deadbeef {
compatible = "ion,physmem";
reg = <0x00000000 0x100000>;
reg-names = "memory";
ion-heap-id = <3>;
ion-heap-type = <ION_HEAP_TYPE_CARVEOUT>;
ion-heap-align = <0x10>;
ion-heap-name = "carveout";

This way you can define any ION heap, so it pretty much supersedes the dummy
driver that has everything hardcoded and is good for nothing but tests.
For ION_HEAP_TYPE_DMA, if 'reg' range is present in devicetree it does a
proper declare_dma_coherent_memory() and parses reg field as a physical address
range. E.g. this way you can pass on-chip SRAM or dedicated RAM banks
to ION to be used as a heap.
If reg is not present - behavior is identical to a DMA heap of ion_dummy driver.

For carveout and chunk heaps it behaves just like the dummy driver, allocating
some free pages as a heap and freeing them when unloaded. reg range is used
for size calculations via resource_size() only.

For system/system_contig things stay pretty much the same, except for it
doesn't do any page allocations by itself and just passes all
parameters down to ION

My use case:
The SoC I'm making this for is K1879XB1YA (Ð1879ÐÐ1Ð) / MB77.07:
Product page: http://www.module.ru/en/catalog/micro/micro_pc/
Hopefully I'll get basic support for this SoC ready for submission by
the next merge window.
It has dedicated 128MiB 'multimedia' memory that ARM core can't execute
code from, but can write/read to and several huge (256KiB) banks of
on-chip SRAM. All mapped into physical address space.
ION's job will be pretty much allocating from those banks, each making up it's
own heap and sharing the buffers between DSP, ARM and a few multimedia devices.

Remaining questions about this driver:
* Should this ION driver take care to optionally enable/disable clocks the way
drivers/misc/sram.c does?
* Not sure if try_module_get/module_put magic is really needed there and used
properly. Building as a module and unloading has NOT yet been tested, is on my
TODO list.


Andrew Andrianov (2):
staging: ion: Add ion-physmem driver
staging: ion: Add ion-physmem documentation

Documentation/devicetree/bindings/ion,physmem.txt | 80 +++++++
drivers/staging/android/ion/Kconfig | 7 +
drivers/staging/android/ion/Makefile | 5 +-
drivers/staging/android/ion/ion_physmem.c | 237 +++++++++++++++++++++
4 files changed, 327 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ion,physmem.txt
create mode 100644 drivers/staging/android/ion/ion_physmem.c


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/