[PATCH 1/4] of: Add device tree bindings for Evatronix
Boris Brezillon
boris.brezillon at free-electrons.com
Fri Oct 28 09:20:22 PDT 2016
On Fri, 28 Oct 2016 18:01:44 +0200
Ricard Wanderlof <ricard.wanderlof at axis.com> wrote:
> On Fri, 28 Oct 2016, Boris Brezillon wrote:
>
> > > One thing I would have liked to have is to have the actual timing mode
> > > number in the nand_data_interface struct, for controllers like in my case
> > > where it's problematic to take the numeric timing values and map them to
> > > register values, and the timing register values need to be pre-computed.
> >
> > What do you mean by pre-computed? If you're able to pre-compute the
> > timings, why can't you do that at runtime?
>
> The short answer in this case is because the timing values were delivered
> by our ASIC integration vendor, partly after running simulations to verify
> the exact timing using the actual silicon layout. That is why I originally
> wanted to put those timing register values directly in the DT, becuase
> they are in practice part of the specifications for the actual ASIC. In
> essence, we looked at the flash chips we wanted to use with the ASIC, and
> realized they all conformed to ONFi mode 2. Our vendor then provided us
> with mode 2 timing values that they guaranteed would work with the chip.
> (In addition, mode 0 is used during initial boot so minimize the
> likeleyhood that something would go wrong, given that the boot loader is
> in a ROM.) Especially given that there was no mtd timing setup
> infrastructure at the time, we had no interest in how the values were
> derived, or to support more modes.
>
> Another issue is how to model the internal delays within the ASIC between
> the NAND controller IP and the pads, which are also part of the equation.
>
> I don't know if our case is unique, but at least it is an example of a
> situation in which runtime calculation of the timing register values is
> problematic.
Okay. I guess we could add the associated ONFI timing mode to the
nand_data_interface struct (it would represent the closest one if the
NAND is not ONFI and some vendor specific implementation decided to
tweak the timing values).
>
> > > There might be other reasons where the driver might want to know the mode
> > > number.
> >
> > Do you have real examples?
>
> No, it just seemed like a reasonable concept, given that
> nand_init_data_interface() actually does this mapping anyway, so it might
> as well inform chip->setup_data_interface() about it, since the
> information is right there anyway.
>
> > We could pass the ONFI timing mode here, but some timings are not
> > defined using this mode (like tCCS), and I'm not sure we have the same
> > mapping between ONFI and JEDEC modes. The other thing is that I wanted
> > to leave the door open for vendor specific timing definitions which do
> > not exactly match one of the timing mode defined in the ONFI spec.
> >
> > That's why I didn't bother exposing the ONFI timing mode to the NAND
> > controller ->setup_data_interface() implementation.
>
> Ok, so the reason is really future expansion, where ONFi modes 0..5 may
> not be the only modes to be configured. Fair enough.
Yep.
More information about the linux-mtd
mailing list