Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756002AbaJaQK7 (ORCPT ); Fri, 31 Oct 2014 12:10:59 -0400 Received: from mail-la0-f49.google.com ([209.85.215.49]:52994 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751279AbaJaQK5 (ORCPT ); Fri, 31 Oct 2014 12:10:57 -0400 MIME-Version: 1.0 In-Reply-To: <1414766288.5833.46.camel@mtksdaap41> References: <1414561058-23803-1-git-send-email-xudong.chen@mediatek.com> <1414561058-23803-4-git-send-email-xudong.chen@mediatek.com> <1414737101.32208.18.camel@mhfsdcap03> <1414766288.5833.46.camel@mtksdaap41> Date: Fri, 31 Oct 2014 17:10:55 +0100 Message-ID: Subject: Re: [PATCH 3/3] I2C: mediatek: Add driver for MediaTek I2C controller From: Matthias Brugger To: Yingjoe Chen Cc: xudong chen , Mark Rutland , arm@kernel.org, Wolfram Sang , srv_heupstream , Sascha Hauer , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Russell King , Grant Likely , Jean Delvare , Arnd Bergmann , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , linux-i2c@vger.kernel.org, Eddie Huang , Nathan Chung , YH Chen Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2014-10-31 15:38 GMT+01:00 Yingjoe Chen : > On Fri, 2014-10-31 at 11:48 +0100, Matthias Brugger wrote: >> 2014-10-31 7:31 GMT+01:00 xudong chen : >> > On Thu, 2014-10-30 at 14:16 +0100, Matthias Brugger wrote: >> >> 2014-10-29 6:37 GMT+01:00 Xudong Chen : >> >> > The mediatek SoCs have I2C controller that handle I2C transfer. >> >> > This patch include common I2C bus driver. >> >> > This driver is compatible with I2C controller on mt65xx/mt81xx. >> >> > >> >> > Signed-off-by: Xudong Chen >> >> > Change-Id: Icc17e326b9df46a226d536956e103f17b0382b6e >> >> > --- >> >> > drivers/i2c/busses/Kconfig | 9 + >> >> > drivers/i2c/busses/Makefile | 1 + >> >> > drivers/i2c/busses/i2c-mt65xx.c | 728 ++++++++++++++++++++++++++++++++++++++++ >> >> > 3 files changed, 738 insertions(+) >> >> > create mode 100644 drivers/i2c/busses/i2c-mt65xx.c >> >> > >> >> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> >> > index 917c358..0d7d0a4 100644 >> >> > --- a/drivers/i2c/busses/Kconfig >> >> > +++ b/drivers/i2c/busses/Kconfig >> >> > @@ -564,6 +564,15 @@ config I2C_MPC >> >> > This driver can also be built as a module. If so, the module >> >> > will be called i2c-mpc. >> >> > >> >> > +config I2C_MT65XX >> >> > + tristate "MediaTek I2C adapter" >> >> > + depends on ARCH_MEDIATEK >> >> > + help >> >> > + This selects the MediaTek(R) Integrated Inter Circuit bus driver >> >> > + for MT65xx and MT81xx. >> >> > + If you want to use MediaTek(R) I2C interface, say Y or M here. >> >> > + If unsure, say N. >> >> > + >> >> > config I2C_MV64XXX >> >> > tristate "Marvell mv64xxx I2C Controller" >> >> > depends on MV64X60 || PLAT_ORION || ARCH_SUNXI >> >> > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> >> > index 78d56c5..7a9f0f3 100644 >> >> > --- a/drivers/i2c/busses/Makefile >> >> > +++ b/drivers/i2c/busses/Makefile >> >> > @@ -54,6 +54,7 @@ obj-$(CONFIG_I2C_IMX) += i2c-imx.o >> >> > obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o >> >> > obj-$(CONFIG_I2C_KEMPLD) += i2c-kempld.o >> >> > obj-$(CONFIG_I2C_MPC) += i2c-mpc.o >> >> > +obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o >> >> > + >> >> > +static int mt_i2c_do_transfer(struct mt_i2c *i2c) >> >> > +{ >> >> > + u16 addr_reg; >> >> > + u16 control_reg; >> >> > + int tmo = i2c->adap.timeout; >> >> > + >> >> > + i2c->trans_stop = false; >> >> > + i2c->irq_stat = 0; >> >> > + >> >> > + /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */ >> >> > + if (i2c->have_pmic) >> >> > + i2c_writew(I2C_CONTROL_WRAPPER, i2c, OFFSET_PATH_DIR); >> >> >> >> So this is some sort of multiplexer bit, right? >> >> I think in this case we need to build a multi function device (mfd) >> >> where the pmic driver will set this bit. >> >> >> > Hi, >> > >> > This feature means the chip can use I2C pins from PMIC(mt6397). >> > In this case, >> > 1. We actually control the register on mt8135 and the DMA/Control Logic >> > is on mt8135, only use pins from mt6397. If set register OFFSET_PATH_DIR >> > bit0 to 1, the I2C data will go/from PMIC pins. >> >> Sorry but I'm a bit puzzled. mt6397 is the PMIC, right? >> So from the mt6589 datasheet it says: >> "PATH_DIR Decides transmission direction >> If set, the I2C data will go/from PMIC; otherwise, the I2C data will >> go/from main die." >> >> From my understanding the I2C bus will be multiplexed depending on >> this bit. The bit decides if it the data will be send to the PMIC or >> to some other I2C peripheral. >> >> So we need a mfd and the PMIC device driver sets/unsets the PATH_DIR register. > > Yes, mt6397 is the PMIC work with mt8135 or mt8127. > > I think the datasheet is a little misleading here. AFAIK, on 8135 even > if your clear the bit for I2C4, there are no corresponding pins for this > i2c port on 8135. So it is not really multiplexed. Base on my > understanding this is more like "Set this bit if this a PMIC I2C port". I had a look at mt6589. The SoC has seven i2c controller. Looking at the source code all controller with an ID bigger then 3 can be set to pmic wrapper state. So I would say that the PATH_DIR bit is not always bound to i2c4. We should implement a driver which will work on all possible configurations. We don't know if apart from mt6589 and mt8135 some other SoC in the future will use this i2c controller. Maybe you can check with the HW guys how this is implemented to shed some light on the issue. > > In order to use i2c4, we do need a PMIC pinmux driver to set pinmux > function for this i2c port. Since all the i2c control logic and > registers are on mt8135, it is strange to have PMIC device driver set > this bit on mt8135. Also, since mt8127 doesn't support this, it will be > even stranger when using this pmic and driver with mt8127. > > Joe.C > > -- motzblog.wordpress.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/