From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF
Date: Thu, 8 Dec 2011 15:48:08 +0000 [thread overview]
Message-ID: <201112081548.08548.arnd@arndb.de> (raw)
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6040CBB@DBDE01.ent.ti.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: "Nori, Sekhar" <nsekhar-l0cyMroinI0@public.gmane.org>
Cc: "Hilman, Kevin" <khilman-l0cyMroinI0@public.gmane.org>,
"davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org"
<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"gregkh-l3A5Bk7waGM@public.gmane.org"
<gregkh-l3A5Bk7waGM@public.gmane.org>,
"hs-ynQEQJNshbs@public.gmane.org"
<hs-ynQEQJNshbs@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] arm, davinci: configure davinci aemif chipselects through OF
Date: Thu, 8 Dec 2011 15:48:08 +0000 [thread overview]
Message-ID: <201112081548.08548.arnd@arndb.de> (raw)
In-Reply-To: <DF0F476B391FA8409C78302C7BA518B6040CBB-Er742YJ7I/eIQmiDNMet8wC/G2K4zDHf@public.gmane.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
next prev parent reply other threads:[~2011-12-08 15:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-04 9:41 [PATCH] arm,davinci: configure davinci aemif chipselects through OF Heiko Schocher
2011-12-04 9:41 ` Heiko Schocher
2011-12-04 12:25 ` [PATCH] arm, davinci: " Sergei Shtylyov
2011-12-04 12:25 ` Sergei Shtylyov
2011-12-05 10:50 ` Heiko Schocher
2011-12-05 10:50 ` Heiko Schocher
2011-12-04 12:33 ` Sergei Shtylyov
2011-12-04 12:33 ` Sergei Shtylyov
2011-12-05 11:49 ` Heiko Schocher
2011-12-05 11:49 ` Heiko Schocher
2011-12-07 10:44 ` [PATCH] arm,davinci: " Nori, Sekhar
2011-12-07 10:44 ` Nori, Sekhar
2011-12-08 7:47 ` [PATCH] arm, davinci: " Heiko Schocher
2011-12-08 7:47 ` Heiko Schocher
2011-12-08 8:19 ` [PATCH] arm,davinci: " Nori, Sekhar
2011-12-08 8:19 ` Nori, Sekhar
2011-12-08 9:06 ` [PATCH] arm, davinci: " Heiko Schocher
2011-12-08 9:06 ` Heiko Schocher
2011-12-08 10:29 ` [PATCH] arm,davinci: " Nori, Sekhar
2011-12-08 10:29 ` Nori, Sekhar
2011-12-08 15:48 ` Arnd Bergmann [this message]
2011-12-08 15:48 ` [PATCH] arm, davinci: " Arnd Bergmann
2011-12-13 18:34 ` [PATCH] arm,davinci: " Nori, Sekhar
2011-12-13 18:34 ` Nori, Sekhar
2011-12-14 14:35 ` [PATCH] arm, davinci: " Ben Gardiner
2011-12-14 14:35 ` Ben Gardiner
2011-12-15 17:10 ` [PATCH] arm,davinci: " Nori, Sekhar
2011-12-15 17:10 ` Nori, Sekhar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201112081548.08548.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.