Messages in this thread | | | Subject | Re: [PATCH 1/2] i2c: qup: Add device tree bindings information | From | "Ivan T. Ivanov" <> | Date | Tue, 10 Sep 2013 17:43:25 +0300 |
| |
Hi,
On Tue, 2013-09-10 at 08:59 -0500, Josh Cartwright wrote: > [Hmm. Fixing b0rked LKML address; that might explain why I am not > seeing Kumar's replies.] >
Yes, sorry about this.
> 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: > > > On Aug 29, 2013, at 12:26 PM, Ivan T. Ivanov wrote: > > > >>> + > > > >>> +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. > > > > > > > >> > > > >> 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.
Yes, I think I got it, but the point is that clock is not already set and it is driver responsibility to do that.
> > > > >>> +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.
I don't have strong objection here, will remove aliases support.
Regards, Ivan >
| |