linux-kernel - [PATCH v2 0/2] staging: ion: Generic ion-physmem driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1428700380-8059-1-git-send-email-andrew@ncrmnt.org>
Date:	Sat, 11 Apr 2015 00:12:58 +0300
From:	Andrew Andrianov <andrew@...mnt.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	pebolle@...cali.nl,
	Arve Hj�nnev�g <arve@...roid.com>,
	Riley Andrews <riandrews@...roid.com>,
	Chen Gang <gang.chen.5i5j@...il.com>,
	Fabian Frederick <fabf@...net.be>,
	Android Kernel Team <kernel-team@...roid.com>
Cc:	Andrew Andrianov <andrew@...mnt.org>, linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/2] staging: ion: Generic ion-physmem driver

Rebased against 4.0-rc7.
This is the resubmit of my previous patches with fixes based on reviews by 
Greg and Paul and some futher improvements.
Changes since previous submit:
* Take care to enable the clock, if clock's specified in devicetree 
  (just like drivers/misc/sram.c)
* Do not ever try to build it as a module - ION doesn't support it (Yet?)  
* More sanity in error-reporting
* Keep track of registered heap ids and complain about duplicates (if any)
* Cleanup

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@...00000 {
                     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";
                };

The same, but with clock gating (if really needed): 
                ion_im0: ion@...00000 {
                     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";
	             clocks = <&pclk>;
		     clock-names = "apb_pclk";
                };

or 
		ion_crv: ion@...dbeef {
		     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. 

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

 Documentation/devicetree/bindings/ion,physmem.txt |   96 +++++++++
 drivers/staging/android/ion/Kconfig               |    7 +
 drivers/staging/android/ion/Makefile              |    5 +-
 drivers/staging/android/ion/ion_physmem.c         |  226 +++++++++++++++++++++
 include/dt-bindings/ion,physmem.h                 |   17 ++
 5 files changed, 349 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ion,physmem.txt
 create mode 100644 drivers/staging/android/ion/ion_physmem.c
 create mode 100644 include/dt-bindings/ion,physmem.h

-- 
1.7.10.4

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