Re: [PATCH 1/2] i2c: qup: Add device tree bindings information
From: Josh Cartwright <hidden>
Date: 2013-09-10 13:59:43
Also in:
linux-arm-msm, linux-i2c, lkml
[Hmm. Fixing b0rked LKML address; that might explain why I am not seeing Kumar's replies.] On Tue, Sep 10, 2013 at 03:08:57PM +0300, Ivan T. Ivanov wrote:
Hi Kumar, On Fri, 2013-08-30 at 10:21 -0500, Kumar Gala wrote:quoted
On Aug 29, 2013, at 12:26 PM, Ivan T. Ivanov wrote:quoted
quoted
quoted
+ +Optional properties : + - Child nodes conforming to i2c bus binding + - clock-frequency : Desired I2C bus clock frequency in Hz. If + not set thedefault frequency is 100kHz + - qcom,src-freq : Frequency of the source clocking this bus in Hz. + Divider value is set based on soruce-frequency and + desired I2C bus frequency. If this value is not + provided, the source clock is assumed to be running + at 19.2 MHz.I'd spell out frequency instead of 'freq' to be consistent with 'clock-frequency'ok.quoted
Is the frequency of the 'iface' clock? Can we not use clk_get_rate?It is for 'core' clock. I think that for higher I2C bus frequencies, 'core' clock have to be higher, but I am not sure what is relation.Ok, can we use clk_get_rate on the 'core' clk to get its frequency instead of needing a DT prop for it?Probably I didn't explain it well. The 'core' clock have to be accelerated before higher bus frequencies could be achieved.
I think what Kumar is suggesting is that the QUP driver not do an explicit clk_set_rate() at all (which AFAICT is what's currently being done to set the consuming clock to the rate specified in 'qcom,src-freq'), but instead assume that the consuming clock has already been setup properly. Then the driver just uses clk_get_rate() and clock-frequency to calculate how to setup any internal dividers.
quoted
quoted
quoted
quoted
+Aliases: An alias may optionally be used to bind the I2C controller +to bus number. Aliases are of the form i2c<n> where <n> is an integer +representing the bus number to use. + +Example: + + aliases { + i2c0 = &i2c_A; + i2c1 = &i2c_B; + i2c2 = &i2c_C; + };What is the purpose here?Define on which I2C bus this controller operate. I2C client drivers usually do i2c_get_adapter(bus_number) before its registration. This is for drivers before invention of of_i2c_register_devices(), I believe.Since this is for upstream why dont we use of_i2c_register_devices() and remove this stuff related to aliases.Adapter driver already is using of_i2c_register_devices(). Also OF helper function will/or is already part of i2c_register_adapter(). Attempt here was to make it compatible with older i2c client drivers.
I agree with Kumar on removing this. If we decide it is something worth keeping, logic to support it doesn't belong in the QUP driver, but in the i2c core. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation