On Thu, May 16, 2013 at 04:32:58PM +0200, Peter Korsgaard wrote:
"Tom" == Tom Rini trini@ti.com writes:
Tom> From: Steve Kipisz s-kipisz2@ti.com Tom> This patch adds support for the NOR module that attaches Tom> to the memory cape for a Beaglebone board. This does not Tom> add booting support; only support so that you can boot from Tom> SD/MMC and see the NOR module so that it can be programmed.
[snip]
Tom> @@ -77,9 +77,15 @@ void gpmc_init(void)
Tom> /* global settings */ Tom> writel(0x00000008, &gpmc_cfg->sysconfig); Tom> +#ifdef CONFIG_NOR Tom> + writel(0x00000000, &gpmc_cfg->irqstatus); Tom> + writel(0x00000000, &gpmc_cfg->irqenable); Tom> + writel(0x00000A00, &gpmc_cfg->config); Tom> +#else Tom> writel(0x00000100, &gpmc_cfg->irqstatus); Tom> writel(0x00000100, &gpmc_cfg->irqenable); Tom> writel(0x00000012, &gpmc_cfg->config); Tom> +#endif
This looks to me as an indication that irqstatus/irqenable/config should really be arguments of gpmc_init().
Perhaps. I've still got an open poke about what's going on, exactly here.
[snip]
Tom> +/* NOR chip on NOR module for Beaglebone */ Tom> +#define STNOR_GPMC_CONFIG1 0x00001200 Tom> +#define STNOR_GPMC_CONFIG2 0x00101000 Tom> +#define STNOR_GPMC_CONFIG3 0x00030301 Tom> +#define STNOR_GPMC_CONFIG4 0x10041004 Tom> +#define STNOR_GPMC_CONFIG5 0x000C1010 Tom> +#define STNOR_GPMC_CONFIG6 0x08070280 Tom> +#define STNOR_GPMC_CONFIG7 0x00000F48
Why are these not in board/ti/am335x/board.{c,h} if they are beaglebone specific?
The timings would be valid to anyone using the same NOR on a custom chip. I'll re-word the comment.
Tom> +#ifdef CONFIG_NOR Tom> + /* Reconfigure CS0 for NOR instead of NAND. */ Tom> + enable_gpmc_cs_config(gpmc_nor, &gpmc_cfg->cs[0], Tom> + CONFIG_SYS_FLASH_BASE, GPMC_SIZE_16M); Tom> +#endif Tom> +
Perhaps the nand handling should just get moved out of gpmc_init() (or the _cs_config args should be passed to gpmc_init() ).
I looked at this, on the scale of redoing omap3 too (where we have a lot of existing examples). The split we've got now works and it's harmless to re-configure CS0 in the case where the defaults don't work. I think this would lead us to an abstraction that leads to a lot of board files duplicating the same code.