On Mon, Sep 29, 2014 at 11:24:50PM +0200, Wolfram Sang wrote: > On Mon, Sep 22, 2014 at 12:12:07PM +0300, Mika Westerberg wrote: > > On Sat, Sep 20, 2014 at 11:36:34AM +0200, Wolfram Sang wrote: > > > On Thu, Sep 18, 2014 at 12:26:07PM +0300, Mika Westerberg wrote: > > > > From: Carl Peng <carlpeng008@xxxxxxxxx> > > > > > > > > Add support for AMD version of the DW I2C host controller. The device is > > > > enumerated from ACPI namespace with ACPI ID AMD0010. Because the core > > > > driver needs an input source clock, and this is not an Intel LPSS device > > > > where clocks are provided through drivers/acpi/acpi_lpss.c, we register the > > > > clock ourselves if the clock rate is given in ->driver_data. > > > > > > > > Signed-off-by: Carl Peng <carlpeng008@xxxxxxxxx> > > > > Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > > > --- > > > > > > Applied to for-next, still wondering... > > > > Thanks! > > I reconsidered and these two patches are not in i2c/for-next because of > two reasons: > > 1) They do not apply cleanly on top of other i2c-designware changes I > applied (check i2c/for-next I just pushed out). The conflicts might not > be hard, but they were not trivial enough for me to do them inbetween > other things. I'd be very happy about a repost on top of i2c/for-next. OK, I'll do that. > > > > > > > drivers/i2c/busses/Kconfig | 1 + > > > > drivers/i2c/busses/i2c-designware-platdrv.c | 27 +++++++++++++++++++++++++++ > > > > 2 files changed, 28 insertions(+) > > > > > > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > > > > index 2ac87fa3058d..9384498ef3c1 100644 > > > > --- a/drivers/i2c/busses/Kconfig > > > > +++ b/drivers/i2c/busses/Kconfig > > > > @@ -422,6 +422,7 @@ config I2C_DESIGNWARE_CORE > > > > > > > > config I2C_DESIGNWARE_PLATFORM > > > > tristate "Synopsys DesignWare Platform" > > > > + depends on COMMON_CLK > > > > > > ... do all previous users have COMMON_CLK? > > > > The driver is being used on x86, ARM and ARC it seems. For x86 and ARM > > we pretty much have COMMON_CLK nowadays but I'm not sure about ARC. > > 2) "pretty much have" is not so convincing to me. That is such a generic > core, it probably has enough out-of-tree users as well. I wasn't aware that we care about out-of-tree users. > And with all these ACPI regressions from this cycle, I am very > cautious right now. Brainstorming: What about "depends on (ACPI && > COMMON_CLK) || !ACPI"? Understood. I'll try the above. Thanks. -- 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
