* Daniel Mack <zonque@xxxxxxxxx> [121017 08:15]: > Hi Afzal, > > On 17.10.2012 07:42, Afzal Mohammed wrote: > > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: > >> 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. > > > > 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. I wish.. Just getting things working to the identification phase requires quite a bit of configuration for the timings. > 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. Yes and the level shifters affect timings too. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
