From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 8 Dec 2011 15:48:08 +0000 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> Message-ID: <201112081548.08548.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 08 December 2011, Nori, Sekhar wrote: > DaVinci AEMIF is an async memory interface peripheral implemented > in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR > and other asynchronous memories. Currently it just provides an API > for timing value configuration. The API is invoked by the MTD NAND > driver. > > Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf > > We are looking at a place for this outside of architecture code. I think the best place depends on how you plan to use the sram interface. If all memory behind the aemif is handled by mtd, I would put the entire driver somewhere in the mtd infrastructure. If you want it to provide endpoint devices that are handled by distinct subsystems in Linux, I would make it an mfd multifunction device and make the common code a driver that scans the connected memories in order to register its child devices for each of the subsystems. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH] arm, davinci: configure davinci aemif chipselects through OF Date: Thu, 8 Dec 2011 15:48:08 +0000 Message-ID: <201112081548.08548.arnd@arndb.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: "Nori, Sekhar" Cc: "Hilman, Kevin" , "davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org" , Wolfgang Denk , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "gregkh-l3A5Bk7waGM@public.gmane.org" , "hs-ynQEQJNshbs@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On Thursday 08 December 2011, Nori, Sekhar wrote: > DaVinci AEMIF is an async memory interface peripheral implemented > in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR > and other asynchronous memories. Currently it just provides an API > for timing value configuration. The API is invoked by the MTD NAND > driver. > > Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf > > We are looking at a place for this outside of architecture code. I think the best place depends on how you plan to use the sram interface. If all memory behind the aemif is handled by mtd, I would put the entire driver somewhere in the mtd infrastructure. If you want it to provide endpoint devices that are handled by distinct subsystems in Linux, I would make it an mfd multifunction device and make the common code a driver that scans the connected memories in order to register its child devices for each of the subsystems. Arnd