From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: I2C adapters protocol deviation Date: Mon, 7 Apr 2014 10:01:28 +0200 Message-ID: <20140407080128.GB3926@lukather> References: <20140403145528.GA6199@lukather> <533D7E81.4050900@redhat.com> <20140404122632.GA3686@katana> <53415E50.9000402@redhat.com> <20140406153728.GB2609@katana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiVenqGWf+H9Y6IX" Return-path: Content-Disposition: inline In-Reply-To: <20140406153728.GB2609@katana> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Wolfram Sang Cc: Hans de Goede , linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, boris-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org List-Id: linux-i2c@vger.kernel.org --IiVenqGWf+H9Y6IX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 06, 2014 at 05:37:29PM +0200, Wolfram Sang wrote: > On Sun, Apr 06, 2014 at 04:01:52PM +0200, Hans de Goede wrote: > > Hi, > >=20 > > On 04/04/2014 02:26 PM, Wolfram Sang wrote: > > >=20 > > >> So what we really have is a single slave i2c host sort of. At least > > >> we could model it like that. The host could be told which address to > > >> listen to (and which single i2c write to do to init the pmic) through > > >> devicetree and then all the differences would be hidden in the host > > >> driver, ie we would check the slave-address and if it is not the sin= gle > > >> one we support, we just return the appropriate error for a device not > > >> acking, and everything should work as a regular i2c host which > > >> only supports i2c_smbus_read_byte and i2c_smbus_write_byte. > > >=20 > > > I'd think we need a new message flag like I2C_M_PUSHPULL which says t= hat > > > this message has only the direction bit instead of the address and ne= eds > > > a parity bit afterwards. In addition to that, we need a new > > > functionality flag I2C_FUNC_PUSHPULL which means the host driver can > > > handle those messages. So, the PMIC driver could query support for > > > I2C_FUNC_SMBUS_BYTE | I2C_FUNC_PUSHPULL and if successful send messag= es > > > using smbus functions with the new flag set. > >=20 > > Thanks for the input this sounds good, I guess we'll give this a shot > > when we get around to coding up support for the p2wi block in the A31. >=20 > On a second thought, maybe more granularity is better. Like using > I2C_M_DROP_ADDRESS and I2C_M_ADD_PARITY and then make > I2C_CLIENT_PUSHPULL involve I2C_M_DROP_ADDRESS | I2C_M_ADD_PARITY. I'd agree with that. Other clients/adapters might need only one of these. Note that you'd probably need a I2C_M_DELAYED_ACK or something. > > > Not sure about the I2C-to-PushPull switch: Is it 100% host configurat= ion > > > or does it also depend on the one slave attached?=20 > >=20 > > The datasheet we've suggests that it actually influences the one slave > > attached. Note that u-boot on this machines will likely already have ma= de > > the switch, but I guess we don't want to count on that. >=20 > Can we detect if this switching was already made? None that we're aware of. Since the PMIC is already most likely initialised, I think we can just use it as if it was already in P2WI mode. > > > Are there some datasheets available? > >=20 > > The AXP221 is documented here: > > http://linux-sunxi.org/AXP221 > > This is translated by one of our community members from a Chinese datas= heet. > >=20 > > The P2WI interface is (somewhat) documented in the A31 datasheet, but w= e cannot > > share that in public. >=20 > Any chance for me to get it if I sign something? Let me see what I can do. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --IiVenqGWf+H9Y6IX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJTQltYAAoJEBx+YmzsjxAgS5cP/2W1BqWiA7wf9TKgH0P7oyWf agF6LuELDIjWkp90q17eNNYkUcX4EzFZ9pJ9eUPQCccRolqZSbj0JfnJcEaLeuce lnW/ltU/4LGy3rv1hbEfxBlwJKeC/PZiiK3HYcgJba9/rfd4ItNdfuuFxjud4fR5 jdgbOVorESPsgcMskQYRcfQyhMthALjRzTppoqjwBkHSdd0Uy83CgWzw6s+T+6uw TqBSyHUjJQQQd2xH4SYB5pumK0dHebg5Owq+eXNR/7egpnDyeSomnILjm5MVGCjC 6HNcct4JLdZfnpQ95HtWR382RtNg0HbKaRT9h7LTW2aQWXwYglKIpwUOxOZzYAYZ F9+/7RXngbbJXQ9y+CSzkVrPkMhCwGOkWqAFJt2ly6gSdD6LIlTs/+94WLODAvx2 DlDGlZLFh0Vwh7zAxzL0b8i3m0NOcm0ijIcTXVU/Dw+gThbXvmwfOx9dxo2MUf3N DL0XPIjvAFiElDSuTxAE4k/6p0nL7FdriRK90oN9Rm471prADamuRUB3wKRUImny Pkwm5J0zkFaXggHoaIsYKOAq+CnfYlZuaK2+1vTo0Q5wGVpn/tkX6AqCNvbHhVp/ S1bPOpU+Jh+SAeSWH7JYfZzodd6MpcZc0NZBq5NupprcByuz+wmac+ddSBwR3Y0A OBb70mkBdTmAU9+RR1uy =v4kH -----END PGP SIGNATURE----- --IiVenqGWf+H9Y6IX--