On Wed, Oct 07, 2015 at 03:33:50AM +0000, Anup Patel wrote:

From: Florian Fainelli [mailto:f.fainelli at gmail.com]

quoted

On 06/10/15 15:25, Scott Branden wrote:

[..]

quoted

Then instead of adding a "reset flag" to Device Tree, another approach could be
to put the desired or currently configured exhaustive list of NAND timings in
Device Tree, and based on that you could have this:

- the NAND controller driver finds that these timings match the current
configuration, you are good to go

- the NAND controller drivers finds a difference in how current timings are
configured vs. desired timings, and issues a controller reset, prior to applying
new timing configuration

To add to this ...

The mechanism to reset is BRCM NAND controller is SOC specific so the
SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how
to reset the NAND controller.

For iProc SoC family, the NAND controller reset is through IDM register
space which is only iomap'ed by iproc_nand.c.

We might end-up having one more SoC specific callback which will be
Provided by iproc_nand.c to brcmnand.c.

Not that I'm familiar with these SoCs, but I did want to chime in and
make sure you are aware of the existing reset_controller_dev
abstraction, which is intended to solve exactly this problem.  Including
a reset_control_get_optional() that might fit your use case.  See
include/linux/reset{,-controller}.h.

  Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151012/7129e0db/attachment.sig>