> -----Original Message----- > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > Sent: Wednesday, June 24, 2009 7:07 PM > To: Premi, Sanjeev > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] Missing implementation of omap3evm_flash_init() > > * Premi, Sanjeev <premi@xxxxxx> [090624 14:45]: > > > -----Original Message----- > > > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > > > Sent: Monday, June 22, 2009 7:04 PM > > > To: Premi, Sanjeev > > > Cc: linux-omap@xxxxxxxxxxxxxxx > > > Subject: Re: [PATCH] Missing implementation of > omap3evm_flash_init() > > > > > > * Premi, Sanjeev <premi@xxxxxx> [090622 16:16]: > > > > > -----Original Message----- > > > > > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > > > > > Sent: Monday, June 22, 2009 2:37 PM > > > > > To: Premi, Sanjeev > > > > > Cc: linux-omap@xxxxxxxxxxxxxxx > > > > > Subject: Re: [PATCH] Missing implementation of > > > omap3evm_flash_init() > > > > > > > > > <snip>--<snip> > > > > Tony, > > > > I had a few follow-up queries below: > > > > > > > > > > > > We already have code that initializes the GPMC for > > > onenand in kernel. > > > > > And I posted a patch to enable onenand for the SDP boards > > > > > last week [1]. > > > > > > > > Did not see it; before creating the patch; lookig at this now... > > > > > > OK, thanks. > > > > > > > > And this is yet another copy of the same code that was > > > duplicated for > > > > > multiple boards. So how about making the following changes: > > > > > > > > > > - Pass the onenand chip select for GPMC in platform data. I > > > > > doubt that the > > > > > chip select is changing? > > > > > > > > > > - If you still need to probe for onenand, please create a > > > > > generic function > > > > > in gpmc-onenand.c to probe for onenand > > > > I always see "onenand_base" being passed as argument. Where is it > > initialized? > > That is allocated with gpmc_cs_request() based on the cs in the > struct omap_onenand_platform_data. Thanks. Will look into this... > > > I did implement this function to probe for nand/onenand - based on > > the code that existed in board-omap3evm-flash.c; but ran into > > some problems with the setting base address. > > I guess the probe is only looking at the GPMC configuration registers > though? > > > Looking at the gpmc-onenand.c do you believe we would need a > > gpmc-nand.c on same lines? Or an implementation within the > > board-omap3evm.c is okay for now? > > Well if you can figure out how to do a common gpmc-nand.c, I'm sure > it would make things easier to bring up new boards (and omaps). MTD devices aren't something that I have been working with :( I am not sure if I could really do justice to all boards; but I will submit a patch and you can decide if it could be a goot start point. ~sanjeev > > Regards, > > Tony > > > > > > Best regards, > > Sanjeev > > > > > > > > > > > > > > > Some EVMs have OneNAND and others have NAND. How/ Where do > > > you suggest > > > > this check sould go? > > > > > > If it's based on just checking the GPMC registers, you could > > > put it into > > > gpmc.c. > > > > > > Regards, > > > > > > Tony > > > > > > > > > > > > > > > <snip>--<snip>--<snip till end> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
