* vimal singh <[email protected]> [090504 22:52]: > > > On Mon, May 4, 2009 at 9:29 PM, Tony Lindgren <[email protected]> wrote: > > * vimal singh <[email protected]> [090503 22:36]: > >> > >> > >> On Fri, May 1, 2009 at 11:08 PM, Tony Lindgren <[email protected]> wrote: > >> > * Tony Lindgren <[email protected]> [090430 11:56]: > >> >> * Tony Lindgren <[email protected]> [090430 07:06]: > >> >> > * vimal singh <[email protected]> [090429 23:33]: > >> >> > > 'gpmc-onenand.c' is still confusing name. This is not going to used > >> >> > > in > >> >> > > all boards anyway. > >> >> > > >> >> > Why do you think this cannot be used for all boards? > >> >> > > >> >> > The GPMC timings are totally based on the onenand chip features. > >> >> > >> >> And these two patches make omap3430sdp to work with the gpmc-onenand > >> >> code. Sync mode does not work, but it seems like it was never enabled > >> >> for sdp anyways. > >> >> > >> >> Similar patch should work for other boards too. > >> > > >> > Setting the sync_write depends on flags and processor, not just flags. > >> > Here's a fixed version of this patch. > >> OK, these both patches seems good to me... > > > > OK, thanks for looking. > > > >> Earlier I was in impression that this patch series is basically to remove > >> board-*-flash.c files. Since in 3430sdp boards we find out 'CS' number for > >> flash devices dynamically in different versions of boards. So, I was > >> confused. > > > > Well looks like those functions are used for at least few boards, so we > > could > > have functions like gpmc_probe_onenand() and gpmc_probe_nor() functions that > > could be called from board-*.c files. > > > > That way we could have generic gpmc-onenand.c and gpmc-nor.c, and still do > > the necessary probe logic in the board-*.c files. > But then how we'll be taking care of timing parameter configuration, for > different chips (part numbers), as some of these parts may vary in timing > specifications, and also for different working frequencies.
Well at least gpmc-onenand.c already configures things based on the onenand revision, see ONENAND_REG_VERSION_ID in gpmc_onenand.c. We should be able to calculate the timings for the connected chip rather than using hardcoded values for each board. This will save lots of time bringing up new boards. > And if we are going to put those information in board-*.c, then rather I will > prefer separate board-*-flash.c file to handle all this. Sure we can have it that way if there's a need for that. It depends how much code is left to initialize there in the end. To me it sounds like it would contain just the partition tables and few lines to query the GPMC for connected flash chips. The rest we should be able to initialize in a generic way. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
