From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Przemyslaw Sroka <psroka@cadence.com>
Cc: Vitor Soares <Vitor.Soares@synopsys.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.m>
Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Date: Tue, 27 Feb 2018 22:14:07 +0100 [thread overview]
Message-ID: <20180227221407.0cd7f8a9@bbrezillon> (raw)
In-Reply-To: <MWHPR07MB278357B74A7D7E31EB109DC5CAC00@MWHPR07MB2783.namprd07.prod.outlook.com>
On Tue, 27 Feb 2018 20:24:43 +0000
Przemyslaw Sroka <psroka@cadence.com> wrote:
> > > SETDASA is simply faster than ENTDAA, but only if there is no
> > > need to collect BCR/DCR/PID of such devices. I think most
> > > applications would like to have them as an status information so
> > > after all ENTDAA can be regarded as an generic approach (unless
> > > I'm mistaken).
> >
> > Actually, we could retrieve BCR/DCR/PID (and all other relevant
> > information, like MAXDS) even with the SETDASA approach. We just
> > need to send the according CCC commands after SETDASA.
> >
> I agree, what I meant by "SETDASA is simply faster than ENTDAA, but
> only if there is no need to collect BCR/DCR/PID of such devices." Is
> that it is faster than DAA but only if not followed by GET CCC
> commands to gather BCR/DCR/PID. I think we are on the same page here.
Yes, but right now it's not the case, see my other reply ;-).
>
> > But that's also my understanding that ENTDAA should always work, and
> > SETDASA usage is only needed if you want to reserve a dynamic
> > address and assign it to a device before DAA takes place. This way
> > you can enforce the device priority (WRT IBIs). But honestly,
> > that's the only use case I can think of, and to me, it sounds like
> > an advanced feature we may want to support at some point, but don't
> > need in the initial implementation.
> Still ENTDAA seems to be sufficient for IBI prioritization but I can
> imagine some use cases where people would like to use it for such
> purposes. Note that SETDASA is applicable only for devices with SA so
> it is self-explanatory that it cannot be considered as utility to
> define priorities for all devices before ENTDAA.
We have SETNEWDA for other use cases: say you want one of your device to
have an higher priority, you can just manually set a new dynamic
address that is lower than any other devices on the bus (I plan to
expose that through sysfs, by making the address file writable).
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Przemyslaw Sroka <psroka@cadence.com>
Cc: Vitor Soares <Vitor.Soares@synopsys.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Date: Tue, 27 Feb 2018 22:14:07 +0100 [thread overview]
Message-ID: <20180227221407.0cd7f8a9@bbrezillon> (raw)
In-Reply-To: <MWHPR07MB278357B74A7D7E31EB109DC5CAC00@MWHPR07MB2783.namprd07.prod.outlook.com>
On Tue, 27 Feb 2018 20:24:43 +0000
Przemyslaw Sroka <psroka@cadence.com> wrote:
> > > SETDASA is simply faster than ENTDAA, but only if there is no
> > > need to collect BCR/DCR/PID of such devices. I think most
> > > applications would like to have them as an status information so
> > > after all ENTDAA can be regarded as an generic approach (unless
> > > I'm mistaken).
> >
> > Actually, we could retrieve BCR/DCR/PID (and all other relevant
> > information, like MAXDS) even with the SETDASA approach. We just
> > need to send the according CCC commands after SETDASA.
> >
> I agree, what I meant by "SETDASA is simply faster than ENTDAA, but
> only if there is no need to collect BCR/DCR/PID of such devices." Is
> that it is faster than DAA but only if not followed by GET CCC
> commands to gather BCR/DCR/PID. I think we are on the same page here.
Yes, but right now it's not the case, see my other reply ;-).
>
> > But that's also my understanding that ENTDAA should always work, and
> > SETDASA usage is only needed if you want to reserve a dynamic
> > address and assign it to a device before DAA takes place. This way
> > you can enforce the device priority (WRT IBIs). But honestly,
> > that's the only use case I can think of, and to me, it sounds like
> > an advanced feature we may want to support at some point, but don't
> > need in the initial implementation.
> Still ENTDAA seems to be sufficient for IBI prioritization but I can
> imagine some use cases where people would like to use it for such
> purposes. Note that SETDASA is applicable only for devices with SA so
> it is self-explanatory that it cannot be considered as utility to
> define priorities for all devices before ENTDAA.
We have SETNEWDA for other use cases: say you want one of your device to
have an higher priority, you can just manually set a new dynamic
address that is lower than any other devices on the bus (I plan to
expose that through sysfs, by making the address file writable).
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-02-27 21:14 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 15:16 [PATCH v2 0/7] Add the I3C subsystem Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 1/7] i2c: Export of_i2c_get_board_info() Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 2/7] i3c: Add core I3C infrastructure Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-17 22:32 ` Randy Dunlap
2017-12-18 8:37 ` Boris Brezillon
2017-12-18 8:37 ` Boris Brezillon
2017-12-18 18:22 ` Randy Dunlap
2017-12-18 18:22 ` Randy Dunlap
2017-12-19 8:52 ` Greg Kroah-Hartman
2017-12-19 8:52 ` Greg Kroah-Hartman
2017-12-19 9:09 ` Boris Brezillon
2017-12-19 9:09 ` Boris Brezillon
2017-12-19 9:13 ` Boris Brezillon
2017-12-19 9:13 ` Boris Brezillon
2017-12-19 9:21 ` Greg Kroah-Hartman
2017-12-19 9:21 ` Greg Kroah-Hartman
2017-12-19 9:28 ` Boris Brezillon
2017-12-19 9:28 ` Boris Brezillon
2017-12-19 9:36 ` Greg Kroah-Hartman
2017-12-19 9:36 ` Greg Kroah-Hartman
2018-02-21 14:22 ` Boris Brezillon
2018-02-21 14:38 ` Greg Kroah-Hartman
2018-02-23 16:28 ` Vitor Soares
2018-02-23 16:28 ` Vitor Soares
2018-02-23 16:56 ` Vitor Soares
2018-02-23 16:56 ` Vitor Soares
2018-02-23 20:30 ` Boris Brezillon
2018-02-23 20:30 ` Boris Brezillon
2018-02-26 18:58 ` Vitor Soares
2018-02-26 18:58 ` Vitor Soares
2018-02-26 20:36 ` Boris Brezillon
2018-02-26 20:36 ` Boris Brezillon
2018-02-26 20:40 ` Boris Brezillon
2018-02-26 20:40 ` Boris Brezillon
2018-02-26 21:38 ` Boris Brezillon
2018-02-26 21:38 ` Boris Brezillon
2018-02-27 16:03 ` Vitor Soares
2018-02-27 16:03 ` Vitor Soares
2018-02-27 16:43 ` Przemyslaw Sroka
2018-02-27 16:43 ` Przemyslaw Sroka
2018-02-27 17:06 ` Przemyslaw Sroka
2018-02-27 17:06 ` Przemyslaw Sroka
2018-02-27 20:25 ` Boris Brezillon
2018-02-27 20:25 ` Boris Brezillon
2018-02-27 20:13 ` Boris Brezillon
2018-02-27 20:13 ` Boris Brezillon
2018-02-27 20:24 ` Przemyslaw Sroka
2018-02-27 20:24 ` Przemyslaw Sroka
2018-02-27 21:14 ` Boris Brezillon [this message]
2018-02-27 21:14 ` Boris Brezillon
2018-02-27 19:57 ` Boris Brezillon
2018-02-27 19:57 ` Boris Brezillon
2018-02-23 22:45 ` Boris Brezillon
2018-02-23 22:45 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 3/7] docs: driver-api: Add I3C documentation Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 4/7] i3c: Add sysfs ABI spec Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 5/7] dt-bindings: i3c: Document core bindings Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2017-12-14 16:24 ` Geert Uytterhoeven
2017-12-14 16:24 ` Geert Uytterhoeven
[not found] ` <20171214151610.19153-6-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-14 21:47 ` Peter Rosin
2017-12-14 21:47 ` Peter Rosin
2017-12-16 17:20 ` Rob Herring
2017-12-16 17:20 ` Rob Herring
2017-12-16 18:35 ` Boris Brezillon
2017-12-16 18:35 ` Boris Brezillon
2017-12-20 18:06 ` Rob Herring
2017-12-20 18:06 ` Rob Herring
2017-12-21 10:41 ` Boris Brezillon
2017-12-21 10:41 ` Boris Brezillon
2017-12-26 18:29 ` Rob Herring
2017-12-26 18:29 ` Rob Herring
2018-01-07 14:14 ` Boris Brezillon
2018-01-07 14:14 ` Boris Brezillon
2018-01-22 8:47 ` Boris Brezillon
2018-01-22 8:47 ` Boris Brezillon
2017-12-14 15:16 ` [PATCH v2 6/7] i3c: master: Add driver for Cadence IP Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
[not found] ` <20171214151610.19153-7-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2017-12-14 19:54 ` Randy Dunlap
2017-12-14 19:54 ` Randy Dunlap
2017-12-14 20:17 ` Boris Brezillon
2017-12-14 20:17 ` Boris Brezillon
2017-12-14 20:25 ` Randy Dunlap
2017-12-14 20:25 ` Randy Dunlap
2017-12-14 20:44 ` Boris Brezillon
2017-12-14 20:44 ` Boris Brezillon
2017-12-14 22:10 ` Randy Dunlap
2017-12-14 22:10 ` Randy Dunlap
2017-12-14 15:16 ` [PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2017-12-14 15:16 ` Boris Brezillon
2018-02-22 15:00 ` [PATCH v2 0/7] Add the I3C subsystem Vitor Soares
2018-02-22 15:00 ` Vitor Soares
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180227221407.0cd7f8a9@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Vitor.Soares@synopsys.com \
--cc=adouglas@cadence.com \
--cc=agolec@cadence.com \
--cc=alicja@cadence.com \
--cc=arnd@arndb.de \
--cc=bfolta@cadence.com \
--cc=boris.brezillon@free-electrons.com \
--cc=corbet@lwn.net \
--cc=cwronka@cadence.com \
--cc=dkos@cadence.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=nm@ti.com \
--cc=psroka@cadence.com \
--cc=robh+dt@kernel.org \
--cc=sureshp@cadence.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.