[PATCH] Documentation: magic-numbers: Fix typo
This fixes a little then / them confusion.
Signed-off-by: Martin Kepplinger
---
Documentation/process/magic-number.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/magic-number.rst
b/Documentation/process/magic-number.rst
index c74199f60c6c..00cecf1fcba9 100644
--- a/Documentation/process/magic-number.rst
+++ b/Documentation/process/magic-number.rst
@@ -14,7 +14,7 @@ passing pointers to structures via a void * pointer. The tty
code,
for example, does this frequently to pass driver-specific and line
discipline-specific structures back and forth.
-The way to use magic numbers is to declare then at the beginning of
+The way to use magic numbers is to declare them at the beginning of
the structure, like so::
struct tty_ldisc {
--
2.14.2
--
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 v6 2/2] cpuset: Add cpuset.sched_load_balance to v2
On 22/03/18 17:50, Waiman Long wrote: > On 03/22/2018 04:41 AM, Juri Lelli wrote: > > On 21/03/18 12:21, Waiman Long wrote: [...] > >> + cpuset.sched_load_balance > >> + A read-write single value file which exists on non-root cgroups. > >> + The default is "1" (on), and the other possible value is "0" > >> + (off). > >> + > >> + When it is on, tasks within this cpuset will be load-balanced > >> + by the kernel scheduler. Tasks will be moved from CPUs with > >> + high load to other CPUs within the same cpuset with less load > >> + periodically. > >> + > >> + When it is off, there will be no load balancing among CPUs on > >> + this cgroup. Tasks will stay in the CPUs they are running on > >> + and will not be moved to other CPUs. > >> + > >> + This flag is hierarchical and is inherited by child cpusets. It > >> + can be turned off only when the CPUs in this cpuset aren't > >> + listed in the cpuset.cpus of other sibling cgroups, and all > >> + the child cpusets, if present, have this flag turned off. > >> + > >> + Once it is off, it cannot be turned back on as long as the > >> + parent cgroup still has this flag in the off state. > >> + > > I'm afraid that this will not work for SCHED_DEADLINE (at least for how > > it is implemented today). As you can see in Documentation [1] the only > > way a user has to perform partitioned/clustered scheduling is to create > > subset of exclusive cpusets and then assign deadline tasks to them. The > > other thing to take into account here is that a root_domain is created > > for each exclusive set and we use such root_domain to keep information > > about admitted bandwidth and speed up load balancing decisions (there is > > a max heap tracking deadlines of active tasks on each root_domain). > > Now, AFAIR distinct root_domain(s) are created when parent group has > > sched_load_balance disabled and cpus_exclusive set (in cgroup v1 that > > is). So, what we normally do is create, say, cpus_exclusive groups for > > the different clusters and then disable sched_load_balance at root level > > (so that each cluster gets its own root_domain). Also, > > sched_load_balance is enabled in children groups (as load balancing > > inside clusters is what we actually needed :). > > That looks like an undocumented side effect to me. I would rather see an > explicit control file that enable root_domain and break it free from > cpu_exclusive && !sched_load_balance, e.g. sched_root_domain(?). Mmm, it actually makes some sort of sense to me that as long as parent groups can't load balance (because !sched_load_balance) and this group can't have CPUs overlapping with some other group (because cpu_exclusive) a data structure (root_domain) is created to handle load balancing for this isolated subsystem. I agree that it should be better documented, though. > > IIUC your proposal this will not be permitted with cgroup v2 because > > sched_load_balance won't be present at root level and children groups > > won't be able to set sched_load_balance back to 1 if that was set to 0 > > in some parent. Is that true? > > Yes, that is the current plan. OK, thanks for confirming. Can you tell again however why do you think we need to remove sched_load_balance from root level? Won't we end up having tasks put on isolated sets? Also, I guess children groups with more than one CPU will need to be able to load balance across their CPUs, no matter what their parent group does? Thanks, - Juri -- 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 1/2] COPYING: create a new file with points to the Kernel license files
Em Thu, 22 Mar 2018 05:13:55 -0700 Matthew Wilcox escreveu: > On Thu, Mar 22, 2018 at 06:54:13AM -0300, Mauro Carvalho Chehab wrote: > > +++ b/Documentation/process/license-rules.rst > > @@ -4,15 +4,17 @@ Linux kernel licensing rules > > > > > > The Linux Kernel is provided under the terms of the GNU General Public > > -License version 2 only (GPL-2.0), as published by the Free Software > > -Foundation, and provided in the COPYING file. This documentation file is > > -not meant to replace the COPYING file, but provides a description of how > > -each source file should be annotated to make the licensing it is governed > > -under clear and unambiguous. > > - > > -The license in the COPYING file applies to the kernel source as a whole, > > -though individual source files can have a different license which is > > -required to be compatible with the GPL-2.0:: > > +version 2 only (GPL-2.0), as written at LICENSES/preferred/GPL-2.0, > > ^^^ you dropped the word 'License' here > > Also, I think this should read "as provided in", not "as written at". > > > +with an explicit syscall exception described at > > s/at/in/ > > > +LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. > > This phrasing is awkward with "desribed" used twice in the same sentence ... > > > +This documentation file is not meant to replace the Kernel's license, > > +but provides a description of how each source file should be annotated > > +to make the licensing it is governed under clear and unambiguous. > > I'd rather this said: > > This documentation file provides a description of how each source file > should be annotated to make its license clear and unambiguous. Thanks for your review! I'll be submitting it again as a v2, with the following text at the license-rules.rst preamble: Linux kernel licensing rules The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, with an explicit syscall exception described in LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. This documentation file provides a description of how each source file should be annotated to make its license clear and unambiguous. It doesn't replace the Kernel's license. The license described in the COPYING file applies to the kernel source as a whole, though individual source files can have a different license which is required to be compatible with the GPL-2.0:: Regards, Mauro > Thanks, Mauro -- 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 1/2] COPYING: create a new file with points to the Kernel license files
With the addition of SPDX patchset, the contents of COPYING file is now duplicated at two other files under LICENSE: LICENSES/preferred/GPL-2.0 LICENSES/exceptions/Linux-syscall-note It is easy to check that the contents of the licence written on those files are identical with COPYING using: $ diff -upr COPYING LICENSES/preferred/GPL-2.0 $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less Also, a new file was added, with describes how SPDX should work at the Kernel source files: Documentation/process/license-rules.rst Instead fo having it copying the contents of two files, and not even mentioning the third one, replace it by a file whose content points to the other tree files, preserving the Kernel's license. Adjust license-rules.rst accordingly. Please notice that this file preserves the Kernel license as is, without any changes. Signed-off-by: Mauro Carvalho Chehab --- Version 2: - Did some text changes at license-rules.rst, based on Matthew Wilcox review. COPYING.new | 18 ++ Documentation/process/license-rules.rst | 20 +++- 2 files changed, 29 insertions(+), 9 deletions(-) create mode 100644 COPYING.new diff --git a/COPYING.new b/COPYING.new new file mode 100644 index ..da4cb28febe6 --- /dev/null +++ b/COPYING.new @@ -0,0 +1,18 @@ +The Linux Kernel is provided under: + + SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note + +Being under the terms of the GNU General Public License version 2 only, +according with: + + LICENSES/preferred/GPL-2.0 + +With an explicit syscall exception, as stated at: + + LICENSES/exceptions/Linux-syscall-note + +In addition, other licenses may also apply. Please see: + + Documentation/process/license-rules.rst + +for more details. diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst index 408f77dc6157..8ea26325fe3f 100644 --- a/Documentation/process/license-rules.rst +++ b/Documentation/process/license-rules.rst @@ -4,15 +4,17 @@ Linux kernel licensing rules The Linux Kernel is provided under the terms of the GNU General Public -License version 2 only (GPL-2.0), as published by the Free Software -Foundation, and provided in the COPYING file. This documentation file is -not meant to replace the COPYING file, but provides a description of how -each source file should be annotated to make the licensing it is governed -under clear and unambiguous. - -The license in the COPYING file applies to the kernel source as a whole, -though individual source files can have a different license which is -required to be compatible with the GPL-2.0:: +License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, +with an explicit syscall exception described in +LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. + +This documentation file provides a description of how each source file +should be annotated to make its license clear and unambiguous. +It doesn't replace the Kernel's license. + +The license described in the COPYING file applies to the kernel source +as a whole, though individual source files can have a different license +which is required to be compatible with the GPL-2.0:: GPL-1.0+ : GNU General Public License v1.0 or later GPL-2.0+ : GNU General Public License v2.0 or later -- 2.14.3 -- 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 0/2] COPYING: create a new file with points to the Kernel license files
The contents of COPYING file is now duplicated at two other files under LICENSE: LICENSES/preferred/GPL-2.0 LICENSES/exceptions/Linux-syscall-note Also, a new file was added, with describes how SPDX should work at the Kernel source files: Documentation/process/license-rules.rst Instead fo having it copying the contents of two files, and not even mentioning the third one, replace it by a file whose content points to the other tree files, preserving the Kernel's license. Adjust license-rules.rst accordingly. No license changes. NOTE In order to make the diff easier to read, I broke it into two patches. Feel free to merge both when merging if you want. Mauro Carvalho Chehab (2): COPYING: create a new file with points to the Kernel license files COPYING: use the new text with points to the license files COPYING | 358 +--- Documentation/process/license-rules.rst | 20 +- 2 files changed, 21 insertions(+), 357 deletions(-) -- 2.14.3 -- 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 2/2] COPYING: use the new text with points to the license files
Now that we have a new COPYING file with points to the Linux license files, replace it with the old content. This patch does: 1 file changed, 0 insertions(+), 0 deletions(-) rename COPYING.new => COPYING (100%) Reviewed-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab --- COPYING | 358 ++-- COPYING.new | 18 --- 2 files changed, 10 insertions(+), 366 deletions(-) delete mode 100644 COPYING.new diff --git a/COPYING b/COPYING index ca442d313d86..da4cb28febe6 100644 --- a/COPYING +++ b/COPYING @@ -1,356 +1,18 @@ +The Linux Kernel is provided under: - NOTE! This copyright does *not* cover user programs that use kernel - services by normal system calls - this is merely considered normal use - of the kernel, and does *not* fall under the heading of "derived work". - Also note that the GPL below is copyrighted by the Free Software - Foundation, but the instance of code that it refers to (the Linux - kernel) is copyrighted by me and others who actually wrote it. + SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note - Also note that the only valid version of the GPL as far as the kernel - is concerned is _this_ particular version of the license (ie v2, not - v2.2 or v3.x or whatever), unless explicitly otherwise stated. +Being under the terms of the GNU General Public License version 2 only, +according with: - Linus Torvalds + LICENSES/preferred/GPL-2.0 - +With an explicit syscall exception, as stated at: - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 + LICENSES/exceptions/Linux-syscall-note - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. +In addition, other licenses may also apply. Please see: - Preamble + Documentation/process/license-rules.rst - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software--to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Library General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this Gen
Re: [PATCH v2 1/2] COPYING: create a new file with points to the Kernel license files
On Fri, Mar 23, 2018 at 06:51:05AM -0300, Mauro Carvalho Chehab wrote: > With the addition of SPDX patchset, the contents of COPYING file > is now duplicated at two other files under LICENSE: > LICENSES/preferred/GPL-2.0 > LICENSES/exceptions/Linux-syscall-note > > It is easy to check that the contents of the licence written on > those files are identical with COPYING using: > > $ diff -upr COPYING LICENSES/preferred/GPL-2.0 > $ diff -upr COPYING LICENSES/exceptions/Linux-syscall-note|less > > Also, a new file was added, with describes how SPDX should work at > the Kernel source files: > Documentation/process/license-rules.rst > > Instead fo having it copying the contents of two files, and not > even mentioning the third one, replace it by a file whose content > points to the other tree files, preserving the Kernel's license. > > Adjust license-rules.rst accordingly. > > Please notice that this file preserves the Kernel license as > is, without any changes. > > Signed-off-by: Mauro Carvalho Chehab > --- > > Version 2: >- Did some text changes at license-rules.rst, based on Matthew > Wilcox review. Reviewed-by: Greg Kroah-Hartman -- 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 these per-device addresses, the protocol defines a broadcast
+address in order to address all
[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;
+
+ return ret;
+}
+
+static int cdns_i3c_gpio_dir_input(struct gpio_chip *g, unsigned offset)
+{
+ struc
[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) ((x) << 8) +#define PRESCL_CTRL1_OD_LOW_MASK GENMASK(7, 0) +#define PRESCL_CTRL1_OD_LOW(x) (x) + +#define MST_IER0x20 +#define MST_IDR
[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/i3c/master-driver-api.rst |8 + Documentation/driver-api/i3c/protocol.rst
[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,
+struct device_node *node)
+{
+ struct i2c_client *result;
+ struct i2c_board_info info;
+ int ret;
+
+ dev_dbg(&adap->dev, "of_i2c: register %pOF\n", node);
+
+ ret = of_i2c_get_board_info(&adap->dev, node, &info);
+ if (ret)
+
[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.
+
+Optional properties
+---
+
[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 > 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-ma
Re: [PATCH v3 09/11] dt-bindings: i3c: Document Cadence I3C master bindings
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.
Thomas
--
Thomas Petazzoni, CTO, 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 2018-03-23 12:00, 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
> ---
> 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
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 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 23, 2018 at 04:23:21AM +0100, Linus Walleij wrote: > On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer > wrote: > > > Jonathan Neuschäfer (8): > > MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/ > > Documentation: driver-api: Move gpio.rst to gpio/index.rst > > Documentation: gpio: Move introduction to driver-api > > Documentation: gpio: Move driver documentation to driver-api > > Documentation: gpio: Move legacy documentation to driver-api > > Documentation: gpio: Move gpiod_* consumer documentation to driver-api > > Documentation: gpio: Move GPIO mapping documentation to driver-api > > Documentation: gpio: Move drivers-on-gpio.txt to driver-api > > I applied all 8 patches to devel for v4.17. Thanks! Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH v2 0/2] COPYING: create a new file with points to the Kernel license files
On Fri, 23 Mar 2018 06:51:04 -0300 Mauro Carvalho Chehab wrote: > The contents of COPYING file is now duplicated at two other > files under LICENSE: > LICENSES/preferred/GPL-2.0 > LICENSES/exceptions/Linux-syscall-note > > Also, a new file was added, with describes how SPDX should work at > the Kernel source files: > Documentation/process/license-rules.rst > > Instead fo having it copying the contents of two files, and not > even mentioning the third one, replace it by a file whose content > points to the other tree files, preserving the Kernel's license. > > Adjust license-rules.rst accordingly. It looks like we're about there with these, so I went ahead and applied them. Thanks, jon -- 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] Documentation: Mention why %p prints ptrval
On Thu, 22 Mar 2018 15:53:36 +1030 Joel Stanley wrote: > When debugging recent kernels, people will see '(ptrval)' but there > isn't much information as to what that means. Briefly describe why it's > there. Applied, thanks. jon -- 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 v6 2/2] cpuset: Add cpuset.sched_load_balance to v2
On 03/23/2018 03:59 AM, Juri Lelli wrote: > On 22/03/18 17:50, Waiman Long wrote: >> On 03/22/2018 04:41 AM, Juri Lelli wrote: >>> On 21/03/18 12:21, Waiman Long wrote: > [...] > + cpuset.sched_load_balance + A read-write single value file which exists on non-root cgroups. + The default is "1" (on), and the other possible value is "0" + (off). + + When it is on, tasks within this cpuset will be load-balanced + by the kernel scheduler. Tasks will be moved from CPUs with + high load to other CPUs within the same cpuset with less load + periodically. + + When it is off, there will be no load balancing among CPUs on + this cgroup. Tasks will stay in the CPUs they are running on + and will not be moved to other CPUs. + + This flag is hierarchical and is inherited by child cpusets. It + can be turned off only when the CPUs in this cpuset aren't + listed in the cpuset.cpus of other sibling cgroups, and all + the child cpusets, if present, have this flag turned off. + + Once it is off, it cannot be turned back on as long as the + parent cgroup still has this flag in the off state. + >>> I'm afraid that this will not work for SCHED_DEADLINE (at least for how >>> it is implemented today). As you can see in Documentation [1] the only >>> way a user has to perform partitioned/clustered scheduling is to create >>> subset of exclusive cpusets and then assign deadline tasks to them. The >>> other thing to take into account here is that a root_domain is created >>> for each exclusive set and we use such root_domain to keep information >>> about admitted bandwidth and speed up load balancing decisions (there is >>> a max heap tracking deadlines of active tasks on each root_domain). >>> Now, AFAIR distinct root_domain(s) are created when parent group has >>> sched_load_balance disabled and cpus_exclusive set (in cgroup v1 that >>> is). So, what we normally do is create, say, cpus_exclusive groups for >>> the different clusters and then disable sched_load_balance at root level >>> (so that each cluster gets its own root_domain). Also, >>> sched_load_balance is enabled in children groups (as load balancing >>> inside clusters is what we actually needed :). >> That looks like an undocumented side effect to me. I would rather see an >> explicit control file that enable root_domain and break it free from >> cpu_exclusive && !sched_load_balance, e.g. sched_root_domain(?). > Mmm, it actually makes some sort of sense to me that as long as parent > groups can't load balance (because !sched_load_balance) and this group > can't have CPUs overlapping with some other group (because > cpu_exclusive) a data structure (root_domain) is created to handle load > balancing for this isolated subsystem. I agree that it should be better > documented, though. Yes, this need to be documented. >>> IIUC your proposal this will not be permitted with cgroup v2 because >>> sched_load_balance won't be present at root level and children groups >>> won't be able to set sched_load_balance back to 1 if that was set to 0 >>> in some parent. Is that true? >> Yes, that is the current plan. > OK, thanks for confirming. Can you tell again however why do you think > we need to remove sched_load_balance from root level? Won't we end up > having tasks put on isolated sets? The root cgroup is special that it owns all the resources in the system. We generally don't want restriction be put on the root cgroup. A child cgroup has to be created to have constraints put on it. In fact, most of the controller files don't show up in the v2 cgroup root at all. An isolated cgroup has to be put under root, e.g. Root /\ isolated balanced > > Also, I guess children groups with more than one CPU will need to be > able to load balance across their CPUs, no matter what their parent > group does? The purpose of an isolated cpuset is to have a dedicated set of CPUs to be used by a certain application that makes its own scheduling decision by placing tasks explicitly on specific CPUs. It just doesn't make sense to have a CPU in an isolated cpuset to participated in load balancing in another cpuset. If one want load balancing in a child cpuset, the parent cpuset should have load balancing turned on as well. As I look into the code, it seems like root domain is probably somewhat associated with cpu_exclusive only. Whether sched_load_balance is set doesn't really matter. I will need to look further on the conditions where a new root domain is created. BTW, there is always a default root domain for the root. So you don't really need to do anything special for the root cpuset to make one. Cheers, Longman It just doesn't make sense to have a CPU in both an isolated CPU set -- 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.kern
[PATCH v5 1/5] dt-bindings: soc: qcom: Add device tree binding for GENI SE
Add device tree binding support for the QCOM GENI SE driver.
Signed-off-by: Karthikeyan Ramasubramanian
Signed-off-by: Sagar Dharia
Signed-off-by: Girish Mahadevan
Reviewed-by: Rob Herring
Reviewed-by: Stephen Boyd
---
.../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 119 +
1 file changed, 119 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
new file mode 100644
index 000..d330c73
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -0,0 +1,119 @@
+Qualcomm Technologies, Inc. GENI Serial Engine QUP Wrapper Controller
+
+Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper
+is a programmable module for supporting a wide range of serial interfaces
+like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial
+Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP
+Wrapper controller is modeled as a node with zero or more child nodes each
+representing a serial engine.
+
+Required properties:
+- compatible: Must be "qcom,geni-se-qup".
+- reg: Must contain QUP register address and length.
+- clock-names: Must contain "m-ahb" and "s-ahb".
+- clocks: AHB clocks needed by the device.
+
+Required properties if child node exists:
+- #address-cells: Must be <1> for Serial Engine Address
+- #size-cells: Must be <1> for Serial Engine Address Size
+- ranges: Must be present
+
+Properties for children:
+
+A GENI based QUP wrapper controller node can contain 0 or more child nodes
+representing serial devices. These serial devices can be a QCOM UART, I2C
+controller, SPI controller, or some combination of aforementioned devices.
+Please refer below the child node definitions for the supported serial
+interface protocols.
+
+Qualcomm Technologies Inc. GENI Serial Engine based I2C Controller
+
+Required properties:
+- compatible: Must be "qcom,geni-i2c".
+- reg: Must contain QUP register address and length.
+- interrupts: Must contain I2C interrupt.
+- clock-names: Must contain "se".
+- clocks: Serial engine core clock needed by the device.
+- #address-cells: Must be <1> for I2C device address.
+- #size-cells: Must be <0> as I2C addresses have no size component.
+
+Optional property:
+- clock-frequency: Desired I2C bus clock frequency in Hz.
+ When missing default to 40Hz.
+
+Child nodes should conform to I2C bus binding as described in i2c.txt.
+
+Qualcomm Technologies Inc. GENI Serial Engine based UART Controller
+
+Required properties:
+- compatible: Must be "qcom,geni-debug-uart".
+- reg: Must contain UART register location and length.
+- interrupts: Must contain UART core interrupts.
+- clock-names: Must contain "se".
+- clocks: Serial engine core clock needed by the device.
+
+Qualcomm Technologies Inc. GENI Serial Engine based SPI Controller
+
+Required properties:
+- compatible: Must contain "qcom,geni-spi".
+- reg: Must contain SPI register location and length.
+- interrupts: Must contain SPI controller interrupts.
+- clock-names: Must contain "se".
+- clocks: Serial engine core clock needed by the device.
+- spi-max-frequency: Specifies maximum SPI clock frequency, units - Hz.
+- #address-cells: Must be <1> to define a chip select address on
+ the SPI bus.
+- #size-cells: Must be <0>.
+
+SPI slave nodes must be children of the SPI master node and conform to SPI bus
+binding as described in Documentation/devicetree/bindings/spi/spi-bus.txt.
+
+Example:
+ geniqup@8c {
+ compatible = "qcom,geni-se-qup";
+ reg = <0x8c 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c0: i2c@a94000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa94000 0x4000>;
+ interrupts = ;
+ clock-names = "se";
+ clocks = <&clock_gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_1_i2c_5_active>;
+ pinctrl-1 = <&qup_1_i2c_5_sleep>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ uart0: serial@a88000 {
+ compati
[PATCH v5 0/5] Introduce GENI SE Controller Driver
Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP) Wrapper is a next generation programmable module for supporting a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial Interfaces using its internal Serial Engines (SE). The protocol supported by each interface is determined by the firmware loaded to the Serial Engine. This patch series introduces GENI SE Driver to manage the GENI based QUP Wrapper and the common aspects of all SEs inside the QUP Wrapper. This patch series also introduces the UART and I2C Controller drivers to drive the SEs that are programmed with the respective protocols. [v5] * Remove Linux specific property from the device tree binding * Clarify I2C SCL time period documentation * Remove redundant checks in I2C controller driver during timeout * Use 100kHz as the default clock frequency in the I2C controller driver * Disable Wrapper controller by default in the SDM845 device tree and enable it explicitly for SDM845 MTP * Specify I2C clock frequency in the SDM845 device tree * Remove bias configuration for I2C pins under sleep state in device tree * Drop the serial driver from the patch series since it is merged * Specify the UART port options in the SDM845 device tree [v4] * Add SPI controller information in device tree binding * Add support for debug UART & I2C controllers in SDM845 device tree * Remove any unnecessary parenthesis & casting * Identify break character in UART line and pass it to the framework * Transmit data from fault handler reliably in debug UART * Map the register block when the UART port is requested * Move concise exported functions as macros or inlines in public header * Move the clock performance table from the wrapper to serial engines * Add a lock to synchronize between IRQ & error handling in I2C controller * Remove any compiler optimization hints like likely/unlikely * Update documentation to clarify tables and hardware blocks [v3] * Update the driver dependencies * Use the SPDX License Expression * Squash all the controller device tree bindings together * Use kernel doc format for documentation * Add additional documentation for packing configuration * Use clk_bulk_* API for related clocks * Remove driver references to pinctrl and their states * Replace magic numbers with appropriate macros * Update memory barrier usage and associated comments * Reduce interlacing of register reads/writes * Fix poll_get_char() operation in console UART driver under polling mode * Address other comments from Bjorn Andersson to improve code readability [v2] * Updated device tree bindings to describe the hardware * Updated SE DT node as child node of QUP Wrapper DT node * Moved common AHB clocks to QUP Wrapper DT node * Use the standard "clock-frequency" I2C property * Update compatible field in UART Controller to reflect hardware manual * Addressed other device tree binding specific comments from Rob Herring Karthikeyan Ramasubramanian (4): dt-bindings: soc: qcom: Add device tree binding for GENI SE soc: qcom: Add GENI based QUP Wrapper driver i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller arm64: dts: sdm845: Add support for an instance of I2C controller Rajendra Nayak (1): arm64: dts: sdm845: Add serial console support .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 119 arch/arm64/boot/dts/qcom/sdm845-mtp.dts| 59 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 68 ++ drivers/i2c/busses/Kconfig | 13 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-qcom-geni.c | 650 ++ drivers/soc/qcom/Kconfig | 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom-geni-se.c| 748 + include/linux/qcom-geni-se.h | 425 10 files changed, 2093 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c create mode 100644 drivers/soc/qcom/qcom-geni-se.c create mode 100644 include/linux/qcom-geni-se.h -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 v5 4/5] arm64: dts: sdm845: Add serial console support
From: Rajendra Nayak
Add the qup uart node and geni se instance needed to
support the serial console on the MTP.
Signed-off-by: Rajendra Nayak
Signed-off-by: Karthikeyan Ramasubramanian
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 41 +
arch/arm64/boot/dts/qcom/sdm845.dtsi| 39 +++
2 files changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49..17b2fb0 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,45 @@
/ {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+ aliases {
+ serial0 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&soc {
+ geniqup@ac {
+ status = "okay";
+
+ serial@a84000 {
+ status = "okay";
+ };
+ };
+
+ pinctrl@340 {
+ qup-uart2-default {
+ pinconf_tx {
+ pins = "gpio4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pinconf_rx {
+ pins = "gpio5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ qup-uart2-sleep {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ bias-pull-down;
+ };
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 32f8561..71801b9 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -6,6 +6,7 @@
*/
#include
+#include
/ {
interrupt-parent = <&intc>;
@@ -194,6 +195,20 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+ qup_uart2_default: qup-uart2-default {
+ pinmux {
+ function = "qup9";
+ pins = "gpio4", "gpio5";
+ };
+ };
+
+ qup_uart2_sleep: qup-uart2-sleep {
+ pinmux {
+ function = "gpio";
+ pins = "gpio4", "gpio5";
+ };
+ };
};
timer@17c9 {
@@ -272,5 +287,29 @@
#interrupt-cells = <4>;
cell-index = <0>;
};
+
+ geniqup@ac {
+ compatible = "qcom,geni-se-qup";
+ reg = <0xac 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+<&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ uart2: serial@a84000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_uart2_default>;
+ pinctrl-1 = <&qup_uart2_sleep>;
+ interrupts = ;
+ status = "disabled";
+ };
+ };
};
};
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v5 3/5] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller
This bus driver supports the GENI based i2c hardware controller in the
Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
module supporting a wide range of serial interfaces including I2C. The
driver supports FIFO mode and DMA mode of transfer and switches modes
dynamically depending on the size of the transfer.
Signed-off-by: Karthikeyan Ramasubramanian
Signed-off-by: Sagar Dharia
Signed-off-by: Girish Mahadevan
---
drivers/i2c/busses/Kconfig | 13 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-qcom-geni.c | 650 +
3 files changed, 664 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e2954fb..89e642a 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -848,6 +848,19 @@ config I2C_PXA_SLAVE
is necessary for systems where the PXA may be a target on the
I2C bus.
+config I2C_QCOM_GENI
+ tristate "Qualcomm Technologies Inc.'s GENI based I2C controller"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on QCOM_GENI_SE
+ help
+ This driver supports GENI serial engine based I2C controller in
+ master mode on the Qualcomm Technologies Inc.'s SoCs. If you say
+ yes to this option, support will be included for the built-in I2C
+ interface on the Qualcomm Technologies Inc.'s SoCs.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-qcom-geni.
+
config I2C_QUP
tristate "Qualcomm QUP based I2C controller"
depends on ARCH_QCOM
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 2ce8576..201fce1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o
obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
+obj-$(CONFIG_I2C_QCOM_GENI)+= i2c-qcom-geni.o
obj-$(CONFIG_I2C_QUP) += i2c-qup.o
obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
new file mode 100644
index 000..24f859d
--- /dev/null
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -0,0 +1,650 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SE_I2C_TX_TRANS_LEN0x26c
+#define SE_I2C_RX_TRANS_LEN0x270
+#define SE_I2C_SCL_COUNTERS0x278
+
+#define SE_I2C_ERR (M_CMD_OVERRUN_EN | M_ILLEGAL_CMD_EN | M_CMD_FAILURE_EN |\
+ M_GP_IRQ_1_EN | M_GP_IRQ_3_EN | M_GP_IRQ_4_EN)
+#define SE_I2C_ABORT BIT(1)
+
+/* M_CMD OP codes for I2C */
+#define I2C_WRITE 0x1
+#define I2C_READ 0x2
+#define I2C_WRITE_READ 0x3
+#define I2C_ADDR_ONLY 0x4
+#define I2C_BUS_CLEAR 0x6
+#define I2C_STOP_ON_BUS0x7
+/* M_CMD params for I2C */
+#define PRE_CMD_DELAY BIT(0)
+#define TIMESTAMP_BEFORE BIT(1)
+#define STOP_STRETCH BIT(2)
+#define TIMESTAMP_AFTERBIT(3)
+#define POST_COMMAND_DELAY BIT(4)
+#define IGNORE_ADD_NACKBIT(6)
+#define READ_FINISHED_WITH_ACK BIT(7)
+#define BYPASS_ADDR_PHASE BIT(8)
+#define SLV_ADDR_MSK GENMASK(15, 9)
+#define SLV_ADDR_SHFT 9
+/* I2C SCL COUNTER fields */
+#define HIGH_COUNTER_MSK GENMASK(29, 20)
+#define HIGH_COUNTER_SHFT 20
+#define LOW_COUNTER_MSKGENMASK(19, 10)
+#define LOW_COUNTER_SHFT 10
+#define CYCLE_COUNTER_MSK GENMASK(9, 0)
+
+enum geni_i2c_err_code {
+ GP_IRQ0,
+ NACK,
+ GP_IRQ2,
+ BUS_PROTO,
+ ARB_LOST,
+ GP_IRQ5,
+ GENI_OVERRUN,
+ GENI_ILLEGAL_CMD,
+ GENI_ABORT_DONE,
+ GENI_TIMEOUT,
+};
+
+#define DM_I2C_CB_ERR ((BIT(NACK) | BIT(BUS_PROTO) | BIT(ARB_LOST)) \
+ << 5)
+
+#define I2C_AUTO_SUSPEND_DELAY 250
+#define KHZ(freq) (1000 * freq)
+#define PACKING_BYTES_PW 4
+
+#define ABORT_TIMEOUT HZ
+#define XFER_TIMEOUT HZ
+#define RST_TIMEOUTHZ
+
+struct geni_i2c_dev {
+ struct geni_se se;
+ u32 tx_wm;
+ int irq;
+ int err;
+ struct i2c_adapter adap;
+ struct completion done;
+ struct i2c_msg *cur;
+ int cur_wr;
+ int cur_rd;
+ spinlock_t lock;
+ u32 clk_freq_out;
+ const struct geni_i2c_clk_fld *clk_fld;
+};
+
+struct geni_i2c_err_log {
+ int err;
+ const c
[PATCH v5 5/5] arm64: dts: sdm845: Add support for an instance of I2C controller
Add one instance of GENI based I2C master controller to enable testing
I2C driver using EEPROM slave.
Signed-off-by: Karthikeyan Ramasubramanian
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 18 ++
arch/arm64/boot/dts/qcom/sdm845.dtsi| 29 +
2 files changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 17b2fb0..e82c98d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -29,9 +29,27 @@
serial@a84000 {
status = "okay";
};
+
+ i2c@a88000 {
+ status = "okay";
+ };
};
pinctrl@340 {
+ qup-i2c10-default {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
+ qup-i2c10-sleep {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ };
+ };
+
qup-uart2-default {
pinconf_tx {
pins = "gpio4";
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 71801b9..a13836f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -196,6 +196,20 @@
interrupt-controller;
#interrupt-cells = <2>;
+ qup_i2c10_default: qup-i2c10-default {
+ pinmux {
+ function = "qup10";
+ pins = "gpio55", "gpio56";
+ };
+ };
+
+ qup_i2c10_sleep: qup-i2c10-sleep {
+ pinmux {
+ function = "gpio";
+ pins = "gpio55", "gpio56";
+ };
+ };
+
qup_uart2_default: qup-uart2-default {
pinmux {
function = "qup9";
@@ -310,6 +324,21 @@
interrupts = ;
status = "disabled";
};
+
+ i2c10: i2c@a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c10_default>;
+ pinctrl-1 = <&qup_i2c10_sleep>;
+ interrupts = ;
+ clock-frequency = <40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
};
};
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v5 2/5] soc: qcom: Add GENI based QUP Wrapper driver
This driver manages the Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation programmable module composed of multiple Serial Engines (SE) and supports a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This driver also enables managing the serial interface independent aspects of Serial Engines. Signed-off-by: Karthikeyan Ramasubramanian Signed-off-by: Sagar Dharia Signed-off-by: Girish Mahadevan --- drivers/soc/qcom/Kconfig| 9 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/qcom-geni-se.c | 748 include/linux/qcom-geni-se.h| 425 +++ 4 files changed, 1183 insertions(+) create mode 100644 drivers/soc/qcom/qcom-geni-se.c create mode 100644 include/linux/qcom-geni-se.h diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index e050eb8..98ca9f5 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -3,6 +3,15 @@ # menu "Qualcomm SoC drivers" +config QCOM_GENI_SE + tristate "QCOM GENI Serial Engine Driver" + depends on ARCH_QCOM || COMPILE_TEST + help + This driver is used to manage Generic Interface (GENI) firmware based + Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This + driver is also used to manage the common aspects of multiple Serial + Engines present in the QUP. + config QCOM_GLINK_SSR tristate "Qualcomm Glink SSR driver" depends on RPMSG diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index dcebf28..959aa74 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o obj-$(CONFIG_QCOM_MDT_LOADER) += mdt_loader.o diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c new file mode 100644 index 000..feed3db2 --- /dev/null +++ b/drivers/soc/qcom/qcom-geni-se.c @@ -0,0 +1,748 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/** + * DOC: Overview + * + * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced + * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper + * controller. QUP Wrapper is designed to support various serial bus protocols + * like UART, SPI, I2C, I3C, etc. + */ + +/** + * DOC: Hardware description + * + * GENI based QUP is a highly-flexible and programmable module for supporting + * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single + * QUP module can provide upto 8 serial interfaces, using its internal + * serial engines. The actual configuration is determined by the target + * platform configuration. The protocol supported by each interface is + * determined by the firmware loaded to the serial engine. Each SE consists + * of a DMA Engine and GENI sub modules which enable serial engines to + * support FIFO and DMA modes of operation. + * + * + * +-+ + * |QUP Wrapper | + * | ++ | + * --QUP & SE Clocks--> | Serial Engine N| +-IO--> + * | | ...| | Interface + * <---Clock Perf.+++---+| | + * State Interface || Serial Engine 1|| | + * |||| | + * |||| | + *||| | + * ||++ | + * ||| | + * ||| | + * <--SE IRQ--+++ | + * | | + * +-+ + * + * Figure 1: GENI based QUP Wrapper + * + * The GENI submodules include primary and secondary sequencers which are + * used to drive TX & RX operations. On serial interfaces that operate using + * master-slave model, primary sequencer drives both TX & RX operations. On + * serial interfaces that operate using peer-to-peer model, primary sequencer + * drives TX operation and secondary sequencer drives RX operation. + */ + +/** + * DOC: Software description + * + * GENI SE Wrapper driver is structured into 2 parts: + * + * geni_wrap
Re: [PATCH v5 3/5] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller
Hi,
On Fri, Mar 23, 2018 at 1:20 PM, Karthikeyan Ramasubramanian
wrote:
> This bus driver supports the GENI based i2c hardware controller in the
> Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
> module supporting a wide range of serial interfaces including I2C. The
> driver supports FIFO mode and DMA mode of transfer and switches modes
> dynamically depending on the size of the transfer.
>
> Signed-off-by: Karthikeyan Ramasubramanian
> Signed-off-by: Sagar Dharia
> Signed-off-by: Girish Mahadevan
> ---
> drivers/i2c/busses/Kconfig | 13 +
> drivers/i2c/busses/Makefile| 1 +
> drivers/i2c/busses/i2c-qcom-geni.c | 650
> +
> 3 files changed, 664 insertions(+)
[...]
> +/*
> + * Hardware uses the underlying formula to calculate time periods of
> + * SCL clock cycle. Firmware uses some additional cycles excluded from the
> + * below formula and it is confirmed that the time periods are within
> + * specification limits.
I was hoping for more than just "oh, and there's a fudge factor", but
I guess this is the best I'm going to get?
> +static int geni_i2c_probe(struct platform_device *pdev)
> +{
> + struct geni_i2c_dev *gi2c;
> + struct resource *res;
> + u32 proto, tx_depth;
> + int ret;
> +
> + gi2c = devm_kzalloc(&pdev->dev, sizeof(*gi2c), GFP_KERNEL);
> + if (!gi2c)
> + return -ENOMEM;
> +
> + gi2c->se.dev = &pdev->dev;
> + gi2c->se.wrapper = dev_get_drvdata(pdev->dev.parent);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + gi2c->se.base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(gi2c->se.base))
> + return PTR_ERR(gi2c->se.base);
> +
> + gi2c->se.clk = devm_clk_get(&pdev->dev, "se");
> + if (IS_ERR(gi2c->se.clk)) {
> + ret = PTR_ERR(gi2c->se.clk);
> + dev_err(&pdev->dev, "Err getting SE Core clk %d\n", ret);
> + return ret;
> + }
> +
> + ret = device_property_read_u32(&pdev->dev, "clock-frequency",
> + &gi2c->clk_freq_out);
> + if (ret) {
> + /* Clock frequency not specified, so default to 100kHz. */
> + dev_info(&pdev->dev,
> + "Bus frequency not specified, default to 100kHz.\n");
If you happen to spin again, can you remove the comment since it's
obvious from the string in the print? It looks a lot like this code:
/* Print hello, world */
printf("hello, world\n");
In any case, that's a pretty minor nit, so I'll add:
Reviewed-by: Douglas Anderson
...assuming that the bindings and "geni" code get Acked / landed
somewhere. Ideally let's not land this before the geni code lands
since if the geni API changes for some reason it'll cause us grief.
-Doug
--
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 v5 5/5] arm64: dts: sdm845: Add support for an instance of I2C controller
Hi,
On Fri, Mar 23, 2018 at 1:21 PM, Karthikeyan Ramasubramanian
wrote:
> + i2c10: i2c@a88000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa88000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c10_default>;
> + pinctrl-1 = <&qup_i2c10_sleep>;
> + interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <40>;
Please move the clock-frequency to the board file. Not all devices on
all boards will support 400 kHz, so we should be at 100 kHz by default
and boards should explicitly say that they support 400 kHz.
Other than that things look good to me and you can add my Reviewed-by tag.
-Doug
--
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 v4 7/8] clocksource: Add a new timer-ingenic driver
On 18/03/2018 00:29, Paul Cercueil wrote:
> This driver will use the TCU (Timer Counter Unit) present on the Ingenic
> JZ47xx SoCs to provide the kernel with a clocksource and timers.
Please provide a more detailed description about the timer.
Where is the clocksource ?
I don't see the point of using channel idx and pwm checking here.
There is one clockevent, why create multiple channels ? Can't you stick
to the usual init routine for a timer.
> Signed-off-by: Paul Cercueil
> ---
> drivers/clocksource/Kconfig | 8 ++
> drivers/clocksource/Makefile| 1 +
> drivers/clocksource/timer-ingenic.c | 278
>
> 3 files changed, 287 insertions(+)
> create mode 100644 drivers/clocksource/timer-ingenic.c
>
> v2: Use SPDX identifier for the license
> v3: - Move documentation to its own patch
> - Search the devicetree for PWM clients, and use all the TCU
> channels that won't be used for PWM
> v4: - Add documentation about why we search for PWM clients
> - Verify that the PWM clients are for the TCU PWM driver
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index d2e5382821a4..481422145fb4 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -592,4 +592,12 @@ config CLKSRC_ST_LPC
> Enable this option to use the Low Power controller timer
> as clocksource.
>
> +config INGENIC_TIMER
> + bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
> + depends on MACH_INGENIC || COMPILE_TEST
bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST
Remove the depends MACH_INGENIC.
> + select CLKSRC_OF
> + default y
No default, Kconfig platform selects the timer.
> + help
> + Support for the timer/counter unit of the Ingenic JZ SoCs.
> +
> endmenu
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index d6dec4489d66..98691e8999fe 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -74,5 +74,6 @@ obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
> obj-$(CONFIG_H8300_TMR8) += h8300_timer8.o
> obj-$(CONFIG_H8300_TMR16)+= h8300_timer16.o
> obj-$(CONFIG_H8300_TPU) += h8300_tpu.o
> +obj-$(CONFIG_INGENIC_TIMER) += timer-ingenic.o
> obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
> obj-$(CONFIG_X86_NUMACHIP) += numachip.o
> diff --git a/drivers/clocksource/timer-ingenic.c
> b/drivers/clocksource/timer-ingenic.c
> new file mode 100644
> index ..8c777c0c0023
> --- /dev/null
> +++ b/drivers/clocksource/timer-ingenic.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Ingenic JZ47xx SoC TCU clocksource driver
> + * Copyright (C) 2018 Paul Cercueil
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NUM_CHANNELS 8
> +
> +struct ingenic_tcu;
> +
> +struct ingenic_tcu_channel {
> + unsigned int idx;
> + struct clk *clk;
> +};
> +
> +struct ingenic_tcu {
> + struct ingenic_tcu_channel channels[NUM_CHANNELS];
> + unsigned long requested;
> + struct regmap *map;
> +};
> +
> +struct ingenic_clock_event_device {
> + struct clock_event_device cevt;
> + struct ingenic_tcu_channel *channel;
> + char name[32];
> +};
> +
> +#define ingenic_cevt(_evt) \
> + container_of(_evt, struct ingenic_clock_event_device, cevt)
> +
> +static inline struct ingenic_tcu *to_ingenic_tcu(struct ingenic_tcu_channel
> *ch)
> +{
> + return container_of(ch, struct ingenic_tcu, channels[ch->idx]);
> +}
> +
> +static int ingenic_tcu_cevt_set_state_shutdown(struct clock_event_device
> *evt)
> +{
> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
> + struct ingenic_tcu_channel *channel = jzcevt->channel;
> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
> + unsigned int idx = channel->idx;
> +
> + regmap_write(tcu->map, TCU_REG_TECR, BIT(idx));
> + return 0;
> +}
> +
> +static int ingenic_tcu_cevt_set_next(unsigned long next,
> + struct clock_event_device *evt)
> +{
> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(evt);
> + struct ingenic_tcu_channel *channel = jzcevt->channel;
> + struct ingenic_tcu *tcu = to_ingenic_tcu(channel);
> + unsigned int idx = channel->idx;
> +
> + if (next > 0x)
> + return -EINVAL;
> +
> + regmap_write(tcu->map, TCU_REG_TDFRc(idx), (unsigned int) next);
> + regmap_write(tcu->map, TCU_REG_TCNTc(idx), 0);
> + regmap_write(tcu->map, TCU_REG_TESR, BIT(idx));
> +
> + return 0;
> +}
> +
> +static irqreturn_t ingenic_tcu_cevt_cb(int irq, void *dev_id)
> +{
> + struct clock_event_device *cevt = dev_id;
> + struct ingenic_clock_event_device *jzcevt = ingenic_cevt(cevt);
> + struct ingeni
