From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Date: Fri, 12 Jun 2009 23:44:16 +0200 Subject: [U-Boot] [PATCH 1/4] OMAP3 I2C Fix the sampling clock. In-Reply-To: <4A310E8B.9050200@windriver.com> References: <1244638432-30893-1-git-send-email-Tom.Rix@windriver.com> <1244638432-30893-2-git-send-email-Tom.Rix@windriver.com> <7A436F7769CA33409C6B44B358BFFF0C0115C326B9@dlee02.ent.ti.com> <4A306F67.6020207@windriver.com> <7A436F7769CA33409C6B44B358BFFF0C0115CBB8BC@dlee02.ent.ti.com> <4A310E8B.9050200@windriver.com> Message-ID: <20090612214416.GD1802@game.jcrosoft.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09:02 Thu 11 Jun , Tom wrote: > Menon, Nishanth wrote: >>> -----Original Message----- >>> From: Tom [mailto:Tom.Rix at windriver.com] >>> Sent: Wednesday, June 10, 2009 9:44 PM >>> >>>> This is a repeat story of what happened in linux-omap and kernel. We had >>>> >>> a similar discussion in [1] and related patch [2] to change equations. I >>> have the same reservations with this patch: >>> >>>> a) using speed as default does not scale for all board combinations. >>>> b) need flexible option to provide scll and sclh on a platform basis. >>>> Regards, >>>> Nishanth Menon >>>> Ref: >>>> [1] http://marc.info/?t=123540865900002&r=1&w=2 >>>> [2] http://marc.info/?l=linux-omap&m=122770723311340&w=2 >>>> >>>> >>> Do you think this could be handled with just config files? >>> Or maybe like fsl_i2c does by passing clk data through the global_data ? >>> >> #defines in config header file might be a viable option.. Though the gd >> might be cleaner I think.. >> >> Regards, >> Nishanth Menon >> > How about something like this? > The timing calculation is moved to a separate function that is weakly > aliased to a function that the boards can define? This is similar to > led initializing in lib_arm. I have put a stub omap_i2c_timing in > zoom1.c to show how the board would do the define. use weak function will increase the size of u-boot I'll prefer to avoid it when it's possible if no board mainline need it I'll prefer to avoid it also Best Regards, J.