Hello, Having used the Microchip SAMA5D2 for some time, I have some devices that work with the legacy device tree bindings for the atmel_nand controller. While updating from 4.14 to 4.19, I am trying to use the updated bindings instead. However I have encountered a problem with the timings configured in the NAND controller. When using the legacy bindings, the hardware timings that have been written by the bootloader are left alone, but with the new bindings they are recalculated, using the ONFI table. When using non-ONFI devices (which is very common, as Toshiba, Samsung, etc. don't implement ONFI), the timings are configured to the work with the slowest ONFI class, which is very slow compared to the possible performance of those chips. For the atmel_nand driver, the root of the difference is that there is no clock available in the "mck" field of the nand_controller structure in the legacy binding, and as a result the setup_data_interface() hook is empty. But this is a problem that could affect any NAND controller that implements the setup_data_interface() hook. Unfortunately, I have a hard time finding a satisfying solution to this: - Adding a property to the NAND chip's device tree node, directing the NAND driver to preserve the bootloader's timings is quite easy, but this is not a good solution as we are adding software information to the hardware description - Adding a property indicating that the Flash chip is not ONFI is redundant, as detecting whether a chip supports ONFI can be autodetected. But the Reset command, that must be sent to ONFI chips on startup to reliably to detect them, needs to be sent with the slowest ONFI timings to work correctly with chips using the ONFI DDR mode. As a result, auto-detection needs to change the NAND controller's timings to detect ONFI chips. The 'best' answer I have for now, is to add a 'timings' subnode to the NAND chip's device tree node, that explicitly encodes all the values from the timing table as described in "struct nand_sdr_timings", which is derived from the ONFI specification, and extend it to add the various values that are present in the timing table for Toshiba NAND chips and compatibles. But I am not very satisfied with this solution, as it adds a lot of code for little gain. What was the original plan for handling timing requirements for non-ONFI chips when introducing setup_data_interface()? Best regards, -- Romain Izard
