Re: [PATCH 2/2] i2c: designware: Add support for AMD I2C controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 22, 2014 at 07:22:52PM +0200, Christian Ruppert wrote:
> On Mon, Sep 22, 2014 at 02:16:25PM +0000, Vineet Gupta wrote:
> > On Monday 22 September 2014 07:30 PM, Mika Westerberg wrote:
> > >>> COMMON_CLK is not selected by the ARC architecture in general. However,
> > >>> > > we do select COMMON_CLK in the TB10x platform which uses the designware
> > >>> > > I2C driver so this new dependency is no problem for us.
> > >>> > >
> > >>> > > Vineet,
> > >>> > >
> > >>> > > Do you see any issues with this on other existing ARC platforms, e.g.
> > >>> > > arcfpga?
> > >> > 
> > >> > So what needs to be done, COMMON_CLK needs to be defined in arch/arc/Kconfig ? And
> > >> > if so why ?
> > > Without COMMON_CLK, you are not able to select I2C_DESIGNWARE_PLATFORM
> > > anymore. So if something on ARC depends on this driver then we either
> > > need the COMMON_CLK there or figure out alternative way to fix Carl's
> > > problem.
> > 
> > I have not seen the orig patch, but it seems COMMON_CLK is already being selected
> > by TB10x, do we still need it in arch/arcKconfig, for all ARC platforms ?
> 
> Sorry for the confusion, I should have given you some context. Mika
> has checked that designware i2c is used by some ARC platforms but he
> didn't say which ones. The orig patch makes COMMON_CLK a requirement for
> designware i2c.

Yeah, sorry about not mentioning the affected platforms. I've included
them now in this email.

> I checked that we're fine for TB10x (we need COMMON_CLK anyway) but
> since you weren't in copy I just wanted to make sure that none of the
> other ARC platforms (which don't seem to select COMMON_CLK) use
> designware i2c and thus run into trouble.
> 
> If there is no designware i2c in any of your platforms, simply ignore
> my message. From my point of view there is no need to move "select
> COMMON_CLK" up to the ARC architecture level.

I grepped for snps,i2c-designware from the kernel source tree and this
is what I found:

Only ARC that is using the driver:

 arch/arc/boot/dts/abilis_tb10x.dtsi -> OK

Two ARMs that pass clock to the driver:

 arch/arm/boot/dts/berlin2q.dtsi -> OK
 arch/arm/boot/dts/socfpga.dts -> OK

Following files have the designware driver listed but it seems to be
disabled and does not get any clocks:

 arch/arm/boot/dts/nspire-cx.dts

 arch/arm/boot/dts/spear1310.dtsi
 arch/arm/boot/dts/spear320.dtsi
 arch/arm/boot/dts/spear3xx.dtsi
 arch/arm/boot/dts/spear600.dtsi

I think we are good to go with the first three but not sure about the
last five. Adding Viresh Kumar and Daniel Tang to the thread.

Viresh, Daniel,

The thread is here http://patchwork.ozlabs.org/patch/390695/.

In summary, we are adding COMMON_CLK dependency to the
i2c-designware-platdrv.c in order to get clocks to one AMD DW based host
controller and wanted to check that we don't break the existing users
(nspire and SPEAR).
--
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




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux