[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:
> > 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.
> > >>> +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
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
>
> > 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.
When resubmitting, please test against v3.12-rcX.
of_i2c_register_devices() is in the core meanwhile and alias support for
of is in the core for a while, too. Check i2c_add_adapter().
Hi,
On Wed, 2013-09-25 at 18:06 +0200, Wolfram Sang wrote:
> > > 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.
>
> When resubmitting, please test against v3.12-rcX.
> of_i2c_register_devices() is in the core meanwhile and alias support for
> of is in the core for a while, too. Check i2c_add_adapter().
Thanks, I will.
Regards,
Ivan