[PATCH 1/4] of: Add device tree bindings for Evatronix

[Ricard Wanderlof]

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.

> > 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.

> > A minor related issue which I been pondering over is that the fact that 
> > the supported timing modes of an ONFi flash are expressed as a bit vector 
> > rather than just a single 'highest possible mode' value, which indicates 
> > that the idea is that a flash may support a certain mode but not 
> > necessarily all the ones below, e.g. supporting modes 3, 2 and 0.
> 
> That was a deliberate choice. Honestly, I've never seen a NAND that is
> capable of supporting higher modes without supporting the lower ones.
> If that ever happens, we'll switch back to a bitmap, but that's rather
> unlikely.

I agree, I would find that hard to believe too. I just don't have the 
experience to back that up. And the fact that ONFi chips actually do 
report this as a bitmap indicates that someone at some time considered 
this a distinct possibility. Or it could just be part of making the 
specification as general as possible without actually having any practical 
case for it.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30