Hello.
Cyril Chemparathy wrote:
Hi Sergei,
[...]
+struct tnetv107x_device_info evm_device_info __initconst = {
+ .serial_config = &serial_config,
+ .mmc_config[1] = &mmc_config,
+ .nand_config[0] = &nand_config,
Index 0 of the nand_config array indicates the chip select.
Please see the comment in the structure's definition:
> struct davinci_nand_pdata *nand_config[4]; /* 4 chipsels */
I guess I should explicitly put in a comment in the initializer as well.
+};
+
+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.
No, they are. What CS is chosen for which flash is totally board
specific. And *that* determines the set of the platfrom device
resource you have.
Sorry, Sergei. I fail to see the argument. In what way does the
emif's control register space end up being board specific?
I'm talking about the 2nd resource all the time, i.e. CS space.
Further, given a specific chip-select (e.g. cs 0), the window is again
fixed in the soc to be at 0x30000000. Therefore, the mapping between
chip select line and window is again board specific.
Yes. And I don't see how different CSs are handled by your code. The
device always has CS0 space as a resource. If you'd make nand_init()
change the resource on the fly before registering, then this would have
worked out.
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.
Right, and I don't see where you retained the chip select.
Please see above, index in the nand_config array is the chip select.
Ah, indeed -- that wasn't obvious -- I rather expected to see
something in the platfrom data...
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?
I don't know -- asking you. We had to do in on DA830 EVM where
NAND is on a daughter board...
The boot-loader on this platform absolutely must set this up to be
able to load the kernel. That said, unless I am unwittingly breaking
an unwritten rule, I'd rather let the bootloader's setup remain.
Agreed.
Regards
Cyril.
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
