[PATCH] arm, davinci: configure davinci aemif chipselects through OF

Ben Gardiner bengardiner at nanometrics.ca
Wed Dec 14 09:35:25 EST 2011

Hello Arnd and Sekhar,

On Tue, Dec 13, 2011 at 1:34 PM, Nori, Sekhar <nsekhar at ti.com> wrote:
> [...]
> On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote:
>> [...]
>> 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.
> Okay. Thanks for the explanation. Since the users of AEMIF at this
> point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c
> (of course, mtd folks need to approve).

We have a vested interest in the davinci AEMIF setup facilities
in-kernel; I'm electing to pipe-up now rather than later. Sadly our
board is not yet in mainline so my opinions may be redirected to the
bit-bucket as you see fit. We are planning to post a patch series for
our complete board support -- but we can't do it right now.

The AEMIF is useful for interfacing to other asynchronous devices too;
our newest board uses it for accessing memory mapped FPGA functional
blocks via UIO and for permanent storage to a compact flash using
pata_platform. In both cases the timings and mode for the chip-select
are manually configured before the devices are registered. In both
cases the performance of the endpoints could be better preserved
across CPU freq transitions if the hooks for cpufreq transitions
recently proposed by Sudhakar [1] were part of an mfd device and hence
applicable to devices other than mtd.

Again, I apologize for requesting features for boards that are not yet
in mainline.

Best Regards,
Ben Gardiner

[1] http://article.gmane.org/gmane.linux.drivers.mtd/36876/

Nanometrics Inc.

More information about the linux-arm-kernel mailing list