| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1414766288.5833.46.camel@mtksdaap41>
Date: Fri, 31 Oct 2014 22:38:08 +0800
From: Yingjoe Chen <yingjoe.chen@...iatek.com>
To: Matthias Brugger <matthias.bgg@...il.com>
CC: xudong chen <xudong.chen@...iatek.com>,
Mark Rutland <mark.rutland@....com>, <arm@...nel.org>,
Wolfram Sang <wsa@...-dreams.de>,
srv_heupstream <srv_heupstream@...iatek.com>,
Sascha Hauer <kernel@...gutronix.de>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Russell King <linux@....linux.org.uk>,
Grant Likely <grant.likely@...aro.org>,
Jean Delvare <jdelvare@...e.de>, Arnd Bergmann <arnd@...db.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
<linux-i2c@...r.kernel.org>,
Eddie Huang <eddie.huang@...iatek.com>,
Nathan Chung <nathan.chung@...iatek.com>,
YH Chen <yh.chen@...iatek.com>
Subject: Re: [PATCH 3/3] I2C: mediatek: Add driver for MediaTek I2C
controller
On Fri, 2014-10-31 at 11:48 +0100, Matthias Brugger wrote:
> 2014-10-31 7:31 GMT+01:00 xudong chen <xudong.chen@...iatek.com>:
> > On Thu, 2014-10-30 at 14:16 +0100, Matthias Brugger wrote:
> >> 2014-10-29 6:37 GMT+01:00 Xudong Chen <xudong.chen@...iatek.com>:
> >> > 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 <xudong.chen@...iatek.com>
> >> > 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".
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists