Simon Glass wrote at Saturday, February 04, 2012 11:03 PM: > On Sat, Feb 4, 2012 at 9:51 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > > Laxman Dewangan wrote at Saturday, February 04, 2012 4:18 AM > >> On Saturday 04 February 2012 05:40 AM, Stephen Warren wrote: > >> > From: Laxman Dewangan<ldewangan@xxxxxxxxxx> > >> > > >> > The clock table has just one entry for a given i2c controller. > >> > Hence, the second clk_get is not required in the driver. > >> > > >> > Originally by Laxman Dewangan<ldewangan@xxxxxxxxxx>, but S-o-b is > >> > missing in our internal repo. > >> > > >> > [swarren: Reworded commit description, resolved merge issue when cherry- > >> > picking to mainline] > >> > Signed-off-by: Stephen Warren<swarren@xxxxxxxxxx> > > > > Ben, Wolfram. The two changes in this patch series are completely > > independent. The 2nd patch is what I really care about, and can be > > applied irrespective of the resolution of the discussion below. > > > >> The tegra i2c controller have two clock inputs i2c_div and i2c_fast_clk. > > > > Is this true on Tegra20 or just Tegra30? The Tegra20 TRM explicitly lists > > the clock domains the I2C controller users, and doesn't mention anything > > about this... > > As I happened to be looking at this on Friday, it seems that Tegra20 > supports the fast I2C also. I couldn't quite see how to select the > fast clock, but since I wasn't planning to support it I didn't mind. > From what I could tell, the slow clock can switch between four options > and the fast clock is fixed at 72MHz (based off PLLP), as below. OK, I've found the location in the TRM that describes this additional clock input to a few modules. It's in the CAR (Clock And Reset) controller section in a couple places, e.g. Table 12 "PLL Clock Usage" and in a section "Special PLL clock usage by certain peripheral" (in version v01p at least). So yes, let's not apply this one patch. Simon, the upshot of this is that when you add the clocks property to the I2C nodes, you'll need to add both the regular variable I2C clock and this other clock to the list: clocks = <&tegra_car 12> /* i2c1 */ <&tegra_car 124> /* pll_p_out3 */; I suggest listing the regular clock first for simplicity in U-Boot's parsing of the property (so the first clock is always the one with a bit in the CLK_ENB registers) and these additional clocks after, as I have above. This appears to apply to modules lfsr, dsi, csi, i2c1/2/3, uart1/2/3/4/5, but apparently not the DVC I2C controller according to the TRM. Laxman, can you confirm that the DVC I2C controller doesn't take a clock from pll_p_out3? P.S. this patch I posted is in our downstream 2.6.39 and 3.1 kernels. Given this thread, I assume it should be reverted there... Thanks. -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
