Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Wed, Dec 13, 2017 at 05:20:43PM +0100, Boris Brezillon wrote: > Hi Greg, > > On Tue, 1 Aug 2017 19:13:27 -0700 > Greg Kroah-Hartman wrote: > > > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep > > > > > it > > > > > this way because

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hi Greg, On Tue, 1 Aug 2017 19:13:27 -0700 Greg Kroah-Hartman wrote: > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it > > > > this way because master IPs are likely to implement advanced queuing > > > > mechanism (allows one to queue

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Thu, 17 Aug 2017 11:03:10 +0200, Linus Walleij a écrit : > On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon > wrote: > > > This infrastructure is not complete yet and will be extended over > > time. > > I noticed the lack of

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon wrote: > This infrastructure is not complete yet and will be extended over > time. I noticed the lack of pm_* from the core. This will be noticed very quickly since the means the problem seen in e.g. commit

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Wed, 16 Aug 2017 23:03:55 +0200, Geert Uytterhoeven a écrit : > On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang wrote: > >> I'm perfectly fine with the I3C / I2C framework separation. The only > >> minor problem I had with that was the inaccuracy of the

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang wrote: >> I'm perfectly fine with the I3C / I2C framework separation. The only >> minor problem I had with that was the inaccuracy of the >> sysfs/device-model representation: we don't have one i2c and one i3c >> bus, we just have

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 17:20:41 +0200 Boris Brezillon wrote: > On Tue, 1 Aug 2017 17:01:08 +0200 > Wolfram Sang wrote: > > > > I do not know of any real devices as of today (all my tests have been > > > done with a dummy/fake I3C slaves

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> > Yes, my wording was a bit too strong. It is possible, sure. Yet, I > > understood that one of the features of I3C is to have in-band interrupt > > support. We will see if the demand for backward compatibility or "saving > > pins" is higher. > > > > Indeed, you can use in-band interrupts if

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote: > > > > No release type? Oh that's bad bad bad and implies you have never > > > > removed a device from your system as the kernel would have complained > > > > loudly at you. > > > > > > You got me, never tried to remove a device

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Tue, 1 Aug 2017 19:27:03 +0200, Wolfram Sang a écrit : > > 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. :( > > Yes, but I3C is push/pull IIRC. It

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hi Greg, Le Tue, 1 Aug 2017 10:51:33 -0700, Greg Kroah-Hartman a écrit : > On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote: > > > > +static DEFINE_MUTEX(i3c_core_lock); > > > > + > > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive) > > > >

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 1, 2017 at 5:14 PM, Boris Brezillon wrote: > On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann wrote: >> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon >> wrote: >> > On Tue, 1 Aug 2017 15:34:14

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote: > > > +static DEFINE_MUTEX(i3c_core_lock); > > > + > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive) > > > +{ > > > + if (exclusive) > > > + down_write(>lock); > > > + else > > > + down_read(>lock); > > >

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> 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. :( Yes, but I3C is push/pull IIRC. > As for interrupts you are always free to wire up an out-of-band > interrupt like before. :)

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann wrote: > On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon > wrote: > > On Tue, 1 Aug 2017 15:34:14 +0200 > > Boris Brezillon wrote: > >> On Tue, 1 Aug 2017

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> I do not know of any real devices as of today (all my tests have been > done with a dummy/fake I3C slaves emulated with a slave IP), I see. > spec clearly describe what legacy/static addresses are for and one of > their use case is to connect an I3C device on an I2C bus and let it act > as an

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 16:12:18 +0200 Wolfram Sang wrote: > > > The second way is to have a number of #ifdef and complex > > > Kconfig dependencies for the driver to only register the > > > device_driver objects for the buses that are enabled. This > > > is also doable, but

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon wrote: > On Tue, 1 Aug 2017 15:34:14 +0200 > Boris Brezillon wrote: >> On Tue, 1 Aug 2017 15:11:44 +0200 >> Arnd Bergmann wrote: >> > On Tue, Aug 1, 2017 at

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 15:34:14 +0200 Boris Brezillon wrote: > On Tue, 1 Aug 2017 15:11:44 +0200 > Arnd Bergmann wrote: > > > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon > > wrote: > > > On Tue, 1 Aug

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 15:11:44 +0200 Arnd Bergmann wrote: > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon > wrote: > > On Tue, 1 Aug 2017 14:00:05 +0200 > > Arnd Bergmann wrote: > > >> Another argument for a combined bus would

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon wrote: > On Tue, 1 Aug 2017 14:00:05 +0200 > Arnd Bergmann wrote: >> Another argument for a combined bus would be devices that >> can be attached to either i2c and i3c, depending on the host >>

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Tue, 1 Aug 2017 14:00:05 +0200 Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon > wrote: > > Hi Arnd, > > > > Le Mon, 31 Jul 2017 22:16:42 +0200, > > Arnd Bergmann a écrit : > > > >> On Mon, Jul 31,

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon wrote: > Hi Arnd, > > Le Mon, 31 Jul 2017 22:16:42 +0200, > Arnd Bergmann a écrit : > >> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon >> wrote: >> > Add

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hello Greg, On Mon, 31 Jul 2017 18:40:21 -0700 Greg Kroah-Hartman wrote: > On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > > This infrastructure is not complete yet and will

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote: > Add core infrastructure to support I3C in Linux and document it. > > This infrastructure is not complete yet and will be extended over > time. > > There are a few design choices that are worth mentioning because they > impact the

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> 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

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On 2017-07-31 23:15, Boris Brezillon wrote: > [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register Stupid non-programmers... This part 65 41 0101 Accelerometer 66 42 0110 Gyroscope 67 43 0111 Magnetometer 68 44 01000100 Accel/Gyro Combo 69 45 01000101 Accel/Mag

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Hi Arnd, Le Mon, 31 Jul 2017 22:16:42 +0200, Arnd Bergmann a écrit : > On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon > wrote: > > Add core infrastructure to support I3C in Linux and document it. > > > - I2C backward compatibility has

Re: [RFC 2/5] i3c: Add core I3C infrastructure

Le Mon, 31 Jul 2017 21:17:21 +0200, Wolfram Sang a écrit : > > +This document is just a brief introduction to the I3C protocol and the > > concepts > > +it brings on the table. If you need more information, please refer to the > > MIPI > > +I3C specification. > > I wish

Re: [RFC 2/5] i3c: Add core I3C infrastructure

On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon wrote: > Add core infrastructure to support I3C in Linux and document it. > - I2C backward compatibility has been designed to be transparent to I2C > drivers and the I2C subsystem. The I3C master just

Re: [RFC 2/5] i3c: Add core I3C infrastructure

> +This document is just a brief introduction to the I3C protocol and the > concepts > +it brings on the table. If you need more information, please refer to the > MIPI > +I3C specification. I wish I could. > + > +Introduction > + > + > +The I3C (I-Cube-C) is a MIPI standardized