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
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 master IPs are likely to
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
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 new transfers even if the
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
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 pm_* from the core.
>
> This will be noticed very quickly
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
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 04f59143b571 and the wakeup IRQ
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
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
> >> sysfs/device-model representation:
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
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 one i3c bus with a
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
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 emulated with a slave IP),
> >
> > I see.
> >
> > >
> > 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
> > 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
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> 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);
> >
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> 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
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
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
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
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 is.
>
> > As for
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)
> > > >
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)
> > > > +{
> > > > + if
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
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 +0200
>> > Boris Brezillon wrote:
>> >> On Tue, 1 Aug 2017 15:11:44 +0200
>> >> Arnd
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);
> > >
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);
> > >
> 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. :)
> 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. :)
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
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
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 emulated with a slave IP),
>
> I see.
>
> > spec clearly describe what legacy/static addresses are for and
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 emulated with a slave IP),
>
> I see.
>
> > spec clearly describe what legacy/static addresses are for and one of
> > their
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
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 15:11:44 +0200
> >> Arnd Bergmann wrote:
> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris
> 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
> 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
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
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 everyone gets the logic
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
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 2:29 PM, Boris Brezillon
>> > wrote:
> I just realized I forgot to add a "depends on I2C"
> > 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 everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer
> > 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 everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer
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
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 2017 14:00:05 +0200
> > > Arnd Bergmann wrote:
> >
> > >> Another argument for a
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
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 be devices that
> >> can be attached to either i2c and i3c,
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
>>
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
>> capabilities.
>
> Hm, that's already the case, isn't
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,
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, 2017 at 6:24 PM, Boris Brezillon
> >> wrote:
> >> > Add core
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
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 core infrastructure to support I3C in Linux and document it.
>>
>> > - I2C backward
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
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 be extended over
> > time.
>
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
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
> 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
> 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
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
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
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
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 been designed to be transparent to I2C
> > drivers
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
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 I could.
>
> > +
>
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
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 registers an I2C
> adapter which creates a
> +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
> +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
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 way I3C device drivers can interact with their devices:
- all functions used
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 way I3C device drivers can interact with their devices:
- all functions used
72 matches
Mail list logo