[U-Boot] [PATCH 1/4] OMAP3 I2C Fix the sampling clock.

[Tom]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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
>
>   
I do not know of an example of a board that needs to be handled specially.
The current code breaks the Zooms. The original fix works on the Zooms 
and beagle and overo.
Can the original fix go in and be changed when we know which board needs 
special handling ?

Tom



> Best Regards,
> J.
>