From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753405AbbDFPzS (ORCPT ); Mon, 6 Apr 2015 11:55:18 -0400 Received: from forward2l.mail.yandex.net ([84.201.143.145]:57015 "EHLO forward2l.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753292AbbDFPzD (ORCPT ); Mon, 6 Apr 2015 11:55:03 -0400 X-Greylist: delayed 331 seconds by postgrey-1.27 at vger.kernel.org; Mon, 06 Apr 2015 11:55:03 EDT From: Andrew Andrianov To: Greg Kroah-Hartman , =?UTF-8?q?Arve=20Hj=EF=BF=BDnnev=EF=BF=BDg?= , Riley Andrews , Chen Gang , Fabian Frederick Cc: Andrew Andrianov , linux-kernel@vger.kernel.org Subject: =?UTF-8?q?=5BPATCH=200/2=5D=20staging=3A=20ion=3A=20Add=20ion-physmem=20driver=20?= Date: Mon, 6 Apr 2015 18:49:21 +0300 Message-Id: <1428335363-9854-1-git-send-email-andrew@ncrmnt.org> X-Mailer: git-send-email 1.7.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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-align = <0x10>; ion-heap-name = "IM0"; }; or ion_crv: ion@deadbeef { compatible = "ion,physmem"; reg = <0x00000000 0x100000>; reg-names = "memory"; ion-heap-id = <3>; ion-heap-type = ; 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. Regards, Andrew 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 -- 1.7.10.4