Re: [PATCH 0/5] Convert more books to ReST
On Sat, 13 May 2017 08:10:53 -0300 Mauro Carvalho Chehab wrote: > This patch series convert the following books to ReST: > - librs > - mtdnand > - sh > > And it is based on my previous series of conversion patches. > > After this series, there will be just one DocBook pending conversion: > - lsm (Linux Security Modules) > > This book is very outdated: no changes since the Kernel moved > to git, in 2005 (except for a minor editorial fix in 2008). > > I took a look on the described API: it doesn't seem to be describing > the current security implementation. > > The best here is if someone that works with LSM to convert it to > ReST with: > $ Documentation/sphinx/tmplcvt Documentation/DocBook/lsm.tmpl lsm.rst > > And fix the document to produce something that reflects the current > implementation. If nobody is interested, then maybe we could just > drop it. > > - > > This patch series is based on my past 00/36 patch series, applied on > the top of docs tree (next branch). > > The full patch series is on this tree is at: > >https://git.linuxtv.org//mchehab/experimental.git/log/?h=docbook > > And the HTML output at: > > http://www.infradead.org/~mchehab/kernel_docs/ > https://mchehab.fedorapeople.org/kernel_docs/ > > Mauro Carvalho Chehab (5): > docs-rst: convert librs book to ReST > docs-rst: convert mtdnand book to ReST > mtdnand.rst: Fix some typos and group the "::" with previous line MTD maintainers did not receive the above patch. Can you Cc us the whole series next time. BTW, I had a look at your branch and it seems the typo you're fixing is actually not a type. Flags are *OR-ed* (with the | operator) to form a valid combination of flags. > mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings Not sure how you plan to merge these changes, but if it goes through a single tree I'll probably need an immutable topic branch, because I plan to change a few things in nand_base.c nand.h for the next release. > docs-rst: convert sh book to ReST > > Documentation/DocBook/Makefile |5 +- > Documentation/DocBook/librs.tmpl | 289 > Documentation/DocBook/mtdnand.tmpl | 1291 > -- > Documentation/DocBook/sh.tmpl| 105 --- > Documentation/conf.py|2 + > Documentation/core-api/index.rst |1 + > Documentation/core-api/librs.rst | 212 ++ > Documentation/driver-api/index.rst |1 + > Documentation/driver-api/mtdnand.rst | 1007 ++ > Documentation/index.rst | 11 + > Documentation/sh/index.rst | 59 ++ > drivers/mtd/nand/nand_base.c |7 +- > include/linux/mtd/nand.h |2 +- > 13 files changed, 1300 insertions(+), 1692 deletions(-) > delete mode 100644 Documentation/DocBook/librs.tmpl > delete mode 100644 Documentation/DocBook/mtdnand.tmpl > delete mode 100644 Documentation/DocBook/sh.tmpl > create mode 100644 Documentation/core-api/librs.rst > create mode 100644 Documentation/driver-api/mtdnand.rst > create mode 100644 Documentation/sh/index.rst > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Convert more books to ReST
Hi Jonathan, On Mon, 15 May 2017 11:15:19 -0600 Jonathan Corbet wrote: > On Mon, 15 May 2017 14:09:12 +0200 > Boris Brezillon wrote: > > > > mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings > > > > Not sure how you plan to merge these changes, but if it goes through > > a single tree I'll probably need an immutable topic branch, because I > > plan to change a few things in nand_base.c nand.h for the next release. > > docs-next doesn't rebase, so there shouldn't be trouble there. But we > could also just separate this patch into two pieces. I suspect we could > live with a couple of warnings for a period during the 4.13 merge window > without too much pain... I like this idea. This way I can take the nand_base.c/nand.h changes through my tree and let you pick the Doc migration bits. Thanks, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 37/53] docs-rst: convert mtdnand book to ReST
On Tue, 16 May 2017 09:16:29 -0300 Mauro Carvalho Chehab wrote: > Use pandoc to convert documentation to ReST by calling > Documentation/sphinx/tmplcvt script. > > The tables were manually adjusted to fit into 80 columns. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Boris Brezillon > --- > Documentation/DocBook/Makefile |1 - > Documentation/DocBook/mtdnand.tmpl | 1291 > -- > Documentation/driver-api/index.rst |1 + > Documentation/driver-api/mtdnand.rst | 1020 +++ > 4 files changed, 1021 insertions(+), 1292 deletions(-) > delete mode 100644 Documentation/DocBook/mtdnand.tmpl > create mode 100644 Documentation/driver-api/mtdnand.rst > > diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile > index 0a82f6253682..226e5e9fc801 100644 > --- a/Documentation/DocBook/Makefile > +++ b/Documentation/DocBook/Makefile > @@ -8,7 +8,6 @@ > > DOCBOOKS := \ > lsm.xml \ > - mtdnand.xml \ > sh.xml > > ifeq ($(DOCBOOKS),) > diff --git a/Documentation/DocBook/mtdnand.tmpl > b/Documentation/DocBook/mtdnand.tmpl > deleted file mode 100644 > index b442921bca54.. > --- a/Documentation/DocBook/mtdnand.tmpl > +++ /dev/null > @@ -1,1291 +0,0 @@ > - > - - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> > - > - > - > - MTD NAND Driver Programming Interface > - > - > - > -Thomas > -Gleixner > - > - > - t...@linutronix.de > - > - > - > - > - > - > - 2004 > - Thomas Gleixner > - > - > - > - > - This documentation is free software; you can redistribute > - it and/or modify it under the terms of the GNU General Public > - License version 2 as published by the Free Software Foundation. > - > - > - > - This program is distributed in the hope that it will be > - useful, but WITHOUT ANY WARRANTY; without even the implied > - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > - See the GNU General Public License for more details. > - > - > - > - You should have received a copy of the GNU General Public > - License along with this program; if not, write to the Free > - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, > - MA 02111-1307 USA > - > - > - > - For more details see the file COPYING in the source > - distribution of Linux. > - > - > - > - > - > - > - > - Introduction > - > - The generic NAND driver supports almost all NAND and AG-AND based > - chips and connects them to the Memory Technology Devices (MTD) > - subsystem of the Linux Kernel. > - > - > - This documentation is provided for developers who want to implement > - board drivers or filesystem drivers suitable for NAND devices. > - > - > - > - > - Known Bugs And Assumptions > - > - None. > - > - > - > - > - Documentation hints > - > - The function and structure docs are autogenerated. Each function and > - struct member has a short description which is marked with an [XXX] > identifier. > - The following chapters explain the meaning of those identifiers. > - > - > - Function identifiers [XXX] > - > - The functions are marked with [XXX] identifiers in the short > - comment. The identifiers explain the usage and scope of the > - functions. Following identifiers are used: > - > - > - > - [MTD Interface] > - These functions provide the interface to the MTD kernel API. > - They are not replaceable and provide functionality > - which is complete hardware independent. > - > - > - [NAND Interface] > - These functions are exported and provide the interface to the > NAND kernel API. > - > - > - [GENERIC] > - Generic functions are not replaceable and provide functionality > - which is complete hardware independent. > - > - > - [DEFAULT] > - Default functions provide hardware related functionality which > is suitable > - for most of the implementations. These functions can be > replaced by the > - board driver if necessary. Those functions are called via > pointers in the &g
Re: [PATCH v2 38/53] mtdnand.rst: group the "::" with previous line
On Tue, 16 May 2017 09:16:30 -0300 Mauro Carvalho Chehab wrote: > Group the :: with the previous paragraph, in order to make it > visually better when reading as a text file. > > While here, replace: > ored (with means "Covered or adorned with ore or metal") > by: > OR-ed > > To reflect its true meaning. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Boris Brezillon > --- > Documentation/driver-api/mtdnand.rst | 24 +++- > 1 file changed, 7 insertions(+), 17 deletions(-) > > diff --git a/Documentation/driver-api/mtdnand.rst > b/Documentation/driver-api/mtdnand.rst > index 8723175f955e..7c19795ebb4a 100644 > --- a/Documentation/driver-api/mtdnand.rst > +++ b/Documentation/driver-api/mtdnand.rst > @@ -843,10 +843,8 @@ Chip option constants > Constants for chip id table > ~~~ > > -These constants are defined in nand.h. They are ored together to > -describe the chip functionality. > - > -:: > +These constants are defined in nand.h. They are OR-ed together to > +describe the chip functionality:: > > /* Buswitdh is 16 bit */ > #define NAND_BUSWIDTH_160x0002 > @@ -867,10 +865,8 @@ describe the chip functionality. > Constants for runtime options > ~ > > -These constants are defined in nand.h. They are ored together to > -describe the functionality. > - > -:: > +These constants are defined in nand.h. They are OR-ed together to > +describe the functionality:: > > /* The hw ecc generator provides a syndrome instead a ecc value on read > * This can only work if we have the ecc bytes directly behind the > @@ -881,9 +877,7 @@ describe the functionality. > ECC selection constants > --- > > -Use these constants to select the ECC algorithm. > - > -:: > +Use these constants to select the ECC algorithm:: > > /* No ECC. Usage is not recommended ! */ > #define NAND_ECC_NONE 0 > @@ -903,9 +897,7 @@ Hardware control related constants > -- > > These constants describe the requested hardware access function when the > -boardspecific hardware control function is called > - > -:: > +boardspecific hardware control function is called:: > > /* Select the chip by setting nCE to low */ > #define NAND_CTL_SETNCE 1 > @@ -929,9 +921,7 @@ Bad block table related constants > - > > These constants describe the options used for bad block table > -descriptors. > - > -:: > +descriptors:: > > /* Options for the bad block table descriptors */ > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 39/53] mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings
On Tue, 16 May 2017 09:16:31 -0300 Mauro Carvalho Chehab wrote: > ./drivers/mtd/nand/nand_bbt.c:1: warning: no structured comments found > ./include/linux/mtd/nand.h:785: ERROR: Unexpected indentation. > ./drivers/mtd/nand/nand_base.c:449: WARNING: Definition list ends without a > blank line; unexpected unindent. > ./drivers/mtd/nand/nand_base.c:1161: ERROR: Unexpected indentation. > ./drivers/mtd/nand/nand_base.c:1162: WARNING: Block quote ends without a > blank line; unexpected unindent. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Boris Brezillon > --- > Documentation/driver-api/mtdnand.rst | 3 --- > drivers/mtd/nand/nand_base.c | 7 +-- > include/linux/mtd/nand.h | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/driver-api/mtdnand.rst > b/Documentation/driver-api/mtdnand.rst > index 7c19795ebb4a..e9afa586d15e 100644 > --- a/Documentation/driver-api/mtdnand.rst > +++ b/Documentation/driver-api/mtdnand.rst > @@ -970,9 +970,6 @@ hints" for an explanation. > .. kernel-doc:: drivers/mtd/nand/nand_base.c > :export: > > -.. kernel-doc:: drivers/mtd/nand/nand_bbt.c > - :export: > - > .. kernel-doc:: drivers/mtd/nand/nand_ecc.c > :export: > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > index b0524f8accb6..c8988c01e0d7 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -442,10 +442,12 @@ static int nand_default_block_markbad(struct mtd_info > *mtd, loff_t ofs) > * specify how to write bad block markers to OOB (chip->block_markbad). > * > * We try operations in the following order: > + * > * (1) erase the affected block, to allow OOB marker to be written cleanly > * (2) write bad block marker to OOB area of affected block (unless flag > * NAND_BBT_NO_OOB_BBM is present) > * (3) update the BBT > + * > * Note that we retain the first error encountered in (2) or (3), finish the > * procedures, and dump the error in the end. > */ > @@ -1155,9 +1157,10 @@ int nand_reset(struct nand_chip *chip, int chipnr) > * @mtd: mtd info > * @ofs: offset to start unlock from > * @len: length to unlock > - * @invert: when = 0, unlock the range of blocks within the lower and > + * @invert: > + *- when = 0, unlock the range of blocks within the lower and > *upper boundary address > - * when = 1, unlock the range of blocks outside the boundaries > + *- when = 1, unlock the range of blocks outside the boundaries > *of the lower and upper boundary address > * > * Returs unlock status. > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h > index 9591e0fbe5bd..3d5b20379ba3 100644 > --- a/include/linux/mtd/nand.h > +++ b/include/linux/mtd/nand.h > @@ -779,7 +779,7 @@ nand_get_sdr_timings(const struct nand_data_interface > *conf) > * Minimum amount of bit errors per @ecc_step_ds guaranteed > * to be correctable. If unknown, set to zero. > * @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds, > - * also from the datasheet. It is the recommended ECC > step > + * also from the datasheet. It is the recommended ECC step > * size, if known; if unknown, set to zero. > * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field > is > * set to the actually used ONFI mode if the chip is -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] Add I3C subsystem
On Mon, 31 Jul 2017 21:17:45 +0200 Wolfram Sang wrote: > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not public :( > > > - the bus element is a separate object and is not implicitly described > > by the master (as done in I2C). The reason is that I want to be able > > to handle multiple master connected to the same bus and visible to > > Linux. > > In this situation, we should only have one instance of the device and > > not one per master, and sharing the bus object would be part of the > > solution to gracefully handle this case. > > I'm not sure if we will ever need to deal with multiple masters > > controlling the same bus and exposed under Linux, but separating the > > bus and master concept is pretty easy, hence the decision to do it > > now, just in case we need it some day. > > From my experience, it is a good thing to have this separation. > > > - 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 new I2C bus. I'd say that, from a > > representation PoV it's not ideal because what should appear as a > > single I3C bus exposing I3C and I2C devices here appears as 2 > > different busses connected to each other through the parenting (the > > I3C master is the parent of the I2C and I3C busses). > > On the other hand, I don't see a better solution if we want something > > that is not invasive. > > I agree this is the least invasive and also the most compatible > approach. The other solution would probably be to have some kind of > emulation layer? > > > I'd also like to get feedback on the doc. Should I detail a bit more > > the protocol or the framework API? Is this the kind of things you > > expect in a subsystem doc? > > Since the spec is not public, details about the protocol will be > especially useful, I'd say. MIPI has opened the I3C spec [1], it can be downloaded here [2]. v2 of this series will come soon (sorry for the delay). Regards, Boris [1]https://www.businesswire.com/news//home/20171212005059/en/MIPI-Alliance-Opens-Access-MIPI-I3C-Sensor [2]http://resources.mipi.org/mipi-i3c-v1-download -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 new transfers even if the master is > > > > already busy processing other requests), and serializing things at the > > > > framework level will just prevent us from using this kind of > > > > optimization. > > > > > > Unless you can prove otherwise, using a rw lock is almost always worse > > > than just a mutex. > > > > Is it still true when it's taken in non-exclusive mode most of the > > time, and the time you spend in the critical section is non-negligible? > > > > I won't pretend I know better than you do what is preferable, it's just > > that the RW lock seemed appropriate to me for the situation I tried to > > described here. > > Again, measure it. If you can't measure it, then don't use it. Use a > simple lock instead. Seriously, don't make it more complex until you > really have to. It sounds like you didn't measure it at all, which > isn't good, please do so. > I'm resurrecting this thread because I finally had the time to implement message queuing in Cadence I3C master driver. So I did a test with 2 I3C devices on the bus, and their drivers sending as much SDR messages as they can in 10s. Here are the results: |mutex|rwsem| --- dev1 |19087|29532| dev2 |19341|29118| === total |38428|58650| msg/sec |~3843|~5865| The results I'm obtaining here are not so surprising since all normal transfers are taking the lock in read mode, so there's no contention. I didn't measure the impact on performances when there's one maintenance operation taking the lock in write mode and several normal transfers waiting for this lock, but really, maintenance operations are infrequent, and that's not where performance matters in our use case. I also did the same test with only one device doing transfers on the bus, and this time the mutex wins, but there's not a huge difference. |mutex|rwsem| --- total |67116|66561| msg/sec |~6712|~6656| Let me know if you want more information on the test procedure. Regards, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] i3c: master: Add driver for Cadence IP
Add a driver for Cadence I3C master IP. Signed-off-by: Boris Brezillon --- Changes in v2: - Add basic IBI support. Note that the IP is not really reliable with regards to IBI because you can't extract IBI payloads as soon as you have more than one IBI waiting in the HW queue. This is something that will hopefully be addressed in future revisions of this IP - Add a simple xfer queueing mechanism to optimize message queuing. - Fix a few bugs - Add support for Hot Join --- drivers/i3c/master/Kconfig |5 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1797 ++ 3 files changed, 1803 insertions(+) create mode 100644 drivers/i3c/master/i3c-master-cdns.c diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig index e69de29bb2d1..56b9a18543b2 100644 --- a/drivers/i3c/master/Kconfig +++ b/drivers/i3c/master/Kconfig @@ -0,0 +1,5 @@ +config CDNS_I3C_MASTER + tristate "Cadence I3C master driver" + depends on I3C + help + Enable this driver if you want to support Cadence I3C master block. diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile index e69de29bb2d1..4c4304aa9534 100644 --- a/drivers/i3c/master/Makefile +++ b/drivers/i3c/master/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c new file mode 100644 index ..3e3ef37c01c2 --- /dev/null +++ b/drivers/i3c/master/i3c-master-cdns.c @@ -0,0 +1,1797 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define DEV_ID 0x0 +#define DEV_ID_I3C_MASTER 0x5034 + +#define CONF_STATUS0 0x4 +#define CONF_STATUS0_ECC_CHK BIT(28) +#define CONF_STATUS0_INTEG_CHK BIT(27) +#define CONF_STATUS0_CSR_DAP_CHK BIT(26) +#define CONF_STATUS0_TRANS_TOUT_CHKBIT(25) +#define CONF_STATUS0_PROT_FAULTS_CHK BIT(24) +#define CONF_STATUS0_GPO_NUM(x)(((x) & GENMASK(23, 16)) >> 16) +#define CONF_STATUS0_GPI_NUM(x)(((x) & GENMASK(15, 8)) >> 8) +#define CONF_STATUS0_SUPPORTS_DDR BIT(5) +#define CONF_STATUS0_SEC_MASTERBIT(4) +#define CONF_STATUS0_DEVS_NUM(x) ((x) & GENMASK(3, 0)) + +#define CONF_STATUS1 0x8 +#define CONF_STATUS1_IBI_HW_RES(x) x) & GENMASK(31, 28)) >> 28) + 1) +#define CONF_STATUS1_CMD_DEPTH(x) (4 << (((x) & GENMASK(27, 26)) >> 26)) +#define CONF_STATUS1_SLVDDR_RX_DEPTH(x)(8 << (((x) & GENMASK(25, 21)) >> 21)) +#define CONF_STATUS1_SLVDDR_TX_DEPTH(x)(8 << (((x) & GENMASK(20, 16)) >> 16)) +#define CONF_STATUS1_IBI_DEPTH(x) (2 << (((x) & GENMASK(12, 10)) >> 10)) +#define CONF_STATUS1_RX_DEPTH(x) (8 << (((x) & GENMASK(9, 5)) >> 5)) +#define CONF_STATUS1_TX_DEPTH(x) (8 << ((x) & GENMASK(4, 0))) + +#define REV_ID 0xc +#define REV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20) +#define REV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8) +#define REV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4) +#define REV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0)) + +#define CTRL 0x10 +#define CTRL_DEV_ENBIT(31) +#define CTRL_HALT_EN BIT(30) +#define CTRL_HJ_DISEC BIT(8) +#define CTRL_MST_ACK BIT(7) +#define CTRL_HJ_ACKBIT(6) +#define CTRL_HJ_INIT BIT(5) +#define CTRL_MST_INIT BIT(4) +#define CTRL_AHDR_OPT BIT(3) +#define CTRL_PURE_BUS_MODE 0 +#define CTRL_MIXED_FAST_BUS_MODE 2 +#define CTRL_MIXED_SLOW_BUS_MODE 3 +#define CTRL_BUS_MODE_MASK GENMASK(1, 0) + +#define PRESCL_CTRL0 0x14 +#define PRESCL_CTRL0_I2C(x)((x) << 16) +#define PRESCL_CTRL0_I3C(x)(x) +#define PRESCL_CTRL0_MAX GENMASK(9, 0) + +#define PRESCL_CTRL1 0x18 +#define PRESCL_CTRL1_PP_LOW_MASK GENMASK(15, 8) +#define PRESCL_CTRL1_PP_LOW(x) ((x) << 8) +#define PRESCL_CTRL1_OD_LOW_MASK GENMASK(7, 0) +#define PRESCL_CTRL1_OD_LOW(x) (x) + +#define MST_IER0x20 +#define MST_IDR0x24 +#define MST_IMR0x28 +#define MST_ICR0x2c +#define MST_ISR0x30 +#define MST_INT_M0_ERR
[PATCH v2 5/7] dt-bindings: i3c: Document core bindings
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
used. Note that the parsing of I3C devices is not yet implemented in
the framework. Will be added when someone really needs it.
---
Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt
b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index ..79a214dee025
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,128 @@
+Generic device tree bindings for I3C busses
+===
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+---
+
+- #address-cells - should be <1>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of I3C bus controller following generic names
+ recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+---
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+transfers. When undefined, the core looks at LVR values
+of I2C devices described in the device tree to determine
+the maximum I2C frequency.
+
+I2C devices
+===
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+ describing device capabilities as described in the I3C
+ specification.
+
+ bit[31:8]: unused
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not
+tolerant to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+I3C devices
+===
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static address and we want to assign it a specific dynamic
+address before the DAA takes place (so that other devices on the bus can't
+take this dynamic address).
+
+Required properties
+---
+- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
+ device discovered during DAA with its device tree definition. The
+ PID is supposed to be unique on a given bus, which guarantees a 1:1
+ match. This property becomes optional if a reg property is defined,
+ meaning that the device has a static address.
+
+Optional properties
+---
+- reg: static address. Only valid is the device has a static address.
+- i3c-dynamic-address: dynamic address to be assigned to this device. This
+ property depends on the reg property.
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+ i2c-scl-frequency = <10>;
+
+ /*
[PATCH v2 1/7] i2c: Export of_i2c_get_board_info()
I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.
We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.
Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- fix memset() call
- rebase on v4.15-rc1
---
drivers/i2c/i2c-core-base.c | 2 +-
drivers/i2c/i2c-core-of.c | 66 ++---
include/linux/i2c.h | 10 +++
3 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 706164b4c5be..025df16e64be 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -774,7 +774,7 @@ i2c_new_device(struct i2c_adapter *adap, struct
i2c_board_info const *info)
client->dev.parent = &client->adapter->dev;
client->dev.bus = &i2c_bus_type;
client->dev.type = &i2c_client_type;
- client->dev.of_node = info->of_node;
+ client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
i2c_dev_set_name(adap, client, info);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 8d474bb1dc15..7470bc418a3b 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,56 +22,66 @@
#include "i2c-core.h"
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
-struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info)
{
- struct i2c_client *result;
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr_be;
u32 addr;
- int len;
+ int ret;
- dev_dbg(&adap->dev, "of_i2c: register %pOF\n", node);
+ memset(info, 0, sizeof(*info));
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %pOF\n",
- node);
- return ERR_PTR(-EINVAL);
+ if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+ dev_err(dev, "of_i2c: modalias failure on %pOF\n", node);
+ return -EINVAL;
}
- addr_be = of_get_property(node, "reg", &len);
- if (!addr_be || (len < sizeof(*addr_be))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %pOF\n", node);
- return ERR_PTR(-EINVAL);
+ ret = of_property_read_u32(node, "reg", &addr);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid reg on %pOF\n", node);
+ return ret;
}
- addr = be32_to_cpup(addr_be);
if (addr & I2C_TEN_BIT_ADDRESS) {
addr &= ~I2C_TEN_BIT_ADDRESS;
- info.flags |= I2C_CLIENT_TEN;
+ info->flags |= I2C_CLIENT_TEN;
}
if (addr & I2C_OWN_SLAVE_ADDRESS) {
addr &= ~I2C_OWN_SLAVE_ADDRESS;
- info.flags |= I2C_CLIENT_SLAVE;
+ info->flags |= I2C_CLIENT_SLAVE;
}
- if (i2c_check_addr_validity(addr, info.flags)) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %pOF\n",
- addr, node);
- return ERR_PTR(-EINVAL);
+ ret = i2c_check_addr_validity(addr, info->flags);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid addr=%x on %pOF\n", addr, node);
+ return ret;
}
- info.addr = addr;
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
+ info->addr = addr;
+ info->of_node = node;
if (of_property_read_bool(node, "host-notify"))
- info.flags |= I2C_CLIENT_HOST_NOTIFY;
+ info->flags |= I2C_CLIENT_HOST_NOTIFY;
if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
+ info->flags |= I2C_CLIENT_WAKE;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_i2c_get_board_info);
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+struct devic
[PATCH v2 0/7] Add the I3C subsystem
This patch series is a proposal for a new I3C [1] subsystem. 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 to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is still open to discussion. Please let me know if you think it's worth considering an asynchronous model here - the bus element is a separate object and is not implicitly described by the master (as done in I2C). The reason is that I want to be able to handle multiple master connected to the same bus and visible to Linux. In this situation, we should only have one instance of the device and not one per master, and sharing the bus object would be part of the solution to gracefully handle this case. I'm not sure if we will ever need to deal with multiple masters controlling the same bus and exposed under Linux, but separating the bus and master concept is pretty easy, hence the decision to do it now, just in case we need it some day. The other benefit of separating the bus and master concepts is that master devices appear under the bus directory in sysfs. - 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 new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different busses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features in this preliminary version: - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Main changes between the initial RFC and this v2 are: - Add a generic infrastructure to support IBIs. It's worth mentioning that I tried exposing IBIs as a regular IRQs, but after several attempts and a discussion with Mark Zyngier, it appeared that it was not really fitting in the Linux IRQ model (the fact that you have payload attached to IBIs, the fact that most of the time an IBI will generate a transfer on the bus which has to be done in an atomic context, ...) The counterpart of this decision is the latency induced by the workqueue approach, but since I don't have real use cases, I don't know if this can be a problem or not. - Add helpers to support Hot Join - Add support for IBIs and Hot Join in Cadence I3C master driver - Address several issues in how I was using the device model I'll finish on a good news: this week the MIPI alliance opened the I3C spec. So everyone can now review the patches (no need to be member of the MIPI I3C group). I'll let you find the link in the doc, this way maybe I'll have reviews on the doc itself :-). Thanks, Boris Boris Brezillon (7): i2c: Export of_i2c_get_board_info() i3c: Add core I3C infrastructure docs: driver-api: Add I3C documentation i3c: Add sysfs ABI spec dt-bindings: i3c: Document core bindings i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings Documentation/ABI/testing/sysfs-bus-i3c| 95 ++ .../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 + Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++ Documentation/driver-api/i3c/conf.py | 10 + Documentation/driver-api/i3c/device-driver-api.rst |7 + Documentation/driver-api/i3c/index.rst |9 + Documentation/driver-api/i3c/master-driver-api.rst |8 + Documentation/driver-api/i3c/protocol.rst | 201 +++ Documentation/driver-api/index.rst |1 + drivers/Kconfig|2 + drivers/Makefile |2 +- drivers/i2c/i2c-core-base.c|2 +- drivers/i2c/i2c-core-of.c | 66 +- drivers/i3c/Kconfig| 24 + drivers/i3c/Makefile |4 + drivers/i3c/core.c |
[PATCH v2 7/7] dt-bindings: i3c: Document Cadence I3C master bindings
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index ..f9e4af4ff1c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,45 @@
+Bindings for cadence I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-frequency
+- i3c-scl-frequency
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-frequency = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] docs: driver-api: Add I3C documentation
Add the I3C documentation describing the protocol, the master driver API
and the device driver API.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
Documentation/driver-api/i3c/conf.py | 10 +
Documentation/driver-api/i3c/device-driver-api.rst | 7 +
Documentation/driver-api/i3c/index.rst | 9 +
Documentation/driver-api/i3c/master-driver-api.rst | 8 +
Documentation/driver-api/i3c/protocol.rst | 201 +
Documentation/driver-api/index.rst | 1 +
6 files changed, 236 insertions(+)
create mode 100644 Documentation/driver-api/i3c/conf.py
create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/index.rst
create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/protocol.rst
diff --git a/Documentation/driver-api/i3c/conf.py
b/Documentation/driver-api/i3c/conf.py
new file mode 100644
index ..5a20832d59a7
--- /dev/null
+++ b/Documentation/driver-api/i3c/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux I3C Subsystem"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'i3c.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst
b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index ..63c843f148a6
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,7 @@
+=
+I3C device driver API
+=
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst
b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index ..9c439220439d
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,9 @@
+=
+I3C subsystem
+=
+
+.. toctree::
+
+ protocol
+ device-driver-api
+ master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst
b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index ..017e7711cdf7
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,8 @@
+
+I3C master controller driver API
+
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst
b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index ..891c4f50c472
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,201 @@
+
+I3C protocol
+
+
+Disclaimer
+==
+
+This chapter will focus on aspects that matter to software developers. For
+everything hardware related (like how things are transmitted on the bus, how
+collisions are prevented, ...) please have a look at the I3C specification.
+
+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 (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+===
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+ transactions or deciding who is allowed to talk on the bus (slave generated
+ events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+ slave on the bus. The device can still send events to the master on
+ its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to these per-device addre
[PATCH v2 4/7] i3c: Add sysfs ABI spec
Document sysfs files/directories/symlinks exposed by the I3C subsystem. Signed-off-by: Boris Brezillon --- Changes in v2: - new patch --- Documentation/ABI/testing/sysfs-bus-i3c | 95 + 1 file changed, 95 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c new file mode 100644 index ..5e88cc093e0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i3c @@ -0,0 +1,95 @@ +What: /sys/bus/i3c/devices/i3c- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C bus. This directory will contain one sub-directory per + I3C device present on the bus. + +What: /sys/bus/i3c/devices/i3c-/current_master +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the master that owns the bus (-) at + the time this file is read. Note that bus ownership can change + overtime, so there's no guarantee that when the read() call + returns, the value returned is still valid. + +What: /sys/bus/i3c/devices/i3c-/mode +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See + the I3C specification for a detailed description of what each + of these modes implies. + +What: /sys/bus/i3c/devices/i3c-/i3c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I3C SDR mode. + +What: /sys/bus/i3c/devices/i3c-/i2c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I2C mode. + +What: /sys/bus/i3c/devices/i3c-/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C device present on I3C bus identified by . Note + that all devices are represented including the master driving + the bus. + +What: /sys/bus/i3c/devices/i3c-/-/address +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Dynamic address assigned to device -. This + address may change if the bus is re-initialized. + +What: /sys/bus/i3c/devices/i3c-/-/bcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + BCR stands for Bus Characteristics Register and express the + device capabilities in term of speed, maximum read/write + length, etc. See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/dcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + DCR stands for Device Characteristics Register and express the + device capabilities in term of exposed features. See the I3C + specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/pid +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + PID stands for Provisional ID and is used to uniquely identify + a device on a bus. This PID contains information about the + vendor, the part and an instance ID so that several devices of + the same type can be connected on the same bus. + See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/hdrcap +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the HDR (High Data Rate) capabilities of a device. + Returns a list of supported HDR mode, each element is separated + by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl". + See the I3C specification for more details about these HDR + modes. + +What: /sys/bus/i3c/devices/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + These directories are just symbolic links to + /sys/bus/i3c/devices/i3c-/-. -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
Hi Randy,
On Thu, 14 Dec 2017 11:54:16 -0800
Randy Dunlap wrote:
> On 12/14/2017 07:16 AM, Boris Brezillon wrote:
> > Add a driver for Cadence I3C master IP.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > Changes in v2:
> > - Add basic IBI support. Note that the IP is not really reliable with
> > regards to IBI because you can't extract IBI payloads as soon as you
> > have more than one IBI waiting in the HW queue. This is something
> > that will hopefully be addressed in future revisions of this IP
> > - Add a simple xfer queueing mechanism to optimize message queuing.
> > - Fix a few bugs
> > - Add support for Hot Join
> > ---
> > drivers/i3c/master/Kconfig |5 +
> > drivers/i3c/master/Makefile |1 +
> > drivers/i3c/master/i3c-master-cdns.c | 1797
> > ++
> > 3 files changed, 1803 insertions(+)
> > create mode 100644 drivers/i3c/master/i3c-master-cdns.c
> >
> > diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> > index e69de29bb2d1..56b9a18543b2 100644
> > --- a/drivers/i3c/master/Kconfig
> > +++ b/drivers/i3c/master/Kconfig
> > @@ -0,0 +1,5 @@
> > +config CDNS_I3C_MASTER
> > + tristate "Cadence I3C master driver"
> > + depends on I3C
> > + help
> > + Enable this driver if you want to support Cadence I3C master block.
> > diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> > index e69de29bb2d1..4c4304aa9534 100644
> > --- a/drivers/i3c/master/Makefile
> > +++ b/drivers/i3c/master/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o
> > diff --git a/drivers/i3c/master/i3c-master-cdns.c
> > b/drivers/i3c/master/i3c-master-cdns.c
> > new file mode 100644
> > index ..3e3ef37c01c2
> > --- /dev/null
> > +++ b/drivers/i3c/master/i3c-master-cdns.c
> > @@ -0,0 +1,1797 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon
> > + */
> > +
>
> Rule #1 from submit-checklist.rst:
> 1) If you use a facility then #include the file that defines/declares
>that facility. Don't depend on other header files pulling in ones
>that you use.
>
>
> #include
> for BIT(x) and hweight8() and clear_bit() and find_next_bit()
> and hweight32()
>
> > +#include
>
> #include
> for IS_ERR(), PTR_ERR()
>
> #include
> for error codes
>
> > +#include
> > +#include
>
> #include
> for writel()
>
> > +#include
>
> #include
> for IORESOURCE_MEM
>
> #include
> for DIV_ROUND_UP()
>
> #include
> for list() macros and INIT_LIST_HEAD()
>
> > +#include
> > +#include
> > +#include
> > +#include
>
> #include
>
> #include
> for workqueue functions and INIT_WORK()
Will fix that.
>
> > +
> > +#define DEV_ID 0x0
> > +#define DEV_ID_I3C_MASTER 0x5034
>
> [snip]
>
>
>
> > +#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE 0x2
> > +#define I3C_DDR_DATA_WORD_PREAMBLE 0x3
> > +
> > +#define I3C_DDR_PREAMBLE(p)((p) << 18)
> > +
> > +static u32 prepare_ddr_word(u16 payload)
> > +{
> > + u32 ret;
> > + u16 pb;
> > +
> > + ret = (u32)payload << 2;
> > +
> > + /* Calculate parity. */
> > + pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
> > +(payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
> > +(payload >> 3) ^ (payload >> 1);
> > + ret |= (pb & 1) << 1;
> > + pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
> > +(payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
> > +(payload >> 2) ^ payload ^ 1;
> > + ret |= (pb & 1);
> > +
> > + return ret;
> > +}
> > +
> > +static u32 prepare_ddr_data_word(u16 data, bool first)
> > +{
> > + return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);
>
> Just defined macros for 2 & 3 above. Use them instead of magic numbers?
Oops, that was my intention, just forgot to use the macros I had
defined.
>
> > +}
> > +
> > +#define I3C_DDR_READ_CMD BIT(15)
> > +
> > +static u32 prepare_ddr_cmd_word(u16 cmd)
> > +{
&g
Re: [PATCH v2 6/7] i3c: master: Add driver for Cadence IP
On Thu, 14 Dec 2017 12:25:14 -0800
Randy Dunlap wrote:
> On 12/14/2017 12:17 PM, Boris Brezillon wrote:
> >>> + events.events = I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR;
> >>> + ret = i3c_master_enec_locked(m, I3C_BROADCAST_ADDR, &events);
> >>> + if (ret)
> >>> + pr_info("Failed to re-enable H-J");
> >>Not very good info...
> > What do you mean? Is it the H-J that bothers you (I can replace it by
> > 'Hot-Join'), or is it something else?
>
> Who is the message for? If it's for developers, you could use
> pr_debug(). If it's for users, it needs more clarity.
I think it's of interest to anyone including users. If we fail to
re-enable Hot-Join that means hotplug is no longer working which is
a bad news.
>
> Does it print the source of the message? (module name e.g.)
I could replace it by
dev_err(m->parent, "Failed to re-enable Hot-Join");
> and yes, Hot-Join would be better IMO.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
On Sat, 16 Dec 2017 11:20:40 -0600 Rob Herring wrote: > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote: > > A new I3C subsystem has been added and a generic description has been > > created to represent the I3C bus and the devices connected on it. > > > > Document this generic representation. > > > > Signed-off-by: Boris Brezillon > > --- > > Changes in v2: > > - Define how to describe I3C devices in the DT and when it should be > > used. Note that the parsing of I3C devices is not yet implemented in > > the framework. Will be added when someone really needs it. > > --- > > Documentation/devicetree/bindings/i3c/i3c.txt | 128 > > ++ > > 1 file changed, 128 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt > > > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt > > b/Documentation/devicetree/bindings/i3c/i3c.txt > > new file mode 100644 > > index ..79a214dee025 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt > > @@ -0,0 +1,128 @@ > > +Generic device tree bindings for I3C busses > > +=== > > + > > +This document describes generic bindings that should be used to describe > > I3C > > +busses in a device tree. > > + > > +Required properties > > +--- > > + > > +- #address-cells - should be <1>. Read more about addresses below. > > +- #size-cells - should be <0>. > > +- compatible - name of I3C bus controller following generic names > > + recommended practice. > > generic names isn't anything recommended. Hm, I agree. Don't even know what I wanted to say (it's probably been copied from somewhere else). > > One problem we have with i2c buses is we can't identify them in the DT > other than with a list of all controller's compatible strings. We can > fix this by defining the controller node name. I'm fine with that. > So please define the node > name to be "i3c-controller". That's more inline with other node names > than i3c-master that you used below. Hm, not sure i3c-controller is appropriate though, because you can have slave controllers. Maybe i3c-host, but I'd prefer to keep the term master since it's employed everywhere in the spec. I can also be i3c-master-controller if you prefer. > > > + > > +For other required properties e.g. to describe register sets, > > +clocks, etc. check the binding documentation of the specific driver. > > + > > +Optional properties > > +--- > > + > > +These properties may not be supported by all I3C master drivers. Each I3C > > +master bindings should specify which of them are supported. > > + > > +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C > > +transfers. When undefined the core set it to 12.5MHz. > > + > > +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C > > +transfers. When undefined, the core looks at LVR values > > +of I2C devices described in the device tree to determine > > +the maximum I2C frequency. > > Add '-hz' suffix. You could drop 'frequency' as that would be implied by > Hz. Okay. > > > + > > +I2C devices > > +=== > > + > > +Each I2C device connected to the bus should be described in a subnode with > > +the following properties: > > + > > +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt > > are > > +valid here. > > + > > +New required properties: > > + > > +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful) > > + describing device capabilities as described in the I3C > > + specification. > > + > > + bit[31:8]: unused > > + bit[7:5]: I2C device index. Possible values > > + * 0: I2C device has a 50 ns spike filter > > + * 1: I2C device does not have a 50 ns spike filter but supports high > > +frequency on SCL > > + * 2: I2C device does not have a 50 ns spike filter and is not > > +tolerant to high frequencies > > + * 3-7: reserved > > + > > + bit[4]: tell whether the device operates in FM or FM+ mode > > + * 0: FM+ mode > > + * 1: FM mode > > + > > + bit[3:0]: device type > > +
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Sun, 17 Dec 2017 14:32:04 -0800
Randy Dunlap wrote:
> On 12/14/17 07:16, Boris Brezillon wrote:
> > Add core infrastructure to support I3C in Linux and document it.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > drivers/Kconfig |2 +
> > drivers/Makefile|2 +-
> > drivers/i3c/Kconfig | 24 +
> > drivers/i3c/Makefile|4 +
> > drivers/i3c/core.c | 573
> > drivers/i3c/device.c| 344 ++
> > drivers/i3c/internals.h | 34 +
> > drivers/i3c/master.c| 1433
> > +++
> > drivers/i3c/master/Kconfig |0
> > drivers/i3c/master/Makefile |0
> > include/linux/i3c/ccc.h | 380 +++
> > include/linux/i3c/device.h | 321 +
> > include/linux/i3c/master.h | 564 +++
> > include/linux/mod_devicetable.h | 17 +
> > 14 files changed, 3697 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/i3c/Kconfig
> > create mode 100644 drivers/i3c/Makefile
> > create mode 100644 drivers/i3c/core.c
> > create mode 100644 drivers/i3c/device.c
> > create mode 100644 drivers/i3c/internals.h
> > create mode 100644 drivers/i3c/master.c
> > create mode 100644 drivers/i3c/master/Kconfig
> > create mode 100644 drivers/i3c/master/Makefile
> > create mode 100644 include/linux/i3c/ccc.h
> > create mode 100644 include/linux/i3c/device.h
> > create mode 100644 include/linux/i3c/master.h
> >
> > diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig
> > new file mode 100644
> > index ..cf3752412ae9
> > --- /dev/null
> > +++ b/drivers/i3c/Kconfig
> > @@ -0,0 +1,24 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +menuconfig I3C
> > + tristate "I3C support"
> > + select I2C
> > + help
> > + I3C is a serial protocol standardized by the MIPI alliance.
> > +
> > + It's supposed to be backward compatible with I2C while providing
> > + support for high speed transfers and native interrupt support
> > + without the need for extra pins.
> > +
> > + The I3C protocol also standardizes the slave device types and is
> > + mainly design to communicate with sensors.
> > +
> > + If you want I3C support, you should say Y here and also to the
> > + specific driver for your bus adapter(s) below.
> > +
> > + This I3C support can also be built as a module. If so, the module
> > + will be called i3c.
> > +
> > +if I3C
> > +source "drivers/i3c/master/Kconfig"
> > +endif # I3C
>
> > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> > new file mode 100644
> > index ..7eb8e84acd33
> > --- /dev/null
> > +++ b/drivers/i3c/core.c
> > @@ -0,0 +1,573 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
>
> #include
> #include
> #include
> #include
> #include
Do you have a tool to detect those missing inclusions?
>
>
> > +#include "internals.h"
> > +
> > +static DEFINE_IDR(i3c_bus_idr);
> > +static DEFINE_MUTEX(i3c_core_lock);
> > +
>
> > +/**
> > + * i3c_bus_maintenance_lock - Release the bus lock after a maintenance
>
> unlock
>
Will fix that.
> > + * operation
> > + * @bus: I3C bus to release the lock on
> > + *
> > + * Should be called when the bus maintenance operation is done. See
> > + * i3c_bus_maintenance_lock() for more details on what these maintenance
> > + * operations are.
> > + */
> > +void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
> > +{
> > + up_write(&bus->lock);
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
> > +
>
> > +/**
> > + * i3c_bus_normaluse_lock - Release the bus lock after a normal operation
>
> unlock
Ditto.
>
> > + * @bus: I3C bus to release the lock on
> > + *
> > + * Should be called when a normal operation is done. See
> > + * i3c_bus_normaluse_lock() for more details on what these normal
> > operations
> > + * are.
> > + */
> > +void i3c_bus_normaluse_unlock(str
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Tue, 19 Dec 2017 09:52:50 +0100
Greg Kroah-Hartman wrote:
> On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > +/**
> > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C dev
> > + * @i3cdev: the I3C device we're searching a match for
> > + * @id_table: the I3C device ID table
> > + *
> > + * Return: a pointer to the first entry matching @i3cdev, or NULL if
> > there's
> > + *no match.
> > + */
> > +const struct i3c_device_id *
> > +i3c_device_match_id(struct i3c_device *i3cdev,
> > + const struct i3c_device_id *id_table)
> > +{
> > + const struct i3c_device_id *id;
> > +
> > + /*
> > +* The lower 32bits of the provisional ID is just filled with a random
> > +* value, try to match using DCR info.
> > +*/
> > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > +
> > + /* First try to match by manufacturer/part ID. */
> > + for (id = id_table; id->match_flags != 0; id++) {
> > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > + I3C_MATCH_MANUF_AND_PART)
> > + continue;
> > +
> > + if (manuf != id->manuf_id || part != id->part_id)
> > + continue;
> > +
> > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > + ext_info != id->extra_info)
> > + continue;
> > +
> > + return id;
> > + }
> > + }
> > +
> > + /* Fallback to DCR match. */
> > + for (id = id_table; id->match_flags != 0; id++) {
> > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > + id->dcr == i3cdev->info.dcr)
> > + return id;
> > + }
> > +
> > + return NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
>
> I just picked one random export here, but it feels like you are
> exporting a bunch of symbols you don't need to. Why would something
> outside of the i3c "core" need to call this function?
Because I'm not passing the i3c_device_id to the ->probe() method, and
if the driver is supporting different variants of the device, it may
want to know which one is being probed.
I considered retrieving this information in the core just before probing
the driver and passing it to the ->probe() function, but it means
having an extra i3c_device_match_id() call for everyone even those who
don't care about the device_id information, so I thought exporting this
function was a good alternative (device drivers can use it when they
actually need to retrieve the device_id).
Anyway, that's something I can change if you think passing the
i3c_device_id to the ->probe() method is preferable.
> Have you looked
> to see if you really have callers for everything you are exporting?
Yes, I tried to only export functions that I think will be needed by
I3C device drivers and I3C master drivers. Note that I didn't post the
dummy device driver I developed to test the framework (partly because
this is
>
> Other than that, the driver core interaction looks good now, nice job.
Thanks.
Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Tue, 19 Dec 2017 10:09:00 +0100
Boris Brezillon wrote:
> On Tue, 19 Dec 2017 09:52:50 +0100
> Greg Kroah-Hartman wrote:
>
> > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > +/**
> > > + * i3c_device_match_id() - Find the I3C device ID entry matching an I3C
> > > dev
> > > + * @i3cdev: the I3C device we're searching a match for
> > > + * @id_table: the I3C device ID table
> > > + *
> > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if
> > > there's
> > > + * no match.
> > > + */
> > > +const struct i3c_device_id *
> > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > + const struct i3c_device_id *id_table)
> > > +{
> > > + const struct i3c_device_id *id;
> > > +
> > > + /*
> > > + * The lower 32bits of the provisional ID is just filled with a random
> > > + * value, try to match using DCR info.
> > > + */
> > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > +
> > > + /* First try to match by manufacturer/part ID. */
> > > + for (id = id_table; id->match_flags != 0; id++) {
> > > + if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
> > > + I3C_MATCH_MANUF_AND_PART)
> > > + continue;
> > > +
> > > + if (manuf != id->manuf_id || part != id->part_id)
> > > + continue;
> > > +
> > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > + ext_info != id->extra_info)
> > > + continue;
> > > +
> > > + return id;
> > > + }
> > > + }
> > > +
> > > + /* Fallback to DCR match. */
> > > + for (id = id_table; id->match_flags != 0; id++) {
> > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > + id->dcr == i3cdev->info.dcr)
> > > + return id;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> >
> > I just picked one random export here, but it feels like you are
> > exporting a bunch of symbols you don't need to. Why would something
> > outside of the i3c "core" need to call this function?
>
> Because I'm not passing the i3c_device_id to the ->probe() method, and
> if the driver is supporting different variants of the device, it may
> want to know which one is being probed.
>
> I considered retrieving this information in the core just before probing
> the driver and passing it to the ->probe() function, but it means
> having an extra i3c_device_match_id() call for everyone even those who
> don't care about the device_id information, so I thought exporting this
> function was a good alternative (device drivers can use it when they
> actually need to retrieve the device_id).
>
> Anyway, that's something I can change if you think passing the
> i3c_device_id to the ->probe() method is preferable.
>
> > Have you looked
> > to see if you really have callers for everything you are exporting?
>
> Yes, I tried to only export functions that I think will be needed by
> I3C device drivers and I3C master drivers. Note that I didn't post the
> dummy device driver I developed to test the framework (partly because
> this is
Sorry, I hit the send button before finishing my sentence :-).
"
Note that I didn't post the dummy device driver [1] I developed to test
the framework (partly because the quality of the code does not meet
mainline standards and I was ashamed of posting it publicly :-)), but
this driver is using some of the exported functions.
"
[1]https://github.com/bbrezillon/linux-0day/commit/10054caf3493524b6ae352a1bdcb71e82c885a6e
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Tue, 19 Dec 2017 10:21:19 +0100
Greg Kroah-Hartman wrote:
> On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > On Tue, 19 Dec 2017 10:09:00 +0100
> > Boris Brezillon wrote:
> >
> > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > Greg Kroah-Hartman wrote:
> > >
> > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > > +/**
> > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching an
> > > > > I3C dev
> > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > + * @id_table: the I3C device ID table
> > > > > + *
> > > > > + * Return: a pointer to the first entry matching @i3cdev, or NULL if
> > > > > there's
> > > > > + * no match.
> > > > > + */
> > > > > +const struct i3c_device_id *
> > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > + const struct i3c_device_id *id_table)
> > > > > +{
> > > > > + const struct i3c_device_id *id;
> > > > > +
> > > > > + /*
> > > > > + * The lower 32bits of the provisional ID is just filled with a
> > > > > random
> > > > > + * value, try to match using DCR info.
> > > > > + */
> > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > +
> > > > > + /* First try to match by manufacturer/part ID. */
> > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > + if ((id->match_flags &
> > > > > I3C_MATCH_MANUF_AND_PART) !=
> > > > > + I3C_MATCH_MANUF_AND_PART)
> > > > > + continue;
> > > > > +
> > > > > + if (manuf != id->manuf_id || part !=
> > > > > id->part_id)
> > > > > + continue;
> > > > > +
> > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > + ext_info != id->extra_info)
> > > > > + continue;
> > > > > +
> > > > > + return id;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + /* Fallback to DCR match. */
> > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > + id->dcr == i3cdev->info.dcr)
> > > > > + return id;
> > > > > + }
> > > > > +
> > > > > + return NULL;
> > > > > +}
> > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > > >
> > > > I just picked one random export here, but it feels like you are
> > > > exporting a bunch of symbols you don't need to. Why would something
> > > > outside of the i3c "core" need to call this function?
> > >
> > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > if the driver is supporting different variants of the device, it may
> > > want to know which one is being probed.
> > >
> > > I considered retrieving this information in the core just before probing
> > > the driver and passing it to the ->probe() function, but it means
> > > having an extra i3c_device_match_id() call for everyone even those who
> > > don't care about the device_id information, so I thought exporting this
> > > function was a good alternative (device drivers can use it when they
> > > actually need to retrieve the device_id).
> > >
> > > Anyway, that's something I can change if you think passing the
> > > i3c_device_id to the ->probe() method is preferable.
> > >
> > > > Have you looked
> > > > to see if you really have callers for everything you are exporting?
> > >
> > > Yes, I tried to only export functions that I think will be needed by
> > > I3C device drivers and I3C master drivers. Note that I didn't post the
> > > dummy device driver I developed to test the framework (partly because
> > > this is
> >
> > Sorry, I hit the send button before finishing my sentence :-).
> >
> > "
> > Note that I didn't post the dummy device driver [1] I developed to test
> > the framework (partly because the quality of the code does not meet
> > mainline standards and I was ashamed of posting it publicly :-)), but
> > this driver is using some of the exported functions.
> > "
>
> We don't export functions that has no in-kernel users :)
But then, I can't export device driver related functions, because
there's no official device driver yet :-). So what should I do?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
On Wed, 20 Dec 2017 12:06:45 -0600 Rob Herring wrote: > On Sat, Dec 16, 2017 at 07:35:37PM +0100, Boris Brezillon wrote: > > On Sat, 16 Dec 2017 11:20:40 -0600 > > Rob Herring wrote: > > > > > On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote: > > > > A new I3C subsystem has been added and a generic description has been > > > > created to represent the I3C bus and the devices connected on it. > > > > > > > > Document this generic representation. > > [...] > > > > So please define the node > > > name to be "i3c-controller". That's more inline with other node names > > > than i3c-master that you used below. > > > > Hm, not sure i3c-controller is appropriate though, because you can have > > slave controllers. Maybe i3c-host, but I'd prefer to keep the term > > master since it's employed everywhere in the spec. I can also be > > i3c-master-controller if you prefer. > > Okay, i3c-master is fine. Just make it explicit. Okay. > > > > > +I3C devices > > > > +=== > > > > + > > > > +All I3C devices are supposed to support DAA (Dynamic Address > > > > Assignment), and > > > > +are thus discoverable. So, by default, I3C devices do not have to be > > > > described > > > > +in the device tree. > > > > +This being said, one might want to attach extra resources to these > > > > devices, > > > > +and those resources may have to be described in the device tree, which > > > > in turn > > > > +means we have to describe I3C devices. > > > > + > > > > +Another use case for describing an I3C device in the device tree is > > > > when this > > > > +I3C device has a static address and we want to assign it a specific > > > > dynamic > > > > +address before the DAA takes place (so that other devices on the bus > > > > can't > > > > +take this dynamic address). > > > > + > > > > +Required properties > > > > +--- > > > > +- i3c-pid: PID (Provisional ID). 64-bit property which is used to > > > > match a > > > > + device discovered during DAA with its device tree > > > > definition. The > > > > + PID is supposed to be unique on a given bus, which > > > > guarantees a 1:1 > > > > + match. This property becomes optional if a reg property is > > > > defined, > > > > + meaning that the device has a static address. > > > > > > What determines this number? > > > > Part of it is fixed (manufacturer and part id) and the last few bits > > represent the device instance on the bus (so you can have several > > identical devices on the same bus). The manufacturer and part ids > > should be statically assigned during production, instance id is usually > > configurable through extra pins that you drive high or low at reset > > time. > > Sounds like an I2C address at least for the pin strapping part... The address space of this instance-id is smaller (4bits) than the I2C one (7bits), and more importantly, the instance-id is not required to be unique, it's the aggregation of the vendor-id, part-id and instance-id that has to be unique. So, if you were thinking about using this id to uniquely identify the device on the bus it's not a good idea. > > > > > + > > > > +Optional properties > > > > +--- > > > > +- reg: static address. Only valid is the device has a static address. > > > > +- i3c-dynamic-address: dynamic address to be assigned to this device. > > > > This > > > > + property depends on the reg property. > > > > > > Perhaps "assigned-address" property would be appropriate. I'm not all > > > that familiar with it though. > > > > Again, the spec use the term "dynamic address" everywhere, and I'd like > > to stay as close as possible to the spec. > > I looked at assigned-addresses a bit more and that won't really fit > because it should be the same format as reg. So I think reg should > always be the PID as that is fixed and always present. Then the DAA > address is separate and can be the i3c-dynamic-address property. > > However, there's still part I don't understand... > > > > > + /* I3C device with a st
Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
Hi Rob,
On Tue, 26 Dec 2017 12:29:34 -0600
Rob Herring wrote:
> >> > > > +Optional properties
> >> > > > +---
> >> > > > +- reg: static address. Only valid is the device has a static
> >> > > > address.
> >> > > > +- i3c-dynamic-address: dynamic address to be assigned to this
> >> > > > device. This
> >> > > > + property depends on the reg property.
> >> > >
> >> > > Perhaps "assigned-address" property would be appropriate. I'm not all
> >> > > that familiar with it though.
> >> >
> >> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> >> > to stay as close as possible to the spec.
> >>
> >> I looked at assigned-addresses a bit more and that won't really fit
> >> because it should be the same format as reg. So I think reg should
> >> always be the PID as that is fixed and always present. Then the DAA
> >> address is separate and can be the i3c-dynamic-address property.
> >>
> >> However, there's still part I don't understand...
> >>
> >> > > > + /* I3C device with a static address. */
> >> > > > + thermal_sensor: sensor@68 {
> >> > > > + reg = <0x68>;
> >> > > > + i3c-dynamic-address = <0xa>;
> >>
> >> I'm confused as to how/why you have both reg and dynamic address?
> >
> > Some I3C devices have an I2C address (also called static or legacy
> > address in a few places). The static/I2C/legacy address is used until
> > the I3C device is assigned a dynamic address by the master. The whole
> > point of specifying both an I2C address (through the reg property) and
> > a dynamic address (through the i3c-dynamic-address) is to tell the
> > controller that a specific dynamic address should be assigned to this
> > device using the SETSADA (Set Dynamic Address from Static Address)
> > command before a DAA (Dynamic Address Assignment) procedure is started.
> > This way, the device will not participate to the DAA (because it
> > already has a valid DA) and the dynamic address can't be assigned to
> > a different device (which is one of the problem with the automatic DAA
> > procedure).
>
> Okay, think I got it now.
>
> I think we should extend "reg" to have either I2C address, I3C PID, or
> both (in a defined order). I'm assuming you can always distinguish a
> static I2C address and an I3C PID just by upper bits all being 0s for
> I2C addresses. Maybe both is not needed? This means we'd have to allow
> 64-bit I2C addresses (#address-cells=2), but that should be easily
> fixed if that causes problems in the kernel.
>
> So i3c-pid would go away and i3c-dynamic-address stays.
Hm, actually I'm not sure this is a good idea. Sounds like we're
abusing the purpose of reg here. For busses, reg is supposed to encode
the id of the device on the bus that is used to communicate with this
device (CS line for SPI, I2C address for I2C devs, ...). With I3C, the
PID is just a way to uniquely identify a device, but is not used during
communications (we either use the static/I2C address or the dynamic
address assigned by the master).
If your concern is just about I3C dev naming convention, maybe we
could have something like:
i3c-master@ {
...
i2cdev@xx {
reg = ;
i3c-lvr = ;
...
};
...
i3cdev-[@zz] {
i3c-pid = ;
/*
* reg only defined if the device has a static
* address.
*/
[reg = ;]
/*
* i3c-dynamic-address only defined if a
* specific dynamic address is requested.
*/
[i3c-dynamic-address = ;]
};
};
With this approach we have a way to quickly identify i3c devices by
their pid when looking at their names (with the - suffix), and
we keep reg for static/i2c addresses only.
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
Hi Rob,
On Sun, 7 Jan 2018 15:14:25 +0100
Boris Brezillon wrote:
> Hi Rob,
>
> On Tue, 26 Dec 2017 12:29:34 -0600
> Rob Herring wrote:
>
> > >> > > > +Optional properties
> > >> > > > +---
> > >> > > > +- reg: static address. Only valid is the device has a static
> > >> > > > address.
> > >> > > > +- i3c-dynamic-address: dynamic address to be assigned to this
> > >> > > > device. This
> > >> > > > + property depends on the reg property.
> > >> > >
> > >> > > Perhaps "assigned-address" property would be appropriate. I'm not all
> > >> > > that familiar with it though.
> > >> >
> > >> > Again, the spec use the term "dynamic address" everywhere, and I'd like
> > >> > to stay as close as possible to the spec.
> > >>
> > >> I looked at assigned-addresses a bit more and that won't really fit
> > >> because it should be the same format as reg. So I think reg should
> > >> always be the PID as that is fixed and always present. Then the DAA
> > >> address is separate and can be the i3c-dynamic-address property.
> > >>
> > >> However, there's still part I don't understand...
> > >>
> > >> > > > + /* I3C device with a static address. */
> > >> > > > + thermal_sensor: sensor@68 {
> > >> > > > + reg = <0x68>;
> > >> > > > + i3c-dynamic-address = <0xa>;
> > >>
> > >> I'm confused as to how/why you have both reg and dynamic address?
> > >
> > > Some I3C devices have an I2C address (also called static or legacy
> > > address in a few places). The static/I2C/legacy address is used until
> > > the I3C device is assigned a dynamic address by the master. The whole
> > > point of specifying both an I2C address (through the reg property) and
> > > a dynamic address (through the i3c-dynamic-address) is to tell the
> > > controller that a specific dynamic address should be assigned to this
> > > device using the SETSADA (Set Dynamic Address from Static Address)
> > > command before a DAA (Dynamic Address Assignment) procedure is started.
> > > This way, the device will not participate to the DAA (because it
> > > already has a valid DA) and the dynamic address can't be assigned to
> > > a different device (which is one of the problem with the automatic DAA
> > > procedure).
> >
> > Okay, think I got it now.
> >
> > I think we should extend "reg" to have either I2C address, I3C PID, or
> > both (in a defined order). I'm assuming you can always distinguish a
> > static I2C address and an I3C PID just by upper bits all being 0s for
> > I2C addresses. Maybe both is not needed? This means we'd have to allow
> > 64-bit I2C addresses (#address-cells=2), but that should be easily
> > fixed if that causes problems in the kernel.
> >
> > So i3c-pid would go away and i3c-dynamic-address stays.
>
> Hm, actually I'm not sure this is a good idea. Sounds like we're
> abusing the purpose of reg here. For busses, reg is supposed to encode
> the id of the device on the bus that is used to communicate with this
> device (CS line for SPI, I2C address for I2C devs, ...). With I3C, the
> PID is just a way to uniquely identify a device, but is not used during
> communications (we either use the static/I2C address or the dynamic
> address assigned by the master).
>
> If your concern is just about I3C dev naming convention, maybe we
> could have something like:
>
> i3c-master@ {
> ...
> i2cdev@xx {
> reg = ;
> i3c-lvr = ;
> ...
> };
> ...
>
> i3cdev-[@zz] {
> i3c-pid = ;
> /*
>* reg only defined if the device has a static
>* address.
>*/
> [reg = ;]
> /*
>* i3c-dynamic-address only defined if a
>* specific dynamic address is requested.
>*/
> [i3c-dynamic-address = ;]
> };
> };
>
> With this approach we have a way to quickly identify i3c devices by
> their pid when looking at their names (with the - suffix), and
> we keep reg for static/i2c addresses only.
Did you have time to read this email (AKA ping)?
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Hi Greg,
On Tue, 19 Dec 2017 10:36:43 +0100
Greg Kroah-Hartman wrote:
> On Tue, Dec 19, 2017 at 10:28:58AM +0100, Boris Brezillon wrote:
> > On Tue, 19 Dec 2017 10:21:19 +0100
> > Greg Kroah-Hartman wrote:
> >
> > > On Tue, Dec 19, 2017 at 10:13:36AM +0100, Boris Brezillon wrote:
> > > > On Tue, 19 Dec 2017 10:09:00 +0100
> > > > Boris Brezillon wrote:
> > > >
> > > > > On Tue, 19 Dec 2017 09:52:50 +0100
> > > > > Greg Kroah-Hartman wrote:
> > > > >
> > > > > > On Thu, Dec 14, 2017 at 04:16:05PM +0100, Boris Brezillon wrote:
> > > > > >
> > > > > > > +/**
> > > > > > > + * i3c_device_match_id() - Find the I3C device ID entry matching
> > > > > > > an I3C dev
> > > > > > > + * @i3cdev: the I3C device we're searching a match for
> > > > > > > + * @id_table: the I3C device ID table
> > > > > > > + *
> > > > > > > + * Return: a pointer to the first entry matching @i3cdev, or
> > > > > > > NULL if there's
> > > > > > > + * no match.
> > > > > > > + */
> > > > > > > +const struct i3c_device_id *
> > > > > > > +i3c_device_match_id(struct i3c_device *i3cdev,
> > > > > > > + const struct i3c_device_id *id_table)
> > > > > > > +{
> > > > > > > + const struct i3c_device_id *id;
> > > > > > > +
> > > > > > > + /*
> > > > > > > + * The lower 32bits of the provisional ID is just filled with a
> > > > > > > random
> > > > > > > + * value, try to match using DCR info.
> > > > > > > + */
> > > > > > > + if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
> > > > > > > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > > > > > > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > > > > > > + u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > > > > > > +
> > > > > > > + /* First try to match by manufacturer/part ID. */
> > > > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > + if ((id->match_flags &
> > > > > > > I3C_MATCH_MANUF_AND_PART) !=
> > > > > > > + I3C_MATCH_MANUF_AND_PART)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + if (manuf != id->manuf_id || part !=
> > > > > > > id->part_id)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
> > > > > > > + ext_info != id->extra_info)
> > > > > > > + continue;
> > > > > > > +
> > > > > > > + return id;
> > > > > > > + }
> > > > > > > + }
> > > > > > > +
> > > > > > > + /* Fallback to DCR match. */
> > > > > > > + for (id = id_table; id->match_flags != 0; id++) {
> > > > > > > + if ((id->match_flags & I3C_MATCH_DCR) &&
> > > > > > > + id->dcr == i3cdev->info.dcr)
> > > > > > > + return id;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return NULL;
> > > > > > > +}
> > > > > > > +EXPORT_SYMBOL_GPL(i3c_device_match_id);
> > > > > >
> > > > > > I just picked one random export here, but it feels like you are
> > > > > > exporting a bunch of symbols you don't need to. Why would something
> > > > > > outside of the i3c "core" need to call this function?
> > > > >
> > > > > Because I'm not passing the i3c_device_id to the ->probe() method, and
> > > > > if the driver is supporting different variants of the device, it may
> > > > > want to know
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Hi Vitor,
On Fri, 23 Feb 2018 16:56:14 +
Vitor Soares wrote:
> Hi Boris,
>
> Às 3:16 PM de 12/14/2017, Boris Brezillon escreveu:
> > +
> > +enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
> > + u16 addr)
> > +{
> > + int status, bitpos = addr * 2;
> > +
> > + if (addr > I2C_MAX_ADDR)
> > + return I3C_ADDR_SLOT_RSVD;
> > +
> > + status = bus->addrslots[bitpos / BITS_PER_LONG];
> > + status >>= bitpos % BITS_PER_LONG;
> > +
> > + return status & I3C_ADDR_SLOT_STATUS_MASK;
> > +}
>
> I don't understand the size of addr. The I3C only allow 7-bit addresses.
>
> Is the addrslots used to store the addresses and its status?
No, slots are used for both I2C and I3C addresses, and an I2C address
can be 10-bits wide, hence the u16 type.
[...]
> > +/**
> > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
> > + * specific device
> > + *
> > + * @dev: device with which the transfers should be done
> > + * @xfers: array of transfers
> > + * @nxfers: number of transfers
> > + *
> > + * Initiate one or several private SDR transfers with @dev.
> > + *
> > + * This function can sleep and thus cannot be called in atomic context.
> > + *
> > + * Return: 0 in case of success, a negative error core otherwise.
> > + */
> > +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > +struct i3c_priv_xfer *xfers,
> > +int nxfers)
> > +{
> > + struct i3c_master_controller *master;
> > + int i, ret;
> > +
> > + master = i3c_device_get_master(dev);
> > + if (!master)
> > + return -EINVAL;
> > +
> > + i3c_bus_normaluse_lock(master->bus);
> > + for (i = 0; i < nxfers; i++)
> > + xfers[i].addr = dev->info.dyn_addr;
> > +
> > + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> > + i3c_bus_normaluse_unlock(master->bus);
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
>
> The controller should know the speed mode for each xfer. The SDR0 mode
> is used by default but if any device have read or write speed
> limitations the controller can use SDRx.
I might be wrong, but that's not my understanding of the spec. A device
can express a speed limitation for SDR priv transfers, but this
limitation applies to all SDR transfers.
The speed R/W speed limitation is encoded in the device object, so, if
the controller has to configure that on a per-transfer basis, one
solution would be to pass the device to the ->priv_xfers().
>
> This could be also applied to i2c transfers.
Not really. The max SCL frequency is something that applies to the
whole bus, because all I2C devices have to decode the address when
messages are sent on the bus to determine if they should ignore or
process the message.
> > +#endif /* I3C_INTERNAL_H */
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > new file mode 100644
> > index ..1c85abac08d5
> > --- /dev/null
> > +++ b/drivers/i3c/master.c
> > @@ -0,0 +1,1433 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon
> > + */
> > +
> > +#include
> > +
> > +#include "internals.h"
> > +
> > +/**
> > + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> > + * procedure
> > + * @master: master used to send frames on the bus
> > + *
> > + * Send a ENTDAA CCC command to start a DAA procedure.
> > + *
> > + * Note that this function only sends the ENTDAA CCC command, all the logic
> > + * behind dynamic address assignment has to be handled in the I3C master
> > + * driver.
> > + *
> > + * This function must be called with the bus lock held in write mode.
> > + *
> > + * Return: 0 in case of success, a negative error code otherwise.
> > + */
> > +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> > +{
> > + struct i3c_ccc_cmd_dest dest = { };
> > + struct i3c_ccc_cmd cmd = { };
> > + int ret;
> > +
> > + dest.addr = I3C_BROADCAST_ADDR;
> > + cmd.dests = &dest;
> > + cmd.ndests = 1;
> > + cmd.rnw = false;
> > + cmd.id = I3C_CCC_ENTDAA;
> > +
> > + ret = i3c_master_send_ccc_cmd_locked(maste
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Fri, 23 Feb 2018 16:56:14 +
Vitor Soares wrote:
> > +
> > +/**
> > + * struct i3c_ccc_setda - payload passed to ENTTM CCC
> > + *
> > + * @mode: one of the &enum i3c_ccc_test_mode modes
> > + *
> > + * Information passed to the ENTTM CCC to instruct an I3C device to enter a
> > + * specific test mode.
Oops, copy&paste error. I'll fix the kernel-doc header.
> > + */
> > +struct i3c_ccc_setda {
> > + u8 addr;
> > +} __packed;
>
> what do you mean with struct? Maybe setdasa? if so, what is the addr?
It's the payload passed to SETDASA and SETNEWDA, hence the generic
_setda suffix. addr is the new dynamic address assigned to the
device.
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Hi Vitor,
On Mon, 26 Feb 2018 18:58:15 +
Vitor Soares wrote:
> >>> +/**
> >>> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to
> >>> a
> >>> + * specific device
> >>> + *
> >>> + * @dev: device with which the transfers should be done
> >>> + * @xfers: array of transfers
> >>> + * @nxfers: number of transfers
> >>> + *
> >>> + * Initiate one or several private SDR transfers with @dev.
> >>> + *
> >>> + * This function can sleep and thus cannot be called in atomic context.
> >>> + *
> >>> + * Return: 0 in case of success, a negative error core otherwise.
> >>> + */
> >>> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> >>> + struct i3c_priv_xfer *xfers,
> >>> + int nxfers)
> >>> +{
> >>> + struct i3c_master_controller *master;
> >>> + int i, ret;
> >>> +
> >>> + master = i3c_device_get_master(dev);
> >>> + if (!master)
> >>> + return -EINVAL;
> >>> +
> >>> + i3c_bus_normaluse_lock(master->bus);
> >>> + for (i = 0; i < nxfers; i++)
> >>> + xfers[i].addr = dev->info.dyn_addr;
> >>> +
> >>> + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> >>> + i3c_bus_normaluse_unlock(master->bus);
> >>> +
> >>> + return ret;
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
> >> The controller should know the speed mode for each xfer. The SDR0 mode
> >> is used by default but if any device have read or write speed
> >> limitations the controller can use SDRx.
> > I might be wrong, but that's not my understanding of the spec. A device
> > can express a speed limitation for SDR priv transfers, but this
> > limitation applies to all SDR transfers.
> >
> > The speed R/W speed limitation is encoded in the device object, so, if
> > the controller has to configure that on a per-transfer basis, one
> > solution would be to pass the device to the ->priv_xfers().
> The speed R/W limitation is only for private transfers. Also the device can
> have
> a limitation to write and not for read data.
> This information is obtained with the command GETMXDS which returns the
> Maximum
> Sustained Data Rate for non-CCC messages.
And that's exactly what I expose in i3c_device_info, which is embedded
in i3c_device, so you should have all the information you need to
determine the speed in the controller driver if ->priv_xfer() is passed
the device attached to those transfers. Would that be okay if we pass an
i3c_device object to ->priv_xfers()?
> >
> >> This could be also applied to i2c transfers.
> > Not really. The max SCL frequency is something that applies to the
> > whole bus, because all I2C devices have to decode the address when
> > messages are sent on the bus to determine if they should ignore or
> > process the message.
> >
> >>> +#endif /* I3C_INTERNAL_H */
> >>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> >>> new file mode 100644
> >>> index ..1c85abac08d5
> >>> --- /dev/null
> >>> +++ b/drivers/i3c/master.c
> >>> @@ -0,0 +1,1433 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * Copyright (C) 2017 Cadence Design Systems Inc.
> >>> + *
> >>> + * Author: Boris Brezillon
> >>> + */
> >>> +
> >>> +#include
> >>> +
> >>> +#include "internals.h"
> >>> +
> >>> +/**
> >>> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> >>> + * procedure
> >>> + * @master: master used to send frames on the bus
> >>> + *
> >>> + * Send a ENTDAA CCC command to start a DAA procedure.
> >>> + *
> >>> + * Note that this function only sends the ENTDAA CCC command, all the
> >>> logic
> >>> + * behind dynamic address assignment has to be handled in the I3C master
> >>> + * driver.
> >>> + *
> >>> + * This function must be called with the bus lock held in write mode.
> >>> + *
> >>> + * Return: 0 in case of success, a negative error code otherwise.
> >>> + */
> >>> +int i3c_master_entda
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Mon, 26 Feb 2018 21:36:07 +0100 Boris Brezillon wrote: > > >>> + > > >>> +/** > > >>> + * struct i3c_master_controller_ops - I3C master methods > > >>> + * @bus_init: hook responsible for the I3C bus initialization. This > > >>> + * initialization should follow the steps described in the > > >>> I3C > > >>> + * specification. This hook is called with the bus lock held > > >>> in > > >>> + * write mode, which means all _locked() helpers can safely > > >>> be > > >>> + * called from there > > >>> + * @bus_cleanup: cleanup everything done in > > >>> + * &i3c_master_controller_ops->bus_init(). This function > > >>> is > > >>> + * optional and should only be implemented if > > >>> + * &i3c_master_controller_ops->bus_init() attached > > >>> private data > > >>> + * to I3C/I2C devices. This hook is called with the bus > > >>> lock > > >>> + * held in write mode, which means all _locked() helpers > > >>> can > > >>> + * safely be called from there > > >>> + * @supports_ccc_cmd: should return true if the CCC command is > > >>> supported, false > > >>> + * otherwise > > >>> + * @send_ccc_cmd: send a CCC command > > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is more > > >>> than one > > >>> + *command, they should ideally be sent in the same HDR > > >>> + *transaction > > >>> + * @priv_xfers: do one or several private I3C SDR transfers > > >>> + * @i2c_xfers: do one or several I2C transfers > > >>> + * @request_ibi: attach an IBI handler to an I3C device. This implies > > >>> defining > > >>> + * an IBI handler and the constraints of the IBI (maximum > > >>> payload > > >>> + * length and number of pre-allocated slots). > > >>> + * Some controllers support less IBI-capable devices than > > >>> regular > > >>> + * devices, so this method might return -%EBUSY if > > >>> there's no > > >>> + * more space for an extra IBI registration > > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). > > >>> The IBI > > >>> + * should have been disabled with ->disable_irq() prior to > > >>> that > > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been > > >>> called > > >>> + * prior to ->enable_ibi(). The controller should first > > >>> enable > > >>> + * the IBI on the controller end (for example, unmask the > > >>> hardware > > >>> + * IRQ) and then send the ENEC CCC command (with the IBI > > >>> flag set) > > >>> + * to the I3C device > > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command with > > >>> the IBI > > >>> + * flag set and then deactivate the hardware IRQ on the > > >>> + * controller end > > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI > > >>> has been > > >>> + * processed by its handler. The IBI slot should be > > >>> put back > > >>> + * in the IBI slot pool so that the controller can > > >>> re-use it > > >>> + * for a future IBI > > >>> + * > > >>> + * One of the most important hooks in these ops is > > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive > > >>> list of > > >>> + * things that should be done in > > >>> &i3c_master_controller_ops->bus_init(): > > >>> + * > > >>> + * 1) call i3c_master_set_info() with all information describing the > > >>> master > > >>> + * 2) ask all slaves to drop their dynamic address by sending the > > >>> RSTDAA CCC > > >>> + *with i3c_master_rs
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Mon, 26 Feb 2018 21:40:32 +0100 Boris Brezillon wrote: > On Mon, 26 Feb 2018 21:36:07 +0100 > Boris Brezillon wrote: > > > > >>> + > > > >>> +/** > > > >>> + * struct i3c_master_controller_ops - I3C master methods > > > >>> + * @bus_init: hook responsible for the I3C bus initialization. This > > > >>> + * initialization should follow the steps described in the > > > >>> I3C > > > >>> + * specification. This hook is called with the bus lock held > > > >>> in > > > >>> + * write mode, which means all _locked() helpers can safely > > > >>> be > > > >>> + * called from there > > > >>> + * @bus_cleanup: cleanup everything done in > > > >>> + *&i3c_master_controller_ops->bus_init(). This function > > > >>> is > > > >>> + *optional and should only be implemented if > > > >>> + *&i3c_master_controller_ops->bus_init() attached > > > >>> private data > > > >>> + *to I3C/I2C devices. This hook is called with the bus > > > >>> lock > > > >>> + *held in write mode, which means all _locked() helpers > > > >>> can > > > >>> + *safely be called from there > > > >>> + * @supports_ccc_cmd: should return true if the CCC command is > > > >>> supported, false > > > >>> + * otherwise > > > >>> + * @send_ccc_cmd: send a CCC command > > > >>> + * @send_hdr_cmds: send one or several HDR commands. If there is > > > >>> more than one > > > >>> + * command, they should ideally be sent in the same HDR > > > >>> + * transaction > > > >>> + * @priv_xfers: do one or several private I3C SDR transfers > > > >>> + * @i2c_xfers: do one or several I2C transfers > > > >>> + * @request_ibi: attach an IBI handler to an I3C device. This > > > >>> implies defining > > > >>> + *an IBI handler and the constraints of the IBI (maximum > > > >>> payload > > > >>> + *length and number of pre-allocated slots). > > > >>> + *Some controllers support less IBI-capable devices than > > > >>> regular > > > >>> + *devices, so this method might return -%EBUSY if > > > >>> there's no > > > >>> + *more space for an extra IBI registration > > > >>> + * @free_ibi: free an IBI previously requested with ->request_ibi(). > > > >>> The IBI > > > >>> + * should have been disabled with ->disable_irq() prior to > > > >>> that > > > >>> + * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has > > > >>> been called > > > >>> + * prior to ->enable_ibi(). The controller should first > > > >>> enable > > > >>> + * the IBI on the controller end (for example, unmask the > > > >>> hardware > > > >>> + * IRQ) and then send the ENEC CCC command (with the IBI > > > >>> flag set) > > > >>> + * to the I3C device > > > >>> + * @disable_ibi: disable an IBI. First send the DISEC CCC command > > > >>> with the IBI > > > >>> + *flag set and then deactivate the hardware IRQ on the > > > >>> + *controller end > > > >>> + * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI > > > >>> has been > > > >>> + * processed by its handler. The IBI slot should be > > > >>> put back > > > >>> + * in the IBI slot pool so that the controller can > > > >>> re-use it > > > >>> + * for a future IBI > > > >>> + * > > > >>> + * One of the most important hooks in these ops is > > > >>> + * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive > > > >>> list of > > > >>> + * things that should be done in > > > &g
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
t;>>> + u8 addr;
> >>>>> + int ndatawords;
> >>>>> + union {
> >>>>> + u16 *in;
> >>>>> + const u16 *out;
> >>>>> + } data;
> >>>>> +};
> >> Please mention that the @code is what will define if the transfer is read
> >> or write.
> > Well, I think it's pretty clear in the definition you'll find in the
> > ccc.h file, but I can add a comment here too if you like.
>
> I don't find it in ccc.h file. Anyway is not good to put this definition there
> because is not related.
Oops! Sorry, I mixed the CCC and HDR stuff. It's indeed not clear that
@code defines the transfer direction. I'll clarify this aspect.
> >> I think the DAA process should be more generic, right now is only made
> >> through
> >> the ENTDAA command with (cmd.ndests = 1).
> >> I mean, shouldn't this be made by the core? First doing DAA for the devices
> >> declared and them try do discover the rest of devices on the bus.
> > Can you detail a bit more? If the only part you're complaining about is
> > pre-assignment of dynamic addresses with SETDASA when a device is
> > declared in the DT with a reg and dynamic-address property, then yes, I
> > think I can provide an helper for that. But this helper would still have
> > to be called from the master controller driver (from ->bus_init() or
> > after a Hot-Join).
> >
> > Now, if the question is, is there a way we can automate things even more
> > and completely implement DAA from the core? I doubt it, because the way
> > the core will trigger DAA, expose discovered devices or allow you to
> > declare manually assigned addresses is likely to be
> > controller-dependent.
>
> Please refer to figure 90 of public specification. As you can see the DAA
> process should start with SETDASA command.
Only if devices with a static address needs to be assigned a specific
dynamic address. At least, that's my understanding. Are there plans to
create devices that would only reply to SETDASA commands but ignore
ENTDAA ones?
>
> With the current flow of this patch the DAA process is limited to ENTDAA
> command
> only.
As a first step, yes. But again, nothing is set in stone, and the
SETDASA step can be added afterwards. As said above, I fail to see a
use case where it's really required (note that I said required, not
useful).
>
> > When I designed the framework I took the decision to base my work on the
> > spec rather than focusing on the I3C master controller I had to support
> > (Cadence). This is the reason I decided to keep the interface as simple
> > as possible at the risk of encouraging code-duplication (at first)
> > rather than coming up with an interface that is designed with a single
> > controller in mind and having to break things every time a new
> > controller comes out.
> >
> > Thank you for you comments, but I'd like to know if some of my design
> > choices are blocking you to support your controller. What I've seen so
> > far is a collection of things that might be relevant to fix (though
> > most of them are subject to interpretation and/or a matter of taste),
> > but nothing that should really block you.
> >
> > Can you clarify that, and maybe come back with a list of things that you
> > think are preventing you from properly supporting the Synopsys
> > controller?
> >
> > Thanks,
> >
> > Boris
>
> As you can check from my comments my concerns are about the i3c specification
> without the controller in mind.
Okay, then we're on the same page.
Regards,
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Hi Przemek, On Tue, 27 Feb 2018 16:43:27 + Przemyslaw Sroka wrote: > > > > >> Either important is the SETDASA for declared I3C devices. So the DAA > > >> process should start by send an SETDASA and them ENTDAA CCC > > command. > > > My understanding was that SETDASA was not mandatory, and was only > > > useful when one wants to assign a specific dynamic address to a slave > > > that has a static address (which is again not mandatory). > > > I've tested it, and even devices with a static address participate to > > > the DAA procedure if they've not been assigned a dynamic address yet, > > > so I don't see the need for this SETDASA step if you don't need to > > > assign a particular dynamic address to the device. > > > > > > Could you tell me why you think SETDASA is required? > > > > Yes, you are right... But in my opinion it is required as it does part of > > DAA > > process. > > 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. 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. -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
Hi Przemek, On Tue, 27 Feb 2018 17:06:37 + Przemyslaw Sroka wrote: > > > > > > > > Could you tell me why you think SETDASA is required? > > > > > > Yes, you are right... But in my opinion it is required as it does part > > > of DAA process. > > > > 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). > > Below are 2 examples on how DAA can be executed: > 1st: > A1) SETDASA to devices with SA I'm not even sure all devices with a static address needs to be assigned a dynamic address with SETDASA (actually, I'm almost sure it's not the case, since, according to section "5.1.9.3 CCC Command Definitions" of the spec, all I3C slaves have to support ENTDAA). To me, it looks like you'd want to do that only is you really need to reserve a specific dynamic address and prevent the DAA step from assigning it to another device. > B1) DAA to remaining devices > C1) GET BCR/DCR/PID to devices that initially had SA > NOTES: C1 is optional and order of B1 and C1 can be changed While that's true in principle, in Linux we'll always retrieve BCR/DCR/PID (and more, like MAXDS), no matter how the device obtained its dynamic address. > > 2nd: > A2) DAA to all devices > NOTES: no need for any follow up steps as all information is collected during > DAA As said above, that's not exactly how the Linux implementation works. Right now I'm ignoring the information retrieved during DAA and forcing a GETPID/GETBCR/GETDCR for every discovered device. This approach is generating a bit more traffic on the bus, but it also makes the implementation more generic, because we have a single function to add an I3C device, no matter how it's been assigned a dynamic address. > > As we can see 2nd approach is more generic and do not see any reason to add > special handling for SETDASA unless there is any reasonable reason to do > otherwise. I agree on one thing: as long as you don't have to reserve a specific dynamic address, SETDASA is not required. At least, that's my understanding. Regards, Boris -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
On Tue, 27 Feb 2018 20:24:43 + Przemyslaw Sroka 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/47] arch-removal: device drivers
Hi Arnd, On Wed, 14 Mar 2018 16:35:13 +0100 Arnd Bergmann wrote: > Hi driver maintainers, > > I just posted one series with the removal of eight architectures, > see https://lkml.org/lkml/2018/3/14/505 for details, or > https://lwn.net/Articles/748074/ for more background. > > These are the device drivers that go along with them. I have already > picked up the drivers for arch/metag/ into my tree, they were reviewed > earlier. > > Please let me know if you have any concerns with the patch, or if you > prefer to pick up the patches in your respective trees. I created > the patches with 'git format-patch -D', so they will not apply without > manually removing those files. > > For anything else, I'd keep the removal patches in my asm-generic tree > and will send a pull request for 4.17 along with the actual arch removal. > >Arnd > > Arnd Bergmann > edac: remove tile driver > net: tile: remove ethernet drivers > net: adi: remove blackfin ethernet drivers > net: 8390: remove m32r specific bits > net: remove cris etrax ethernet driver > net: smsc: remove m32r specific smc91x configuration > raid: remove tile specific raid6 implementation > rtc: remove tile driver > rtc: remove bfin driver > char: remove obsolete ds1302 rtc driver > char: remove tile-srom.c > char: remove blackfin OTP driver > pcmcia: remove m32r drivers > pcmcia: remove blackfin driver > ASoC: remove blackfin drivers > video/logo: remove obsolete logo files > fbdev: remove blackfin drivers > fbdev: s1d13xxxfb: remove m32r specific hacks > crypto: remove blackfin CRC driver > media: platform: remove blackfin capture driver > media: platform: remove m32r specific arv driver > cpufreq: remove blackfin driver > cpufreq: remove cris specific drivers > gpio: remove etraxfs driver > pinctrl: remove adi2/blackfin drivers > ata: remove bf54x driver > input: keyboard: remove bf54x driver > input: misc: remove blackfin rotary driver > mmc: remove bfin_sdh driver > can: remove bfin_can driver > watchdog: remove bfin_wdt driver > mtd: maps: remove bfin-async-flash driver > mtd: nand: remove bf5xx_nand driver If you don't mind, I'd like to take the mtd patches through the MTD tree. As you've probably noticed, nand code has been moved around and it's easier for me to carry those 2 simple changes in my tree than creating an immutable branch. Let me know if this is a problem. Regards, Boris -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/11] docs: driver-api: Add I3C documentation
From: Boris Brezillon
Add the I3C documentation describing the protocol, the master driver API
and the device driver API.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
Documentation/driver-api/i3c/conf.py | 10 +
Documentation/driver-api/i3c/device-driver-api.rst | 7 +
Documentation/driver-api/i3c/index.rst | 9 +
Documentation/driver-api/i3c/master-driver-api.rst | 8 +
Documentation/driver-api/i3c/protocol.rst | 201 +
Documentation/driver-api/index.rst | 1 +
6 files changed, 236 insertions(+)
create mode 100644 Documentation/driver-api/i3c/conf.py
create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/index.rst
create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/protocol.rst
diff --git a/Documentation/driver-api/i3c/conf.py
b/Documentation/driver-api/i3c/conf.py
new file mode 100644
index ..5a20832d59a7
--- /dev/null
+++ b/Documentation/driver-api/i3c/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux I3C Subsystem"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'i3c.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst
b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index ..63c843f148a6
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,7 @@
+=
+I3C device driver API
+=
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst
b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index ..9c439220439d
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,9 @@
+=
+I3C subsystem
+=
+
+.. toctree::
+
+ protocol
+ device-driver-api
+ master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst
b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index ..017e7711cdf7
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,8 @@
+
+I3C master controller driver API
+
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst
b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index ..9c704d596ae3
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,201 @@
+
+I3C protocol
+
+
+Disclaimer
+==
+
+This chapter will focus on aspects that matter to software developers. For
+everything hardware related (like how things are transmitted on the bus, how
+collisions are prevented, ...) please have a look at the I3C specification.
+
+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 (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+===
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+ transactions or deciding who is allowed to talk on the bus (slave generated
+ events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+ slave on the bus. The device can still send events to the master on
+ its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to the
[PATCH v3 10/11] gpio: Add a driver for Cadence I3C GPIO expander
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon
---
drivers/gpio/Kconfig | 11 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-cdns-i3c.c | 380 +++
3 files changed, 392 insertions(+)
create mode 100644 drivers/gpio/gpio-cdns-i3c.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8dbb2280538d..87b7083179ff 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -862,6 +862,17 @@ config GPIO_TS4900
endmenu
+menu "I3C GPIO expanders"
+ depends on I3C
+
+config GPIO_CDNS_I3C
+ tristate "Cadence I3C GPIO expander"
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to enabled the driver for Cadence I3C GPIO expander.
+
+endmenu
+
menu "MFD GPIO expanders"
config GPIO_ADP5520
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index cccb0d40846c..22a7151fc565 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
+obj-$(CONFIG_GPIO_CDNS_I3C)+= gpio-cdns-i3c.o
obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
diff --git a/drivers/gpio/gpio-cdns-i3c.c b/drivers/gpio/gpio-cdns-i3c.c
new file mode 100644
index ..5a75891b47fe
--- /dev/null
+++ b/drivers/gpio/gpio-cdns-i3c.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon
+ */
+
+#include
+#include
+#include
+
+#define OVR0x0
+#define IVR0x1
+#define DIR_MODE 0x2
+#define IMR0x3
+#define ISR0x4
+#define ITR(x) (0x5 + (x))
+
+struct cdns_i3c_gpio {
+ struct gpio_chip gpioc;
+ struct irq_chip irqc;
+ struct i3c_device *i3cdev;
+ struct mutex irq_lock;
+ u8 dir;
+ u8 ovr;
+ u8 imr;
+ u8 itr[3];
+};
+
+static struct cdns_i3c_gpio *gpioc_to_cdns_gpioc(struct gpio_chip *gpioc)
+{
+ return container_of(gpioc, struct cdns_i3c_gpio, gpioc);
+}
+
+static int cdns_i3c_gpio_read_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 *val)
+{
+ struct i3c_priv_xfer xfers[] = {
+ {
+ .len = sizeof(reg),
+ .data.out = ®,
+ },
+ {
+ .rnw = true,
+ .len = sizeof(*val),
+ .data.in = val,
+ },
+ };
+
+ return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+}
+
+static int cdns_i3c_gpio_write_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 val)
+{
+ struct i3c_priv_xfer xfers[] = {
+ {
+ .len = sizeof(reg),
+ .data.out = ®,
+ },
+ {
+ .len = sizeof(val),
+ .data.out = &val,
+ },
+ };
+
+ return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+}
+
+static int cdns_i3c_gpio_get_direction(struct gpio_chip *g, unsigned offset)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+
+ return gpioc->dir & BIT(offset);
+}
+
+static void cdns_i3c_gpio_set_multiple(struct gpio_chip *g,
+ unsigned long *mask,
+ unsigned long *bits)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+ u8 newovr;
+ int ret;
+
+ newovr = (gpioc->ovr & ~(*mask)) | (*bits & *mask);
+ if (newovr == gpioc->ovr)
+ return;
+
+ ret = cdns_i3c_gpio_write_reg(gpioc, OVR, newovr);
+ if (!ret)
+ gpioc->ovr = newovr;
+}
+
+static void cdns_i3c_gpio_set(struct gpio_chip *g, unsigned offset, int value)
+{
+ unsigned long mask = BIT(offset), bits = value ? BIT(offset) : 0;
+
+ cdns_i3c_gpio_set_multiple(g, &mask, &bits);
+}
+
+static int cdns_i3c_gpio_set_dir(struct cdns_i3c_gpio *gpioc, unsigned pin,
+bool in)
+{
+ u8 newdir;
+ int ret;
+
+ newdir = gpioc->dir;
+ if (in)
+ newdir |= BIT(pin);
+ else
+ newdir &= ~BIT(pin);
+
+ if (newdir == gpioc->dir)
+ return 0;
+
+ gpioc->dir = newdir;
+ ret = cdns_i3c_gpio_write_reg(gpioc, DIR_MODE, newdir);
+ if (!ret)
+ gpioc->dir = newdir;
+
+ r
[PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
Document the Cadence I3C gpio expander bindings.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
new file mode 100644
index ..634b1f268215
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
@@ -0,0 +1,38 @@
+* Cadence I3C GPIO expander
+
+The Cadence I3C GPIO expander provides 8 GPIOs controllable over I3C.
+This GPIOs can be configured in output or input mode and if they are in input
+mode they can generate IBIs (In Band Interrupts).
+
+Required properties for GPIO node:
+- reg : 3 cells encoding the I3C static address (none in our case) and the I3C
+ Provisional ID. See Documentation/devicetree/bindings/i3c/i3c.txt for
+ more details.
+ Should be <0x0 0x392 0x0>.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = active high
+ 1 = active low
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be 2. The first cell is the GPIO number.
+ The second cell bits[3:0] is used to specify trigger type and level flags:
+ 1 = low-to-high edge triggered.
+ 2 = high-to-low edge triggered.
+ 3 = triggered on both edges.
+ 4 = active high level-sensitive.
+ 8 = active low level-sensitive.
+
+Example:
+
+ i3c-master@xxx {
+ ...
+ i3c_gpio_expander: gpio@0,1c9,0 {
+ reg = <0 0x392 0x0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ ...
+ };
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/11] i3c: master: Add driver for Cadence IP
From: Boris Brezillon Add a driver for Cadence I3C master IP. Signed-off-by: Boris Brezillon --- Changes in v3: - Adjust to match I3C framework changes - Implement support the CMD RESPONSE QUEUE and IBI QUEUE added in the latest revision of Cadence master IP - Remove support for HDR modes Changes in v2: - Add basic IBI support. Note that the IP is not really reliable with regards to IBI because you can't extract IBI payloads as soon as you have more than one IBI waiting in the HW queue. This is something that will hopefully be addressed in future revisions of this IP - Add a simple xfer queueing mechanism to optimize message queuing. - Fix a few bugs - Add support for Hot Join --- drivers/i3c/master/Kconfig |5 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1648 ++ 3 files changed, 1654 insertions(+) create mode 100644 drivers/i3c/master/i3c-master-cdns.c diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig index e69de29bb2d1..56b9a18543b2 100644 --- a/drivers/i3c/master/Kconfig +++ b/drivers/i3c/master/Kconfig @@ -0,0 +1,5 @@ +config CDNS_I3C_MASTER + tristate "Cadence I3C master driver" + depends on I3C + help + Enable this driver if you want to support Cadence I3C master block. diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile index e69de29bb2d1..4c4304aa9534 100644 --- a/drivers/i3c/master/Makefile +++ b/drivers/i3c/master/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c new file mode 100644 index ..b37695e98a33 --- /dev/null +++ b/drivers/i3c/master/i3c-master-cdns.c @@ -0,0 +1,1648 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DEV_ID 0x0 +#define DEV_ID_I3C_MASTER 0x5034 + +#define CONF_STATUS0 0x4 +#define CONF_STATUS0_ECC_CHK BIT(28) +#define CONF_STATUS0_INTEG_CHK BIT(27) +#define CONF_STATUS0_CSR_DAP_CHK BIT(26) +#define CONF_STATUS0_TRANS_TOUT_CHKBIT(25) +#define CONF_STATUS0_PROT_FAULTS_CHK BIT(24) +#define CONF_STATUS0_GPO_NUM(x)(((x) & GENMASK(23, 16)) >> 16) +#define CONF_STATUS0_GPI_NUM(x)(((x) & GENMASK(15, 8)) >> 8) +#define CONF_STATUS0_SUPPORTS_DDR BIT(5) +#define CONF_STATUS0_SEC_MASTERBIT(4) +#define CONF_STATUS0_DEVS_NUM(x) ((x) & GENMASK(3, 0)) + +#define CONF_STATUS1 0x8 +#define CONF_STATUS1_IBI_HW_RES(x) x) & GENMASK(31, 28)) >> 28) + 1) +#define CONF_STATUS1_CMD_DEPTH(x) (4 << (((x) & GENMASK(27, 26)) >> 26)) +#define CONF_STATUS1_SLVDDR_RX_DEPTH(x)(8 << (((x) & GENMASK(25, 21)) >> 21)) +#define CONF_STATUS1_SLVDDR_TX_DEPTH(x)(8 << (((x) & GENMASK(20, 16)) >> 16)) +#define CONF_STATUS1_IBI_DEPTH(x) (2 << (((x) & GENMASK(12, 10)) >> 10)) +#define CONF_STATUS1_RX_DEPTH(x) (8 << (((x) & GENMASK(9, 5)) >> 5)) +#define CONF_STATUS1_TX_DEPTH(x) (8 << ((x) & GENMASK(4, 0))) + +#define REV_ID 0xc +#define REV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20) +#define REV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8) +#define REV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4) +#define REV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0)) + +#define CTRL 0x10 +#define CTRL_DEV_ENBIT(31) +#define CTRL_HALT_EN BIT(30) +#define CTRL_MCS BIT(29) +#define CTRL_MCS_ENBIT(28) +#define CTRL_HJ_DISEC BIT(8) +#define CTRL_MST_ACK BIT(7) +#define CTRL_HJ_ACKBIT(6) +#define CTRL_HJ_INIT BIT(5) +#define CTRL_MST_INIT BIT(4) +#define CTRL_AHDR_OPT BIT(3) +#define CTRL_PURE_BUS_MODE 0 +#define CTRL_MIXED_FAST_BUS_MODE 2 +#define CTRL_MIXED_SLOW_BUS_MODE 3 +#define CTRL_BUS_MODE_MASK GENMASK(1, 0) + +#define PRESCL_CTRL0 0x14 +#define PRESCL_CTRL0_I2C(x)((x) << 16) +#define PRESCL_CTRL0_I3C(x)(x) +#define PRESCL_CTRL0_MAX GENMASK(9, 0) + +#define PRESCL_CTRL1 0x18 +#define PRESCL_CTRL1_PP_LOW_MASK GENMASK(15, 8) +#define PRESCL_CTRL1_PP_LOW(x) (
[PATCH v3 09/11] dt-bindings: i3c: Document Cadence I3C master bindings
From: Boris Brezillon
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index ..f9e4af4ff1c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,45 @@
+Bindings for cadence I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-frequency
+- i3c-scl-frequency
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-frequency = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 00/11] Add the I3C subsystem
This patch series is a proposal for a new I3C [1] subsystem. 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 to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is still open to discussion. Please let me know if you think it's worth considering an asynchronous model here - the bus element is a separate object and is not implicitly described by the master (as done in I2C). The reason is that I want to be able to handle multiple master connected to the same bus and visible to Linux. In this situation, we should only have one instance of the device and not one per master, and sharing the bus object would be part of the solution to gracefully handle this case. I'm not sure if we will ever need to deal with multiple masters controlling the same bus and exposed under Linux, but separating the bus and master concept is pretty easy, hence the decision to do it now, just in case we need it some day. The other benefit of separating the bus and master concepts is that master devices appear under the bus directory in sysfs. - 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 new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different busses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features in this preliminary version: - support for HDR modes (has been removed because of lack of real users) - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Main changes between v2 and v3 are: - Reworked the DT bindings as suggested by Rob - Reworked the bus initialization step as suggested by Vitor - Added a driver for an I3C GPIO expander Main changes between the initial RFC and this v2 are: - Add a generic infrastructure to support IBIs. It's worth mentioning that I tried exposing IBIs as a regular IRQs, but after several attempts and a discussion with Mark Zyngier, it appeared that it was not really fitting in the Linux IRQ model (the fact that you have payload attached to IBIs, the fact that most of the time an IBI will generate a transfer on the bus which has to be done in an atomic context, ...) The counterpart of this decision is the latency induced by the workqueue approach, but since I don't have real use cases, I don't know if this can be a problem or not. - Add helpers to support Hot Join - Add support for IBIs and Hot Join in Cadence I3C master driver - Address several issues in how I was using the device model I'll finish on a good news: this week the MIPI alliance opened the I3C spec. So everyone can now review the patches (no need to be member of the MIPI I3C group). I'll let you find the link in the doc, this way maybe I'll have reviews on the doc itself :-). Thanks, Boris Boris Brezillon (11): i2c: Export of_i2c_get_board_info() i3c: Add core I3C infrastructure docs: driver-api: Add I3C documentation i3c: Add sysfs ABI spec dt-bindings: i3c: Document core bindings dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property MAINTAINERS: Add myself as the I3C subsystem maintainer i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings gpio: Add a driver for Cadence I3C GPIO expander dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Documentation/ABI/testing/sysfs-bus-i3c| 95 ++ .../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 38 + .../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 + Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++ Documentation/driver-api/i3c/conf.py | 10 + Documentation/driver-api/i3c/device-driver-api.rst |7 + Documentation/driver-api/i3c/index.rst |9 + Documentation/driver-api/i3
[PATCH v3 07/11] MAINTAINERS: Add myself as the I3C subsystem maintainer
Create an entry for the I3C subsystem and mark it as maintained by me. There's no official git repository, patchwork instance, mailing list or website yet, but this will be added after the subsystem has been accepted. Signed-off-by: Boris Brezillon --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3bdc260e36b7..f323864131ed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6669,6 +6669,15 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/i2c/i2c-stub.c +I3C SUBSYSTEM +M: Boris Brezillon +S: Maintained +F: Documentation/devicetree/bindings/i3c/ +F: Documentation/driver-api/i3c +F: drivers/i3c/ +F: include/linux/i3c/ +F: include/dt-bindings/i3c/ + IA64 (Itanium) PLATFORM M: Tony Luck M: Fenghua Yu -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/11] i2c: Export of_i2c_get_board_info()
From: Boris Brezillon
I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.
We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.
Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- fix memset() call
- rebase on v4.15-rc1
---
drivers/i2c/i2c-core-base.c | 2 +-
drivers/i2c/i2c-core-of.c | 66 ++---
include/linux/i2c.h | 10 +++
3 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 5a00bf443d06..e57715f5064c 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -736,7 +736,7 @@ i2c_new_device(struct i2c_adapter *adap, struct
i2c_board_info const *info)
client->dev.parent = &client->adapter->dev;
client->dev.bus = &i2c_bus_type;
client->dev.type = &i2c_client_type;
- client->dev.of_node = info->of_node;
+ client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
i2c_dev_set_name(adap, client, info);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 8d474bb1dc15..7470bc418a3b 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,56 +22,66 @@
#include "i2c-core.h"
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
-struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info)
{
- struct i2c_client *result;
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr_be;
u32 addr;
- int len;
+ int ret;
- dev_dbg(&adap->dev, "of_i2c: register %pOF\n", node);
+ memset(info, 0, sizeof(*info));
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %pOF\n",
- node);
- return ERR_PTR(-EINVAL);
+ if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+ dev_err(dev, "of_i2c: modalias failure on %pOF\n", node);
+ return -EINVAL;
}
- addr_be = of_get_property(node, "reg", &len);
- if (!addr_be || (len < sizeof(*addr_be))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %pOF\n", node);
- return ERR_PTR(-EINVAL);
+ ret = of_property_read_u32(node, "reg", &addr);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid reg on %pOF\n", node);
+ return ret;
}
- addr = be32_to_cpup(addr_be);
if (addr & I2C_TEN_BIT_ADDRESS) {
addr &= ~I2C_TEN_BIT_ADDRESS;
- info.flags |= I2C_CLIENT_TEN;
+ info->flags |= I2C_CLIENT_TEN;
}
if (addr & I2C_OWN_SLAVE_ADDRESS) {
addr &= ~I2C_OWN_SLAVE_ADDRESS;
- info.flags |= I2C_CLIENT_SLAVE;
+ info->flags |= I2C_CLIENT_SLAVE;
}
- if (i2c_check_addr_validity(addr, info.flags)) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %pOF\n",
- addr, node);
- return ERR_PTR(-EINVAL);
+ ret = i2c_check_addr_validity(addr, info->flags);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid addr=%x on %pOF\n", addr, node);
+ return ret;
}
- info.addr = addr;
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
+ info->addr = addr;
+ info->of_node = node;
if (of_property_read_bool(node, "host-notify"))
- info.flags |= I2C_CLIENT_HOST_NOTIFY;
+ info->flags |= I2C_CLIENT_HOST_NOTIFY;
if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
+ info->flags |= I2C_CLIENT_WAKE;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_i2c_get_board_info);
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+
[PATCH v3 06/11] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property
The reg property of devices connected to an I3C bus have 3 cells, and filling them manually is not trivial. Provides macros to help doing that. Signed-off-by: Boris Brezillon --- include/dt-bindings/i3c/i3c.h | 28 1 file changed, 28 insertions(+) create mode 100644 include/dt-bindings/i3c/i3c.h diff --git a/include/dt-bindings/i3c/i3c.h b/include/dt-bindings/i3c/i3c.h new file mode 100644 index ..97448c546649 --- /dev/null +++ b/include/dt-bindings/i3c/i3c.h @@ -0,0 +1,28 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + */ + +#ifndef _DT_BINDINGS_I3C_I3C_H +#define _DT_BINDINGS_I3C_I3C_H + +#define IS_I2C_DEV 0x8000 + +#define I2C_DEV(addr, lvr) \ + (addr) (IS_I2C_DEV | (lvr)) 0x0 + +#define I3C_PID(manufid, partid, instid, extrainfo)\ + ((manufid) << 1)\ + (((partid) << 16) | ((instid) << 12) | (extrainfo)) + +#define I3C_DEV_WITH_STATIC_ADDR(addr, manufid, partid,\ +instid, extrainfo) \ + (addr) I3C_PID(manufid, partid, instid, extrainfo) + +#define I3C_DEV(manufid, partid, instid, extrainfo)\ + I3C_DEV_WITH_STATIC_ADDR(0x0, manufid, partid, \ +instid, extrainfo) + +#endif -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/11] dt-bindings: i3c: Document core bindings
From: Boris Brezillon
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
- Rework the way we expose the provisional ID and LVR information
- Rename dynamic-address into assigned-address
- Enforce the I3C master node name
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
used. Note that the parsing of I3C devices is not yet implemented in
the framework. Will be added when someone really needs it.
---
Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++
1 file changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt
b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index ..ed858228d26b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,140 @@
+Generic device tree bindings for I3C busses
+===
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+---
+
+- #address-cells - should be <3>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of the I3C master controller driving the I3C bus
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+The node describing an I3C bus should be named i3c-master.
+
+Optional properties
+---
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-hz: frequency of the SCL signal used for I3C transfers.
+ When undefined the core sets it to 12.5MHz.
+
+- i2c-scl-hz: frequency of the SCL signal used for I2C transfers.
+ When undefined, the core looks at LVR (Legacy Virtual Register)
+ values of I2C devices described in the device tree to determine
+ the maximum I2C frequency.
+
+I2C devices
+===
+
+Each I2C device connected to the bus should be described in a subnode. All
+properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here, but several new properties have been added.
+
+New constraint on existing properties:
+--
+- reg: contains 3 cells
+ + first cell : still encoding the I2C address
+
+ + second cell: should have bit 31 set to 1 signify that this is an I2C
+device. Bits 0 to 7 encode the I3C LVR (Legacy Virtual
+Register):
+
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not tolerant
+to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM (Fast Mode) or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+ + third cell: should be 0
+
+I3C devices
+===
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static address and we want to assign it a specific dynamic
+address before the DAA takes place (so that other devices on the bus can't
+take this dynamic address).
+
+The I3C device should be names @,,
+where device-type is describing the type of device connected on the bus
+(gpio-controller, sensor, ...).
+
+Required properties
+---
+- reg: contains 3 cells
+ + first cell : encodes the I2C address. Should be 0 if the device does not
+have one (0 is not a valid I3C address).
+
+ + second and third cells: should encode the ProvisionalID. The second cell
+ contains the manufacturer ID left-shifted by 1.
+ The third cell contains ORing of the part ID
+ left-shifted by 16, the instance ID left-shifted
+ by 12 and the extra information. This encoding is
+ following the PID definition provided by the I3C
+ specification.
+
+Op
[PATCH v3 04/11] i3c: Add sysfs ABI spec
From: Boris Brezillon Document sysfs files/directories/symlinks exposed by the I3C subsystem. Signed-off-by: Boris Brezillon --- Changes in v2: - new patch --- Documentation/ABI/testing/sysfs-bus-i3c | 95 + 1 file changed, 95 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c new file mode 100644 index ..5e88cc093e0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i3c @@ -0,0 +1,95 @@ +What: /sys/bus/i3c/devices/i3c- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C bus. This directory will contain one sub-directory per + I3C device present on the bus. + +What: /sys/bus/i3c/devices/i3c-/current_master +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the master that owns the bus (-) at + the time this file is read. Note that bus ownership can change + overtime, so there's no guarantee that when the read() call + returns, the value returned is still valid. + +What: /sys/bus/i3c/devices/i3c-/mode +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See + the I3C specification for a detailed description of what each + of these modes implies. + +What: /sys/bus/i3c/devices/i3c-/i3c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I3C SDR mode. + +What: /sys/bus/i3c/devices/i3c-/i2c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I2C mode. + +What: /sys/bus/i3c/devices/i3c-/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C device present on I3C bus identified by . Note + that all devices are represented including the master driving + the bus. + +What: /sys/bus/i3c/devices/i3c-/-/address +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Dynamic address assigned to device -. This + address may change if the bus is re-initialized. + +What: /sys/bus/i3c/devices/i3c-/-/bcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + BCR stands for Bus Characteristics Register and express the + device capabilities in term of speed, maximum read/write + length, etc. See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/dcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + DCR stands for Device Characteristics Register and express the + device capabilities in term of exposed features. See the I3C + specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/pid +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + PID stands for Provisional ID and is used to uniquely identify + a device on a bus. This PID contains information about the + vendor, the part and an instance ID so that several devices of + the same type can be connected on the same bus. + See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/hdrcap +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the HDR (High Data Rate) capabilities of a device. + Returns a list of supported HDR mode, each element is separated + by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl". + See the I3C specification for more details about these HDR + modes. + +What: /sys/bus/i3c/devices/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + These directories are just symbolic links to + /sys/bus/i3c/devices/i3c-/-. -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/11] Add the I3C subsystem
On Fri, 23 Mar 2018 12:00:09 +0100 Boris Brezillon wrote: > This patch series is a proposal for a new I3C [1] subsystem. > > 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 to send I3C/I2C frames must be called in > non-atomic context. Mainly done this way to ease implementation, but > this is still open to discussion. Please let me know if you think it's > worth considering an asynchronous model here > - the bus element is a separate object and is not implicitly described > by the master (as done in I2C). The reason is that I want to be able > to handle multiple master connected to the same bus and visible to > Linux. > In this situation, we should only have one instance of the device and > not one per master, and sharing the bus object would be part of the > solution to gracefully handle this case. > I'm not sure if we will ever need to deal with multiple masters > controlling the same bus and exposed under Linux, but separating the > bus and master concept is pretty easy, hence the decision to do it > now, just in case we need it some day. > The other benefit of separating the bus and master concepts is that > master devices appear under the bus directory in sysfs. > - 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 new I2C bus. I'd say that, from a > representation PoV it's not ideal because what should appear as a > single I3C bus exposing I3C and I2C devices here appears as 2 > different busses connected to each other through the parenting (the > I3C master is the parent of the I2C and I3C busses). > On the other hand, I don't see a better solution if we want something > that is not invasive. > > Missing features in this preliminary version: > - support for HDR modes (has been removed because of lack of real users) > - no support for multi-master and the associated concepts (mastership > handover, support for secondary masters, ...) > - I2C devices can only be described using DT because this is the only > use case I have. However, the framework can easily be extended with > ACPI and board info support > - I3C slave framework. This has been completely omitted, but shouldn't > have a huge impact on the I3C framework because I3C slaves don't see > the whole bus, it's only about handling master requests and generating > IBIs. Some of the struct, constant and enum definitions could be > shared, but most of the I3C slave framework logic will be different > > Main changes between v2 and v3 are: > - Reworked the DT bindings as suggested by Rob > - Reworked the bus initialization step as suggested by Vitor > - Added a driver for an I3C GPIO expander > > Main changes between the initial RFC and this v2 are: > - Add a generic infrastructure to support IBIs. It's worth mentioning > that I tried exposing IBIs as a regular IRQs, but after several > attempts and a discussion with Mark Zyngier, it appeared that it was > not really fitting in the Linux IRQ model (the fact that you have > payload attached to IBIs, the fact that most of the time an IBI will > generate a transfer on the bus which has to be done in an atomic > context, ...) > The counterpart of this decision is the latency induced by the > workqueue approach, but since I don't have real use cases, I don't > know if this can be a problem or not. > - Add helpers to support Hot Join > - Add support for IBIs and Hot Join in Cadence I3C master driver > - Address several issues in how I was using the device model > > I'll finish on a good news: this week the MIPI alliance opened the I3C > spec. So everyone can now review the patches (no need to be member of > the MIPI I3C group). Okay, okay, the news is a bit out-dated, but this is still good news :-). I'll try to remove this part in the next iteration. > I'll let you find the link in the doc, this way maybe I'll have reviews > on the doc itself :-). > > Thanks, > > Boris > > Boris Brezillon (11): > i2c: Export of_i2c_get_board_info() > i3c: Add core I3C infrastructure > docs: driver-api: Add I3C documentation > i3c: Add sysfs ABI spec > dt-bindings: i3c: Document core bindings > dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg > property > MAINTAINERS: Add myself as the I3C subsystem maintainer > i3c: master: Add driver for Cadence IP >
Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
On Fri, 23 Mar 2018 13:47:49 +0100
Peter Rosin wrote:
> > +Example:
> > +
> > + i3c-master@d04 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d04 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <10>;
>
> Another s/frequency/hz/ instance, similar to those reported by Thomas.
Will fix it in v4.
Thanks,
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/11] dt-bindings: i3c: Document Cadence I3C master bindings
On Fri, 23 Mar 2018 12:10:35 +0100
Thomas Petazzoni wrote:
> Hello,
>
> On Fri, 23 Mar 2018 12:00:18 +0100, Boris Brezillon wrote:
>
> > +Optional properties defined by the generic binding (see
> > +Documentation/devicetree/bindings/i3c/i3c.txt for more details):
> > +
> > +- i2c-scl-frequency
> > +- i3c-scl-frequency
>
> These properties are now named *-scl-hz.
>
> > +Example:
> > +
> > + i3c-master@0d04 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d04 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + i2c-scl-frequency = <10>;
>
> Ditto.
I'll fix that in v4.
Thanks for the review.
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()
Hi Wolfram, On Sat, 24 Mar 2018 23:35:18 +0100 Wolfram Sang wrote: > Hi Boris, > > > - rebase on v4.15-rc1 > > This code has changed a little meanwhile. Please check my for-next > branch. Some changes are identical, some similar. Actually it was rebased on top of v4.16-rc1, but I'll check if this patch applies correctly on top of your for-next branch. > > > - info.archdata = &dev_ad; > > Why did you drop this? Well, this line could have been moved in of_i2c_register_device(), but I realized dev_ad was zero initialized without any further modification, and leaving info->archdata to NULL has the exact same effect (see [1]). Regards, Boris [1]https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/i2c/i2c-core-base.c#L711 -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/11] i2c: Export of_i2c_get_board_info()
On Sat, 24 Mar 2018 23:38:32 +0100 Wolfram Sang wrote: > > > - info.archdata = &dev_ad; > > > > Why did you drop this? > > If the removal is safe, it should be a seperate patch, I mean. > Sure, I'll move that in a separate patch. Actually, I had a closer look and it seems the only user of info->archdata is i2c-core-of.c, so we can even remove the info->archdata field. -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
Hi Geert,
On Mon, 26 Mar 2018 12:22:24 +0200
Geert Uytterhoeven wrote:
> Hi Boris,
>
> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
> wrote:
> > From: Boris Brezillon
> >
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,140 @@
>
> > +I3C devices
> > +===
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment),
> > and
> > +are thus discoverable. So, by default, I3C devices do not have to be
> > described
> > +in the device tree.
>
> But if they're described, they should have a compatible value, no?
What's the point of having a compatible here? I mean, I3C devices are
already attached to the relevant drivers using the Provisional ID, why
would we need a compatible if we don't parse it?
>
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in
> > turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when
> > this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> > +take this dynamic address).
> > +
> > +The I3C device should be names @,,
>
> named
Oops. Will fix the typo.
>
> So the i3c-pid in the unit address is represented as a 64-bit number, not as
> two
> comma-separated 32-bit numbers?
Right. I've changed my mind so many times that I ended up mixing the 2
representations I have considered.
Here are the choices we have:
1/ expose the raw ProvisionalID which is a 48-bit integer formed by the
concatenation of the vendor ID, part ID and instance ID:
ProvisionalID = VendorID << 33 | PartID << 16 | InstanceID << 12 |
ExtraInfo
The I3C dev node name should in this case be something like
@,
2/ split the fields we are really interested in in different cells:
2nd cell: vendorID
3rd cell: partID
4th cell: instanceID
In this case, the node name should be
@,,,
Note that we can still change for the second representation if Rob is
okay.
>
> > +Example:
> > +
> > + i3c-master@d04 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d04 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <10>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
>
> @52,8010?
Well, I2C devs is a special case, and I'm not sure we want to add the
extra LVR information + the IS_I2C_DEV bit in the node name.
>
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x8010 0x0>;
One more detail: people are unlikely to define reg using raw values: I
provide macros to do that in patch 6.
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
>
> No compatible value?
No, as said above, it's not needed.
>
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > +* I3C device without a static address but requiring
> > resources
> > +* described in the DT.
> > +*/
> > + sensor@0,39200154004 {
>
> No compatible value?
Ditto.
Thanks for your review.
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
Hi Geert,
On Mon, 26 Mar 2018 12:17:26 +0200
Geert Uytterhoeven wrote:
> Hi Boris,
>
> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
> wrote:
> > Document the Cadence I3C gpio expander bindings.
> >
> > Signed-off-by: Boris Brezillon
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
> > @@ -0,0 +1,38 @@
> > +* Cadence I3C GPIO expander
> > +
> > +The Cadence I3C GPIO expander provides 8 GPIOs controllable over I3C.
> > +This GPIOs can be configured in output or input mode and if they are in
> > input
> > +mode they can generate IBIs (In Band Interrupts).
> > +
> > +Required properties for GPIO node:
> > +- reg : 3 cells encoding the I3C static address (none in our case) and the
> > I3C
> > + Provisional ID. See Documentation/devicetree/bindings/i3c/i3c.txt
> > for
> > + more details.
> > + Should be <0x0 0x392 0x0>.
>
> No compatible value?
See my other reply.
>
> > +- gpio-controller : Marks the device node as a gpio controller.
> > +- #gpio-cells : Should be two. The first cell is the pin number and
> > + the second cell is used to specify the gpio polarity:
> > + 0 = active high
> > + 1 = active low
> > +- interrupt-controller: Marks the device node as an interrupt controller.
> > +- #interrupt-cells : Should be 2. The first cell is the GPIO number.
> > + The second cell bits[3:0] is used to specify trigger type and level
> > flags:
> > + 1 = low-to-high edge triggered.
> > + 2 = high-to-low edge triggered.
> > + 3 = triggered on both edges.
> > + 4 = active high level-sensitive.
> > + 8 = active low level-sensitive.
> > +
> > +Example:
> > +
> > + i3c-master@xxx {
> > + ...
> > + i3c_gpio_expander: gpio@0,1c9,0 {
>
> gpio@0,392,0?
Actually, if I follow the DT bindings, it should be gpio@0,392
Thanks,
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
On Mon, 26 Mar 2018 12:12:54 +0200 Geert Uytterhoeven wrote: > Hi Boris, > > On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon > wrote: > > Document the Cadence I3C gpio expander bindings. > > > > Signed-off-by: Boris Brezillon > > Thanks for your patch! > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt > > > +- #interrupt-cells : Should be 2. The first cell is the GPIO number. > > + The second cell bits[3:0] is used to specify trigger type and level > > flags: > > + 1 = low-to-high edge triggered. > > + 2 = high-to-low edge triggered. > > + 3 = triggered on both edges. > > + 4 = active high level-sensitive. > > + 8 = active low level-sensitive. > > These are identical to the values in . > Perhaps you can refer to those definitions? Well, I'm not sure this is allowed since DT bindings docs are supposed to be OS-agnostic and macros defined in are, AFAIK, only available to Linux. Note that I copied these definitions from another binding ;-). Rob, any opinion? -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
Hi Rob,
On Mon, 26 Mar 2018 17:24:58 -0500
Rob Herring wrote:
> > +
> > +I3C devices
> > +===
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment),
> > and
> > +are thus discoverable. So, by default, I3C devices do not have to be
> > described
> > +in the device tree.
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in
> > turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when
> > this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> >
>
> static is I2C address and dynamic is an I3C address. That could be
> clearer throughout.
I'll clarify that.
>
> > +take this dynamic address).
> > +
> > +The I3C device should be names @,,
>
> s/static-address/static-i2c-address/
Okay.
>
> > +where device-type is describing the type of device connected on the bus
> > +(gpio-controller, sensor, ...).
> > +
> > +Required properties
> > +---
> > +- reg: contains 3 cells
> > + + first cell : encodes the I2C address. Should be 0 if the device does
> > not
> > +have one (0 is not a valid I3C address).
>
> Change here to "encodes the static I2C address".
>
> 0 is not a valid I2C address?
According to [1] it is reserved, and it's reserved in the I3C spec
anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec).
>
> > +
> > + + second and third cells: should encode the ProvisionalID. The second
> > cell
> > + contains the manufacturer ID left-shifted by 1.
> > + The third cell contains ORing of the part ID
> > + left-shifted by 16, the instance ID left-shifted
> > + by 12 and the extra information. This encoding is
> > + following the PID definition provided by the I3C
> > + specification.
One extra question for you: should I refer to the I3C_DEV(),
I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc?
And if I do, should I use them my example?
Thanks,
Boris
> > +
> > +Optional properties
> > +---
> > +- assigned-address: dynamic address to be assigned to this device. This
> > + property is only valid if the I3C device has a static
> > + address (first cell of the reg property != 0).
> > +
> > +
> > +Example:
> > +
> > + i3c-master@d04 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d04 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <10>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x8010 0x0>;
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > +* I3C device without a static address but requiring resources
> > +* described in the DT.
> > +*/
> > + sensor@0,39200154004 {
> > + reg = <0x0 0x392 0x154004>;
> > + clocks = <&clock_provider 0>;
> > + };
> > + };
> > +
> > --
> > 2.14.1
> >
[1]http://www.i2c-bus.org/addressing
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
On Wed, 28 Mar 2018 11:42:07 -0500 Rob Herring wrote: > >> > >> > +where device-type is describing the type of device connected on the bus > >> > +(gpio-controller, sensor, ...). > >> > + > >> > +Required properties > >> > +--- > >> > +- reg: contains 3 cells > >> > + + first cell : encodes the I2C address. Should be 0 if the device > >> > does not > >> > +have one (0 is not a valid I3C address). > >> > >> Change here to "encodes the static I2C address". > >> > >> 0 is not a valid I2C address? > > > > According to [1] it is reserved, and it's reserved in the I3C spec > > anyway (see "Table 9 I3C Slave Address Restrictions" in the I3C spec). > > Sorry, what I meant was s/I3C/I2C/. The first cell is I2C address and > 0 is not valid. Okay, got it now :-). > > >> > + > >> > + + second and third cells: should encode the ProvisionalID. The second > >> > cell > >> > + contains the manufacturer ID left-shifted by 1. > >> > + The third cell contains ORing of the part ID > >> > + left-shifted by 16, the instance ID left-shifted > >> > + by 12 and the extra information. This encoding is > >> > + following the PID definition provided by the I3C > >> > + specification. > > > > One extra question for you: should I refer to the I3C_DEV(), > > I3C_DEV_WITH_STATIC_ADDR() and I2C_DEV() macros in the bindings doc? > > And if I do, should I use them my example? > > Well, I don't want to see "device@I3C_DEV(...)" for unit-addresses. That wouldn't work anyway. > You can use them for reg property, but it's somewhat pointless to use > it in one place and not the other. Not sure I follow you. These macros have been added to ease definitions of reg, but you'll still have to manually define the unit-address manually. Are you saying I should not use them in dts files or just that I should not mention it in the doc. If this is the former, then patch 6 should be dropped. -- Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/10] docs: driver-api: Add I3C documentation
Add the I3C documentation describing the protocol, the master driver API
and the device driver API.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
Documentation/driver-api/i3c/conf.py | 10 +
Documentation/driver-api/i3c/device-driver-api.rst | 7 +
Documentation/driver-api/i3c/index.rst | 9 +
Documentation/driver-api/i3c/master-driver-api.rst | 8 +
Documentation/driver-api/i3c/protocol.rst | 201 +
Documentation/driver-api/index.rst | 1 +
6 files changed, 236 insertions(+)
create mode 100644 Documentation/driver-api/i3c/conf.py
create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/index.rst
create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/protocol.rst
diff --git a/Documentation/driver-api/i3c/conf.py
b/Documentation/driver-api/i3c/conf.py
new file mode 100644
index ..5a20832d59a7
--- /dev/null
+++ b/Documentation/driver-api/i3c/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux I3C Subsystem"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'i3c.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst
b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index ..63c843f148a6
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,7 @@
+=
+I3C device driver API
+=
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst
b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index ..9c439220439d
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,9 @@
+=
+I3C subsystem
+=
+
+.. toctree::
+
+ protocol
+ device-driver-api
+ master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst
b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index ..017e7711cdf7
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,8 @@
+
+I3C master controller driver API
+
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst
b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index ..9c704d596ae3
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,201 @@
+
+I3C protocol
+
+
+Disclaimer
+==
+
+This chapter will focus on aspects that matter to software developers. For
+everything hardware related (like how things are transmitted on the bus, how
+collisions are prevented, ...) please have a look at the I3C specification.
+
+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 (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+===
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+ transactions or deciding who is allowed to talk on the bus (slave generated
+ events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+ slave on the bus. The device can still send events to the master on
+ its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to these per-device addre
[PATCH v4 09/10] gpio: Add a driver for Cadence I3C GPIO expander
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon
---
drivers/gpio/Kconfig | 11 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-cdns-i3c.c | 380 +++
3 files changed, 392 insertions(+)
create mode 100644 drivers/gpio/gpio-cdns-i3c.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8dbb2280538d..87b7083179ff 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -862,6 +862,17 @@ config GPIO_TS4900
endmenu
+menu "I3C GPIO expanders"
+ depends on I3C
+
+config GPIO_CDNS_I3C
+ tristate "Cadence I3C GPIO expander"
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to enabled the driver for Cadence I3C GPIO expander.
+
+endmenu
+
menu "MFD GPIO expanders"
config GPIO_ADP5520
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index cccb0d40846c..22a7151fc565 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
+obj-$(CONFIG_GPIO_CDNS_I3C)+= gpio-cdns-i3c.o
obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
obj-$(CONFIG_GPIO_CRYSTAL_COVE)+= gpio-crystalcove.o
diff --git a/drivers/gpio/gpio-cdns-i3c.c b/drivers/gpio/gpio-cdns-i3c.c
new file mode 100644
index ..58a903fabb0a
--- /dev/null
+++ b/drivers/gpio/gpio-cdns-i3c.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon
+ */
+
+#include
+#include
+#include
+
+#define OVR0x0
+#define IVR0x1
+#define DIR_MODE 0x2
+#define IMR0x3
+#define ISR0x4
+#define ITR(x) (0x5 + (x))
+
+struct cdns_i3c_gpio {
+ struct gpio_chip gpioc;
+ struct irq_chip irqc;
+ struct i3c_device *i3cdev;
+ struct mutex irq_lock;
+ u8 dir;
+ u8 ovr;
+ u8 imr;
+ u8 itr[3];
+};
+
+static struct cdns_i3c_gpio *gpioc_to_cdns_gpioc(struct gpio_chip *gpioc)
+{
+ return container_of(gpioc, struct cdns_i3c_gpio, gpioc);
+}
+
+static int cdns_i3c_gpio_read_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 *val)
+{
+ struct i3c_priv_xfer xfers[] = {
+ {
+ .len = sizeof(reg),
+ .data.out = ®,
+ },
+ {
+ .rnw = true,
+ .len = sizeof(*val),
+ .data.in = val,
+ },
+ };
+
+ return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+}
+
+static int cdns_i3c_gpio_write_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 val)
+{
+ struct i3c_priv_xfer xfers[] = {
+ {
+ .len = sizeof(reg),
+ .data.out = ®,
+ },
+ {
+ .len = sizeof(val),
+ .data.out = &val,
+ },
+ };
+
+ return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+}
+
+static int cdns_i3c_gpio_get_direction(struct gpio_chip *g, unsigned offset)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+
+ return gpioc->dir & BIT(offset);
+}
+
+static void cdns_i3c_gpio_set_multiple(struct gpio_chip *g,
+ unsigned long *mask,
+ unsigned long *bits)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+ u8 newovr;
+ int ret;
+
+ newovr = (gpioc->ovr & ~(*mask)) | (*bits & *mask);
+ if (newovr == gpioc->ovr)
+ return;
+
+ ret = cdns_i3c_gpio_write_reg(gpioc, OVR, newovr);
+ if (!ret)
+ gpioc->ovr = newovr;
+}
+
+static void cdns_i3c_gpio_set(struct gpio_chip *g, unsigned offset, int value)
+{
+ unsigned long mask = BIT(offset), bits = value ? BIT(offset) : 0;
+
+ cdns_i3c_gpio_set_multiple(g, &mask, &bits);
+}
+
+static int cdns_i3c_gpio_set_dir(struct cdns_i3c_gpio *gpioc, unsigned pin,
+bool in)
+{
+ u8 newdir;
+ int ret;
+
+ newdir = gpioc->dir;
+ if (in)
+ newdir |= BIT(pin);
+ else
+ newdir &= ~BIT(pin);
+
+ if (newdir == gpioc->dir)
+ return 0;
+
+ gpioc->dir = newdir;
+ ret = cdns_i3c_gpio_write_reg(gpioc, DIR_MODE, newdir);
+ if (!ret)
+ gpioc->dir = newdir;
+
+ r
[PATCH v4 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
Document the Cadence I3C gpio expander bindings.
Signed-off-by: Boris Brezillon
---
Changes in v4:
- Use GPIO_ and IRQ_TYPE_ macros instead of raw numbers
- Fix the unit-address in the example
---
.../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
new file mode 100644
index ..d0155a9cea79
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
@@ -0,0 +1,39 @@
+* Cadence I3C GPIO expander
+
+The Cadence I3C GPIO expander provides 8 GPIOs controllable over I3C.
+This GPIOs can be configured in output or input mode and if they are in input
+mode they can generate IBIs (In Band Interrupts).
+
+Required properties for GPIO node:
+- reg : 3 cells encoding the I3C static address (none in our case) and the I3C
+ Provisional ID. See Documentation/devicetree/bindings/i3c/i3c.txt for
+ more details.
+ Should be <0x0 0x392 0x0>.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity (GPIO_ACTIVE_HIGH or
+ GPIO_ACTIVE_LOW)
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be 2. The first cell is the GPIO number.
+ The second cell is used to specify trigger type and level flags.
+ The following trigger types are accepted (see
+ for their definition):
+ IRQ_TYPE_EDGE_RISING
+ IRQ_TYPE_EDGE_FALLING
+ IRQ_TYPE_EDGE_BOTH
+ IRQ_TYPE_LEVEL_HIGH
+ IRQ_TYPE_LEVEL_LOW
+
+Example:
+
+ i3c-master@xxx {
+ ...
+ i3c_gpio_expander: gpio@0,392 {
+ reg = <0 0x392 0x0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ ...
+ };
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/10] i3c: master: Add driver for Cadence IP
Add a driver for Cadence I3C master IP. Signed-off-by: Boris Brezillon --- Changes in v4: - Fix potential unsigned integer underflow - Add missing static specific on IBI related functions Changes in v3: - Adjust to match I3C framework changes - Implement support the CMD RESPONSE QUEUE and IBI QUEUE added in the latest revision of Cadence master IP - Remove support for HDR modes Changes in v2: - Add basic IBI support. Note that the IP is not really reliable with regards to IBI because you can't extract IBI payloads as soon as you have more than one IBI waiting in the HW queue. This is something that will hopefully be addressed in future revisions of this IP - Add a simple xfer queueing mechanism to optimize message queuing. - Fix a few bugs - Add support for Hot Join --- drivers/i3c/master/Kconfig |5 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1650 ++ 3 files changed, 1656 insertions(+) create mode 100644 drivers/i3c/master/i3c-master-cdns.c diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig index e69de29bb2d1..56b9a18543b2 100644 --- a/drivers/i3c/master/Kconfig +++ b/drivers/i3c/master/Kconfig @@ -0,0 +1,5 @@ +config CDNS_I3C_MASTER + tristate "Cadence I3C master driver" + depends on I3C + help + Enable this driver if you want to support Cadence I3C master block. diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile index e69de29bb2d1..4c4304aa9534 100644 --- a/drivers/i3c/master/Makefile +++ b/drivers/i3c/master/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c new file mode 100644 index ..3940cc0a46e2 --- /dev/null +++ b/drivers/i3c/master/i3c-master-cdns.c @@ -0,0 +1,1650 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DEV_ID 0x0 +#define DEV_ID_I3C_MASTER 0x5034 + +#define CONF_STATUS0 0x4 +#define CONF_STATUS0_ECC_CHK BIT(28) +#define CONF_STATUS0_INTEG_CHK BIT(27) +#define CONF_STATUS0_CSR_DAP_CHK BIT(26) +#define CONF_STATUS0_TRANS_TOUT_CHKBIT(25) +#define CONF_STATUS0_PROT_FAULTS_CHK BIT(24) +#define CONF_STATUS0_GPO_NUM(x)(((x) & GENMASK(23, 16)) >> 16) +#define CONF_STATUS0_GPI_NUM(x)(((x) & GENMASK(15, 8)) >> 8) +#define CONF_STATUS0_SUPPORTS_DDR BIT(5) +#define CONF_STATUS0_SEC_MASTERBIT(4) +#define CONF_STATUS0_DEVS_NUM(x) ((x) & GENMASK(3, 0)) + +#define CONF_STATUS1 0x8 +#define CONF_STATUS1_IBI_HW_RES(x) x) & GENMASK(31, 28)) >> 28) + 1) +#define CONF_STATUS1_CMD_DEPTH(x) (4 << (((x) & GENMASK(27, 26)) >> 26)) +#define CONF_STATUS1_SLVDDR_RX_DEPTH(x)(8 << (((x) & GENMASK(25, 21)) >> 21)) +#define CONF_STATUS1_SLVDDR_TX_DEPTH(x)(8 << (((x) & GENMASK(20, 16)) >> 16)) +#define CONF_STATUS1_IBI_DEPTH(x) (2 << (((x) & GENMASK(12, 10)) >> 10)) +#define CONF_STATUS1_RX_DEPTH(x) (8 << (((x) & GENMASK(9, 5)) >> 5)) +#define CONF_STATUS1_TX_DEPTH(x) (8 << ((x) & GENMASK(4, 0))) + +#define REV_ID 0xc +#define REV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20) +#define REV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8) +#define REV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4) +#define REV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0)) + +#define CTRL 0x10 +#define CTRL_DEV_ENBIT(31) +#define CTRL_HALT_EN BIT(30) +#define CTRL_MCS BIT(29) +#define CTRL_MCS_ENBIT(28) +#define CTRL_HJ_DISEC BIT(8) +#define CTRL_MST_ACK BIT(7) +#define CTRL_HJ_ACKBIT(6) +#define CTRL_HJ_INIT BIT(5) +#define CTRL_MST_INIT BIT(4) +#define CTRL_AHDR_OPT BIT(3) +#define CTRL_PURE_BUS_MODE 0 +#define CTRL_MIXED_FAST_BUS_MODE 2 +#define CTRL_MIXED_SLOW_BUS_MODE 3 +#define CTRL_BUS_MODE_MASK GENMASK(1, 0) + +#define PRESCL_CTRL0 0x14 +#define PRESCL_CTRL0_I2C(x)((x) << 16) +#define PRESCL_CTRL0_I3C(x)(x) +#define PRESCL_CTRL0_MAX GENMASK(9, 0) + +#define PRESCL_CTRL1 0x18 +#define PR
[PATCH v4 08/10] dt-bindings: i3c: Document Cadence I3C master bindings
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
---
Changes in v4:
- Fix example to match the new representation
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt| 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index ..0e2b8b8770bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,44 @@
+Bindings for cadence I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-hz
+- i3c-scl-hz
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-hz = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52 0x8010 0>;
+ };
+ };
+
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer
Create an entry for the I3C subsystem and mark it as maintained by me. There's no official git repository, patchwork instance, mailing list or website yet, but this will be added after the subsystem has been accepted. Signed-off-by: Boris Brezillon --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3bdc260e36b7..f323864131ed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6669,6 +6669,15 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/i2c/i2c-stub.c +I3C SUBSYSTEM +M: Boris Brezillon +S: Maintained +F: Documentation/devicetree/bindings/i3c/ +F: Documentation/driver-api/i3c +F: drivers/i3c/ +F: include/linux/i3c/ +F: include/dt-bindings/i3c/ + IA64 (Itanium) PLATFORM M: Tony Luck M: Fenghua Yu -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property
The reg property of devices connected to an I3C bus have 3 cells, and filling them manually is not trivial. Provides macros to help doing that. Signed-off-by: Boris Brezillon Reviewed-by: Rob Herring --- include/dt-bindings/i3c/i3c.h | 28 1 file changed, 28 insertions(+) create mode 100644 include/dt-bindings/i3c/i3c.h diff --git a/include/dt-bindings/i3c/i3c.h b/include/dt-bindings/i3c/i3c.h new file mode 100644 index ..97448c546649 --- /dev/null +++ b/include/dt-bindings/i3c/i3c.h @@ -0,0 +1,28 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + */ + +#ifndef _DT_BINDINGS_I3C_I3C_H +#define _DT_BINDINGS_I3C_I3C_H + +#define IS_I2C_DEV 0x8000 + +#define I2C_DEV(addr, lvr) \ + (addr) (IS_I2C_DEV | (lvr)) 0x0 + +#define I3C_PID(manufid, partid, instid, extrainfo)\ + ((manufid) << 1)\ + (((partid) << 16) | ((instid) << 12) | (extrainfo)) + +#define I3C_DEV_WITH_STATIC_ADDR(addr, manufid, partid,\ +instid, extrainfo) \ + (addr) I3C_PID(manufid, partid, instid, extrainfo) + +#define I3C_DEV(manufid, partid, instid, extrainfo)\ + I3C_DEV_WITH_STATIC_ADDR(0x0, manufid, partid, \ +instid, extrainfo) + +#endif -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/10] i3c: Add sysfs ABI spec
Document sysfs files/directories/symlinks exposed by the I3C subsystem. Signed-off-by: Boris Brezillon --- Changes in v2: - new patch --- Documentation/ABI/testing/sysfs-bus-i3c | 95 + 1 file changed, 95 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c new file mode 100644 index ..5e88cc093e0e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i3c @@ -0,0 +1,95 @@ +What: /sys/bus/i3c/devices/i3c- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C bus. This directory will contain one sub-directory per + I3C device present on the bus. + +What: /sys/bus/i3c/devices/i3c-/current_master +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the master that owns the bus (-) at + the time this file is read. Note that bus ownership can change + overtime, so there's no guarantee that when the read() call + returns, the value returned is still valid. + +What: /sys/bus/i3c/devices/i3c-/mode +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See + the I3C specification for a detailed description of what each + of these modes implies. + +What: /sys/bus/i3c/devices/i3c-/i3c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I3C SDR mode. + +What: /sys/bus/i3c/devices/i3c-/i2c_scl_frequency +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + The frequency (expressed in Hz) of the SCL signal when + operating in I2C mode. + +What: /sys/bus/i3c/devices/i3c-/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + An I3C device present on I3C bus identified by . Note + that all devices are represented including the master driving + the bus. + +What: /sys/bus/i3c/devices/i3c-/-/address +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Dynamic address assigned to device -. This + address may change if the bus is re-initialized. + +What: /sys/bus/i3c/devices/i3c-/-/bcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + BCR stands for Bus Characteristics Register and express the + device capabilities in term of speed, maximum read/write + length, etc. See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/dcr +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + DCR stands for Device Characteristics Register and express the + device capabilities in term of exposed features. See the I3C + specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/pid +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + PID stands for Provisional ID and is used to uniquely identify + a device on a bus. This PID contains information about the + vendor, the part and an instance ID so that several devices of + the same type can be connected on the same bus. + See the I3C specification for more details. + +What: /sys/bus/i3c/devices/i3c-/-/hdrcap +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + Expose the HDR (High Data Rate) capabilities of a device. + Returns a list of supported HDR mode, each element is separated + by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl". + See the I3C specification for more details about these HDR + modes. + +What: /sys/bus/i3c/devices/- +KernelVersion: 4.16 +Contact: linux-...@vger.kernel.org +Description: + These directories are just symbolic links to + /sys/bus/i3c/devices/i3c-/-. -- 2.14.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/10] Add the I3C subsystem
This patch series is a proposal for a new I3C subsystem. 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 to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is still open to discussion. Please let me know if you think it's worth considering an asynchronous model here - the bus element is a separate object and is not implicitly described by the master (as done in I2C). The reason is that I want to be able to handle multiple master connected to the same bus and visible to Linux. In this situation, we should only have one instance of the device and not one per master, and sharing the bus object would be part of the solution to gracefully handle this case. I'm not sure if we will ever need to deal with multiple masters controlling the same bus and exposed under Linux, but separating the bus and master concept is pretty easy, hence the decision to do it now, just in case we need it some day. The other benefit of separating the bus and master concepts is that master devices appear under the bus directory in sysfs. - 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 new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different busses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. Missing features in this preliminary version: - support for HDR modes (has been removed because of lack of real users) - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different Main changes between v2 and v3 are: - Reworked the DT bindings as suggested by Rob - Reworked the bus initialization step as suggested by Vitor - Added a driver for an I3C GPIO expander Main changes between the initial RFC and this v2 are: - Add a generic infrastructure to support IBIs. It's worth mentioning that I tried exposing IBIs as a regular IRQs, but after several attempts and a discussion with Mark Zyngier, it appeared that it was not really fitting in the Linux IRQ model (the fact that you have payload attached to IBIs, the fact that most of the time an IBI will generate a transfer on the bus which has to be done in an atomic context, ...) The counterpart of this decision is the latency induced by the workqueue approach, but since I don't have real use cases, I don't know if this can be a problem or not. - Add helpers to support Hot Join - Add support for IBIs and Hot Join in Cadence I3C master driver - Address several issues in how I was using the device model Note that I2C changes have been sent separately [1] this time. Other than that, no big changes in this version, I just addressed the comments I received from Thomas, Peter, Geert and Rob. Thanks, Boris [1]https://patchwork.ozlabs.org/project/linux-i2c/list/?series=35687 Boris Brezillon (10): i3c: Add core I3C infrastructure docs: driver-api: Add I3C documentation i3c: Add sysfs ABI spec dt-bindings: i3c: Document core bindings dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property MAINTAINERS: Add myself as the I3C subsystem maintainer i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings gpio: Add a driver for Cadence I3C GPIO expander dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Documentation/ABI/testing/sysfs-bus-i3c| 95 ++ .../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 39 + .../devicetree/bindings/i3c/cdns,i3c-master.txt| 44 + Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++ Documentation/driver-api/i3c/conf.py | 10 + Documentation/driver-api/i3c/device-driver-api.rst |7 + Documentation/driver-api/i3c/index.rst |9 + Documentation/driver-api/i3c/master-driver-api.rst |8 + Documentation/driver-api/i3
[PATCH v4 04/10] dt-bindings: i3c: Document core bindings
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
---
Changes in v4:
- Clarify the fact that static address == I3C address and dynamic
address == I3C address
- Use i2c-scl-hz in the example
Changes in v3:
- Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
- Rework the way we expose the provisional ID and LVR information
- Rename dynamic-address into assigned-address
- Enforce the I3C master node name
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
used. Note that the parsing of I3C devices is not yet implemented in
the framework. Will be added when someone really needs it.
---
Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++
1 file changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt
b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index ..13b719f1ef15
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,140 @@
+Generic device tree bindings for I3C busses
+===
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+---
+
+- #address-cells - should be <3>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of the I3C master controller driving the I3C bus
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+The node describing an I3C bus should be named i3c-master.
+
+Optional properties
+---
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-hz: frequency of the SCL signal used for I3C transfers.
+ When undefined the core sets it to 12.5MHz.
+
+- i2c-scl-hz: frequency of the SCL signal used for I2C transfers.
+ When undefined, the core looks at LVR (Legacy Virtual Register)
+ values of I2C devices described in the device tree to determine
+ the maximum I2C frequency.
+
+I2C devices
+===
+
+Each I2C device connected to the bus should be described in a subnode. All
+properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here, but several new properties have been added.
+
+New constraint on existing properties:
+--
+- reg: contains 3 cells
+ + first cell : still encoding the I2C address
+
+ + second cell: should have bit 31 set to 1 to signify that this is an I2C
+device. Bits 0 to 7 encode the I3C LVR (Legacy Virtual
+Register):
+
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not tolerant
+to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM (Fast Mode) or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+ + third cell: should be 0
+
+I3C devices
+===
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static I2C address and we want to assign it a specific I3C
+dynamic address before the DAA takes place (so that other devices on the bus
+can't take this dynamic address).
+
+The I3C device should be names @,,
+where device-type is describing the type of device connected on the bus
+(gpio-controller, sensor, ...).
+
+Required properties
+---
+- reg: contains 3 cells
+ + first cell : encodes the static I2C address. Should be 0 if the device does
+not have one (0 is not a valid I2C address).
+
+ + second and third cells: should encode the ProvisionalID. The second cell
+ contains the manufacturer ID left-shifted by 1.
+ The third cell contains ORing of the part ID
+ left-shifted by 16, the instance ID left-shifted
+ by 12 and the extra information.
Re: [PATCH v4 04/10] dt-bindings: i3c: Document core bindings
On Fri, 30 Mar 2018 09:55:22 +0200
Geert Uytterhoeven wrote:
> Hi Boris,
>
> On Fri, Mar 30, 2018 at 9:47 AM, Boris Brezillon
> wrote:
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > Changes in v4:
> > - Clarify the fact that static address == I3C address and dynamic
>
> static address == I2C address?
hehe, indeed.
>
> > address == I3C address
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 0/9] Add the I3C subsystem
Hi Greg, On Sun, 11 Nov 2018 09:39:32 -0800 Greg Kroah-Hartman wrote: > On Fri, Oct 26, 2018 at 04:43:24PM +0200, Boris Brezillon wrote: > > Hi Greg, > > > > I think we've reached a point where we can eventually consider the I3C > > framework for inclusion in 4.20 (5.0?). A few more issues were reported > > on v9 and fixed in v10. I can't guarantee that the implementation is > > free of bugs but I still think it's worth merging it in v4.20: it's a > > new subsystem, so we don't risk regressions, and the only way we can > > detect other issues is by having other people experiment with this > > implementation. > > > > The only remaining concern raised by Arnd is the fact that both hosts > > and slaves share the same bus type and are differentiated thanks to > > their device_type, which IMHO is fine since this is what other > > subsystems do (plus I don't see other solutions to have both I3C > > devices and I3C buses represented under /sys/bus/i3c/). > > Yeah, it's not the nicest, but it will work, we did it also for USB and > greybus and it solves the issue. > > This all looks good to me, so I've queued it up. Let's see if > linux-next has any problems with it. I recently asked Stephen to add the linux-i3c tree to linux-next, so I'm expecting conflicts :-/. Sorry, I didn't know you were planning to take these patches through your tree. BTW, I also fixed a couple of things when rebasing on top of 4.20-rc1: - KernelVersion in the sysfs ABI doc has been updated to 5.0 - Fixed i3c_master_getmxds_locked() (bug reported/fixed by Colin here https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1799850.html) - Removed a blank line at the end of master-driver-api.rst For the record, the i3c/next branch pulled by Stephen is available here [1]. > Thanks for sticking with it, nice work! Thanks for reviewing it! Greg, Stephen, let me know if you want me to reset i3c/next to v4.20-rc1 to avoid conflicts in linux-next. Regards, Boris [1]https://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git/log/?h=i3c/next
Re: [PATCH v10 0/9] Add the I3C subsystem
On Sun, 11 Nov 2018 11:10:20 -0800 Greg Kroah-Hartman wrote: > On Sun, Nov 11, 2018 at 07:10:17PM +0100, Boris Brezillon wrote: > > Hi Greg, > > > > On Sun, 11 Nov 2018 09:39:32 -0800 > > Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 26, 2018 at 04:43:24PM +0200, Boris Brezillon wrote: > > > > Hi Greg, > > > > > > > > I think we've reached a point where we can eventually consider the I3C > > > > framework for inclusion in 4.20 (5.0?). A few more issues were reported > > > > on v9 and fixed in v10. I can't guarantee that the implementation is > > > > free of bugs but I still think it's worth merging it in v4.20: it's a > > > > new subsystem, so we don't risk regressions, and the only way we can > > > > detect other issues is by having other people experiment with this > > > > implementation. > > > > > > > > The only remaining concern raised by Arnd is the fact that both hosts > > > > and slaves share the same bus type and are differentiated thanks to > > > > their device_type, which IMHO is fine since this is what other > > > > subsystems do (plus I don't see other solutions to have both I3C > > > > devices and I3C buses represented under /sys/bus/i3c/). > > > > > > Yeah, it's not the nicest, but it will work, we did it also for USB and > > > greybus and it solves the issue. > > > > > > This all looks good to me, so I've queued it up. Let's see if > > > linux-next has any problems with it. > > > > I recently asked Stephen to add the linux-i3c tree to linux-next, so > > I'm expecting conflicts :-/. Sorry, I didn't know you were planning to > > take these patches through your tree. > > > > BTW, I also fixed a couple of things when rebasing on top of 4.20-rc1: > > > > - KernelVersion in the sysfs ABI doc has been updated to 5.0 > > There is no 5.0 yet :) Actually I had a hard time choosing between 4.21 and 5.0, and then I saw Linus' email announcing 4.20-rc1 ;-). But I can change it back to 4.21 if you prefer. > > > - Fixed i3c_master_getmxds_locked() (bug reported/fixed by Colin here > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1799850.html) > > - Removed a blank line at the end of master-driver-api.rst One extra thing I didn't mention (and didn't fix yet) is the I3C mailing list. I asked Dave Miller if he'd be okay to create the linux-i3c ML on vger.kernel.org, and he suggested that we use the linux-i2c ML instead which I know Wolfram is not fond of. I might decide to just put linux-ker...@vger.kernel.org as the ML to Cc for I3C patches until we settle on something. > > > > For the record, the i3c/next branch pulled by Stephen is available here > > [1]. > > > > > Thanks for sticking with it, nice work! > > > > Thanks for reviewing it! Greg, Stephen, let me know if you want me to > > reset i3c/next to v4.20-rc1 to avoid conflicts in linux-next. > > So do you want me to just drop these patches from my tree? If so, I > can, but i have no problem sending these to Linus for the next -rc1 > merge window through my tree if that is easier. > > It's up to you. I think that's easier for me and for you if I take them in the i3c tree and then send a PR to Linus myself. This way I won't bother you if fixes are needed or if I decide to apply patches adding support for other I3C controllers (I see you commented on the Synopsys driver already, and I might indeed decide to queue this patchset for this release). Doing that also allows me to get everything in place since I'll anyway have to send PRs to Linus at some point. Regards, Boris PS: If you're fine with me taking the I3C patches, I'll need your Acked-by.
Re: [PATCH v3 0/3] Add driver for Synopsys DesignWare I3C master IP
On Thu, 8 Nov 2018 17:14:08 + Vitor soares wrote: > This patch series is a proposal for the I3C master driver for Synopsys IP. > This patch is to be applied on top of I3C subsystem RFC V10 submitted by > Boris Brezillon. The patch series looks to me. I'm just waiting an ack from Rob on the bindings to queue it to the i3c/next branch. Thanks, Boris > > Supported features: > Regular CCC commands. > I3C private transfers. > I2C transfers. > > Missing functionalities: > Support DMA interface. > Support for I3C_BUS_MODE_MIXED_SLOW. > Hot-join. > IBI. > > Main change between v2 and v3: > - Minor fixes. They are described in each patch > > Main change between v1 and v2: > - Add controller version on dt-binding > - The driver now calls writesl/readsl() instead readl/writel > - Rename some variables in the driver > > Vitor soares (3): > i3c: master: Add driver for Synopsys DesignWare IP > dt-bindings: i3c: Document Synopsys DesignWare I3C master bindings > MAINTAINERS: Add myself as the dw-i3c-master module maintainer > > .../devicetree/bindings/i3c/snps,dw-i3c-master.txt | 42 + > MAINTAINERS|6 + > drivers/i3c/master/Kconfig | 15 + > drivers/i3c/master/Makefile|1 + > drivers/i3c/master/dw-i3c-master.c | 1216 > > 5 files changed, 1280 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt > create mode 100644 drivers/i3c/master/dw-i3c-master.c >
Re: [PATCH v3 2/3] dt-bindings: i3c: Document Synopsys DesignWare I3C master bindings
On Thu, 8 Nov 2018 17:14:10 +
Vitor soares wrote:
> Document Synopsys DesignWare I3C master module
>
> Signed-off-by: Vitor soares
> ---
> Changes in v3:
> - Remove dummy characters
>
> Changes in v2:
> - Address the changes in Documentation/devicetree/bindings/i3c/i3c.txt
> - Add controller version on compatible string
>
> .../devicetree/bindings/i3c/snps,dw-i3c-master.txt | 42
> ++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt
>
> diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt
> b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt
> new file mode 100644
> index 000..b930c09
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt
> @@ -0,0 +1,42 @@
> +Bindings for Synopsys DesignWare I3C master block
> +=
> +
> +Required properties:
> +
> +- compatible: shall be "snps,dw-i3c-master-1.00a"
> +- clocks: shall reference the core_clk
Are you sure this IP only requires only one clock? If you're unsure,
you'd better have a clock-names prop.
> +- interrupts: the interrupt line connected to this I3C master
> +- reg: Offset and length of I3C master registers
> +
> +Mandatory properties defined by the generic binding (see
> +Documentation/devicetree/bindings/i3c/i3c.txt for more details):
> +
> +- #address-cells: shall be set to 3
> +- #size-cells: shall be set to 0
> +
> +Optional properties defined by the generic binding (see
> +Documentation/devicetree/bindings/i3c/i3c.txt for more details):
> +
> +- i2c-scl-hz
> +- i3c-scl-hz
> +
> +I3C device connected on the bus follow the generic description (see
> +Documentation/devicetree/bindings/i3c/i3c.txt for more details).
> +
> +Example:
> +
> + i3c-master@2000 {
> + compatible = "snps,dw-i3c-master-1.00a";
> + #address-cells = <3>;
> + #size-cells = <0>;
> + reg = <0x02000 0x1000>;
> + interrupts = <0>;
> + clocks = <&i3cclk>;
> +
> + eeprom@57{
> + compatible = "atmel,24c01";
> + reg = < 0x57 0x0 0x10>;
^ remove this white space.
> + pagesize = <0x8>;
> + };
> + };
> +
Re: [PATCH v10 0/9] Add the I3C subsystem
+Mark Brown for the question about /dev/spidev Hi Vitor, On Thu, 15 Nov 2018 12:14:37 + vitor wrote: > Hi Boris, > > Given the current state of the subsystem I think it might worth start to > think how to expose the devices under /dev. Thanks for starting this discussion. I'm not against the idea in general, we just need to be careful when doing that. > My initial thoughts are to do the same think as for i2c, expose the > buses or the i3c_devices and use ioctl for private transfers. Exposing the bus is dangerous IMO, because an I3C bus is not like an I2C bus: * I3C device needs to be discovered through DAA * I2C devices need to be declared ahead of time, and LVR is used to determine the limitations on the bus at runtime So you'd anyway be able to interact only with devices that have previously been discovered. Note that the virtual I2C bus is already exposed, but any command targeting an address that is not attached to a registered I2C dev will get a -ENOENT error. What we could do though, is expose I3C devices that do not have a driver in kernel space, like spidev does. > Some > direct CCC commands can be sent through the /sys as you plan for SETNEWDA . Yes, CCC commands that need to be exposed to userspace should be exposed through sysfs, or, if we decide to create a /dev/i3cX device per bus, through ioctls. > > What do you think about this? I think this request is perfectly valid, we just need to decide how it should be done, and before we take this decision, I'd like to get inputs from other maintainers. Mark, Wolfram, Arnd, Greg, any opinion? Regards, Boris
Re: [PATCH v10 0/9] Add the I3C subsystem
On Thu, 15 Nov 2018 16:01:37 +0100 Wolfram Sang wrote: > Hi Boris, > > > What we could do though, is expose I3C devices that do not have a > > driver in kernel space, like spidev does. > > ... > > > Mark, Wolfram, Arnd, Greg, any opinion? > > Is there a benefit for having drivers in userspace? My gut feeling is to > encourage people to write kernel drivers. If this is, for some reason, > not possible for some driver, then we have a use case at hand to test > the then-to-be-developed userspace interface against. Until then, I > personally wouldn't waste effort on designing it without a user in > sight. I kind of agree with that. Vitor, do you have a use case in mind for such userspace drivers? I don't think it's worth designing an API for something we don't need (yet).
Re: [PATCH v10 0/9] Add the I3C subsystem
On Thu, 15 Nov 2018 18:03:47 + vitor wrote: > Hi Boris, > > > On 15/11/18 15:28, Boris Brezillon wrote: > > On Thu, 15 Nov 2018 16:01:37 +0100 > > Wolfram Sang wrote: > > > >> Hi Boris, > >> > >>> What we could do though, is expose I3C devices that do not have a > >>> driver in kernel space, like spidev does. > >> ... > >> > >>> Mark, Wolfram, Arnd, Greg, any opinion? > >> Is there a benefit for having drivers in userspace? My gut feeling is to > >> encourage people to write kernel drivers. If this is, for some reason, > >> not possible for some driver, then we have a use case at hand to test > >> the then-to-be-developed userspace interface against. Until then, I > >> personally wouldn't waste effort on designing it without a user in > >> sight. > > I kind of agree with that. Vitor, do you have a use case in mind for > > such userspace drivers? I don't think it's worth designing an API for > > something we don't need (yet). > > My use case is a tool for tests, lets say like the i2c tools. What would you like to test exactly? > There is > other subsystems, some of them mentioned on this thread, that have and > ioctl system call or other method to change parameters or send data. I don't think they added the /dev interface before having a real use case for it. > > > I rise this topic because I really think it worth to define now how this > should be design (and for me how to do the things right) to avoid future > issues. Actually it should be done the other way around: you should have a real need and the /dev interface should be designed to fulfill this need. Based on this real use case we can discuss other potential usage that might appear in the future and try to design something more future-proof, but clearly, this userspace interface should be driven by a real/well-defined use case. Also, exposing things to userspace is way more risky than adding a new in-kernel subsystem/framework, because it then becomes part of the stable ABI. To make things clearer, I'm not against the idea of exposing I3C devices (or I3C buses) to userspace, but I'd like to understand what you plan to do with that. If this is about testing, what kind of tests you'd like to run. If this is about developing drivers in userspace, why can't these be done in kernel space (license issues?), and what would those drivers be allowed to do?
Re: [PATCH v10 0/9] Add the I3C subsystem
On Thu, 15 Nov 2018 15:25:11 + vitor wrote: > Hi Arnd, > > On 15/11/18 14:25, Arnd Bergmann wrote: > > I agree about better not exposing the bus as a /dev/i3c* node, and that we > > probably do need to expose individual devices in some form to allow > > writing complete user space drivers that can do everything a kernel driver > > can do. > > > > Can you describe what a low-level interface to the device looks like > > in the kernel? Can this be abstracted as simply pread()/pwrite() plus > > an interrupt mechanism, or do we need a set of ioctl() operations as > > well? > > Like in i2c is likely to need the ioctl() too. Yep, I think we'll need an ioctl given the various type of transfers one case use to interact with a device.
Re: [PATCH v4 0/3] Add driver for Synopsys DesignWare I3C master IP
On Tue, 13 Nov 2018 14:09:50 + Vitor Soares wrote: > This patch series is a proposal for the I3C master driver for Synopsys IP. > This patch is to be applied on top of I3C subsystem RFC V10 submitted by > Boris Brezillon. > > Supported features: > Regular CCC commands. > I3C private transfers. > I2C transfers. > > Missing functionalities: > Support DMA interface. > Support for I3C_BUS_MODE_MIXED_SLOW. > Hot-join. > IBI. Patchset queued to i3c/next. Thanks, Boris > > Main change between v3 and v4: > - Minor fixes. They are described in each patch > > Main change between v2 and v3: > - Minor fixes. They are described in each patch > > Main change between v1 and v2: > - Add controller version on dt-binding > - The driver now calls writesl/readsl() instead readl/writel > - Rename some variables in the driver > > Vitor Soares (3): > i3c: master: Add driver for Synopsys DesignWare IP > dt-binding: i3c: Document Synopsys DesignWare I3C > MAINTAINERS: Add myself as the dw-i3c-master module maintainer > > .../devicetree/bindings/i3c/snps,dw-i3c-master.txt | 41 + > MAINTAINERS|6 + > drivers/i3c/master/Kconfig | 14 + > drivers/i3c/master/Makefile|1 + > drivers/i3c/master/dw-i3c-master.c | 1216 > > 5 files changed, 1278 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt > create mode 100644 drivers/i3c/master/dw-i3c-master.c >
Re: [PATCH 3/9] drm: replace "drm_dev_unref" function with "drm_dev_put"
On Thu, 15 Nov 2018 23:16:23 +0100
Fernando Ramos wrote:
> This patch unifies the naming of DRM functions for reference counting as
> requested on Documentation/gpu/todo.rst
>
> Signed-off-by: Fernando Ramos
> ---
> drivers/gpu/drm/arc/arcpgu_drv.c | 4 ++--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 ++--
For the Atmel HLCDC driver
Acked-by: Boris Brezillon
> drivers/gpu/drm/etnaviv/etnaviv_drv.c| 4 ++--
> drivers/gpu/drm/mxsfb/mxsfb_drv.c| 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++--
> drivers/gpu/drm/tve200/tve200_drv.c | 4 ++--
> drivers/gpu/drm/zte/zx_drm_drv.c | 4 ++--
> 8 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index f067de4e1e82..dcb06d4e9135 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -216,7 +216,7 @@ static int arcpgu_probe(struct platform_device *pdev)
> arcpgu_unload(drm);
>
> err_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return ret;
> }
> @@ -227,7 +227,7 @@ static int arcpgu_remove(struct platform_device *pdev)
>
> drm_dev_unregister(drm);
> arcpgu_unload(drm);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 843cac222e60..f8da51a63e2f 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -775,7 +775,7 @@ static int atmel_hlcdc_dc_drm_probe(struct
> platform_device *pdev)
> atmel_hlcdc_dc_unload(ddev);
>
> err_unref:
> - drm_dev_unref(ddev);
> + drm_dev_put(ddev);
>
> return ret;
> }
> @@ -786,7 +786,7 @@ static int atmel_hlcdc_dc_drm_remove(struct
> platform_device *pdev)
>
> drm_dev_unregister(ddev);
> atmel_hlcdc_dc_unload(ddev);
> - drm_dev_unref(ddev);
> + drm_dev_put(ddev);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 83c1f46670bf..52802e6049e0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -550,7 +550,7 @@ static int etnaviv_bind(struct device *dev)
> out_bind:
> kfree(priv);
> out_unref:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return ret;
> }
> @@ -567,7 +567,7 @@ static void etnaviv_unbind(struct device *dev)
> drm->dev_private = NULL;
> kfree(priv);
>
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
> }
>
> static const struct component_master_ops etnaviv_master_ops = {
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 2393e6d16ffd..88ba003979e6 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -417,7 +417,7 @@ static int mxsfb_probe(struct platform_device *pdev)
> err_unload:
> mxsfb_unload(drm);
> err_free:
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return ret;
> }
> @@ -428,7 +428,7 @@ static int mxsfb_remove(struct platform_device *pdev)
>
> drm_dev_unregister(drm);
> mxsfb_unload(drm);
> - drm_dev_unref(drm);
> + drm_dev_put(drm);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 084f58df4a8c..c7fe2433ab9e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -454,7 +454,7 @@ static int rcar_du_remove(struct platform_device *pdev)
> drm_kms_helper_poll_fini(ddev);
> drm_mode_config_cleanup(ddev);
>
> - drm_dev_unref(ddev);
> + drm_dev_put(ddev);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 6ececad6f845..8554102a6ead 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -194,7 +194,7 @@ static int shmob_drm_remove(struct platform_device *pdev)
> drm_kms_helper_poll_fini(ddev);
> drm_mode_config_cleanup(ddev);
> drm_irq_uninstall(ddev);
> - drm_dev_unref(ddev);
> + drm_dev_put(ddev);
>
> return 0;
> }
> @@ -290,7 +290,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
>
Re: [PATCH v10 0/9] Add the I3C subsystem
On Fri, 16 Nov 2018 12:31:42 + vitor wrote: > Hi Boris, > > > On 15/11/18 19:00, Boris Brezillon wrote: > > On Thu, 15 Nov 2018 18:03:47 + > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 15/11/18 15:28, Boris Brezillon wrote: > >>> On Thu, 15 Nov 2018 16:01:37 +0100 > >>> Wolfram Sang wrote: > >>> > >>>> Hi Boris, > >>>> > >>>>> What we could do though, is expose I3C devices that do not have a > >>>>> driver in kernel space, like spidev does. > >>>> ... > >>>> > >>>>> Mark, Wolfram, Arnd, Greg, any opinion? > >>>> Is there a benefit for having drivers in userspace? My gut feeling is to > >>>> encourage people to write kernel drivers. If this is, for some reason, > >>>> not possible for some driver, then we have a use case at hand to test > >>>> the then-to-be-developed userspace interface against. Until then, I > >>>> personally wouldn't waste effort on designing it without a user in > >>>> sight. > >>> I kind of agree with that. Vitor, do you have a use case in mind for > >>> such userspace drivers? I don't think it's worth designing an API for > >>> something we don't need (yet). > >> My use case is a tool for tests, lets say like the i2c tools. > > What would you like to test exactly? > > > >> There is > >> other subsystems, some of them mentioned on this thread, that have and > >> ioctl system call or other method to change parameters or send data. > > I don't think they added the /dev interface before having a real use > > case for it. > > > >> > >> I rise this topic because I really think it worth to define now how this > >> should be design (and for me how to do the things right) to avoid future > >> issues. > > Actually it should be done the other way around: you should have a real > > need and the /dev interface should be designed to fulfill this need. > > Based on this real use case we can discuss other potential usage that > > might appear in the future and try to design something more > > future-proof, but clearly, this userspace interface should be driven by > > a real/well-defined use case. > > > > Also, exposing things to userspace is way more risky than adding a new > > in-kernel subsystem/framework, because it then becomes part of the > > stable ABI. > > > > To make things clearer, I'm not against the idea of exposing I3C > > devices (or I3C buses) to userspace, but I'd like to understand what you > > plan to do with that. If this is about testing, what kind of tests > > you'd like to run. If this is about developing drivers in userspace, > > why can't these be done in kernel space (license issues?), and what > > would those drivers be allowed to do? > > > Basically I need a tool that help me during the development and to avoid > me to write a dummy driver for each device that I test. But we want I3C device drivers to be upstreamed, so why not developing a real driver everytime you test a new device and submitting it upstream? > > For instances do some read/write, Doing SDR/DDR transfers is probably acceptable, but I still think we should push hard to have kernel drivers when that's possible. > get/set ccc commands, Exposing CCC commands is definitely not a good idea, since they're not even exposed to kernel drivers. > if something > goes wrong during the bus initialization have a to debug etc... Can't we add such a debug infrastructure in the kernel. Maybe we can expose debugfs files too if that helps, though if those debugfs files are actually used by userspace libs/tools, it's not any better than ioctls or sysfs files, since they will anyway become a stable ABI. > > > For me this is a valid use case and I imagine when people start to > develop in i3c this interface will help everyone. How about you propose an i3cdev driver that allow users to do SDR transfers throuh an ioctl?
Re: [PATCH v10 0/9] Add the I3C subsystem
On Mon, 19 Nov 2018 12:35:42 + vitor wrote: > Hi Boris, > > On 16/11/18 13:16, Boris Brezillon wrote: > > On Fri, 16 Nov 2018 12:31:42 + > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 15/11/18 19:00, Boris Brezillon wrote: > >>> On Thu, 15 Nov 2018 18:03:47 + > >>> vitor wrote: > >>> > >>>> Hi Boris, > >>>> > >>>> > >>>> On 15/11/18 15:28, Boris Brezillon wrote: > >>>>> On Thu, 15 Nov 2018 16:01:37 +0100 > >>>>> Wolfram Sang wrote: > >>>>> > >>>>>> Hi Boris, > >>>>>> > >>>>>>> What we could do though, is expose I3C devices that do not have a > >>>>>>> driver in kernel space, like spidev does. > >>>>>> ... > >>>>>> > >>>>>>> Mark, Wolfram, Arnd, Greg, any opinion? > >>>>>> Is there a benefit for having drivers in userspace? My gut feeling is > >>>>>> to > >>>>>> encourage people to write kernel drivers. If this is, for some reason, > >>>>>> not possible for some driver, then we have a use case at hand to test > >>>>>> the then-to-be-developed userspace interface against. Until then, I > >>>>>> personally wouldn't waste effort on designing it without a user in > >>>>>> sight. > >>>>> I kind of agree with that. Vitor, do you have a use case in mind for > >>>>> such userspace drivers? I don't think it's worth designing an API for > >>>>> something we don't need (yet). > >>>> My use case is a tool for tests, lets say like the i2c tools. > >>> What would you like to test exactly? > >>> > >>>> There is > >>>> other subsystems, some of them mentioned on this thread, that have and > >>>> ioctl system call or other method to change parameters or send data. > >>> I don't think they added the /dev interface before having a real use > >>> case for it. > >>> > >>>> I rise this topic because I really think it worth to define now how this > >>>> should be design (and for me how to do the things right) to avoid future > >>>> issues. > >>> Actually it should be done the other way around: you should have a real > >>> need and the /dev interface should be designed to fulfill this need. > >>> Based on this real use case we can discuss other potential usage that > >>> might appear in the future and try to design something more > >>> future-proof, but clearly, this userspace interface should be driven by > >>> a real/well-defined use case. > >>> > >>> Also, exposing things to userspace is way more risky than adding a new > >>> in-kernel subsystem/framework, because it then becomes part of the > >>> stable ABI. > >>> > >>> To make things clearer, I'm not against the idea of exposing I3C > >>> devices (or I3C buses) to userspace, but I'd like to understand what you > >>> plan to do with that. If this is about testing, what kind of tests > >>> you'd like to run. If this is about developing drivers in userspace, > >>> why can't these be done in kernel space (license issues?), and what > >>> would those drivers be allowed to do? > >> > >> Basically I need a tool that help me during the development and to avoid > >> me to write a dummy driver for each device that I test. > > But we want I3C device drivers to be upstreamed, so why not developing a > > real driver everytime you test a new device and submitting it upstream? > > > Usually the devices that I test aren't the final product so it isn't > easy to do the upstream. > > But when possible I plan to do that. > > > > > >> For instances do some read/write, > > Doing SDR/DDR transfers is probably acceptable, but I still think we > > should push hard to have kernel drivers when that's possible. > > > >> get/set ccc commands, > > Exposing CCC commands is definitely not a good idea, since they're not > > even exposed to kernel drivers. > > > >> if something > >> goes wrong during the bus initialization have a to debug etc... > > Can't we add such a debug infrastructure in the kernel. Maybe we can > > expose debugfs files too if that helps, though if those debugfs files > > are actually used by userspace libs/tools, it's not any better than > > ioctls or sysfs files, since they will anyway become a stable ABI. > > > >> > >> For me this is a valid use case and I imagine when people start to > >> develop in i3c this interface will help everyone. > > How about you propose an i3cdev driver that allow users to do SDR > > transfers throuh an ioctl? > > I think that was for v6 I started to something to expose the bus like in > i2c-dev, but I liked the idea of expose only the device doesn't have a > driver. Do you know if there is already something in the kernel doing > the same? I know [1], but there might be other subsystems doing the same thing. [1]https://elixir.bootlin.com/linux/v4.20-rc3/source/drivers/spi/spidev.c
Re: [PATCH] kbuild: announce removal of SUBDIRS if used
On Wed, 21 Nov 2018 00:04:18 +0900
Masahiro Yamada wrote:
> SUBDIRS has been kept as a backward compatibility since
> commit ("[PATCH] kbuild: external module support") in 2002.
>
> We do not need multiple ways to do the same thing, so I will remove
> SUBDIRS after the Linux 5.3 release. I cleaned up in-tree code, and
> updated the document so that nobody would try to use it.
>
> Meanwhile, display the following warning if SUBDIRS is used.
>
> Makefile:189: = WARNING
> Makefile:190: 'SUBDIRS' will be removed after Linux 5.3
> Makefile:191: Please use 'M=' or 'KBUILD_EXTMOD' instead
> Makefile:192: ==
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Documentation/kbuild/kbuild.txt| 7 +--
> Makefile | 4
> drivers/mtd/maps/scx200_docflash.c | 7 ---
For the docflash driver
Acked-by: Boris Brezillon
> drivers/watchdog/scx200_wdt.c | 7 ---
> samples/connector/Makefile | 2 +-
> 5 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
> index 8390c36..c9e3d93 100644
> --- a/Documentation/kbuild/kbuild.txt
> +++ b/Documentation/kbuild/kbuild.txt
> @@ -81,12 +81,7 @@ KBUILD_EXTMOD
> --
> Set the directory to look for the kernel source when building external
> modules.
> -The directory can be specified in several ways:
> -1) Use "M=..." on the command line
> -2) Environment variable KBUILD_EXTMOD
> -3) Environment variable SUBDIRS
> -The possibilities are listed in the order they take precedence.
> -Using "M=..." will always override the others.
> +Setting "M=..." takes precedence over KBUILD_EXTMOD.
>
> KBUILD_OUTPUT
> --
> diff --git a/Makefile b/Makefile
> index 370d13b..57be5fb 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -186,6 +186,10 @@ endif
> # Old syntax make ... SUBDIRS=$PWD is still supported
> # Setting the environment variable KBUILD_EXTMOD take precedence
> ifdef SUBDIRS
> + $(warning = WARNING )
> + $(warning 'SUBDIRS' will be removed after Linux 5.3)
> + $(warning Please use 'M=' or 'KBUILD_EXTMOD' instead)
> + $(warning ==)
>KBUILD_EXTMOD ?= $(SUBDIRS)
> endif
>
> diff --git a/drivers/mtd/maps/scx200_docflash.c
> b/drivers/mtd/maps/scx200_docflash.c
> index f1c1f73..7f1a0e6 100644
> --- a/drivers/mtd/maps/scx200_docflash.c
> +++ b/drivers/mtd/maps/scx200_docflash.c
> @@ -216,10 +216,3 @@ static void __exit cleanup_scx200_docflash(void)
>
> module_init(init_scx200_docflash);
> module_exit(cleanup_scx200_docflash);
> -
> -/*
> -Local variables:
> -compile-command: "make -k -C ../../.. SUBDIRS=drivers/mtd/maps
> modules"
> -c-basic-offset: 8
> -End:
> -*/
> diff --git a/drivers/watchdog/scx200_wdt.c b/drivers/watchdog/scx200_wdt.c
> index 836377c..ec4063e 100644
> --- a/drivers/watchdog/scx200_wdt.c
> +++ b/drivers/watchdog/scx200_wdt.c
> @@ -262,10 +262,3 @@ static void __exit scx200_wdt_cleanup(void)
>
> module_init(scx200_wdt_init);
> module_exit(scx200_wdt_cleanup);
> -
> -/*
> -Local variables:
> - compile-command: "make -k -C ../.. SUBDIRS=drivers/char modules"
> - c-basic-offset: 8
> -End:
> -*/
> diff --git a/samples/connector/Makefile b/samples/connector/Makefile
> index fe3c854..6ad7162 100644
> --- a/samples/connector/Makefile
> +++ b/samples/connector/Makefile
> @@ -14,4 +14,4 @@ HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include
> all: modules
>
> modules clean:
> - $(MAKE) -C ../.. SUBDIRS=$(CURDIR) $@
> + $(MAKE) -C ../.. M=$(CURDIR) $@
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Thu, 22 Nov 2018 17:54:54 +
Vitor Soares wrote:
> From: Vitor Soares
>
> This patch slipts dw-i3c-master.c into three pieces:
> dw-i3c-master.c - contains the code that interacts directly with the
> core in master mode.
>
> dw-i3c-platdrv.c - contains the code specific to the platform driver.
>
> dw-i3c-core.h - contains the definitions and declarations shared by
> dw-i3c-master and dw-i3c-platdrv
>
> This patch will allow SOC integrators to add their code specific to
> DesignWare I3C IP.
Isn't it too early to do this change? Can't we wait until we have a SoC
that actually embeds this IP?
>
> Signed-off-by: Vitor Soares
> ---
> drivers/i3c/master/Kconfig | 9 +-
> drivers/i3c/master/Makefile | 5 +-
> drivers/i3c/master/dw-i3c-core.h| 214 ++
> drivers/i3c/master/dw-i3c-master.c | 299
> ++--
> drivers/i3c/master/dw-i3c-platdrv.c | 112 ++
I'd prefer to have a dw/ subdir where you'd place all dw files.
> 5 files changed, 349 insertions(+), 290 deletions(-)
> create mode 100644 drivers/i3c/master/dw-i3c-core.h
> create mode 100644 drivers/i3c/master/dw-i3c-platdrv.c
>
> diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
> index 8ee1ce6..fdc6e46 100644
> --- a/drivers/i3c/master/Kconfig
> +++ b/drivers/i3c/master/Kconfig
> @@ -5,9 +5,14 @@ config CDNS_I3C_MASTER
> help
> Enable this driver if you want to support Cadence I3C master block.
>
> -config DW_I3C_MASTER
> - tristate "Synospsys DesignWare I3C master driver"
> +config DW_I3C_CORE
> + tristate
> +
> +config DW_I3C_PLATFORM
> + tristate "Synospsys DesignWare I3C Platform driver"
> + select DW_I3C_CORE
> depends on I3C
> + depends on HAS_IOMEM
> depends on !(ALPHA || PARISC)
> # ALPHA and PARISC needs {read,write}sl()
> help
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
> index fc53939..004ad1c 100644
> --- a/drivers/i3c/master/Makefile
> +++ b/drivers/i3c/master/Makefile
> @@ -1,2 +1,5 @@
> obj-$(CONFIG_CDNS_I3C_MASTER)+= i3c-master-cdns.o
> -obj-$(CONFIG_DW_I3C_MASTER) += dw-i3c-master.o
> +obj-$(CONFIG_DW_I3C_CORE)+= dw-i3c-core.o
> +dw-i3c-core-objs := dw-i3c-master.o
> +obj-$(CONFIG_DW_I3C_PLATFORM)+= dw-i3c-platform.o
> +dw-i3c-platform-objs := dw-i3c-platdrv.o
Do we really have to create one module for the core and one per SoC?
Can't we have everything in the same .ko?
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Fri, 23 Nov 2018 12:39:31 + vitor wrote: > Hi Boris, > > > On 22/11/18 20:02, Boris Brezillon wrote: > > On Thu, 22 Nov 2018 17:54:54 + > > Vitor Soares wrote: > > > >> From: Vitor Soares > >> > >> This patch slipts dw-i3c-master.c into three pieces: > >>dw-i3c-master.c - contains the code that interacts directly with the > >>core in master mode. > >> > >>dw-i3c-platdrv.c - contains the code specific to the platform driver. > >> > >>dw-i3c-core.h - contains the definitions and declarations shared by > >>dw-i3c-master and dw-i3c-platdrv > >> > >> This patch will allow SOC integrators to add their code specific to > >> DesignWare I3C IP. > > Isn't it too early to do this change? Can't we wait until we have a SoC > > that actually embeds this IP? > > > I'm trying to turn it more flexible so the other can reuse the code. Looking at the separation you've done here, I don't see why you need it. All the resources you request are generic, so why not just adding a new compat in the of_match_table? > > > > > >> Signed-off-by: Vitor Soares > >> --- > >> drivers/i3c/master/Kconfig | 9 +- > >> drivers/i3c/master/Makefile | 5 +- > >> drivers/i3c/master/dw-i3c-core.h| 214 ++ > >> drivers/i3c/master/dw-i3c-master.c | 299 > >> ++-- > >> drivers/i3c/master/dw-i3c-platdrv.c | 112 ++ Just realized the driver is named dw-i3c-master, while the cadence driver is named i3c-master-cdns.c. I'll send a patch to make that consistent and follow the initial naming scheme: i3c-master-.c.
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Mon, 26 Nov 2018 12:06:24 + vitor wrote: > Hi Boris, > > > On 23/11/18 12:50, Boris Brezillon wrote: > > On Fri, 23 Nov 2018 12:39:31 + > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 22/11/18 20:02, Boris Brezillon wrote: > >>> On Thu, 22 Nov 2018 17:54:54 + > >>> Vitor Soares wrote: > >>> > >>>> From: Vitor Soares > >>>> > >>>> This patch slipts dw-i3c-master.c into three pieces: > >>>> dw-i3c-master.c - contains the code that interacts directly with the > >>>> core in master mode. > >>>> > >>>> dw-i3c-platdrv.c - contains the code specific to the platform driver. > >>>> > >>>> dw-i3c-core.h - contains the definitions and declarations shared by > >>>> dw-i3c-master and dw-i3c-platdrv > >>>> > >>>> This patch will allow SOC integrators to add their code specific to > >>>> DesignWare I3C IP. > >>> Isn't it too early to do this change? Can't we wait until we have a SoC > >>> that actually embeds this IP? > >> > >> I'm trying to turn it more flexible so the other can reuse the code. > > Looking at the separation you've done here, I don't see why you need > > it. All the resources you request are generic, so why not just adding a > > new compat in the of_match_table? > > I understand your point. > > > I'm just following what it's done in others Synopsys drivers and what I > expect is that in the future we will have the same for the I3C. > > Some of the current generic functions might be override according with > SoC requirements (e.g i2c-designware, pcie-designware). > > > for now what do you prefer? > I prefer that we keep the driver as is until we actually need to split things up. > >> > >>> > >>>> Signed-off-by: Vitor Soares > >>>> --- > >>>>drivers/i3c/master/Kconfig | 9 +- > >>>>drivers/i3c/master/Makefile | 5 +- > >>>>drivers/i3c/master/dw-i3c-core.h| 214 ++ > >>>>drivers/i3c/master/dw-i3c-master.c | 299 > >>>> ++-- > >>>>drivers/i3c/master/dw-i3c-platdrv.c | 112 ++ > > Just realized the driver is named dw-i3c-master, while the cadence > > driver is named i3c-master-cdns.c. I'll send a patch to make that > > consistent and follow the initial naming scheme: i3c-master-.c. > > As I shared with you in previous email, the structure that I have in > mind is this one: > > - core.h (or common.h, any though?) > > - common.c > > - master.c > > - slave.c > > > so for me doesn't make sense to have for instance: i3c-master-dw-slave.c If you have several files and they're all placed in a dw/ subdir, then I agree, prefixing everything with i3c-master- is useless, as you'll have to define a custom rule to create the i3c-master-dw.ko object. When there's a single source file, and this source file is directly used to create a .ko, we need this prefix, otherwise we would have dw.ko, and this would basically conflict with any other designware driver that does not have a proper prefix. > > But seeing what is already in the kernel I wasn't coherent and it should > be named to i3c-designware-master.c Actually it's i3c-master-designware.c (or i3c-master-dw.c) if we follow what's been done for the cadence driver. > > > or > > > follow this https://lkml.org/lkml/2017/7/12/430 And I agree with Linus on this, except that does not apply to single source file drivers. > > > This topic rise another one related with the master folder. I understand > that now the subsystem doesn't have slave support but the name is > limited. Isn't better to have something like controller or busses? What > do you have in mind for the slave? drivers/i3c/slave/... for slave drivers and drivers/i3c/slave.c for the framework, just like we have drivers/i3c/master/ for master controller drivers and drivers/i3c/master.c.
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Mon, 26 Nov 2018 18:33:37 + vitor wrote: > On 26/11/18 12:35, Boris Brezillon wrote: > > On Mon, 26 Nov 2018 12:06:24 + > > vitor wrote: > > > >> Hi Boris, > >> > >> > >> On 23/11/18 12:50, Boris Brezillon wrote: > >>> On Fri, 23 Nov 2018 12:39:31 + > >>> vitor wrote: > >>> > >>>> Hi Boris, > >>>> > >>>> > >>>> On 22/11/18 20:02, Boris Brezillon wrote: > >>>>> On Thu, 22 Nov 2018 17:54:54 + > >>>>> Vitor Soares wrote: > >>>>> > >>>>>> From: Vitor Soares > >>>>>> > >>>>>> This patch slipts dw-i3c-master.c into three pieces: > >>>>>>dw-i3c-master.c - contains the code that interacts directly > >>>>>> with the > >>>>>>core in master mode. > >>>>>> > >>>>>>dw-i3c-platdrv.c - contains the code specific to the platform > >>>>>> driver. > >>>>>> > >>>>>>dw-i3c-core.h - contains the definitions and declarations > >>>>>> shared by > >>>>>>dw-i3c-master and dw-i3c-platdrv > >>>>>> > >>>>>> This patch will allow SOC integrators to add their code specific to > >>>>>> DesignWare I3C IP. > >>>>> Isn't it too early to do this change? Can't we wait until we have a SoC > >>>>> that actually embeds this IP? > >>>> I'm trying to turn it more flexible so the other can reuse the code. > >>> Looking at the separation you've done here, I don't see why you need > >>> it. All the resources you request are generic, so why not just adding a > >>> new compat in the of_match_table? > >> I understand your point. > >> > >> > >> I'm just following what it's done in others Synopsys drivers and what I > >> expect is that in the future we will have the same for the I3C. > >> > >> Some of the current generic functions might be override according with > >> SoC requirements (e.g i2c-designware, pcie-designware). > >> > >> > >> for now what do you prefer? > >> > > I prefer that we keep the driver as is until we actually need to split > > things up. > > This is already done and will benefit everyone: > > - for me is better do it now than the secondary master and slave > development. Sorry, I don't get that one. > > - for the others it will easy the SoC integration avoiding > duplicated work and doing things from scratch. What would be duplicated? You want to support a new SoC, just add a new entry in the of_match_table and you're done. When you need to add SoC/integration specific stuff, create a struct and attach a different instance per-compatible so that each SoC can have its own configuration (or even init sequence if needed). That's how we do for pretty much all IPs out there, why should designware ones be different? > > > > > >>>> > >>>>> > >>>>>> Signed-off-by: Vitor Soares > >>>>>> --- > >>>>>> drivers/i3c/master/Kconfig | 9 +- > >>>>>> drivers/i3c/master/Makefile | 5 +- > >>>>>> drivers/i3c/master/dw-i3c-core.h| 214 > >>>>>> ++ > >>>>>> drivers/i3c/master/dw-i3c-master.c | 299 > >>>>>> ++-- > >>>>>> drivers/i3c/master/dw-i3c-platdrv.c | 112 ++ > >>> Just realized the driver is named dw-i3c-master, while the cadence > >>> driver is named i3c-master-cdns.c. I'll send a patch to make that > >>> consistent and follow the initial naming scheme: i3c-master-.c. > >> As I shared with you in previous email, the structure that I have in > >> mind is this one: > >> > >> - core.h (or common.h, any though?) > >> > >> - common.c > >> > >> - master.c > >> > >> - slave.c > >> > >> > >> so for me doesn't make sense to have for instance: i3c-master-dw-slave.c > > If you have several files and they're all placed in a dw/ subdir, then > > I agree, prefixing everything with i
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Mon, 26 Nov 2018 19:56:18 +0100 Boris Brezillon wrote: > > > > - for the others it will easy the SoC integration avoiding > > duplicated work and doing things from scratch. > > What would be duplicated? You want to support a new SoC, just add a new > entry in the of_match_table and you're done. When you need to add > SoC/integration specific stuff, create a struct and attach a different > instance per-compatible so that each SoC can have its own configuration > (or even init sequence if needed). That's how we do for pretty much all > IPs out there, why should designware ones be different? To be more specific, I'd like a real example that shows why the separation is needed.
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Mon, 26 Nov 2018 19:28:02 + vitor wrote: > On 26/11/18 19:08, Boris Brezillon wrote: > > On Mon, 26 Nov 2018 19:56:18 +0100 > > Boris Brezillon wrote: > > > >>> - for the others it will easy the SoC integration avoiding > >>> duplicated work and doing things from scratch. > >> What would be duplicated? You want to support a new SoC, just add a new > >> entry in the of_match_table and you're done. When you need to add > >> SoC/integration specific stuff, create a struct and attach a different > >> instance per-compatible so that each SoC can have its own configuration > >> (or even init sequence if needed). That's how we do for pretty much all > >> IPs out there, why should designware ones be different? > > To be more specific, I'd like a real example that shows why the > > separation is needed. > > Ok no problem. We can delay this for PCI and other rules support. I finally understand what this separation is all about: supporting both PCI and platform devices. I guess I've been distracted by this sentence: " This patch will allow SOC integrators to add their code specific to DesignWare I3C IP. " which for me meant each SoC would have its own platform_driver. In any case, I think this is a bit premature do this separation, unless you already know about one integrator planning to expose this IP over PCI.
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Mon, 26 Nov 2018 20:11:39 +
vitor wrote:
> >>> I prefer that we keep the driver as is until we actually need to split
> >>> things up.
> >> This is already done and will benefit everyone:
> >>
> >> - for me is better do it now than the secondary master and slave
> >> development.
> > Sorry, I don't get that one.
>
>
> I already share my plan with you. See the structure above.
My point is, I don't get the relationship between your patch and
secondary-master/slave-mode support.
> This topic rise another one related with the master folder. I understand
> that now the subsystem doesn't have slave support but the name is
> limited. Isn't better to have something like controller or busses? What
> do you have in mind for the slave?
> >>> drivers/i3c/slave/... for slave drivers and drivers/i3c/slave.c for the
> >>> framework, just like we have drivers/i3c/master/ for master controller
> >>> drivers and drivers/i3c/master.c.
> >> I have to disagree here. I don't see any place on the kernel with
> >> .../master/ and ../slave/ folders and it is very likely that both rules
> >> will have some common code.
> > I see at least one that uses this model: the USB framework
> > (drivers/usb/gadget/ for device controllers and drivers/usb/host/ for
> > host controllers). Given that I3C is closer to USB than I2C I initially
> > decided to keep this separation. Maybe I'm wrong, but I'd like to
> > understand why you think it's not appropriate.
>
>
> You can say there some features from USB in I3C but cannot compare USB
> vs I3C since they are in different championships.
I maintain that functionally, I3C is closer to USB than I2C. That does
not mean that it's competing with USB performance-wise, it just means
that the SW stack is likely to resemble the USB one (probably a bit
simpler, at least at the beginning).
>
> The aim of I3C is to fill the gaps discovery on I2C over the years but
> still keeping its simplicity not to go to the complexity of USB.
Look at the bus discovery mechanism, the notion of DCR (close to the
concept of USB class), or the fact that each dev has a unique
manufacturer+PID pair (which resemble the product/vendor ID concept)
that allows us to easily bind a dev to a driver without requiring a
static description.
>
>
> I'm not sure but I think that a controller cannot change between gadget
> to host in USB in runtime.
That's called USB OTG. Okay, to be fair, it's not exactly the same, and
the mastership handover in I3C is probably more complex than what we
have with USB OTG (I'm not a USB expert, so I might be wrong here).
> Even so, this kind of behavior is more likely
> to have in an I3C bus.
Maybe.
>
>
> >
> >> With this structure the user will have the code spread in /master and
> >> /slave folders...
> > Not sure who you call "user" here, but yes, master controller and slave
> > controller drivers would be placed in different dirs.
> >
> >>
> >> I would like you consider to change the folder name and the names rules
> >> to something like in i2c.
> > Why? And more importantly, why is this coming up now? You've been
> > reviewing the framework since the beginning, and never complained about
> > the subdirs/files organization so far.
>
>
> Sorry for that and don't take me wrong... maybe I should rise this
> question early but this only came up now when I started splitting and
> thinking where to put what is for master for slave, what is common and
> the thing of putting everything of controller in a folder.
So you have such a dual-role controller? I mean, Cadence IP has a dummy
GPIO mode in its Master IP when is operating in slave mode (secondary
master, or main master after it's released the bus), but I'm not sure
this was designed for anything else but testing.
What I call a slave controller would be something that lets you reply to
SDR/DDR transactions or fill a generic regmap that would be exposed to
other masters on the bus. This way we could implement generic slave
drivers in Linux (the same way we have gadget drivers). Anything else
is likely to be to specific to be exposed as a generic framework.
>
>
> Taking the USB as exemple do you prefer a dwc folder on i3c root?
Hm, not sure I like this idea either. So I see 2 options:
1/ put all controller drivers (both master and slave ones) in a common
directory (drivers/i3c/controllers) as you suggest, and prefix them
correctly (i3c-master-.c, i3c-slave-.c and i3c-dual-.c)
2/ place them in separate directories: drivers/i3c/{master,slave,dual}
I'm fine either way.
>
>
> >
> > I'm okay changing it, but I want to understand why the proposed
> > separation is not good.
>
>
> I already tell you my use case and as I said maybe someone can advise :)
>
I think I understand your concerns now, but only because you started to
mention a few things that were not clearly stated before (at least, I
didn't understand it this way), like the fact that your controll
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
Hi Vitor,
On Tue, 27 Nov 2018 11:50:53 +
vitor wrote:
> Hi Boris
>
> On 26/11/18 21:33, Boris Brezillon wrote:
> > On Mon, 26 Nov 2018 20:11:39 +
> > vitor wrote:
> >
> > Look at the bus discovery mechanism, the notion of DCR (close to the
> > concept of USB class), or the fact that each dev has a unique
> > manufacturer+PID pair (which resemble the product/vendor ID concept)
> > that allows us to easily bind a dev to a driver without requiring a
> > static description.
>
>
> The major feature close to USB is this one and it can be found in others
> protocols (standardization process).
>
> Just to close this topic I3C vs USB, IMO it's wrong to pass the message
> that the I3C is closer to USB than I2C even more because I3C support the
> I2C on the fly.
I think you didn't read my reply carefully. I'm not saying I3C == USB,
I'm just saying that the way you interact with an I3C from a SW PoV is
not at all the same as you would do for an I2C device. Do you deny that?
>
>
> >
> >>
> >> I'm not sure but I think that a controller cannot change between gadget
> >> to host in USB in runtime.
> > That's called USB OTG. Okay, to be fair, it's not exactly the same, and
> > the mastership handover in I3C is probably more complex than what we
> > have with USB OTG (I'm not a USB expert, so I might be wrong here).
> >
> >> Even so, this kind of behavior is more likely
> >> to have in an I3C bus.
> > Maybe.
>
>
> Sorry, with the proliferation of sensors I cannot see a multi master
> sensor network based on USB.
Looks like there's a misunderstanding here. The question is not whether
I3C will replace I2C or USB, of course it's meant to overcome the
limitations of I2C. I'm just pointing out that, if we have to expose
I3C devices, we should look at what other discoverable buses do (PCI,
USB, ...), not what I2C does.
>
>
> >> Sorry for that and don't take me wrong... maybe I should rise this
> >> question early but this only came up now when I started splitting and
> >> thinking where to put what is for master for slave, what is common and
> >> the thing of putting everything of controller in a folder.
> > So you have such a dual-role controller?
>
>
> Yes, we already talked about secondary master support.
There's a difference between a secondary master that waits for its time
to become the currrent master, and a secondary master that provides I3C
device features when it's acting as a slave (sensor, GPIO
controller, ...). So far we focused on supporting the former. If
there's a need for the latter, then we should start thinking about the
slave framework...
>
>
> > What I call a slave controller would be something that lets you reply to
> > SDR/DDR transactions or fill a generic regmap that would be exposed to
> > other masters on the bus. This way we could implement generic slave
> > drivers in Linux (the same way we have gadget drivers). Anything else
> > is likely to be to specific to be exposed as a generic framework.
>
>
> I would bet to do something like in i2c, we don't need the same level of
> complexity found in USB.
Can you detail a bit more what you have in mind? I don't think we can
do like I2C, simply because we need to expose a valid DCR +
manuf-ID/PID so that other masters can bind the device to the
appropriate driver on their side. Plus, if we're about to expose
generic profiles, we likely don't want each I3C slave controller driver
to do that on its own.
>
>
> >>
> >> Taking the USB as exemple do you prefer a dwc folder on i3c root?
> > Hm, not sure I like this idea either. So I see 2 options:
> >
> > 1/ put all controller drivers (both master and slave ones) in a common
> > directory (drivers/i3c/controllers) as you suggest, and prefix them
> > correctly (i3c-master-.c, i3c-slave-.c and i3c-dual-.c)
>
>
> I agree with the controller folder but not with prefix. Please check
> what is already in the kernel.
If we mix everything in the same subdir, I'd like to have an easy way
to quickly identify those that are slave controllers and those that are
master controllers. For the dual-role thing, maybe we can consider them
as master (ones with advances slave features).
Would you be okay with drivers/i3c/controllers/{designware,dw}/..., so
that you can have all designware drivers (for both slave and master
blocks) in the same dir?
For those that are placed directly under drivers/i3c/controllers/...
(because they only have one .c file), I'd like to keep a standard
prefix.
>
Re: [PATCH] i3c: master: dw: split dw-i3c-master.c into master and bus specific parts
On Tue, 4 Dec 2018 00:34:20 +
vitor wrote:
> >>> What I call a slave controller would be something that lets you reply to
> >>> SDR/DDR transactions or fill a generic regmap that would be exposed to
> >>> other masters on the bus. This way we could implement generic slave
> >>> drivers in Linux (the same way we have gadget drivers). Anything else
> >>> is likely to be to specific to be exposed as a generic framework.
> >> I would bet to do something like in i2c, we don't need the same level of
> >> complexity found in USB.
> > Can you detail a bit more what you have in mind? I don't think we can
> > do like I2C, simply because we need to expose a valid DCR +
> > manuf-ID/PID so that other masters can bind the device to the
> > appropriate driver on their side. Plus, if we're about to expose
> > generic profiles, we likely don't want each I3C slave controller driver
> > to do that on its own.
>
>
> I think this should be discuss in another thread. Do you agree?
If you want. Actually that's the most interesting part for me:
discussing how we want to support I3C slave controllers or mixed
master/slave controllers. All the driver split we're talking about
here is just bikeshedding.
>
>
> Taking the USB as exemple do you prefer a dwc folder on i3c root?
> >>> Hm, not sure I like this idea either. So I see 2 options:
> >>>
> >>> 1/ put all controller drivers (both master and slave ones) in a common
> >>> directory (drivers/i3c/controllers) as you suggest, and prefix them
> >>> correctly (i3c-master-.c, i3c-slave-.c and i3c-dual-.c)
> >> I agree with the controller folder but not with prefix. Please check
> >> what is already in the kernel.
> > If we mix everything in the same subdir, I'd like to have an easy way
> > to quickly identify those that are slave controllers and those that are
> > master controllers. For the dual-role thing, maybe we can consider them
> > as master (ones with advances slave features).
> >
> > Would you be okay with drivers/i3c/controllers/{designware,dw}/..., so
> > that you can have all designware drivers (for both slave and master
> > blocks) in the same dir?
>
>
> Yes, that was what I trying to tell you. For me this might be the best
> option.
Ok.
>
> I would like to avoid having dual role i3c driver in a master folder.
I don't see why. If the driver is simple enough to fit in one file,
there's no reason to create a new subdir. You think your DW IP is so
complex and configurable that it requires several source files, fine,
but please don't force others to do the same.
>
>
> > For those that are placed directly under drivers/i3c/controllers/...
> > (because they only have one .c file), I'd like to keep a standard
> > prefix.
>
>
> I don't disagree, and for those that have more than one file they should
> be in a folder, right?
Yes.
>
> What prefix do you have in mind for those files inside a folder?
You mean, inside a sub-folder (drivers/i3c/controllers/{vendor}/)? It
depends what you do with those source files. If they are to be exposed
directly as modules, then they should be prefixed
(i3c--.c). On the other hand, if you create a single
module out of several source files, source files don't need to be
prefixed, as long as the resulting module as a proper prefix.
>
>
> >> To be clear, the subsystem is nice and I working with daily. As I said
> >> this is something that I dealing now and I'm telling what I think that
> >> is not correct.
> >>
> > Come on! All I've seen so far are complaints on tiny details, it
> > definitely doesn't prevent you from adding new features.
> >
> > Regards,
> >
> > Boris
>
>
> No, it's not. But as you can see to slipt the driver in parts this
> subject has some relevance.
I'm not saying the discussion is useless, just that it's happening way
too early compared to the other things we should work on. If you were
adding support for slaves, and were doing this split as part of this
patch series explaining that part of the code between slave and master
can be shared, then we wouldn't have this debate. But right now, you're
telling me that we need to split the DW driver to prepare for features
that have not even been discussed/proposed. That's what I'm complaining
about.
Re: [PATCH] mtd: nand: fix kernel-doc warnings
On Sun, 27 Jan 2019 18:21:42 -0800
Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix kernel-doc warnings in drivers/mtd/nand/raw:
>
> ../drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or
> member 'chip' not described in 'nand_fill_oob'
> ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member
> 'this' not described in 'read_bbt'
> ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter
> 'chip' description in 'read_bbt'
>
> Signed-off-by: Randy Dunlap
> Cc: Boris Brezillon
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: linux-...@lists.infradead.org
> ---
> Do you want Fixes: tags for these:
>
> Fixes: 0813621ba898a ("mtd: rawnand: Stop passing mtd_info objects to
> internal functions")
Will add this one.
> Fixes: 99f3351a6d6e0 ("mtd: rawnand: Reorganize code to avoid forward
> declarations")
Well, I don't think that one is responsible for the new warnings since
all I did was moving code around.
Thanks,
Boris
>
> drivers/mtd/nand/raw/nand_base.c |1 +
> drivers/mtd/nand/raw/nand_bbt.c |2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> --- lnx-50-rc4.orig/drivers/mtd/nand/raw/nand_base.c
> +++ lnx-50-rc4/drivers/mtd/nand/raw/nand_base.c
> @@ -410,6 +410,7 @@ static int nand_check_wp(struct nand_chi
>
> /**
> * nand_fill_oob - [INTERN] Transfer client buffer to oob
> + * @chip: NAND chip object
> * @oob: oob data buffer
> * @len: oob data write length
> * @ops: oob ops structure
> --- lnx-50-rc4.orig/drivers/mtd/nand/raw/nand_bbt.c
> +++ lnx-50-rc4/drivers/mtd/nand/raw/nand_bbt.c
> @@ -158,7 +158,7 @@ static u32 add_marker_len(struct nand_bb
>
> /**
> * read_bbt - [GENERIC] Read the bad block table starting from page
> - * @chip: NAND chip object
> + * @this: NAND chip object
> * @buf: temporary buffer
> * @page: the starting page
> * @num: the number of bbt descriptors to read
>
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: mtd: nand: fix kernel-doc warnings
On Mon, 2019-01-28 at 02:21:42 UTC, Randy Dunlap wrote: > From: Randy Dunlap > > Fix kernel-doc warnings in drivers/mtd/nand/raw: > > ../drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or > member 'chip' not described in 'nand_fill_oob' > ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member > 'this' not described in 'read_bbt' > ../drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter > 'chip' description in 'read_bbt' > > Signed-off-by: Randy Dunlap > Cc: Boris Brezillon > Cc: Miquel Raynal > Cc: Richard Weinberger > Cc: linux-...@lists.infradead.org Applied to http://git.infradead.org/linux-mtd.git mtd/fixes, thanks. Boris
[RFC 1/5] i2c: Export of_i2c_get_board_info()
I3C busses have to know about all I2C devices connected on the I3C bus
to properly initialize the I3C master, and I2C frames can't be sent on
the bus until this initialization is done.
We can't let the I2C core parse the DT and instantiate I2C devices as
part of its i2c_add_adapter() procedure because, when done this way,
I2C devices are directly registered to the device-model and might be
attached to drivers which could in turn start sending frames on the bus,
which won't work since, as said above, the bus is not yet initialized.
Export of_i2c_register_device() in order to let the I3C core parse the
I2C device nodes by itself and initialize the bus.
Signed-off-by: Boris Brezillon
---
drivers/i2c/i2c-core-base.c | 2 +-
drivers/i2c/i2c-core-of.c | 64 ++---
include/linux/i2c.h | 10 +++
3 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index c89dac7fd2e7..ea1391d09266 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -762,7 +762,7 @@ i2c_new_device(struct i2c_adapter *adap, struct
i2c_board_info const *info)
client->dev.parent = &client->adapter->dev;
client->dev.bus = &i2c_bus_type;
client->dev.type = &i2c_client_type;
- client->dev.of_node = info->of_node;
+ client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
i2c_dev_set_name(adap, client);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index ccf82fdbcd8e..b201613e71e5 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,63 +22,73 @@
#include "i2c-core.h"
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
-struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info)
{
- struct i2c_client *result;
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr_be;
u32 addr;
- int len;
+ int ret;
- dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
+ memset(info, 0, sizeof(info));
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
+ if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+ dev_err(dev, "of_i2c: modalias failure on %s\n",
node->full_name);
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
}
- addr_be = of_get_property(node, "reg", &len);
- if (!addr_be || (len < sizeof(*addr_be))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
+ ret = of_property_read_u32(node, "reg", &addr);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid reg on %s\n",
node->full_name);
- return ERR_PTR(-EINVAL);
+ return ret;
}
- addr = be32_to_cpup(addr_be);
if (addr & I2C_TEN_BIT_ADDRESS) {
addr &= ~I2C_TEN_BIT_ADDRESS;
- info.flags |= I2C_CLIENT_TEN;
+ info->flags |= I2C_CLIENT_TEN;
}
if (addr & I2C_OWN_SLAVE_ADDRESS) {
addr &= ~I2C_OWN_SLAVE_ADDRESS;
- info.flags |= I2C_CLIENT_SLAVE;
+ info->flags |= I2C_CLIENT_SLAVE;
}
- if (i2c_check_addr_validity(addr, info.flags)) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
+ ret = i2c_check_addr_validity(addr, info->flags);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid addr=%x on %s\n",
addr, node->full_name);
- return ERR_PTR(-EINVAL);
+ return ret;
}
- info.addr = addr;
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
+ info->addr = addr;
+ info->of_node = node;
if (of_property_read_bool(node, "host-notify"))
- info.flags |= I2C_CLIENT_HOST_NOTIFY;
+ info->flags |= I2C_CLIENT_HOST_NOTIFY;
if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
+ info->flags |= I2C_CLIENT_WAKE;
+
+ return 0;
+}
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+struct device_node *node)
+{
+ struct i2c_client *result;
+ struct i2c
[RFC 5/5] dt-bindings: i3c: Document Cadence I3C master bindings
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index ..f9e4af4ff1c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,45 @@
+Bindings for cadence I3C master block
+=
+
+Required properties:
+
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-frequency
+- i3c-scl-frequency
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-frequency = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/5] i3c: master: Add driver for Cadence IP
Add a driver for Cadence I3C master IP. Signed-off-by: Boris Brezillon --- drivers/i3c/master/Kconfig |4 + drivers/i3c/master/Makefile |1 + drivers/i3c/master/i3c-master-cdns.c | 1382 ++ 3 files changed, 1387 insertions(+) create mode 100644 drivers/i3c/master/i3c-master-cdns.c diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig index e69de29bb2d1..23ed1642828c 100644 --- a/drivers/i3c/master/Kconfig +++ b/drivers/i3c/master/Kconfig @@ -0,0 +1,4 @@ +config CDNS_I3C_MASTER + tristate "Cadence I3C master driver" + help + Enable this driver if you want to support Cadence I3C master block. diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile index e69de29bb2d1..4c4304aa9534 100644 --- a/drivers/i3c/master/Makefile +++ b/drivers/i3c/master/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c new file mode 100644 index ..74564fe55247 --- /dev/null +++ b/drivers/i3c/master/i3c-master-cdns.c @@ -0,0 +1,1382 @@ +/* + * Copyright (C) 2017 Cadence Design Systems Inc. + * + * Author: Boris Brezillon + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; either version 2 of the License, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#define DEV_ID 0x0 +#define DEV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20) +#define DEV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8) +#define DEV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4) +#define DEV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0)) + +#define CONF_STATUS0x4 +#define CONF_STATUS_HAS_FIFOS BIT(26) +#define CONF_STATUS_GPO_NUM(s) (((s) & GENMASK(25, 18)) >> 18) +#define CONF_STATUS_GPI_NUM(s) (((s) & GENMASK(17, 10)) >> 10) +#define CONF_STATUS_DEVS_NUM(s)(((s) & GENMASK(6, 3)) >> 3) +#define DEV_TYPE_MAIN_MASTER 0 +#define DEV_TYPE_SECONDARY_MASTER 1 +#define DEV_TYPE_SLAVE 2 +#define CONF_STATUS_DEV_TYPE(s)((s) & GENMASK(2, 0)) + +#define DEVS_CTRL 0x8 +#define DEVS_CTRL_DEV_CLR_ALL GENMASK(31, 16) +#define DEVS_CTRL_DEV_CLR(dev) BIT(16 + (dev)) +#define DEVS_CTRL_DEV_ACTIVE(dev) BIT(dev) + +#define CTRL 0x10 +#define CTRL_DEV_ENBIT(31) +#define CTRL_HALT_EN BIT(30) +#define CTRL_HJ_DISEC BIT(8) +#define CTRL_MST_ACK BIT(7) +#define CTRL_HJ_ACKBIT(6) +#define CTRL_HJ_INIT BIT(5) +#define CTRL_MST_INIT BIT(4) +#define CTRL_AHDR_OPT BIT(3) +#define CTRL_PURE_BUS_MODE 0 +#define CTRL_MIXED_FAST_BUS_MODE 2 +#define CTRL_MIXED_SLOW_BUS_MODE 3 +#define CTRL_BUS_MODE_MASK GENMASK(1, 0) + +#define PRESCL_CTRL0 0x14 +#define PRESCL_CTRL0_I2C(x)((x) << 16) +#define PRESCL_CTRL0_I3C(x)(x) +#define PRESCL_CTRL0_MAX GENMASK(15, 0) + +#define PRESCL_CTRL1 0x18 +#define PRESCL_CTRL1_PP_LOW(x) ((x) << 8) +#define PRESCL_CTRL1_OD_LOW(x) (x) + +#define MST_IER0x20 +#define MST_IDR0x24 +#define MST_IMR0x28 +#define MST_ICR0x2c +#define MST_ISR0x30 +#define MST_INT_RX_THR BIT(24) +#define MST_INT_TX_THR BIT(23) +#define MST_INT_IBI_THRBIT(22) +#define MST_INT_CMD_THRBIT(21) +#define MST_INT_RX_UNF BIT(20) +#define MST_INT_TX_OVF BIT(19) +#define MST_INT_IBI_UNFBIT(18) +#define MST_INT_CMD_OVFBIT(17) +#define MST_INT_CMD_EMPTY BIT(16) +#define MST_INT_MR_DONEBIT(11) +#define MST_INT_IBI_FAIL BIT(10) +#define MST_INT_SDR_FAIL BIT(9) +#define MST_INT_DDR_FAIL BIT(8) +#define MST_INT_HJ_REQ BIT(7) +#define MST_INT_MR_REQ BIT(6) +#define MST_INT_IBI
[RFC 0/5] Add I3C subsystem
This patch series is a proposal for a new I3C [1] subsystem. 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 to send I3C/I2C frames must be called in non-atomic context. Mainly done this way to ease implementation, but this is still open to discussion. Please let me know if you think it's worth considering an asynchronous model here - the bus element is a separate object and is not implicitly described by the master (as done in I2C). The reason is that I want to be able to handle multiple master connected to the same bus and visible to Linux. In this situation, we should only have one instance of the device and not one per master, and sharing the bus object would be part of the solution to gracefully handle this case. I'm not sure if we will ever need to deal with multiple masters controlling the same bus and exposed under Linux, but separating the bus and master concept is pretty easy, hence the decision to do it now, just in case we need it some day. The other benefit of separating the bus and master concepts is that master devices appear under the bus directory in sysfs. - 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 new I2C bus. I'd say that, from a representation PoV it's not ideal because what should appear as a single I3C bus exposing I3C and I2C devices here appears as 2 different busses connected to each other through the parenting (the I3C master is the parent of the I2C and I3C busses). On the other hand, I don't see a better solution if we want something that is not invasive. - the whole API is exposed through a single header file (i3c.h), but I'm seriously considering the option of splitting the I3C driver/user API and the I3C master one, mainly to hide I3C core internals and restrict what I3C users can do to a limited set of functionalities (send I3C/I2C frames to a specific device and that's all). Missing features in this preliminary version: - no support for IBI (In Band Interrupts). This is something I'm working on, and I'm still unsure how to represent it: an irqchip or a completely independent representation that would be I3C specific. Right now, I'm more inclined to go for the irqchip approach, since this is something people are used to deal with already. - no Hot Join support, which is similar to hotplug - no support for multi-master and the associated concepts (mastership handover, support for secondary masters, ...) - I2C devices can only be described using DT because this is the only use case I have. However, the framework can easily be extended with ACPI and board info support - I3C slave framework. This has been completely omitted, but shouldn't have a huge impact on the I3C framework because I3C slaves don't see the whole bus, it's only about handling master requests and generating IBIs. Some of the struct, constant and enum definitions could be shared, but most of the I3C slave framework logic will be different If possible, I'd like to have reviews from people that are familiar with the device model and complex/autodiscoverable busses like USB. Arnd, Greg, I think your feedback would be very valuable here. Wolfram, feel free to comment on the integration with the I2C subsystem, and let me know if you see a better option. I'd also like to get feedback on the doc. Should I detail a bit more the protocol or the framework API? Is this the kind of things you expect in a subsystem doc? I'm also unsure how far I should go with sysfs attributes. Right now, I have exposed things that should matter to udev & co plus some extra information about I3C dev capabilities (sysfs files have not been documented yet, but I'll do it for the next version of this patch series). I could go even further and expose more details like device limitations (in terms of speed), device status, etc. However, I don't know if those information are relevant to user-space applications. If you know other people that might be interested by this patchset, just let me know and I'll Cc them on the next version. Thanks, Boris [1]https://www.mipi.org/specifications/i3c-sensor-specification Boris Brezillon (5): i2c: Export of_i2c_get_board_info() i3c: Add core I3C infrastructure dt-bindings: i3c: Document core bindings i3c: master: Add driver for Cadence IP dt-bindings: i3c: Document Cadence I3C master bindings .../devicetree/bindings/i3c/cdns,i3c-master.txt| 45 + Documentation/devicetree/bindings/i3c/i3c.txt | 90 ++ Documentation/i3c/conf.py | 10 + Documentation/i3c/device-driver-api.rst
[RFC 3/5] dt-bindings: i3c: Document core bindings
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt
b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index ..49261dec7b01
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,90 @@
+Generic device tree bindings for I3C busses
+===
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+---
+
+- #address-cells - should be <1>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of I3C bus controller following generic names
+ recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+---
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+transfers. When undefined, the core looks at LVR values
+of I2C devices described in the device tree to determine
+the maximum I2C frequency.
+
+I2C devices
+===
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+ describing device capabilities as described in the I3C
+ specification.
+
+ bit[31:8]: unused
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not
+tolerant to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+I3C devices
+===
+
+I3C are not described in the device tree yet. We could decide to represent them
+at some point to assign a specific dynamic address to a device or to force an
+I3C device to act as an I2C device if it has a static address.
+
+Example:
+
+ i3c-master@0d04 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d04 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+ i2c-scl-frequency = <10>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/5] Add I3C subsystem
Hi Wolfram, Le Mon, 31 Jul 2017 21:17:45 +0200, Wolfram Sang a écrit : > Hi Boris, > > > This patch series is a proposal for a new I3C [1] subsystem. > > Nice. Good luck with that! > > Some hi-level comments from me related to I2C. I can't say a lot more > because the specs are not public :( Unfortunately they're not :(. > > > - the bus element is a separate object and is not implicitly described > > by the master (as done in I2C). The reason is that I want to be able > > to handle multiple master connected to the same bus and visible to > > Linux. > > In this situation, we should only have one instance of the device and > > not one per master, and sharing the bus object would be part of the > > solution to gracefully handle this case. > > I'm not sure if we will ever need to deal with multiple masters > > controlling the same bus and exposed under Linux, but separating the > > bus and master concept is pretty easy, hence the decision to do it > > now, just in case we need it some day. > > From my experience, it is a good thing to have this separation. Good to hear that you agree with this approach. > > > - 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 new I2C bus. I'd say that, from a > > representation PoV it's not ideal because what should appear as a > > single I3C bus exposing I3C and I2C devices here appears as 2 > > different busses connected to each other through the parenting (the > > I3C master is the parent of the I2C and I3C busses). > > On the other hand, I don't see a better solution if we want something > > that is not invasive. > > I agree this is the least invasive and also the most compatible > approach. The other solution would probably be to have some kind of > emulation layer? Could you detail a bit more what you mean by "emulation layer"? > > > I'd also like to get feedback on the doc. Should I detail a bit more > > the protocol or the framework API? Is this the kind of things you > > expect in a subsystem doc? > > Since the spec is not public, details about the protocol will be > especially useful, I'd say. Okay, I'll see what I can do. Thanks, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 I could. > > > + > > +Introduction > > + > > + > > +The I3C (I-Cube-C) is a MIPI standardized protocol designed to overcome > > I2C > > "Eye-three-See", according to: > http://eecatalog.com/sensors/2017/07/05/after-35-years-of-i2c-i3c-improves-capability-and-performance/ I remember hearing eye-cube-see during the discussion we had with Cadence engineers but I might wrong. I'll double check (or maybe I'll just drop any mention of the pronunciation). > > > +Backward compatibility with I2C devices > > +=== > > + > > +The I3C protocol has been designed to be backward compatible with I2C > > devices. > > +This backward compatibility allows one to connect a mix of I2C and I3C > > devices > > +on the same bus, though, in order to be really efficient, I2C devices > > should > > +be equipped with 50 ns spike filters. > > I just found a slide which says I3C does not support clock stretching. > That should be mentioned here, too. > You're right, clock stretching is not allowed, and if devices without a 50ns spike filter are connected to the bus, it lowers the maximum speed for all devices, which renders I3C kind of useless. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 been designed to be transparent to I2C > > drivers and the I2C subsystem. The I3C master just registers an I2C > > adapter which creates a new I2C bus. I'd say that, from a > > representation PoV it's not ideal because what should appear as a > > single I3C bus exposing I3C and I2C devices here appears as 2 > > different busses connected to each other through the parenting (the > > I3C master is the parent of the I2C and I3C busses). > > On the other hand, I don't see a better solution if we want something > > that is not invasive. > > Can you describe the reasons for making i3c a separate subsystem then, > rather than extending the i2c subsystem to handle both i2c devices as > before and also i3c devices and hosts? 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. Indeed, all I3C devices can be discovered and do not need to be described at the board level (using DT, board files, ACPI or whatever). Also, some I3C devices are hotpluggable, and most importantly, all I3C devices describe themselves during the discovery procedure (called DAA in the I3C world). There is some kind of "device class" concept. In the I3C world it's called DCR (Device Characteristic Register), but it plays the same role: it's a set of generic interfaces devices have to comply with when they declare themselves as being compatible with a DCR ID (like accelerometer, gyroscope, or whatever). See this table of normalized DCR for more information [1]. Devices also expose a 48-bit Provisional ID which is made of sub-fields. Two of them are particularly interesting: the manufacturer ID and the part ID, which are comparable to the vendor and product ID in the USB world. These three information (DCR, ManufacturerID and PartID) can be used to match drivers instead of the compatible string or driver-name used for I2C devices So, as you can imagine, dealing with an I3C bus is really different from dealing with an I2C bus, and I found the "expose an i2c_adapter object for each i3c_master" way simpler (and less invasive) than extending the I2C framework to support I3C devices. 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. 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. 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 ;-). Thanks, Boris [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 to send I3C/I2C frames must be called in > > non-atomic context. Mainly done this way to ease implementation, but > > this is still open to discussion. Please let me know if you think it's > > worth considering an asynchronous model here > > - the bus element is a separate object and is not implicitly described > > by the master (as done in I2C). The reason is that I want to be able > > to handle multiple master connected to the same bus and visible to > > Linux. > > In this situation, we should only have one instance of the device and > > not one per master, and sharing the bus object would be part of the > > solution to gracefully handle this case. > > I'm not sure we will ever need to deal with multiple masters > > controlling the same bus and exposed under Linux, but separating the > > bus and master concept is pretty easy, hence the decision to do it > > like that. > > The other benefit of separating the bus and master concepts is that > > master devices appear under the bus directory in sysfs. > > - 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 new I2C bus. I'd say that, from a > > representation PoV it's not ideal because what should appear as a > > single I3C bus exposing I3C and I2C devices here appears as 2 > > different busses connected to each other through the parenting (the > > I3C master is the parent of the I2C and I3C busses). > > On the other hand, I don't see a better solution if we want something > > that is not invasive. > > - the whole API is exposed through a single header file (i3c.h), but I'm > > seriously considering the option of splitting the I3C driver/user API > > and the I3C master one, mainly to hide I3C core internals and restrict > > what I3C users can do to a limited set of functionalities (send > > I3C/I2C frames to a specific device and that's all). > > > > Missing features in this preliminary version: > > - no support for IBI (In Band Interrupts). This is something I'm working > > on, and I'm still unsure how to represent it: an irqchip or a > > completely independent representation that would be I3C specific. > > Right now, I'm more inclined to go for the irqchip approach, since > > this is something people are used to deal with already. > > - no Hot Join support, which is similar to hotplug > > - no support for multi-master and the associated concepts (mastership > > handover, support for secondary masters, ...) > > - I2C devices can only be described using DT because this is the only > > use case I have. However, the framework can easily be extended with > > ACPI and board info support > > - I3C slave framework. This has been completely omitted, but shouldn't > > have a huge impact on the I3C framework because I3C slaves don't see > > the whole bus, it's only about handling master requests and generating > > IBIs. Some of the struct, constant and enum definitions could be > > shared, but most of the I3C slave framework logic will be different > > > > Signed-off-by: Boris Brezillon > > --- > > Documentation/i3c/conf.py | 10 + > > Documentation/i3c/device-driver-api.rst |7 + > > Documentation/i3c/index.rst |9 + > > Documentation/i3c/master-driver-api.rst |8 + > > Documentation/i3c/protocol.rst | 199 + > > Documentation/index.rst |1 + > > drivers/Kconfig |2 + > > drivers/Makefile|2 +- > > drivers/i3c/Kconfig | 24 + > > drivers/i3c/Makefile|3 + > > drivers/i3c/core.c | 532 ++ > > drivers/i3c/device.c| 138 > > drivers/i3c/internals.h | 45 ++ > > drivers/i3c/master.c| 1225 > > +++ &g
