On Thursday, September 15, 2011 04:26:17 AM Jason Hui wrote:
On Thu, Sep 15, 2011 at 10:07 AM, Marek Vasut marek.vasut@gmail.com wrote:
On Thursday, September 15, 2011 03:43:42 AM Jason Hui wrote:
On Thu, Sep 15, 2011 at 3:39 AM, Marek Vasut marek.vasut@gmail.com wrote:
On Friday, July 29, 2011 08:55:14 AM Jason Hui wrote:
Hi, Marek,
On Thu, Jul 14, 2011 at 5:58 AM, Marek Vasut marek.vasut@gmail.com
wrote:
Rewrite the mxc_i2c driver.
- This version is much closer to Linux implementation.
- Fixes IPG_PERCLK being incorrectly used as clock source
- Fixes behaviour of the driver on iMX51
- Clean up coding style a bit ;-)
why you change i2c clock from IPG_PERCLK to IPG_CLK?
[...]
Ok, I investigated a bit deeper and I suspect the clock.c is the culprit.
Apparently, the PERCLK doesn't run at the frequency the clock.c reports it runs on. Therefore, the i2c miscalculates the divider etc -- falling crap model (waterfall model).
But apparently, the i2c function clock should be IPG_PERCLK not IPG clock. And Linux also fix it already.
Then there's bulls**t in your mx51 and mx53 datasheet or what ?
Please refer to MCIMX51RM.PDF, page 305, Table 7-41. PERCLK-dependent Module Clock Sources PERCLK-dependent Module Clocks Associated CCGR Register uart1_perclk CCGR1 uart2_perclk uart3_perclk i2c1 clocks i2c2 clocks epit1_highfreq CCGR2 epit2_highfreq pwm1_highfreq pwm2_highfreq gpt_highfreq owire clocks
You see ... I'm starting to understand what is actually going wrong. The lowlevel_init.S is bloated with crap (why? why can't that be in cpu init C code ?) and there is this one part, where CBCDR is overwritten with a configurable value instead of hardcoded value.
No documentation about that at all, but it's there ... and that's -- amongst other bugs -- my problem I assume. So I need to set this CONFIG_SYS_CLKTL_CBCDR to another magic value, now I get it.
besides, PERCLK is faster than IPGCLK on MX51 so it makes even less sense!
I don't think PERCLK is always faster than IPG clock, it's configurable. please refer to MCIMX51RM.PDF, page 307.
Yea ... it's configurable via some undocumented macro in assembler code. Damn.
Can you please comment on the other patches?
Thanks
Can you please talk
to the HW guys or whatever to clear this once and for all ? I smell noone really knows where the clock are sourced from and all this crap is just blind guessing.
I have asked the IC module owner again. It confirms that I2C function clock is ipg_perclk.
Jason