From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Fri, 28 Sep 2012 14:55:25 +0200 (CEST)
Subject: [U-Boot] [PATCH v2 09/14] mx5 clocks: Fix get_ipg_per_clk()
In-Reply-To: <50657FCB.7020300@denx.de>
Message-ID: <461266343.5418513.1348836925163.JavaMail.root@advansee.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Stefano,

On Friday, September 28, 2012 12:45:31 PM, Stefano Babic wrote:
> On 28/09/2012 12:42, Beno?t Th?baudeau wrote:
> > Hi Stefano,
> > 
> > On Friday, September 28, 2012 11:31:11 AM, Stefano Babic wrote:
> >> On 27/09/2012 22:23, Beno?t Th?baudeau wrote:
> >>> This fixes the "IPG PERCLK" frequency printed by the clocks
> >>> command. The issue
> >>> was that get_ipg_per_clk() used periph_clk instead of lp_apm in
> >>> the
> >>> case
> >>> CCM.CBCMR.perclk_lp_apm_sel is set.
> >>>
> >>> It also fixes I?C support.
> >>>
> >>
> >> Hi Beno?t,
> >>
> >> I understand "clocks" reports a wrong value only if
> >> CCM.CBCMR.perclk_lp_apm_sel is set, not always.
> > 
> > Correct.
> > 
> >> Can you better explain me which is wrong and which is the fix for
> >> I2C
> >> ?
> >> It seems unrelated, and I do not get the reason checking the patch
> > 
> > It's only because mxc_get_clock(MXC_IPG_CLK) (or
> > mxc_get_clock(MXC_I2C_CLK)
> > after [1]) both return get_ipg_per_clk() for the I?C driver's
> > clock.
> 
> Ah, thanks - it is clear now.

For the full story, I?C was completely broken on my custom i.MX51 platform
because of this issue. The command "i2c probe" only detected address 0x00, and
if run again, it hung.

Best regards,
Beno?t