Hi Sergei, [...]
+static struct davinci_nand_pdata nand_config = { + .mask_cle = 0x4000, + .mask_ale = 0x2000, + .parts = nand_partitions, + .nr_parts = ARRAY_SIZE(nand_partitions), + .ecc_mode = NAND_ECC_HW, +}; + +struct davinci_uart_config serial_config __initconst = { + .enabled_uarts = BIT(1), +}; + +struct tnetv107x_device_info evm_device_info __initconst = { + .serial_config = &serial_config, + .mmc_config[1] = &mmc_config, + .nand_config[0] = &nand_config, +}; + +static __init void tnetv107x_evm_board_init(void) +{ + davinci_cfg_reg_list(sdio1_pins); + davinci_cfg_reg_list(uart1_pins); + + tnetv107x_devices_init(&evm_device_info); +}I totally disagree about moving NAND to devices-tnetv107x.c -- it's a board level device, not SoC level! Look at the existing boards, they all define NAND/NOR devices in the board file.
The EMIF controller in itself is a soc level device. The resources in question - EMIF control registers and the chipsel windows - are not board specific. Therefore I have moved these pieces into soc-level code.
The board-specific pieces are the ALE/CLE lines, and the chip-select on which the nand chip is connected. These elements have been retained in board-specific code.
For these reasons, I retain the belief (until convinced otherwise) that the existing boards get this wrong.
That aside, there is a bug in this code - it incorrectly uses chipsel0 window regardless of the chipsel index indicated by the board. This will be fixed in the next rev.
BTW, don't you also need a pin list for NAND?
The EMIF pins need to be muxed out by the bootloader for it to get the kernel into DDR. If so, do we still need to forcibly configure these pins?
Thanks Cyril. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
