From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751965AbdHAQry (ORCPT ); Tue, 1 Aug 2017 12:47:54 -0400 Received: from lelnx194.ext.ti.com ([198.47.27.80]:62327 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbdHAQrq (ORCPT ); Tue, 1 Aug 2017 12:47:46 -0400 Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure To: Wolfram Sang , Boris Brezillon CC: Arnd Bergmann , , Jonathan Corbet , , Greg Kroah-Hartman , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , , Linux Kernel Mailing List References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170731231509.77d1fba4@bbrezillon> <20170731214211.GA11776@tetsubishi> From: "Andrew F. Davis" Message-ID: <1538596b-80ed-7800-db97-70e73b90b9e2@ti.com> Date: Tue, 1 Aug 2017 11:47:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170731214211.GA11776@tetsubishi> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/31/2017 04:42 PM, Wolfram Sang wrote: > >> Actually, that's the first option I considered, but I3C and I2C are >> really different. I'm not talking about the physical layer here, but >> the way the bus has to be handled by the software layer. Actually, I >> thing the I3C bus is philosophically closer to auto-discoverable busses >> like USB than I2C or SPI. > > Acked-by: Wolfram Sang > >> Of course, I can move all the code in drivers/i2c/, but that won't >> change the fact that I3C and I2C busses are completely different >> with little to share between them. > > That wouldn't make sense. > >> To me, the I2C backward compatibility is just a nice feature that was >> added to help people smoothly transition from mixed I3C busses with >> both I2C and I3C devices connected to it (I2C devices being here >> when no (affordable) equivalent exist in the I3C world) to pure I3C >> busses with only I3C devices connected to it. > > Yeah, and it is still to be seen how good this really works. Devices > which do clock stretching are out of the question. Probably everything > which needs an interrupt as well? > I'm surprised they didn't allow for slave clock stretching when communicating with a legacy i2c device, it will prohibit use of a rather large class of devices. :( As for interrupts you are always free to wire up an out-of-band interrupt like before. :) >> This being said, I'd be happy if you prove me wrong and propose a >> solution that allows us to extend the I2C framework to support I3C >> without to much pain ;-). > > From all I know, I don't see that coming. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew F. Davis" Subject: Re: [RFC 2/5] i3c: Add core I3C infrastructure Date: Tue, 1 Aug 2017 11:47:15 -0500 Message-ID: <1538596b-80ed-7800-db97-70e73b90b9e2@ti.com> References: <1501518290-5723-1-git-send-email-boris.brezillon@free-electrons.com> <1501518290-5723-3-git-send-email-boris.brezillon@free-electrons.com> <20170731231509.77d1fba4@bbrezillon> <20170731214211.GA11776@tetsubishi> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170731214211.GA11776@tetsubishi> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Wolfram Sang , Boris Brezillon Cc: Arnd Bergmann , linux-i2c@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Greg Kroah-Hartman , Przemyslaw Sroka , Arkadiusz Golec , Alan Douglas , Bartosz Folta , Damian Kos , Alicja Jurasik-Urbaniak , Jan Kotas , Cyprian Wronka , Alexandre Belloni , Thomas Petazzoni , Nishanth Menon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell K List-Id: devicetree@vger.kernel.org On 07/31/2017 04:42 PM, Wolfram Sang wrote: > >> Actually, that's the first option I considered, but I3C and I2C are >> really different. I'm not talking about the physical layer here, but >> the way the bus has to be handled by the software layer. Actually, I >> thing the I3C bus is philosophically closer to auto-discoverable busses >> like USB than I2C or SPI. > > Acked-by: Wolfram Sang > >> Of course, I can move all the code in drivers/i2c/, but that won't >> change the fact that I3C and I2C busses are completely different >> with little to share between them. > > That wouldn't make sense. > >> To me, the I2C backward compatibility is just a nice feature that was >> added to help people smoothly transition from mixed I3C busses with >> both I2C and I3C devices connected to it (I2C devices being here >> when no (affordable) equivalent exist in the I3C world) to pure I3C >> busses with only I3C devices connected to it. > > Yeah, and it is still to be seen how good this really works. Devices > which do clock stretching are out of the question. Probably everything > which needs an interrupt as well? > I'm surprised they didn't allow for slave clock stretching when communicating with a legacy i2c device, it will prohibit use of a rather large class of devices. :( As for interrupts you are always free to wire up an out-of-band interrupt like before. :) >> This being said, I'd be happy if you prove me wrong and propose a >> solution that allows us to extend the I2C framework to support I3C >> without to much pain ;-). > > From all I know, I don't see that coming. >