* vimal singh <vimalsingh@xxxxxx> [090504 22:52]: > > > On Mon, May 4, 2009 at 9:29 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * vimal singh <vimalsingh@xxxxxx> [090503 22:36]: > >> > >> > >> On Fri, May 1, 2009 at 11:08 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >> > * Tony Lindgren <tony@xxxxxxxxxxx> [090430 11:56]: > >> >> * Tony Lindgren <tony@xxxxxxxxxxx> [090430 07:06]: > >> >> > * vimal singh <vimalsingh@xxxxxx> [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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
