On Fri, Dec 7, 2018 at 11:22 AM Benjamin GAIGNARD <benjamin.gaignard@xxxxxx> wrote: > On 12/7/18 10:06 AM, Linus Walleij wrote: > > Hi Christophe, > > > > On Thu, Nov 29, 2018 at 5:42 PM Christophe Kerello > > <christophe.kerello@xxxxxx> wrote: > > > >> +/* FMC2 Controller Registers */ > >> +#define FMC2_BCR1 0x0 > >> +#define FMC2_PCR 0x80 > > (...) > >> +/* Register: FMC2_BCR1 */ > >> +#define FMC2_BCR1_FMC2EN BIT(31) > > Well this looks like an especially clever register map and a specific choice > > of bit 31 in the fist register to activate FMC2. Registers 0x04 thru > > 0x7c are completely unused save for one bit. > > > > It's almost like this is the good old FSMC integrated in parallel with FMC2, > > so that if you don't set bit 31, this becomes something that can be used > > with drivers/mtd/nand/raw/fsmc_nand.c, and FMC2 mode is activated > > by setting this bit, activating all the new registers. > > > > It wouldn't surprise me given how HW designers like to work. > > > > Is this the case? > > No, it is the same story than for stmfx driver, it looks to be the same > from registers > > point of view but internal hardware block design is completely different. I'm not saying FMC2 is the same, just that it seems they have duct-taped both IP-blocks (FSMC and FMC2) together at some point. It just looks so extremely odd to leave all registers below 0x80 unused except for 0x0 where a single bit is used. Maybe there is no FSMC there, but it sure looks like the hardware engineers planned for old+new FSM[C] block coexistence in the same address space. Yours, Linus Walleij