OMAP-GPMC generic timing migration

Hi Afzal,

Quoted 6 lines · Afzal Mohammed

Quoted 4 lines · Afzal Mohammed

I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one.

Quoted 8 lines

I commented on auxdata usage without visualising in more detail how it can be implemented, it was bad of me.

I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though.

Maybe slightly off-topic, but still:

When GPMC is used for driving NAND chips that comply to CFI, the timings could actually be derived from the connected peripheral as well. I believe a slowest-possible-mode will have to be selected first for the identication phase.

Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific.