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

[Boris Brezillon <boris.brezillon@free-electrons.com>]

On Fri, 28 Oct 2016 18:01:44 +0200
Ricard Wanderlof <ricard.wanderlof@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.