[PATCH] mtd: mxc_nand: Set timing for v2 controllers
Boris Brezillon
boris.brezillon at free-electrons.com
Mon Aug 29 01:50:50 PDT 2016
Hi Sascha,
On Mon, 29 Aug 2016 10:35:58 +0200
Sascha Hauer <s.hauer at pengutronix.de> wrote:
> Hi Boris,
>
> On Fri, Aug 26, 2016 at 09:46:53AM +0200, Boris Brezillon wrote:
> > Hi Sascha,
> >
> > On Tue, 23 Aug 2016 12:34:05 +0200
> > Sascha Hauer <s.hauer at pengutronix.de> wrote:
> >
> > AFAIR, you should apply the new mode on the NAND side
> > (ONFI_FEATURE_ADDR_TIMING_MODE) before applying the new config to the
> > controller.
> >
> > See what's done here [1].
> >
> > Note that on all the NANDs I tested, it seems to work even if you don't
> > set ONFI_FEATURE_ADDR_TIMING_MODE, but the ONFI Spec describes the
> > procedure as:
>
> Indeed, works here without notifying the NAND chip aswell. I wasn't even
> aware that there is a possibility to notify the NAND chip.
>
> >
> > 1/ detect supported modes
> > 2/ select one
> > 3/ apply it to the NAND using set(ONFI_FEATURE_ADDR_TIMING_MODE)
> > 4/ release the CS
> > 5/ adjust the controller setting to match the new config
> >
> > On a side note, I really think we should handle this timing selection in
> > the core, and only ask the NAND controller drivers to adapt the
> > controller settings.
>
> I agree that the core should do this. Do you already have any thoughts
> how the API could could look like?
I already provided a simple implementation a while ago [1]. Not sure it
handles all the corner cases though.
> The Nand drivers probably have to
> propagate somehow which modes they support, maybe we add a onfi_modes
> field to struct nand_chip. Then if onfi_modes is nonzero we call a
> nand_chip->set_onfi_mode() function?
The idea was to have some way to ask the controller whether it supports
specific timings or not. I don't remember if this was part of my
initial proposal.
Note that we should pass struct real timings and not ONFI timing
mode.
Regards,
Boris
[1]https://lkml.org/lkml/2015/10/23/179
More information about the linux-arm-kernel
mailing list