* [RFC 0/5] Add I3C subsystem
@ 2017-07-31 16:24 Boris Brezillon
2017-07-31 16:24 ` [RFC 1/5] i2c: Export of_i2c_get_board_info() Boris Brezillon
` (5 more replies)
0 siblings, 6 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Boris Brezillon
This patch series is a proposal for a new I3C [1] subsystem.
This infrastructure is not complete yet and will be extended over
time.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to send I3C/I2C frames must be called in
non-atomic context. Mainly done this way to ease implementation, but
this is still open to discussion. Please let me know if you think it's
worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
by the master (as done in I2C). The reason is that I want to be able
to handle multiple master connected to the same bus and visible to
Linux.
In this situation, we should only have one instance of the device and
not one per master, and sharing the bus object would be part of the
solution to gracefully handle this case.
I'm not sure if we will ever need to deal with multiple masters
controlling the same bus and exposed under Linux, but separating the
bus and master concept is pretty easy, hence the decision to do it
now, just in case we need it some day.
The other benefit of separating the bus and master concepts is that
master devices appear under the bus directory in sysfs.
- I2C backward compatibility has been designed to be transparent to I2C
drivers and the I2C subsystem. The I3C master just registers an I2C
adapter which creates a new I2C bus. I'd say that, from a
representation PoV it's not ideal because what should appear as a
single I3C bus exposing I3C and I2C devices here appears as 2
different busses connected to each other through the parenting (the
I3C master is the parent of the I2C and I3C busses).
On the other hand, I don't see a better solution if we want something
that is not invasive.
- the whole API is exposed through a single header file (i3c.h), but I'm
seriously considering the option of splitting the I3C driver/user API
and the I3C master one, mainly to hide I3C core internals and restrict
what I3C users can do to a limited set of functionalities (send
I3C/I2C frames to a specific device and that's all).
Missing features in this preliminary version:
- no support for IBI (In Band Interrupts). This is something I'm working
on, and I'm still unsure how to represent it: an irqchip or a
completely independent representation that would be I3C specific.
Right now, I'm more inclined to go for the irqchip approach, since
this is something people are used to deal with already.
- no Hot Join support, which is similar to hotplug
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
have a huge impact on the I3C framework because I3C slaves don't see
the whole bus, it's only about handling master requests and generating
IBIs. Some of the struct, constant and enum definitions could be
shared, but most of the I3C slave framework logic will be different
If possible, I'd like to have reviews from people that are familiar
with the device model and complex/autodiscoverable busses like USB.
Arnd, Greg, I think your feedback would be very valuable here.
Wolfram, feel free to comment on the integration with the I2C subsystem,
and let me know if you see a better option.
I'd also like to get feedback on the doc. Should I detail a bit more
the protocol or the framework API? Is this the kind of things you
expect in a subsystem doc?
I'm also unsure how far I should go with sysfs attributes. Right
now, I have exposed things that should matter to udev & co plus some
extra information about I3C dev capabilities (sysfs files have not
been documented yet, but I'll do it for the next version of this patch
series). I could go even further and expose more details like device
limitations (in terms of speed), device status, etc. However, I don't
know if those information are relevant to user-space applications.
If you know other people that might be interested by this patchset,
just let me know and I'll Cc them on the next version.
Thanks,
Boris
[1]https://www.mipi.org/specifications/i3c-sensor-specification
Boris Brezillon (5):
i2c: Export of_i2c_get_board_info()
i3c: Add core I3C infrastructure
dt-bindings: i3c: Document core bindings
i3c: master: Add driver for Cadence IP
dt-bindings: i3c: Document Cadence I3C master bindings
.../devicetree/bindings/i3c/cdns,i3c-master.txt | 45 +
Documentation/devicetree/bindings/i3c/i3c.txt | 90 ++
Documentation/i3c/conf.py | 10 +
Documentation/i3c/device-driver-api.rst | 7 +
Documentation/i3c/index.rst | 9 +
Documentation/i3c/master-driver-api.rst | 8 +
Documentation/i3c/protocol.rst | 199 +++
Documentation/index.rst | 1 +
drivers/Kconfig | 2 +
drivers/Makefile | 2 +-
drivers/i2c/i2c-core-base.c | 2 +-
drivers/i2c/i2c-core-of.c | 64 +-
drivers/i3c/Kconfig | 24 +
drivers/i3c/Makefile | 3 +
drivers/i3c/core.c | 532 ++++++++
drivers/i3c/device.c | 138 ++
drivers/i3c/internals.h | 45 +
drivers/i3c/master.c | 1225 +++++++++++++++++
drivers/i3c/master/Kconfig | 4 +
drivers/i3c/master/Makefile | 1 +
drivers/i3c/master/i3c-master-cdns.c | 1382 ++++++++++++++++++++
include/linux/i2c.h | 10 +
include/linux/i3c/ccc.h | 389 ++++++
include/linux/i3c/device.h | 212 +++
include/linux/i3c/master.h | 453 +++++++
include/linux/mod_devicetable.h | 15 +
26 files changed, 4843 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
create mode 100644 Documentation/i3c/conf.py
create mode 100644 Documentation/i3c/device-driver-api.rst
create mode 100644 Documentation/i3c/index.rst
create mode 100644 Documentation/i3c/master-driver-api.rst
create mode 100644 Documentation/i3c/protocol.rst
create mode 100644 drivers/i3c/Kconfig
create mode 100644 drivers/i3c/Makefile
create mode 100644 drivers/i3c/core.c
create mode 100644 drivers/i3c/device.c
create mode 100644 drivers/i3c/internals.h
create mode 100644 drivers/i3c/master.c
create mode 100644 drivers/i3c/master/Kconfig
create mode 100644 drivers/i3c/master/Makefile
create mode 100644 drivers/i3c/master/i3c-master-cdns.c
create mode 100644 include/linux/i3c/ccc.h
create mode 100644 include/linux/i3c/device.h
create mode 100644 include/linux/i3c/master.h
--
2.7.4
^ permalink raw reply [flat|nested] 91+ messages in thread
* [RFC 1/5] i2c: Export of_i2c_get_board_info()
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
@ 2017-07-31 16:24 ` Boris Brezillon
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
` (4 subsequent siblings)
5 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, 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 <boris.brezillon@free-electrons.com>
---
drivers/i2c/i2c-core-base.c | 2 +-
drivers/i2c/i2c-core-of.c | 64 ++++++++++++++++++++++++++-------------------
include/linux/i2c.h | 10 +++++++
3 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index c89dac7fd2e7..ea1391d09266 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -762,7 +762,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
client->dev.parent = &client->adapter->dev;
client->dev.bus = &i2c_bus_type;
client->dev.type = &i2c_client_type;
- client->dev.of_node = info->of_node;
+ client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
i2c_dev_set_name(adap, client);
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index ccf82fdbcd8e..b201613e71e5 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -22,63 +22,73 @@
#include "i2c-core.h"
-static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
- struct device_node *node)
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info)
{
- struct i2c_client *result;
- struct i2c_board_info info = {};
- struct dev_archdata dev_ad = {};
- const __be32 *addr_be;
u32 addr;
- int len;
+ int ret;
- dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
+ memset(info, 0, sizeof(info));
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
- dev_err(&adap->dev, "of_i2c: modalias failure on %s\n",
+ if (of_modalias_node(node, info->type, sizeof(info->type)) < 0) {
+ dev_err(dev, "of_i2c: modalias failure on %s\n",
node->full_name);
- return ERR_PTR(-EINVAL);
+ return -EINVAL;
}
- addr_be = of_get_property(node, "reg", &len);
- if (!addr_be || (len < sizeof(*addr_be))) {
- dev_err(&adap->dev, "of_i2c: invalid reg on %s\n",
+ ret = of_property_read_u32(node, "reg", &addr);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid reg on %s\n",
node->full_name);
- return ERR_PTR(-EINVAL);
+ return ret;
}
- addr = be32_to_cpup(addr_be);
if (addr & I2C_TEN_BIT_ADDRESS) {
addr &= ~I2C_TEN_BIT_ADDRESS;
- info.flags |= I2C_CLIENT_TEN;
+ info->flags |= I2C_CLIENT_TEN;
}
if (addr & I2C_OWN_SLAVE_ADDRESS) {
addr &= ~I2C_OWN_SLAVE_ADDRESS;
- info.flags |= I2C_CLIENT_SLAVE;
+ info->flags |= I2C_CLIENT_SLAVE;
}
- if (i2c_check_addr_validity(addr, info.flags)) {
- dev_err(&adap->dev, "of_i2c: invalid addr=%x on %s\n",
+ ret = i2c_check_addr_validity(addr, info->flags);
+ if (ret) {
+ dev_err(dev, "of_i2c: invalid addr=%x on %s\n",
addr, node->full_name);
- return ERR_PTR(-EINVAL);
+ return ret;
}
- info.addr = addr;
- info.of_node = of_node_get(node);
- info.archdata = &dev_ad;
+ info->addr = addr;
+ info->of_node = node;
if (of_property_read_bool(node, "host-notify"))
- info.flags |= I2C_CLIENT_HOST_NOTIFY;
+ info->flags |= I2C_CLIENT_HOST_NOTIFY;
if (of_get_property(node, "wakeup-source", NULL))
- info.flags |= I2C_CLIENT_WAKE;
+ info->flags |= I2C_CLIENT_WAKE;
+
+ return 0;
+}
+
+static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+ struct device_node *node)
+{
+ struct i2c_client *result;
+ struct i2c_board_info info;
+ int ret;
+
+ dev_dbg(&adap->dev, "of_i2c: register %s\n", node->full_name);
+
+ ret = of_i2c_get_board_info(&adap->dev, node, &info);
+ if (ret)
+ return ERR_PTR(ret);
result = i2c_new_device(adap, &info);
if (result == NULL) {
dev_err(&adap->dev, "of_i2c: Failure registering %s\n",
node->full_name);
- of_node_put(node);
return ERR_PTR(-EINVAL);
}
return result;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 00ca5b86a753..ea91270c258d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -806,6 +806,9 @@ extern const struct of_device_id
*i2c_of_match_device(const struct of_device_id *matches,
struct i2c_client *client);
+int of_i2c_get_board_info(struct device *dev, struct device_node *node,
+ struct i2c_board_info *info);
+
#else
static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
@@ -830,6 +833,13 @@ static inline const struct of_device_id
return NULL;
}
+static inline int of_i2c_get_board_info(struct device *dev,
+ struct device_node *node,
+ struct i2c_board_info *info)
+{
+ return -ENOTSUPP;
+}
+
#endif /* CONFIG_OF */
#if IS_ENABLED(CONFIG_ACPI)
--
2.7.4
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
2017-07-31 16:24 ` [RFC 1/5] i2c: Export of_i2c_get_board_info() Boris Brezillon
@ 2017-07-31 16:24 ` Boris Brezillon
2017-07-31 19:17 ` Wolfram Sang
` (3 more replies)
2017-07-31 16:24 ` Boris Brezillon
` (3 subsequent siblings)
5 siblings, 4 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Boris Brezillon
Add core infrastructure to support I3C in Linux and document it.
This infrastructure is not complete yet and will be extended over
time.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to send I3C/I2C frames must be called in
non-atomic context. Mainly done this way to ease implementation, but
this is still open to discussion. Please let me know if you think it's
worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
by the master (as done in I2C). The reason is that I want to be able
to handle multiple master connected to the same bus and visible to
Linux.
In this situation, we should only have one instance of the device and
not one per master, and sharing the bus object would be part of the
solution to gracefully handle this case.
I'm not sure we will ever need to deal with multiple masters
controlling the same bus and exposed under Linux, but separating the
bus and master concept is pretty easy, hence the decision to do it
like that.
The other benefit of separating the bus and master concepts is that
master devices appear under the bus directory in sysfs.
- I2C backward compatibility has been designed to be transparent to I2C
drivers and the I2C subsystem. The I3C master just registers an I2C
adapter which creates a new I2C bus. I'd say that, from a
representation PoV it's not ideal because what should appear as a
single I3C bus exposing I3C and I2C devices here appears as 2
different busses connected to each other through the parenting (the
I3C master is the parent of the I2C and I3C busses).
On the other hand, I don't see a better solution if we want something
that is not invasive.
- the whole API is exposed through a single header file (i3c.h), but I'm
seriously considering the option of splitting the I3C driver/user API
and the I3C master one, mainly to hide I3C core internals and restrict
what I3C users can do to a limited set of functionalities (send
I3C/I2C frames to a specific device and that's all).
Missing features in this preliminary version:
- no support for IBI (In Band Interrupts). This is something I'm working
on, and I'm still unsure how to represent it: an irqchip or a
completely independent representation that would be I3C specific.
Right now, I'm more inclined to go for the irqchip approach, since
this is something people are used to deal with already.
- no Hot Join support, which is similar to hotplug
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
have a huge impact on the I3C framework because I3C slaves don't see
the whole bus, it's only about handling master requests and generating
IBIs. Some of the struct, constant and enum definitions could be
shared, but most of the I3C slave framework logic will be different
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Documentation/i3c/conf.py | 10 +
Documentation/i3c/device-driver-api.rst | 7 +
Documentation/i3c/index.rst | 9 +
Documentation/i3c/master-driver-api.rst | 8 +
Documentation/i3c/protocol.rst | 199 +++++
Documentation/index.rst | 1 +
drivers/Kconfig | 2 +
drivers/Makefile | 2 +-
drivers/i3c/Kconfig | 24 +
drivers/i3c/Makefile | 3 +
drivers/i3c/core.c | 532 ++++++++++++++
drivers/i3c/device.c | 138 ++++
drivers/i3c/internals.h | 45 ++
drivers/i3c/master.c | 1225 +++++++++++++++++++++++++++++++
drivers/i3c/master/Kconfig | 0
drivers/i3c/master/Makefile | 0
include/linux/i3c/ccc.h | 389 ++++++++++
include/linux/i3c/device.h | 212 ++++++
include/linux/i3c/master.h | 453 ++++++++++++
include/linux/mod_devicetable.h | 15 +
20 files changed, 3273 insertions(+), 1 deletion(-)
create mode 100644 Documentation/i3c/conf.py
create mode 100644 Documentation/i3c/device-driver-api.rst
create mode 100644 Documentation/i3c/index.rst
create mode 100644 Documentation/i3c/master-driver-api.rst
create mode 100644 Documentation/i3c/protocol.rst
create mode 100644 drivers/i3c/Kconfig
create mode 100644 drivers/i3c/Makefile
create mode 100644 drivers/i3c/core.c
create mode 100644 drivers/i3c/device.c
create mode 100644 drivers/i3c/internals.h
create mode 100644 drivers/i3c/master.c
create mode 100644 drivers/i3c/master/Kconfig
create mode 100644 drivers/i3c/master/Makefile
create mode 100644 include/linux/i3c/ccc.h
create mode 100644 include/linux/i3c/device.h
create mode 100644 include/linux/i3c/master.h
diff --git a/Documentation/i3c/conf.py b/Documentation/i3c/conf.py
new file mode 100644
index 000000000000..5a20832d59a7
--- /dev/null
+++ b/Documentation/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/i3c/device-driver-api.rst b/Documentation/i3c/device-driver-api.rst
new file mode 100644
index 000000000000..63c843f148a6
--- /dev/null
+++ b/Documentation/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/i3c/index.rst b/Documentation/i3c/index.rst
new file mode 100644
index 000000000000..9c439220439d
--- /dev/null
+++ b/Documentation/i3c/index.rst
@@ -0,0 +1,9 @@
+=============
+I3C subsystem
+=============
+
+.. toctree::
+
+ protocol
+ device-driver-api
+ master-driver-api
diff --git a/Documentation/i3c/master-driver-api.rst b/Documentation/i3c/master-driver-api.rst
new file mode 100644
index 000000000000..017e7711cdf7
--- /dev/null
+++ b/Documentation/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/i3c/protocol.rst b/Documentation/i3c/protocol.rst
new file mode 100644
index 000000000000..f140029d8175
--- /dev/null
+++ b/Documentation/i3c/protocol.rst
@@ -0,0 +1,199 @@
+============
+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.
+
+Introduction
+============
+
+The I3C (I-Cube-C) 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 devices on the bus.
+
+Once a dynamic address has been assigned to a device, this address will be used
+for any direct communication with the device. Note that even after being
+assigned a dynamic address, the device should still process broadcast messages.
+
+I3C Device discovery
+====================
+
+The I3C protocol defines a mechanism to automatically discover devices present
+on the bus, their capabilities and the functionalities they provide. In this
+regard I3C is closer to a discoverable bus like USB than it is to I2C or SPI.
+
+The discovery mechanism is called DAA (Dynamic Address Assignment), because it
+not only discovers devices but also assigns them a dynamic address.
+
+During DAA, each I3C device reports 3 important things:
+
+* BCR: Bus Characteristic Register. This 8-bit register describes the device bus
+ related capabilities
+* DCR: Device Characteristic Register. This 8-bit register describes the
+ functionalities provided by the device
+* Provisional ID: A 48-bit unique identifier. On a given bus there should be no
+ Provisional ID collision, otherwise the discovery mechanism may fail.
+
+I3C slave events
+================
+
+The I3C protocol allows slaves to generate events on their own, and thus allows
+them to take temporary control of the bus.
+
+This mechanism is called IBI for In Band Interrupts, and as stated in the name,
+it allows devices to generate interrupts without requiring an external signal.
+
+During DAA, each device on the bus has been assigned an address, and this
+address will serve as a priority identifier to determine who wins if 2 different
+devices are generating an interrupt at the same moment on the bus (the lower the
+dynamic address the higher the priority).
+
+Masters are allowed to inhibit interrupts if they want to. This inhibition
+request can be broadcasted (applies to all devices) or sent to a specific
+device.
+
+I3C Hot-Join
+============
+
+The Hot-Join mechanism is similart to USB hotplug. This mechanism allows
+slaves to join the bus after it has been initialized by the master.
+
+This covers the following use cases:
+* the device is not powered when the bus is probed
+* the device is hotplugged on the bus through an extension board
+
+This mechanism is relying on slave events to inform the master that a new
+device joined the bus and is waiting for a dynamic address.
+
+The master is then free to address the request as it wishes: ignore it or
+assign a dynamic address to the slave.
+
+I3C transfer types
+==================
+
+If you omit SMBus (which is just a standardization on how to access registers
+exposed by I2C devices), I2C has only one transfer type.
+
+I3C defines 3 different classes of transfer in addition to I2C transfers which
+are here for backward compatibility with I2C devices.
+
+I3C CCC commands
+----------------
+
+CCC (Common Command Code) commands are meant to be used for anything that is
+related to bus management and all features that are common to a set of devices.
+
+CCC commands contain an 8-bit CCC id describing the command that is executed.
+The MSB of this id specifies whether this is a broadcast command (bit7 = 0) or a
+unicast one (bit7 = 1).
+
+The command ID can be followed by a payload. Depending on the command, this
+payload is either sent by the master sending the command (write CCC command),
+or sent by the slave receiving the command (read CCC command). Of course, read
+accesses only apply to unicast commands.
+Note that, when sending a CCC command to a specific device, the device address
+is passed in the first byte of the payload.
+
+The payload length is not explicitly passed on the bus, and should be extracted
+from the CCC id.
+
+Note that vendors can use a dedicated range of CCC ids for their own commands
+(0x61-0x7f and 0xe0-0xef).
+
+I3C Private SDR transfers
+-------------------------
+
+Private SDR (Single Data Rate) transfers should be used for anything that is
+device specific and does not require high transfer speed.
+
+It is the equivalent of I2C transfers but in the I3C world. Each transfer is
+passed the device address (dynamic address assigned during DAA), a payload
+and a direction.
+
+The only difference with I2C is that the transfer is much faster (typical SCL
+frequency is 12.5MHz).
+
+I3C Private HDR commands
+------------------------
+
+HDR commands should be used for anything that is device specific and requires
+high transfer speed.
+
+The first thing attached to an HDR command is the HDR mode. There are currently
+3 different modes defined by the I3C specification (refer to the specification
+for more details):
+
+* HDR-DDR: Double Data Rate mode
+* HDR-TSP: Ternary Symbol Pure. Only usable on busses with no I2C devices
+* HDR-TSL: Ternary Symbol Legacy. Usable on busses with I2C devices
+
+When sending an HDR command, the whole bus has to enter HDR mode, which is done
+using a broadcast CCC command.
+Once the bus has entered a specific HDR mode, the master sends the HDR command.
+An HDR command is made of:
+
+* one 16-bits command word
+* N 16-bits data words
+
+Those words may be wrapped with specific preambles/post-ambles which depend on
+the chosen HDR mode and are detailed here (see the specification for more
+details).
+
+The 16-bits command word is made of:
+
+* bit[15]: direction bit, read is 1 write is 0
+* bit[14:8]: command code. Identifies the command being executed, the amount of
+ data words and their meaning
+* bit[7:1]: I3C address of the device this command is addressed to
+* bit[0]: reserved/parity-bit
+
+Backward compatibility with I2C devices
+=======================================
+
+The I3C protocol has been designed to be backward compatible with I2C devices.
+This backward compatibility allows one to connect a mix of I2C and I3C devices
+on the same bus, though, in order to be really efficient, I2C devices should
+be equipped with 50 ns spike filters.
+
+I2C devices can't be discovered like I3C ones and have to be statically
+declared. In order to let the master know what these devices are capable of
+(both in terms of bus related limitations and functionalities), the software
+has to provide some information, which is done through the LVR (Legacy I2C
+Virtual Register).
diff --git a/Documentation/index.rst b/Documentation/index.rst
index cb7f1ba5b3b1..da041b972fb1 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -75,6 +75,7 @@ needed).
sound/index
crypto/index
filesystems/index
+ i3c/index
Architecture-specific documentation
-----------------------------------
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 505c676fa9c7..281e883bbdaf 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -54,6 +54,8 @@ source "drivers/char/Kconfig"
source "drivers/i2c/Kconfig"
+source "drivers/i3c/Kconfig"
+
source "drivers/spi/Kconfig"
source "drivers/spmi/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index dfdcda00bfe3..e2a74abbd5b1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -111,7 +111,7 @@ obj-$(CONFIG_SERIO) += input/serio/
obj-$(CONFIG_GAMEPORT) += input/gameport/
obj-$(CONFIG_INPUT) += input/
obj-$(CONFIG_RTC_LIB) += rtc/
-obj-y += i2c/ media/
+obj-y += i2c/ i3c/ media/
obj-$(CONFIG_PPS) += pps/
obj-y += ptp/
obj-$(CONFIG_W1) += w1/
diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig
new file mode 100644
index 000000000000..0165c1072ac6
--- /dev/null
+++ b/drivers/i3c/Kconfig
@@ -0,0 +1,24 @@
+menu "I3C support"
+
+config I3C
+ tristate "I3C support"
+ ---help---
+ I3C (pronounce: I-cube-C) is a serial protocol standardized by the
+ MIPI alliance.
+
+ It's supposed to be backward compatible with I2C while providing
+ support for high speed transfers and native interrupt support
+ without the need for extra pins.
+
+ The I3C protocol also standardizes the slave device types and is
+ mainly design to communicate with sensors.
+
+ If you want I3C support, you should say Y here and also to the
+ specific driver for your bus adapter(s) below.
+
+ This I3C support can also be built as a module. If so, the module
+ will be called i3c.
+
+source "drivers/i3c/master/Kconfig"
+
+endmenu
diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
new file mode 100644
index 000000000000..0605a275f47b
--- /dev/null
+++ b/drivers/i3c/Makefile
@@ -0,0 +1,3 @@
+i3c-y := core.o device.o master.o
+obj-$(CONFIG_I3C) += i3c.o
+obj-$(CONFIG_I3C) += master/
diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
new file mode 100644
index 000000000000..c000fb458547
--- /dev/null
+++ b/drivers/i3c/core.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/idr.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+
+#include "internals.h"
+
+static DEFINE_IDR(i3c_bus_idr);
+static DEFINE_MUTEX(i3c_core_lock);
+
+void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
+{
+ if (exclusive)
+ down_write(&bus->lock);
+ else
+ down_read(&bus->lock);
+}
+
+void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive)
+{
+ if (exclusive)
+ up_write(&bus->lock);
+ else
+ up_read(&bus->lock);
+}
+
+static ssize_t bcr_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+ ssize_t ret;
+
+ i3c_bus_lock(bus, false);
+ ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
+ i3c_bus_unlock(bus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(bcr);
+
+static ssize_t dcr_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+ ssize_t ret;
+
+ i3c_bus_lock(bus, false);
+ ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
+ i3c_bus_unlock(bus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(dcr);
+
+static ssize_t pid_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+ ssize_t ret;
+
+ i3c_bus_lock(bus, false);
+ ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
+ i3c_bus_unlock(bus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(pid);
+
+static ssize_t address_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+ ssize_t ret;
+
+ i3c_bus_lock(bus, false);
+ ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
+ i3c_bus_unlock(bus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(address);
+
+static const char * const hdrcap_strings[] = {
+ "hdr-ddr", "hdr-tsp", "hdr-tsl",
+};
+
+static ssize_t hdrcap_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
+ unsigned long caps = i3cdev->info.hdr_cap;
+ ssize_t offset = 0, ret;
+ int mode;
+
+ i3c_bus_lock(bus, false);
+ for_each_set_bit(mode, &caps, 8) {
+ if (mode >= ARRAY_SIZE(hdrcap_strings))
+ break;
+
+ if (!hdrcap_strings[mode])
+ continue;
+
+ ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
+ if (ret < 0)
+ goto out;
+
+ offset += ret;
+ }
+ ret = offset;
+
+out:
+ i3c_bus_unlock(bus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(hdrcap);
+
+static struct attribute *i3c_device_attrs[] = {
+ &dev_attr_bcr.attr,
+ &dev_attr_dcr.attr,
+ &dev_attr_pid.attr,
+ &dev_attr_address.attr,
+ &dev_attr_hdrcap.attr,
+ NULL,
+};
+
+static const struct attribute_group i3c_device_group = {
+ .attrs = i3c_device_attrs,
+};
+
+static const struct attribute_group *i3c_device_groups[] = {
+ &i3c_device_group,
+ NULL,
+};
+
+static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
+ u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
+ u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
+
+ if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
+ return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
+ i3cdev->info.dcr, manuf);
+
+ return add_uevent_var(env,
+ "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
+ i3cdev->info.dcr, manuf, part, ext);
+}
+
+const struct device_type i3c_device_type = {
+ .groups = i3c_device_groups,
+ .uevent = i3c_device_uevent,
+};
+
+static const struct attribute_group *i3c_master_groups[] = {
+ &i3c_device_group,
+ NULL,
+};
+
+const struct device_type i3c_master_type = {
+ .groups = i3c_master_groups,
+};
+
+static const char * const i3c_bus_mode_strings[] = {
+ [I3C_BUS_MODE_PURE] = "pure",
+ [I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
+ [I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
+};
+
+static ssize_t mode_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+ ssize_t ret;
+
+ i3c_bus_lock(i3cbus, false);
+ if (i3cbus->mode < 0 ||
+ i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
+ !i3c_bus_mode_strings[i3cbus->mode])
+ ret = sprintf(buf, "unknown\n");
+ else
+ ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
+ i3c_bus_unlock(i3cbus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(mode);
+
+static ssize_t current_master_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+ ssize_t ret;
+
+ i3c_bus_lock(i3cbus, false);
+ ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
+ i3c_bus_unlock(i3cbus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(current_master);
+
+static ssize_t i3c_scl_frequency_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+ ssize_t ret;
+
+ i3c_bus_lock(i3cbus, false);
+ ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
+ i3c_bus_unlock(i3cbus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(i3c_scl_frequency);
+
+static ssize_t i2c_scl_frequency_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
+ ssize_t ret;
+
+ i3c_bus_lock(i3cbus, false);
+ ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
+ i3c_bus_unlock(i3cbus, false);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(i2c_scl_frequency);
+
+static struct attribute *i3c_busdev_attrs[] = {
+ &dev_attr_mode.attr,
+ &dev_attr_current_master.attr,
+ &dev_attr_i3c_scl_frequency.attr,
+ &dev_attr_i2c_scl_frequency.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(i3c_busdev);
+
+static const struct device_type i3c_busdev_type = {
+ .groups = i3c_busdev_groups,
+};
+
+static const struct i3c_device_id *
+i3c_device_match_id(struct i3c_device *i3cdev,
+ const struct i3c_device_id *id_table)
+{
+ const struct i3c_device_id *id;
+
+ /*
+ * The lower 32bits of the provisional ID is just filled with a random
+ * value, try to match using DCR info.
+ */
+ if (!I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid)) {
+ u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
+ u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
+ u16 ext_info = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
+
+ /* First try to match by manufacturer/part ID. */
+ for (id = id_table; id->match_flags != 0; id++) {
+ if ((id->match_flags & I3C_MATCH_MANUF_AND_PART) !=
+ I3C_MATCH_MANUF_AND_PART)
+ continue;
+
+ if (manuf != id->manuf_id || part != id->part_id)
+ continue;
+
+ if ((id->match_flags & I3C_MATCH_EXTRA_INFO) &&
+ ext_info != id->extra_info)
+ continue;
+
+ return id;
+ }
+ }
+
+ /* Fallback to DCR match. */
+ for (id = id_table; id->match_flags != 0; id++) {
+ if ((id->match_flags & I3C_MATCH_DCR) &&
+ id->dcr == i3cdev->info.dcr)
+ return id;
+ }
+
+ return NULL;
+}
+
+static int i3c_device_match(struct device *dev, struct device_driver *drv)
+{
+ struct i3c_device *i3cdev;
+ struct i3c_driver *i3cdrv;
+
+ if (dev->type != &i3c_device_type)
+ return 0;
+
+ i3cdev = dev_to_i3cdev(dev);
+ i3cdrv = drv_to_i3cdrv(drv);
+ if (i3c_device_match_id(i3cdev, i3cdrv->id_table))
+ return 1;
+
+ return 0;
+}
+
+static int i3c_device_probe(struct device *dev)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_driver *driver = drv_to_i3cdrv(dev->driver);
+
+ return driver->probe(i3cdev);
+}
+
+static int i3c_device_remove(struct device *dev)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_driver *driver = drv_to_i3cdrv(dev->driver);
+
+ return driver->remove(i3cdev);
+}
+
+struct bus_type i3c_bus_type = {
+ .name = "i3c",
+ .match = i3c_device_match,
+ .probe = i3c_device_probe,
+ .remove = i3c_device_remove,
+};
+
+enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
+ u16 addr)
+{
+ int status, bitpos = addr * 2;
+
+ if (addr > I2C_MAX_ADDR)
+ return I3C_ADDR_SLOT_RSVD;
+
+ status = bus->addrslots[bitpos / BITS_PER_LONG];
+ status >>= bitpos % BITS_PER_LONG;
+
+ return status & I3C_ADDR_SLOT_STATUS_MASK;
+}
+
+void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
+ enum i3c_addr_slot_status status)
+{
+ int bitpos = addr * 2;
+ unsigned long *ptr;
+
+ if (addr > I2C_MAX_ADDR)
+ return;
+
+ ptr = bus->addrslots + (bitpos / BITS_PER_LONG);
+ *ptr &= ~(I3C_ADDR_SLOT_STATUS_MASK << (bitpos % BITS_PER_LONG));
+ *ptr |= status << (bitpos % BITS_PER_LONG);
+}
+
+bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr)
+{
+ enum i3c_addr_slot_status status;
+
+ status = i3c_bus_get_addr_slot_status(bus, addr);
+
+ return status == I3C_ADDR_SLOT_FREE;
+}
+
+int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr)
+{
+ enum i3c_addr_slot_status status;
+ u8 addr;
+
+ for (addr = start_addr; addr < I3C_MAX_ADDR; addr++) {
+ status = i3c_bus_get_addr_slot_status(bus, addr);
+ if (status == I3C_ADDR_SLOT_FREE)
+ return addr;
+ }
+
+ return -ENOMEM;
+}
+
+static void i3c_bus_init_addrslots(struct i3c_bus *bus)
+{
+ int i;
+
+ /* Addresses 0 to 7 are reserved. */
+ for (i = 0; i < 8; i++)
+ i3c_bus_set_addr_slot_status(bus, i, I3C_ADDR_SLOT_RSVD);
+
+ /*
+ * Reserve broadcast address and all addresses that might collide
+ * with the broadcast address when facing a single bit error.
+ */
+ i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR,
+ I3C_ADDR_SLOT_RSVD);
+ for (i = 0; i < 7; i++)
+ i3c_bus_set_addr_slot_status(bus, I3C_BROADCAST_ADDR ^ BIT(i),
+ I3C_ADDR_SLOT_RSVD);
+}
+
+void i3c_bus_destroy(struct i3c_bus *bus)
+{
+ mutex_lock(&i3c_core_lock);
+ idr_remove(&i3c_bus_idr, bus->id);
+ mutex_unlock(&i3c_core_lock);
+
+ kfree(bus);
+}
+
+struct i3c_bus *i3c_bus_create(struct device *parent)
+{
+ struct i3c_bus *i3cbus;
+ int ret;
+
+ i3cbus = kzalloc(sizeof(*i3cbus), GFP_KERNEL);
+ if (!i3cbus)
+ return ERR_PTR(-ENOMEM);
+
+ init_rwsem(&i3cbus->lock);
+ INIT_LIST_HEAD(&i3cbus->devs.i2c);
+ INIT_LIST_HEAD(&i3cbus->devs.i3c);
+ i3c_bus_init_addrslots(i3cbus);
+ i3cbus->mode = I3C_BUS_MODE_PURE;
+ i3cbus->dev.parent = parent;
+ i3cbus->dev.of_node = parent->of_node;
+ i3cbus->dev.bus = &i3c_bus_type;
+ i3cbus->dev.type = &i3c_busdev_type;
+
+ mutex_lock(&i3c_core_lock);
+ ret = idr_alloc(&i3c_bus_idr, i3cbus, 0, 0, GFP_KERNEL);
+ mutex_unlock(&i3c_core_lock);
+ if (ret < 0)
+ goto err_free_bus;
+
+ i3cbus->id = ret;
+
+ return i3cbus;
+
+err_free_bus:
+ kfree(i3cbus);
+
+ return ERR_PTR(ret);
+}
+
+void i3c_bus_unregister(struct i3c_bus *bus)
+{
+ device_unregister(&bus->dev);
+}
+
+int i3c_bus_register(struct i3c_bus *i3cbus)
+{
+ struct i2c_device *i2cdev;
+
+ i3c_bus_for_each_i2cdev(i3cbus, i2cdev) {
+ switch (i2cdev->lvr & I3C_LVR_I2C_INDEX_MASK) {
+ case I3C_LVR_I2C_INDEX(0):
+ if (i3cbus->mode < I3C_BUS_MODE_MIXED_FAST)
+ i3cbus->mode = I3C_BUS_MODE_MIXED_FAST;
+ break;
+
+ case I3C_LVR_I2C_INDEX(1):
+ case I3C_LVR_I2C_INDEX(2):
+ if (i3cbus->mode < I3C_BUS_MODE_MIXED_SLOW)
+ i3cbus->mode = I3C_BUS_MODE_MIXED_SLOW;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+ }
+
+ if (!i3cbus->scl_rate.i3c)
+ i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
+
+ if (!i3cbus->scl_rate.i2c) {
+ if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW)
+ i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
+ else
+ i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
+ }
+
+ /*
+ * I3C/I2C frequency may have been overridden, check that user-provided
+ * values are not exceeding max possible frequency.
+ */
+ if (i3cbus->scl_rate.i3c > I3C_BUS_MAX_I3C_SCL_RATE ||
+ i3cbus->scl_rate.i2c > I3C_BUS_I2C_FM_PLUS_SCL_RATE) {
+ return -EINVAL;
+ }
+
+ dev_set_name(&i3cbus->dev, "i3c-%d", i3cbus->id);
+
+ return device_register(&i3cbus->dev);
+}
+
+static int __init i3c_init(void)
+{
+ return bus_register(&i3c_bus_type);
+}
+subsys_initcall(i3c_init);
+
+static void __exit i3c_exit(void)
+{
+ bus_unregister(&i3c_bus_type);
+}
+module_exit(i3c_exit);
diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
new file mode 100644
index 000000000000..31fb7cc9e12d
--- /dev/null
+++ b/drivers/i3c/device.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include "internals.h"
+
+/**
+ * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to a
+ * specific device
+ *
+ * @dev: device with which the transfers should be done
+ * @xfers: array of transfers
+ * @nxfers: number of transfers
+ *
+ * Initiate one or several private SDR transfers with @dev.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_do_priv_xfers(struct i3c_device *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ struct i3c_master_controller *master;
+ int i, ret;
+
+ master = i3c_device_get_master(dev);
+ if (!master)
+ return -EINVAL;
+
+ i3c_bus_lock(master->bus, false);
+ for (i = 0; i < nxfers; i++)
+ xfers[i].addr = dev->info.dyn_addr;
+
+ ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
+ i3c_bus_unlock(master->bus, false);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
+
+/**
+ * i3c_device_send_hdr_cmds() - send HDR commands to a specific device
+ *
+ * @dev: device to which these commands should be sent
+ * @cmds: array of commands
+ * @ncmds: number of commands
+ *
+ * Send one or several HDR commands to @dev.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_send_hdr_cmds(struct i3c_device *dev,
+ struct i3c_hdr_cmd *cmds,
+ int ncmds)
+{
+ struct i3c_master_controller *master;
+ enum i3c_hdr_mode mode;
+ int ret, i;
+
+ if (ncmds < 1)
+ return 0;
+
+ mode = cmds[0].mode;
+ for (i = 1; i < ncmds; i++) {
+ if (mode != cmds[i].mode)
+ return -EINVAL;
+ }
+
+ master = i3c_device_get_master(dev);
+ if (!master)
+ return -EINVAL;
+
+ i3c_bus_lock(master->bus, false);
+ for (i = 0; i < ncmds; i++)
+ cmds[i].addr = dev->info.dyn_addr;
+
+ ret = i3c_master_send_hdr_cmds_locked(master, cmds, ncmds);
+ i3c_bus_unlock(master->bus, false);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_send_hdr_cmds);
+
+void i3c_device_get_info(struct i3c_device *dev,
+ struct i3c_device_info *info)
+{
+ if (info)
+ *info = dev->info;
+}
+EXPORT_SYMBOL_GPL(i3c_device_get_info);
+
+/**
+ * i3c_driver_register_with_owner() - register an I3C device driver
+ *
+ * @drv: driver to register
+ * @owner: module that owns this driver
+ *
+ * Register @drv to the core.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_driver_register_with_owner(struct i3c_driver *drv, struct module *owner)
+{
+ drv->driver.owner = owner;
+ drv->driver.bus = &i3c_bus_type;
+
+ return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(i3c_driver_register_with_owner);
+
+/**
+ * i3c_driver_unregister() - unregister an I3C device driver
+ *
+ * @drv: driver to unregister
+ *
+ * Unregister @drv.
+ */
+void i3c_driver_unregister(struct i3c_driver *drv)
+{
+ driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL_GPL(i3c_driver_unregister);
diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
new file mode 100644
index 000000000000..4d5438e471b5
--- /dev/null
+++ b/drivers/i3c/internals.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef I3C_INTERNALS_H
+#define I3C_INTERNALS_H
+
+#include <linux/i3c/master.h>
+
+extern struct bus_type i3c_bus_type;
+extern const struct device_type i3c_master_type;
+extern const struct device_type i3c_device_type;
+
+void i3c_bus_destroy(struct i3c_bus *bus);
+struct i3c_bus *i3c_bus_create(struct device *parent);
+void i3c_bus_unregister(struct i3c_bus *bus);
+int i3c_bus_register(struct i3c_bus *i3cbus);
+void i3c_bus_lock(struct i3c_bus *bus, bool exclusive);
+void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive);
+int i3c_bus_get_free_addr(struct i3c_bus *bus, u8 start_addr);
+bool i3c_bus_dev_addr_is_avail(struct i3c_bus *bus, u8 addr);
+void i3c_bus_set_addr_slot_status(struct i3c_bus *bus, u16 addr,
+ enum i3c_addr_slot_status status);
+enum i3c_addr_slot_status i3c_bus_get_addr_slot_status(struct i3c_bus *bus,
+ u16 addr);
+
+int i3c_master_do_priv_xfers_locked(struct i3c_master_controller *master,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers);
+int i3c_master_send_hdr_cmds_locked(struct i3c_master_controller *master,
+ const struct i3c_hdr_cmd *cmds, int ncmds);
+
+#endif /* I3C_INTERNAL_H */
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
new file mode 100644
index 000000000000..b8a6ae4f81bf
--- /dev/null
+++ b/drivers/i3c/master.c
@@ -0,0 +1,1225 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/slab.h>
+
+#include "internals.h"
+
+static inline struct i3c_master_controller *
+i2c_adapter_to_i3c_master(struct i2c_adapter *adap)
+{
+ return container_of(adap, struct i3c_master_controller, i2c);
+}
+
+static inline struct i2c_adapter *
+i3c_master_to_i2c_adapter(struct i3c_master_controller *master)
+{
+ return &master->i2c;
+}
+
+static void i3c_i2c_dev_init(struct i3c_master_controller *master,
+ struct i3c_i2c_dev *dev, bool i2cdev)
+{
+ dev->bus = master->bus;
+ dev->master = master;
+}
+
+static struct i2c_device *
+i3c_master_alloc_i2c_dev(struct i3c_master_controller *master,
+ const struct i2c_board_info *info, u8 lvr)
+{
+ struct i2c_device *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return ERR_PTR(-ENOMEM);
+
+ i3c_i2c_dev_init(master, &dev->common, true);
+ dev->info = *info;
+ dev->lvr = lvr;
+ dev->info.of_node = of_node_get(info->of_node);
+ i3c_bus_set_addr_slot_status(master->bus, info->addr,
+ I3C_ADDR_SLOT_I2C_DEV);
+
+ return dev;
+}
+
+static void i3c_master_init_i3c_dev(struct i3c_master_controller *master,
+ struct i3c_device *dev,
+ const struct i3c_device_info *info,
+ const struct device_type *type)
+{
+ i3c_i2c_dev_init(master, &dev->common, false);
+ dev->dev.parent = &master->bus->dev;
+ dev->dev.type = type;
+ dev->dev.bus = &i3c_bus_type;
+ dev->info = *info;
+ dev_set_name(&dev->dev, "%d-%llx", master->bus->id, info->pid);
+}
+
+static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller *master,
+ struct i3c_ccc_cmd *cmd)
+{
+ if (WARN_ON(!rwsem_is_locked(&master->bus->lock)))
+ return -EINVAL;
+
+ if (!cmd || !master)
+ return -EINVAL;
+
+ if (!master->ops->send_ccc_cmd)
+ return -ENOTSUPP;
+
+ if ((cmd->id & I3C_CCC_DIRECT)) {
+ enum i3c_addr_slot_status status;
+ int i;
+
+ if (!cmd->dests || !cmd->ndests)
+ return -EINVAL;
+
+ for (i = 0; i < cmd->ndests; i++) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ cmd->dests[i].addr);
+ if (status != I3C_ADDR_SLOT_I3C_DEV)
+ return -EINVAL;
+ }
+ }
+
+ if (master->ops->supports_ccc_cmd &&
+ !master->ops->supports_ccc_cmd(master, cmd))
+ return -ENOTSUPP;
+
+ return master->ops->send_ccc_cmd(master, cmd);
+}
+
+int i3c_master_send_hdr_cmds_locked(struct i3c_master_controller *master,
+ const struct i3c_hdr_cmd *cmds, int ncmds)
+{
+ int i;
+
+ if (!cmds || !master || ncmds <= 0)
+ return -EINVAL;
+
+ if (!master->ops->send_hdr_cmds)
+ return -ENOTSUPP;
+
+ for (i = 0; i < ncmds; i++) {
+ if (!(master->base.info.hdr_cap & BIT(cmds->mode)))
+ return -ENOTSUPP;
+ }
+
+ return master->ops->send_hdr_cmds(master, cmds, ncmds);
+}
+
+/**
+ * i3c_master_send_hdr_cmds() - send HDR commands on the I3C bus
+ *
+ * @master: master used to send frames on the bus.
+ * @cmds: array of HDR commands.
+ * @ncmds: number of commands to send.
+ *
+ * Send one or several HDR commands.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_send_hdr_cmds(struct i3c_master_controller *master,
+ const struct i3c_hdr_cmd *cmds, int ncmds)
+{
+ int ret;
+
+ i3c_bus_lock(master->bus, false);
+ ret = i3c_master_send_hdr_cmds_locked(master, cmds, ncmds);
+ i3c_bus_unlock(master->bus, false);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_send_hdr_cmds);
+
+int i3c_master_do_priv_xfers_locked(struct i3c_master_controller *master,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ int i;
+
+ if (!xfers || !master || nxfers <= 0)
+ return -EINVAL;
+
+ if (!master->ops->priv_xfers)
+ return -ENOTSUPP;
+
+ for (i = 0; i < nxfers; i++) {
+ enum i3c_addr_slot_status status;
+
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ xfers[i].addr);
+ if (status != I3C_ADDR_SLOT_I3C_DEV)
+ return -EINVAL;
+ }
+
+ return master->ops->priv_xfers(master, xfers, nxfers);
+}
+
+/**
+ * i3c_master_do_priv_xfers() - do SDR private transfers on the I3C bus
+ *
+ * @master: master used to send frames on the bus
+ * @xfers: array of SDR private transfers
+ * @nxfers: number of transfers
+ *
+ * Do one or several private SDR I3C transfers.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_do_priv_xfers(struct i3c_master_controller *master,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ int ret;
+
+ i3c_bus_lock(master->bus, false);
+ ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
+ i3c_bus_unlock(master->bus, false);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_do_priv_xfers);
+
+/**
+ * i3c_master_do_i2c_xfers() - do I2C transfers on the I3C bus
+ *
+ * @master: master used to send frames on the bus
+ * @xfers: array of I2C transfers
+ * @nxfers: number of transfers
+ *
+ * Does one or several I2C transfers.
+ *
+ * This function can sleep and thus cannot be called in atomic context.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
+ const struct i2c_msg *xfers,
+ int nxfers)
+{
+ int ret, i;
+
+ if (!xfers || !master || nxfers <= 0)
+ return -EINVAL;
+
+ if (!master->ops->i2c_xfers)
+ return -ENOTSUPP;
+
+ i3c_bus_lock(master->bus, false);
+
+ for (i = 0; i < nxfers; i++) {
+ enum i3c_addr_slot_status status;
+
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ xfers[i].addr);
+ if (status != I3C_ADDR_SLOT_I2C_DEV) {
+ ret = -EINVAL;
+ goto out;
+ }
+ }
+
+ ret = master->ops->i2c_xfers(master, xfers, nxfers);
+
+out:
+ i3c_bus_unlock(master->bus, false);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_do_i2c_xfers);
+
+/**
+ * i3c_master_get_free_addr() - get a free address on the bus
+ *
+ * @master: I3C master object
+ * @start_addr: where to start searching
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: the first free address starting at @start_addr (included) or -ENOMEM
+ * if there's no more address available.
+ */
+int i3c_master_get_free_addr(struct i3c_master_controller *master,
+ u8 start_addr)
+{
+ return i3c_bus_get_free_addr(master->bus, start_addr);
+}
+EXPORT_SYMBOL_GPL(i3c_master_get_free_addr);
+
+/**
+ * i3c_master_set_info() - set master device information
+ *
+ * @master: master used to send frames on the bus
+ * @info: I3C device information
+ *
+ * Set master device info. This should be done in
+ * &i3c_master_controller_ops->bus_init().
+ *
+ * Not all &i3c_device_info fields are meaningful for a master device.
+ * Here is a list of fields that should be properly filled:
+ *
+ * - &i3c_device_info->dyn_addr
+ * - &i3c_device_info->bcr
+ * - &i3c_device_info->dcr
+ * - &i3c_device_info->pid
+ * - &i3c_device_info->hdr_cap if %I3C_BCR_HDR_CAP bit is set in
+ * &i3c_device_info->bcr
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 if @info contains valid information (not every piece of
+ * information can be checked, but we can at least make sure @info->dyn_addr
+ * and @info->bcr are correct), -EINVAL otherwise.
+ */
+int i3c_master_set_info(struct i3c_master_controller *master,
+ const struct i3c_device_info *info)
+{
+ if (!i3c_bus_dev_addr_is_avail(master->bus, info->dyn_addr))
+ return -EINVAL;
+
+ if (I3C_BCR_DEVICE_ROLE(info->bcr) == I3C_BCR_I3C_MASTER &&
+ master->secondary)
+ return -EINVAL;
+
+ i3c_master_init_i3c_dev(master, &master->base, info, &i3c_master_type);
+ i3c_bus_set_addr_slot_status(master->bus, info->dyn_addr,
+ I3C_ADDR_SLOT_I3C_DEV);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_set_info);
+
+static struct i3c_device *
+i3c_master_alloc_i3c_dev(struct i3c_master_controller *master,
+ const struct i3c_device_info *info)
+{
+ struct i3c_device *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return ERR_PTR(-ENOMEM);
+
+ i3c_master_init_i3c_dev(master, dev, info, &i3c_device_type);
+
+ return dev;
+}
+
+/**
+ * i3c_master_rstdaa_locked() - reset dev(s) dynamic address
+ *
+ * @master: master used to send frames on the bus
+ * @addr: a valid I3C device address or %I3C_BROADCAST_ADDR
+ *
+ * Send a RSTDAA CCC command to ask a specific slave (or all slave if @addr is
+ * %I3C_BROADCAST_ADDR) to drop their dynamic address.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_rstdaa_locked(struct i3c_master_controller *master, u8 addr)
+{
+ struct i3c_ccc_cmd_dest dest = { };
+ struct i3c_ccc_cmd cmd = { };
+ enum i3c_addr_slot_status addrstat;
+ int ret;
+
+ if (!master)
+ return -EINVAL;
+
+ addrstat = i3c_bus_get_addr_slot_status(master->bus, addr);
+ if (addr != I3C_BROADCAST_ADDR && addrstat != I3C_ADDR_SLOT_I3C_DEV)
+ return -EINVAL;
+
+ dest.addr = addr;
+ cmd.dests = &dest;
+ cmd.ndests = 1;
+ cmd.rnw = false;
+ cmd.id = I3C_CCC_RSTDAA(addr == I3C_BROADCAST_ADDR);
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_rstdaa_locked);
+
+/**
+ * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
+ * procedure
+ *
+ * @master: master used to send frames on the bus
+ *
+ * Send a ENTDAA CCC command to start a DAA procedure.
+ *
+ * Note that this function only sends the ENTDAA CCC command, all the logic
+ * behind dynamic address assignment has to be handled in the I3C master
+ * driver.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_entdaa_locked(struct i3c_master_controller *master)
+{
+ struct i3c_ccc_cmd_dest dest = { };
+ struct i3c_ccc_cmd cmd = { };
+ int ret;
+
+ dest.addr = I3C_BROADCAST_ADDR;
+ cmd.dests = &dest;
+ cmd.ndests = 1;
+ cmd.rnw = false;
+ cmd.id = I3C_CCC_ENTDAA;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
+
+/**
+ * i3c_master_disec_locked() - send a DISEC CCC command
+ *
+ * @master: master used to send frames on the bus
+ * @addr: a valid I3C slave address or %I3C_BROADCAST_ADDR
+ * @evts: events to disable
+ *
+ * Send a DISEC CCC command to disable some or all events coming from a
+ * specific slave, or all devices if @addr is %I3C_BROADCAST_ADDR.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
+ const struct i3c_ccc_events *evts)
+{
+ struct i3c_ccc_events events = *evts;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = addr,
+ .payload.len = sizeof(events),
+ .payload.data = &events,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .id = I3C_CCC_DISEC(addr == I3C_BROADCAST_ADDR),
+ .dests = &dest,
+ .ndests = 1,
+ };
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+EXPORT_SYMBOL_GPL(i3c_master_disec_locked);
+
+/**
+ * i3c_master_defslvs_locked() - send a DEFSLVS CCC command
+ *
+ * @master: master used to send frames on the bus
+ *
+ * Send a DEFSLVS CCC command containing all the devices known to the @master.
+ * This is useful when you have secondary masters on the bus to propagate
+ * device information.
+ *
+ * This should be called after all I3C devices have been discovered (in other
+ * words, after the DAA procedure has finished) and instantiated in
+ * i3c_master_controller_ops->bus_init().
+ * It should also be called if a master ACKed an Hot-Join request and assigned
+ * a dynamic address to the device joining the bus.
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_defslvs_locked(struct i3c_master_controller *master)
+{
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = I3C_BROADCAST_ADDR,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .id = I3C_CCC_DEFSLVS,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ struct i3c_ccc_defslvs *defslvs;
+ struct i3c_ccc_dev_desc *desc;
+ struct i3c_device *i3cdev;
+ struct i2c_device *i2cdev;
+ struct i3c_bus *bus;
+ bool send = false;
+ int ndevs, ret;
+
+ if (!master)
+ return -EINVAL;
+
+ bus = i3c_master_get_bus(master);
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ ndevs++;
+ if (I3C_BCR_DEVICE_ROLE(i3cdev->info.bcr) == I3C_BCR_I3C_MASTER)
+ send = true;
+ }
+
+ /* No other master on the bus, skip DEFSLVS. */
+ if (!send)
+ return 0;
+
+ i3c_bus_for_each_i2cdev(bus, i2cdev)
+ ndevs++;
+
+ dest.payload.len = sizeof(*defslvs) +
+ (ndevs * sizeof(struct i3c_ccc_dev_desc));
+ defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
+ if (!defslvs)
+ return -ENOMEM;
+
+ dest.payload.data = defslvs;
+
+ defslvs->count = ndevs + 1;
+ defslvs->master.bcr = master->base.info.bcr;
+ defslvs->master.dcr = master->base.info.dcr;
+ defslvs->master.dyn_addr = master->base.info.dyn_addr;
+ defslvs->master.static_addr = master->base.info.static_addr;
+
+ desc = defslvs->slaves;
+ i3c_bus_for_each_i2cdev(bus, i2cdev) {
+ desc->lvr = i2cdev->lvr;
+ desc->static_addr = i2cdev->info.addr;
+ desc++;
+ }
+
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ desc->bcr = i3cdev->info.bcr;
+ desc->dcr = i3cdev->info.dcr;
+ desc->dyn_addr = i3cdev->info.dyn_addr;
+ desc->static_addr = i3cdev->info.static_addr;
+ desc++;
+ }
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ kfree(defslvs);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_defslvs_locked);
+
+static int i3c_master_getmrl_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_mrl mrl;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(mrl),
+ .payload.data = &mrl,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETMRL,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ if (dest.payload.len != sizeof(mrl))
+ return -EIO;
+
+ info->max_read_len = be16_to_cpu(mrl.read_len);
+
+ if (info->bcr & I3C_BCR_IBI_PAYLOAD)
+ info->max_ibi_len = mrl.ibi_len;
+
+ return 0;
+}
+
+static int i3c_master_getmwl_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_mwl mwl;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(mwl),
+ .payload.data = &mwl,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETMWL,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ if (dest.payload.len != sizeof(mwl))
+ return -EIO;
+
+ info->max_write_len = be16_to_cpu(mwl.len);
+
+ return 0;
+}
+
+static int i3c_master_getmxds_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_getmxds getmaxds;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(getmaxds),
+ .payload.data = &getmaxds,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETMXDS,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ if (dest.payload.len != 2 && dest.payload.len != 5)
+ return -EIO;
+
+ info->max_read_ds = getmaxds.maxrd;
+ info->max_read_ds = getmaxds.maxwr;
+ if (dest.payload.len == 5)
+ info->max_read_turnaround = getmaxds.maxrdturn[0] |
+ ((u32)getmaxds.maxrdturn[1] << 8) |
+ ((u32)getmaxds.maxrdturn[2] << 16);
+
+ return 0;
+}
+
+static int i3c_master_gethdrcap_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_gethdrcap gethdrcap;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(gethdrcap),
+ .payload.data = &gethdrcap,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETHDRCAP,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ if (dest.payload.len != 1)
+ return -EIO;
+
+ info->hdr_cap = gethdrcap.modes;
+
+ return 0;
+}
+
+static int i3c_master_getpid_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_getpid getpid;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(struct i3c_ccc_getpid),
+ .payload.data = &getpid,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETPID,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret, i;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ info->pid = 0;
+ for (i = 0; i < sizeof(getpid.pid); i++) {
+ int sft = (sizeof(getpid.pid) - i - 1) * 8;
+
+ info->pid |= (u64)getpid.pid[i] << sft;
+ }
+
+ return 0;
+}
+
+static int i3c_master_getbcr_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_getbcr getbcr;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(struct i3c_ccc_getbcr),
+ .payload.data = &getbcr,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETBCR,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ info->bcr = getbcr.bcr;
+
+ return 0;
+}
+
+static int i3c_master_getdcr_locked(struct i3c_master_controller *master,
+ struct i3c_device_info *info)
+{
+ struct i3c_ccc_getdcr getdcr;
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = info->dyn_addr,
+ .payload.len = sizeof(struct i3c_ccc_getdcr),
+ .payload.data = &getdcr,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = true,
+ .id = I3C_CCC_GETDCR,
+ .dests = &dest,
+ .ndests = 1,
+ };
+ int ret;
+
+ ret = i3c_master_send_ccc_cmd_locked(master, &cmd);
+ if (ret)
+ return ret;
+
+ info->dcr = getdcr.dcr;
+
+ return 0;
+}
+
+static int i3c_master_retrieve_dev_info(struct i3c_master_controller *master,
+ struct i3c_device_info *info, u8 addr)
+{
+ enum i3c_addr_slot_status slot_status;
+ int ret;
+
+ if (!master || !info)
+ return -EINVAL;
+
+ memset(info, 0, sizeof(*info));
+ info->dyn_addr = addr;
+
+ slot_status = i3c_bus_get_addr_slot_status(master->bus,
+ info->dyn_addr);
+ if (slot_status == I3C_ADDR_SLOT_RSVD ||
+ slot_status == I3C_ADDR_SLOT_I2C_DEV)
+ return -EINVAL;
+
+ ret = i3c_master_getpid_locked(master, info);
+ if (ret)
+ return ret;
+
+ ret = i3c_master_getbcr_locked(master, info);
+ if (ret)
+ return ret;
+
+ ret = i3c_master_getdcr_locked(master, info);
+ if (ret)
+ return ret;
+
+ ret = i3c_master_getmxds_locked(master, info);
+ if (ret && (info->bcr & I3C_BCR_MAX_DATA_SPEED_LIM))
+ return -EINVAL;
+
+ if (info->bcr & I3C_BCR_IBI_PAYLOAD)
+ info->max_ibi_len = 1;
+
+ i3c_master_getmrl_locked(master, info);
+ i3c_master_getmwl_locked(master, info);
+
+ if (info->bcr & I3C_BCR_HDR_CAP) {
+ ret = i3c_master_gethdrcap_locked(master, info);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * i3c_master_add_i3c_dev_locked() - add an I3C slave to the bus
+ *
+ * @master: master used to send frames on the bus
+ * @addr: I3C slave dynamic address assigned to the device
+ *
+ * This function is instantiating an I3C device object and adding it to the
+ * I3C device list. All device information are automatically retrieved using
+ * standard CCC commands.
+ *
+ * The I3C device object is returned in case the master wants to attach
+ * private data to it using i3c_device_set_master_data().
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: a pointer to a &struct i3c_device object in case of success,
+ * an ERR_PTR() otherwise.
+ */
+struct i3c_device *
+i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master, u8 addr)
+{
+ enum i3c_addr_slot_status status;
+ struct i3c_device *i3cdev;
+ struct i3c_device_info info;
+ int ret;
+
+ if (!master)
+ return ERR_PTR(-EINVAL);
+
+ status = i3c_bus_get_addr_slot_status(master->bus, addr);
+ if (status != I3C_ADDR_SLOT_FREE)
+ return ERR_PTR(-EINVAL);
+
+ i3c_bus_set_addr_slot_status(master->bus, addr, I3C_ADDR_SLOT_I3C_DEV);
+
+ ret = i3c_master_retrieve_dev_info(master, &info, addr);
+ if (ret)
+ goto err_release_addr;
+
+ i3cdev = i3c_master_alloc_i3c_dev(master, &info);
+ if (IS_ERR(i3cdev)) {
+ ret = PTR_ERR(i3cdev);
+ goto err_release_addr;
+ }
+
+ list_add_tail(&i3cdev->common.node, &master->bus->devs.i3c);
+
+ return i3cdev;
+
+err_release_addr:
+ i3c_bus_set_addr_slot_status(master->bus, addr, I3C_ADDR_SLOT_FREE);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
+
+static int of_i3c_master_add_dev(struct i3c_master_controller *master,
+ struct device_node *node)
+{
+ struct device *dev = master->base.dev.parent;
+ struct i2c_board_info info = { };
+ struct i2c_device *i2cdev;
+ u32 lvr, addr;
+ int ret;
+
+ if (!master || !node)
+ return -EINVAL;
+
+ /*
+ * This node is not describing an I2C device, skip it.
+ * We only add I2C devices here (i.e. nodes with an i3c-lvr property).
+ * I3C devices will be discovered during DAA, even if they have a
+ * static address.
+ */
+ if (of_property_read_u32(node, "reg", &addr) ||
+ of_property_read_u32(node, "i3c-lvr", &lvr))
+ return 0;
+
+ ret = of_i2c_get_board_info(master->base.dev.parent, node, &info);
+ if (ret)
+ return ret;
+
+ /*
+ * We do not register the I2C device here, because the bus is not
+ * necessarily ready to transmit I2C frames, and the I2C adapter has
+ * not been registered yet.
+ * This is done in i3c_master_i2c_adapter_init() once everything is
+ * ready.
+ */
+ i2cdev = i3c_master_alloc_i2c_dev(master, &info, lvr);
+ if (IS_ERR(i2cdev)) {
+ dev_err(dev, "Failed to allocate device %02x\n", addr);
+ return ret;
+ }
+
+ if (lvr & I3C_LVR_I2C_FM_MODE)
+ master->bus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
+
+ list_add_tail(&i2cdev->common.node, &master->bus->devs.i2c);
+
+ return 0;
+}
+
+static void i3c_master_remove_devs(struct i3c_master_controller *master)
+{
+ while (!list_empty(&master->bus->devs.i2c)) {
+ struct i2c_device *i2cdev;
+
+ i2cdev = list_first_entry(&master->bus->devs.i2c,
+ struct i2c_device, common.node);
+ list_del(&i2cdev->common.node);
+ of_node_put(i2cdev->info.of_node);
+ kfree(i2cdev);
+ }
+
+ while (!list_empty(&master->bus->devs.i3c)) {
+ struct i3c_device *i3cdev;
+
+ i3cdev = list_first_entry(&master->bus->devs.i3c,
+ struct i3c_device, common.node);
+ list_del(&i3cdev->common.node);
+ of_node_put(i3cdev->dev.of_node);
+ kfree(i3cdev);
+ }
+}
+
+static int of_populate_i3c_bus(struct i3c_master_controller *master)
+{
+ struct device *dev = &master->bus->dev;
+ struct device_node *i3cbus_np = dev->of_node;
+ struct device_node *node;
+ int ret;
+ u32 val;
+
+ if (!i3cbus_np)
+ return 0;
+
+ for_each_available_child_of_node(i3cbus_np, node) {
+ ret = of_i3c_master_add_dev(master, node);
+ if (ret)
+ goto err_remove_devs;
+ }
+
+ /*
+ * The user might want to limit I2C and I3C speed in case some devices
+ * on the bus are not supporting typical rates, or if the bus topology
+ * prevents it from using max possible rate.
+ */
+ if (!of_property_read_u32(i3cbus_np, "i2c-scl-frequency", &val))
+ master->bus->scl_rate.i2c = val;
+
+ if (!of_property_read_u32(i3cbus_np, "i3c-scl-frequency", &val))
+ master->bus->scl_rate.i3c = val;
+
+ return 0;
+
+err_remove_devs:
+ i3c_master_remove_devs(master);
+
+ return ret;
+}
+
+static int i3c_master_i2c_adapter_xfer(struct i2c_adapter *adap,
+ struct i2c_msg *xfers, int nxfers)
+{
+ struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
+ int i, ret;
+
+ for (i = 0; i < nxfers; i++) {
+ enum i3c_addr_slot_status status;
+
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ xfers[i].addr);
+ if (status != I3C_ADDR_SLOT_I2C_DEV)
+ return -EINVAL;
+ }
+
+ ret = i3c_master_do_i2c_xfers(master, xfers, nxfers);
+ if (ret)
+ return ret;
+
+ return nxfers;
+}
+
+static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
+}
+
+static const struct i2c_algorithm i3c_master_i2c_algo = {
+ .master_xfer = i3c_master_i2c_adapter_xfer,
+ .functionality = i3c_master_i2c_functionalities,
+};
+
+static int i3c_master_i2c_adapter_init(struct i3c_master_controller *master)
+{
+ struct i2c_adapter *adap = i3c_master_to_i2c_adapter(master);
+ struct i2c_device *i2cdev;
+ int ret;
+
+ adap->dev.parent = master->parent;
+ adap->owner = master->parent->driver->owner;
+ adap->algo = &i3c_master_i2c_algo;
+ strncpy(adap->name, dev_name(master->base.dev.parent),
+ sizeof(adap->name));
+
+ /* FIXME: Should we allow i3c masters to override these values? */
+ adap->timeout = 1000;
+ adap->retries = 3;
+
+ ret = i2c_add_adapter(adap);
+ if (ret)
+ return ret;
+
+ /*
+ * We silently ignore failures here. The bus should keep working
+ * correctly even if one or more i2c devices are not registered.
+ */
+ i3c_bus_for_each_i2cdev(master->bus, i2cdev)
+ i2cdev->client = i2c_new_device(adap, &i2cdev->info);
+
+ return 0;
+}
+
+static void i3c_master_i2c_adapter_cleanup(struct i3c_master_controller *master)
+{
+ i2c_del_adapter(&master->i2c);
+}
+
+static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
+{
+ struct i3c_device *i3cdev;
+
+ i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+ if (device_is_registered(&i3cdev->dev))
+ device_unregister(&i3cdev->dev);
+ }
+}
+
+static int i3c_master_register_i3c_devs(struct i3c_master_controller *master)
+{
+ struct i3c_device *i3cdev;
+ int ret;
+
+ i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+ ret = device_register(&i3cdev->dev);
+ if (ret)
+ goto err_unregister_devs;
+ }
+
+ return 0;
+
+err_unregister_devs:
+ i3c_master_unregister_i3c_devs(master);
+
+ return ret;
+}
+
+static int i3c_master_init_bus(struct i3c_master_controller *master)
+{
+ int ret;
+
+ if (!master->ops->bus_init)
+ return 0;
+
+ /*
+ * Take an exclusive lock on the bus before calling ->bus_init(), so
+ * that all _locked() helpers can safely be called within this hook.
+ */
+ i3c_bus_lock(master->bus, true);
+ ret = master->ops->bus_init(master);
+ i3c_bus_unlock(master->bus, true);
+
+ return ret;
+}
+
+static void i3c_master_cleanup_bus(struct i3c_master_controller *master)
+{
+ if (master->ops->bus_cleanup) {
+ /*
+ * Take an exclusive lock on the bus before calling
+ * ->bus_cleanup(), so that all _locked() helpers can safely be
+ * called within this hook.
+ */
+ i3c_bus_lock(master->bus, true);
+ master->ops->bus_cleanup(master);
+ i3c_bus_unlock(master->bus, true);
+ }
+}
+
+static void i3c_master_destroy_bus(struct i3c_master_controller *master)
+{
+ i3c_bus_unregister(master->bus);
+ i3c_bus_destroy(master->bus);
+}
+
+static int i3c_master_create_bus(struct i3c_master_controller *master)
+{
+ struct i3c_bus *i3cbus;
+ int ret;
+
+ i3cbus = i3c_bus_create(master->parent);
+ if (IS_ERR(i3cbus))
+ return PTR_ERR(i3cbus);
+
+ i3cbus->cur_master = &master->base;
+ master->bus = i3cbus;
+
+ if (i3cbus->dev.of_node) {
+ ret = of_populate_i3c_bus(master);
+ if (ret)
+ goto err_destroy_bus;
+ }
+
+ ret = i3c_bus_register(i3cbus);
+ if (ret)
+ goto err_destroy_bus;
+
+ return 0;
+
+err_destroy_bus:
+ i3c_bus_destroy(i3cbus);
+
+ return ret;
+}
+
+/**
+ * i3c_master_register() - register an I3C master
+ *
+ * @master: master used to send frames on the bus
+ * @parent: the parent device (the one that provides this I3C master
+ * controller)
+ * @ops: the master controller operations
+ * @secondary: true if you are registering a secondary master. Will return
+ * -ENOTSUPP if set to true since secondary masters are not yet
+ * supported.
+ *
+ * This function takes care of everything for you:
+ *
+ * - creates and initializes the I3C bus
+ * - populates the bus with static I2C devs if @parent->of_node is not
+ * NULL
+ * - registers all I3C devices added by the controller during bus
+ * initialization
+ * - registers the I2C adapter and all I2C devices
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_register(struct i3c_master_controller *master,
+ struct device *parent,
+ const struct i3c_master_controller_ops *ops,
+ bool secondary)
+{
+ int ret;
+
+ /* We do not support secondary masters yet. */
+ if (secondary)
+ return -ENOTSUPP;
+
+ master->parent = parent;
+ master->ops = ops;
+ master->secondary = secondary;
+
+ ret = i3c_master_create_bus(master);
+ if (ret)
+ return ret;
+
+ /*
+ * Before doing any operation on the bus, we need to initialize it.
+ * This operation is highly controller dependent, but it is expected
+ * to do the following operations:
+ * 1/ reset all addresses of all devices on the bus (using RSTDAA CCC
+ * command)
+ * 2/ start a DAA (Dynamic Address Assignment) procedure
+ * 3/ populate the bus with all I3C devices discovered during DAA using
+ *
+ */
+ ret = i3c_master_init_bus(master);
+ if (ret)
+ goto err_destroy_bus;
+
+ /*
+ * Register a dummy device to represent this master under the I3C bus
+ * in sysfs.
+ */
+ ret = device_register(&master->base.dev);
+ if (ret)
+ goto err_cleanup_bus;
+
+ /* Register all I3C devs that have been added during DAA. */
+ ret = i3c_master_register_i3c_devs(master);
+ if (ret)
+ goto err_unreg_master_dev;
+
+ /*
+ * This is the last step: expose our i3c bus as an i2c adapter so that
+ * i2c devices are exposed through the i2c subsystem.
+ */
+ ret = i3c_master_i2c_adapter_init(master);
+ if (ret)
+ goto err_unreg_i3c_devs;
+
+ return 0;
+
+err_unreg_i3c_devs:
+ i3c_master_unregister_i3c_devs(master);
+
+err_unreg_master_dev:
+ device_unregister(&master->base.dev);
+
+err_cleanup_bus:
+ i3c_master_cleanup_bus(master);
+
+err_destroy_bus:
+ i3c_master_destroy_bus(master);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_register);
+
+/**
+ * i3c_master_unregister() - unregister an I3C master
+ *
+ * @master: master used to send frames on the bus
+ *
+ * Basically undo everything done in i3c_master_register().
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int i3c_master_unregister(struct i3c_master_controller *master)
+{
+ i3c_master_i2c_adapter_cleanup(master);
+
+ i3c_master_unregister_i3c_devs(master);
+
+ i3c_master_cleanup_bus(master);
+
+ i3c_master_remove_devs(master);
+
+ i3c_master_destroy_bus(master);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_unregister);
diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
new file mode 100644
index 000000000000..e69de29bb2d1
diff --git a/include/linux/i3c/ccc.h b/include/linux/i3c/ccc.h
new file mode 100644
index 000000000000..81848081b9cd
--- /dev/null
+++ b/include/linux/i3c/ccc.h
@@ -0,0 +1,389 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef I3C_CCC_H
+#define I3C_CCC_H
+
+/* I3C CCC (Common Command Codes) related definitions */
+#define I3C_CCC_DIRECT BIT(7)
+
+#define I3C_CCC_ID(id, broadcast) \
+ ((id) | ((broadcast) ? 0 : I3C_CCC_DIRECT))
+
+/* Commands valid in both broadcast and unicast modes */
+#define I3C_CCC_ENEC(broadcast) I3C_CCC_ID(0x0, broadcast)
+#define I3C_CCC_DISEC(broadcast) I3C_CCC_ID(0x1, broadcast)
+#define I3C_CCC_ENTAS(as, broadcast) I3C_CCC_ID(0x2 + (as), broadcast)
+#define I3C_CCC_RSTDAA(broadcast) I3C_CCC_ID(0x6, broadcast)
+#define I3C_CCC_SETMWL(broadcast) I3C_CCC_ID(0x9, broadcast)
+#define I3C_CCC_SETMRL(broadcast) I3C_CCC_ID(0xa, broadcast)
+#define I3C_CCC_SETXTIME(broadcast) ((broadcast) ? 0x28 : 0x98)
+#define I3C_CCC_VENDOR(id, broadcast) ((id) + ((broadcast) ? 0x61 : 0xe0))
+
+/* Broadcast-only commands */
+#define I3C_CCC_ENTDAA I3C_CCC_ID(0x7, true)
+#define I3C_CCC_DEFSLVS I3C_CCC_ID(0x8, true)
+#define I3C_CCC_ENTTM I3C_CCC_ID(0xb, true)
+#define I3C_CCC_ENTHDR(x) I3C_CCC_ID(0x20 + (x), true)
+
+/* Unicast-only commands */
+#define I3C_CCC_SETDASA I3C_CCC_ID(0x7, false)
+#define I3C_CCC_SETNEWDA I3C_CCC_ID(0x8, false)
+#define I3C_CCC_GETMWL I3C_CCC_ID(0xb, false)
+#define I3C_CCC_GETMRL I3C_CCC_ID(0xc, false)
+#define I3C_CCC_GETPID I3C_CCC_ID(0xd, false)
+#define I3C_CCC_GETBCR I3C_CCC_ID(0xe, false)
+#define I3C_CCC_GETDCR I3C_CCC_ID(0xf, false)
+#define I3C_CCC_GETSTATUS I3C_CCC_ID(0x10, false)
+#define I3C_CCC_GETACCMST I3C_CCC_ID(0x11, false)
+#define I3C_CCC_SETBRGTGT I3C_CCC_ID(0x13, false)
+#define I3C_CCC_GETMXDS I3C_CCC_ID(0x14, false)
+#define I3C_CCC_GETHDRCAP I3C_CCC_ID(0x15, false)
+#define I3C_CCC_GETXTIME I3C_CCC_ID(0x19, false)
+
+#define I3C_CCC_EVENT_SIR BIT(0)
+#define I3C_CCC_EVENT_MR BIT(1)
+#define I3C_CCC_EVENT_HJ BIT(3)
+
+/**
+ * struct i3c_ccc_events - payload passed to ENEC/DISEC CCC
+ *
+ * @events: bitmask of I3C_CCC_EVENT_xxx events.
+ *
+ * Depending on the CCC command, the specific events coming from all devices
+ * (broadcast version) or a specific device (unicast version) will be
+ * enabled (ENEC) or disabled (DISEC).
+ */
+struct i3c_ccc_events {
+ u8 events;
+} __packed;
+
+/**
+ * struct i3c_ccc_mwl - payload passed to SETMWL/GETMWL CCC
+ *
+ * @len: maximum write length in bytes
+ *
+ * The maximum write length is only applicable to SDR private messages or
+ * extended Write CCCs (like SETXTIME).
+ */
+struct i3c_ccc_mwl {
+ __be16 len;
+} __packed;
+
+/**
+ * struct i3c_ccc_mrl - payload passed to SETMRL/GETMRL CCC
+ *
+ * @len: maximum read length in bytes
+ * @ibi_len: maximum IBI payload length
+ *
+ * The maximum read length is only applicable to SDR private messages or
+ * extended Read CCCs (like GETXTIME).
+ * The IBI length is only valid if the I3C slave is IBI capable
+ * (%I3C_BCR_IBI_REQ_CAP is set).
+ */
+struct i3c_ccc_mrl {
+ __be16 read_len;
+ u8 ibi_len;
+} __packed;
+
+/**
+ * struct i3c_ccc_dev_desc - I3C/I3C device descriptor used for DEFSLVS
+ *
+ * @dyn_addr: dynamic address assigned to the I3C slave or 0 if the entry is
+ * describing an I2C slave.
+ * @dcr: DCR value (not applicable to entries describing I2C devices)
+ * @lvr: LVR value (not applicable to entries describing I3C devices)
+ * @bcr: BCR value or 0 if this entry is describing an I2C slave
+ * @static_addr: static address or 0 if the device does not have a static
+ * address
+ *
+ * The DEFSLVS command should be passed an array of i3c_ccc_dev_desc
+ * descriptors (one entry per I3C/I2C dev controlled by the master).
+ */
+struct i3c_ccc_dev_desc {
+ u8 dyn_addr;
+ union {
+ u8 dcr;
+ u8 lvr;
+ };
+ u8 bcr;
+ u8 static_addr;
+} __packed;
+
+/**
+ * struct i3c_ccc_defslvs - payload passed to DEFSLVS CCC
+ *
+ * @count: number of dev descriptors
+ * @master: descriptor describing the current master
+ * @slaves: array of descriptors describing slaves controlled by the
+ * current master
+ *
+ * Information passed to the broadcast DEFSLVS to propagate device
+ * information to all masters currently acting as slaves on the bus.
+ * This is only meaningful if you have more than one master.
+ */
+struct i3c_ccc_defslvs {
+ u8 count;
+ struct i3c_ccc_dev_desc master;
+ struct i3c_ccc_dev_desc slaves[0];
+} __packed;
+
+/**
+ * enum i3c_ccc_test_mode - enum listing all available test modes
+ *
+ * @I3C_CCC_EXIT_TEST_MODE: exit test mode
+ * @I3C_CCC_VENDOR_TEST_MODE: enter vendor test mode
+ */
+enum i3c_ccc_test_mode {
+ I3C_CCC_EXIT_TEST_MODE,
+ I3C_CCC_VENDOR_TEST_MODE,
+};
+
+/**
+ * struct i3c_ccc_enttm - payload passed to ENTTM CCC
+ *
+ * @mode: one of the &enum i3c_ccc_test_mode modes
+ *
+ * Information passed to the ENTTM CCC to instruct an I3C device to enter a
+ * specific test mode.
+ */
+struct i3c_ccc_enttm {
+ u8 mode;
+} __packed;
+
+/**
+ * struct i3c_ccc_setda - payload passed to ENTTM CCC
+ *
+ * @mode: one of the &enum i3c_ccc_test_mode modes
+ *
+ * Information passed to the ENTTM CCC to instruct an I3C device to enter a
+ * specific test mode.
+ */
+struct i3c_ccc_setda {
+ u8 addr;
+} __packed;
+
+/**
+ * struct i3c_ccc_getpid - payload passed to GETPID CCC
+ *
+ * @pid: 48 bits PID in big endian
+ */
+struct i3c_ccc_getpid {
+ u8 pid[6];
+} __packed;
+
+/**
+ * struct i3c_ccc_getbcr - payload passed to GETBCR CCC
+ *
+ * @bcr: BCR (Bus Characteristic Register) value
+ */
+struct i3c_ccc_getbcr {
+ u8 bcr;
+} __packed;
+
+/**
+ * struct i3c_ccc_getdcr - payload passed to GETDCR CCC
+ *
+ * @dcr: DCR (Device Characteristic Register) value
+ */
+struct i3c_ccc_getdcr {
+ u8 dcr;
+} __packed;
+
+#define I3C_CCC_STATUS_PENDING_INT(status) ((status) & GENMASK(3, 0))
+#define I3C_CCC_STATUS_PROTOCOL_ERROR BIT(5)
+#define I3C_CCC_STATUS_ACTIVITY_MODE(status) \
+ (((status) & GENMASK(7, 6)) >> 6)
+
+/**
+ * struct i3c_ccc_getstatus - payload passed to GETSTATUS CCC
+ *
+ * @status: status of the I3C slave (see I3C_CCC_STATUS_xxx macros for more
+ * information).
+ */
+struct i3c_ccc_getstatus {
+ __be16 status;
+} __packed;
+
+/**
+ * struct i3c_ccc_getaccmst - payload passed to GETACCMST CCC
+ *
+ * @newmaster: address of the master taking bus ownership
+ */
+struct i3c_ccc_getaccmst {
+ u8 newmaster;
+} __packed;
+
+/**
+ * struct i3c_ccc_bridged_slave_desc - bridged slave descriptor
+ *
+ * @addr: dynamic address of the bridged device
+ * @id: ID of the slave device behind the bridge
+ */
+struct i3c_ccc_bridged_slave_desc {
+ u8 addr;
+ __be16 id;
+} __packed;
+
+/**
+ * struct i3c_ccc_setbrgtgt - payload passed to SETBRGTGT CCC
+ *
+ * @count: number of bridged slaves
+ * @bslaves: bridged slave descriptors
+ */
+struct i3c_ccc_setbrgtgt {
+ u8 count;
+ struct i3c_ccc_bridged_slave_desc bslaves[0];
+} __packed;
+
+/**
+ * enum i3c_sdr_max_data_rate - max data rate values for private SDR transfers
+ */
+enum i3c_sdr_max_data_rate {
+ I3C_SDR_DR_FSCL_MAX,
+ I3C_SDR_DR_FSCL_8MHZ,
+ I3C_SDR_DR_FSCL_6MHZ,
+ I3C_SDR_DR_FSCL_4MHZ,
+ I3C_SDR_DR_FSCL_2MHZ,
+};
+
+/**
+ * enum i3c_tsco - clock to data turn-around
+ */
+enum i3c_tsco {
+ I3C_TSCO_LT_8NS,
+ I3C_TSCO_LT_9NS,
+ I3C_TSCO_LT_10NS,
+ I3C_TSCO_LT_11NS,
+ I3C_TSCO_LT_12NS,
+};
+
+#define I3C_CCC_MAX_SDR_FSCL_MASK GENMASK(2, 0)
+#define I3C_CCC_MAX_SDR_FSCL(x) ((x) & I3C_CCC_MAX_SDR_FSCL_MASK)
+
+/**
+ * struct i3c_ccc_getmxds - payload passed to GETMXDS CCC
+ *
+ * @maxwr: write limitations
+ * @maxrd: read limitations
+ * @maxrdturn: maximum read turn-around expressed micro-seconds and
+ * little-endian formatted
+ */
+struct i3c_ccc_getmxds {
+ u8 maxwr;
+ u8 maxrd;
+ u8 maxrdturn[3];
+} __packed;
+
+#define I3C_CCC_HDR_MODE(mode) BIT(mode)
+
+/**
+ * struct i3c_ccc_gethdrcap - payload passed to GETHDRCAP CCC
+ *
+ * @modes: bitmap of supported HDR modes
+ */
+struct i3c_ccc_gethdrcap {
+ u8 modes;
+} __packed;
+
+/**
+ * enum i3c_ccc_setxtime_subcmd - SETXTIME sub-commands
+ */
+enum i3c_ccc_setxtime_subcmd {
+ I3C_CCC_SETXTIME_ST = 0x7f,
+ I3C_CCC_SETXTIME_DT = 0xbf,
+ I3C_CCC_SETXTIME_ENTER_ASYNC_MODE0 = 0xdf,
+ I3C_CCC_SETXTIME_ENTER_ASYNC_MODE1 = 0xef,
+ I3C_CCC_SETXTIME_ENTER_ASYNC_MODE2 = 0xf7,
+ I3C_CCC_SETXTIME_ENTER_ASYNC_MODE3 = 0xfb,
+ I3C_CCC_SETXTIME_ASYNC_TRIGGER = 0xfd,
+ I3C_CCC_SETXTIME_TPH = 0x3f,
+ I3C_CCC_SETXTIME_TU = 0x9f,
+ I3C_CCC_SETXTIME_ODR = 0x8f,
+};
+
+/**
+ * struct i3c_ccc_setxtime - payload passed to SETXTIME CCC
+ *
+ * @subcmd: one of the sub-commands ddefined in &enum i3c_ccc_setxtime_subcmd
+ * @data: sub-command payload. Amount of data is determined by
+ * &i3c_ccc_setxtime->subcmd
+ */
+struct i3c_ccc_setxtime {
+ u8 subcmd;
+ u8 data[0];
+} __packed;
+
+#define I3C_CCC_GETXTIME_SYNC_MODE BIT(0)
+#define I3C_CCC_GETXTIME_ASYNC_MODE(x) BIT((x) + 1)
+#define I3C_CCC_GETXTIME_OVERFLOW BIT(7)
+
+/**
+ * struct i3c_ccc_getxtime - payload retrieved from GETXTIME CCC
+ *
+ * @supported_modes: bitmap describing supported XTIME modes
+ * @state: current status (enabled mode and overflow status)
+ * @frequency: slave's internal oscillator frequency in 500KHz steps
+ * @inaccuracy: slave's internal oscillator inaccuracy in 0.1% steps
+ */
+struct i3c_ccc_getxtime {
+ u8 supported_modes;
+ u8 state;
+ u8 frequency;
+ u8 inaccuracy;
+} __packed;
+
+/**
+ * struct i3c_ccc_cmd_payload - CCC payload
+ *
+ * @len: payload length
+ * @data: payload data
+ */
+struct i3c_ccc_cmd_payload {
+ u16 len;
+ void *data;
+};
+
+/**
+ * struct i3c_ccc_cmd_dest - CCC command destination
+ *
+ * @addr: can be an I3C device address or the broadcast address if this is a
+ * broadcast CCC
+ * @payload: payload to be sent to this device or broadcasted
+ */
+struct i3c_ccc_cmd_dest {
+ u8 addr;
+ struct i3c_ccc_cmd_payload payload;
+};
+
+/**
+ * struct i3c_ccc_cmd - CCC command
+ *
+ * @rnw: true if the CCC should retrieve data from the device. Only valid for
+ * unicast commands
+ * @id: CCC command id
+ * @dests: array of destinations and associated payload for this CCC. Most of
+ * the time, only one destination is provided
+ * @ndests: number of destinations. Should always be one for broadcast commands
+ */
+struct i3c_ccc_cmd {
+ bool rnw;
+ u8 id;
+ struct i3c_ccc_cmd_dest *dests;
+ int ndests;
+};
+
+#endif /* I3C_CCC_H */
diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
new file mode 100644
index 000000000000..4c8675e01ddf
--- /dev/null
+++ b/include/linux/i3c/device.h
@@ -0,0 +1,212 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef I3C_DEV_H
+#define I3C_DEV_H
+
+#include <linux/device.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+
+/**
+ * enum i3c_hdr_mode - HDR mode ids
+ */
+enum i3c_hdr_mode {
+ I3C_HDR_DDR,
+ I3C_HDR_TSP,
+ I3C_HDR_TSL,
+};
+
+/**
+ * struct i3c_hdr_cmd - I3C HDR command
+ *
+ * @mode: HDR mode selected for this command
+ * @addr: I3C dynamic address
+ * @ndatawords: number of data words (a word is 16bits wide)
+ * @data: input/output buffer
+ */
+struct i3c_hdr_cmd {
+ enum i3c_hdr_mode mode;
+ u8 code;
+ u8 addr;
+ int ndatawords;
+ union {
+ u16 *in;
+ const u16 *out;
+ } data;
+};
+
+/* Private SDR read transfer */
+#define I3C_PRIV_XFER_READ BIT(0)
+/*
+ * Instruct the controller to issue a STOP after a specific transfer instead
+ * of a REPEATED START.
+ */
+#define I3C_PRIV_XFER_STOP BIT(1)
+
+/**
+ * struct i3c_priv_xfer - I3C SDR private transfer
+ *
+ * @addr: I3C dynamic address
+ * @len: transfer length in bytes of the transfer
+ * @flags: combination of I3C_PRIV_XFER_xxx flags
+ * @data: input/output buffer
+ */
+struct i3c_priv_xfer {
+ u8 addr;
+ u16 len;
+ u32 flags;
+ struct {
+ void *in;
+ const void *out;
+ } data;
+};
+
+/**
+ * enum i3c_dcr - I3C DCR values
+ */
+enum i3c_dcr {
+ I3C_DCR_GENERIC_DEVICE = 0,
+};
+
+#define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33)
+#define I3C_PID_RND_LOWER_32BITS(pid) (!!((pid) & BIT_ULL(32)))
+#define I3C_PID_RND_VAL(pid) ((pid) & GENMASK_ULL(31, 0))
+#define I3C_PID_PART_ID(pid) (((pid) & GENMASK_ULL(31, 16)) >> 16)
+#define I3C_PID_INSTANCE_ID(pid) (((pid) & GENMASK_ULL(15, 12)) >> 12)
+#define I3C_PID_EXTRA_INFO(pid) ((pid) & GENMASK_ULL(11, 0))
+
+#define I3C_BCR_DEVICE_ROLE(bcr) ((bcr) & GENMASK(7, 6))
+#define I3C_BCR_I3C_SLAVE (0 << 6)
+#define I3C_BCR_I3C_MASTER (1 << 6)
+#define I3C_BCR_HDR_CAP BIT(5)
+#define I3C_BCR_BRIDGE BIT(4)
+#define I3C_BCR_OFFLINE_CAP BIT(3)
+#define I3C_BCR_IBI_PAYLOAD BIT(2)
+#define I3C_BCR_IBI_REQ_CAP BIT(1)
+#define I3C_BCR_MAX_DATA_SPEED_LIM BIT(0)
+
+/**
+ * struct i3c_device_info - I3C device information
+ *
+ * @pid: Provisional ID
+ * @bcr: Bus Characteristic Register
+ * @dcr: Device Characteristic Register
+ * @static_addr: static/I2C address
+ * @dyn_addr: dynamic address
+ * @hdr_cap: supported HDR modes
+ * @max_read_ds: max read speed information
+ * @max_write_ds: max write speed information
+ * @max_ibi_len: max IBI payload length
+ * @max_read_turnaround: max read turn-around time in micro-seconds
+ * @max_read_len: max private SDR read length in bytes
+ * @max_write_len: max private SDR write length in bytes
+ *
+ * These are all basic information that should be advertised by an I3C device.
+ * Some of them are optional depending on the device type and device
+ * capabilities.
+ * For each I3C slave attached to a master with
+ * i3c_master_add_i3c_dev_locked(), the core will send the relevant CCC command
+ * to retrieve these data.
+ */
+struct i3c_device_info {
+ u64 pid;
+ u8 bcr;
+ u8 dcr;
+ u8 static_addr;
+ u8 dyn_addr;
+ u8 hdr_cap;
+ u8 max_read_ds;
+ u8 max_write_ds;
+ u8 max_ibi_len;
+ u32 max_read_turnaround;
+ u16 max_read_len;
+ u16 max_write_len;
+};
+
+/*
+ * I3C device internals are kept hidden from I3C device users. It's just
+ * simpler to refactor things when everything goes through getter/setters, and
+ * I3C device drivers should not have to worry about internal representation
+ * anyway.
+ */
+struct i3c_device;
+
+/* These macros should be used to i3c_device_id entries. */
+#define I3C_MATCH_MANUF_AND_PART (I3C_MATCH_MANUF | I3C_MATCH_PART)
+
+#define I3C_DEVICE(manuf, part) \
+ { \
+ .match_flags = I3C_MATCH_MANUF_AND_PART, \
+ .manuf_id = manuf, \
+ .part_id = part, \
+ }
+
+#define I3C_DEVICE_EXTRA_INFO(manuf, part, info) \
+ { \
+ .match_flags = I3C_MATCH_MANUF_AND_PART | \
+ I3C_MATCH_EXTRA_INFO, \
+ .manuf_id = manuf, \
+ .part_id = part, \
+ .extra_info = info, \
+ }
+
+#define I3C_CLASS(__dcr) \
+ { \
+ .match_flags = I3C_MATCH_DCR, \
+ .dcr = __dcr, \
+ }
+
+/**
+ * struct i3c_driver - I3C device driver
+ * @driver: inherit from device_driver
+ * @probe: I3C device probe method
+ * @remove: I3C device remove method
+ * @id_table: I3C device match table. Will be used by the framework to decide
+ * which device to bind to this driver
+ */
+struct i3c_driver {
+ struct device_driver driver;
+ int (*probe)(struct i3c_device *dev);
+ int (*remove)(struct i3c_device *dev);
+ const struct i3c_device_id *id_table;
+};
+
+static inline struct i3c_driver *drv_to_i3cdrv(struct device_driver *drv)
+{
+ return container_of(drv, struct i3c_driver, driver);
+}
+
+int i3c_driver_register_with_owner(struct i3c_driver *drv,
+ struct module *owner);
+void i3c_driver_unregister(struct i3c_driver *drv);
+
+#define i3c_driver_register(drv) \
+ i3c_driver_register_with_owner(drv, THIS_MODULE)
+
+#define module_i3c_driver(i3cdrv) \
+ module_driver(i3cdrv, i3c_driver_register, i3c_driver_unregister)
+
+int i3c_device_do_priv_xfers(struct i3c_device *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers);
+int i3c_device_send_hdr_cmds(struct i3c_device *dev,
+ struct i3c_hdr_cmd *cmds,
+ int ncmds);
+
+void i3c_device_get_info(struct i3c_device *dev, struct i3c_device_info *info);
+
+#endif /* I3C_DEV_H */
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
new file mode 100644
index 000000000000..4ff9c6475c92
--- /dev/null
+++ b/include/linux/i3c/master.h
@@ -0,0 +1,453 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef I3C_MASTER_H
+#define I3C_MASTER_H
+
+#include <linux/i2c.h>
+#include <linux/i3c/ccc.h>
+#include <linux/i3c/device.h>
+
+#define I3C_HOT_JOIN_ADDR 0x2
+#define I3C_BROADCAST_ADDR 0x7e
+#define I3C_MAX_ADDR GENMASK(6, 0)
+
+struct i3c_master_controller;
+struct i3c_bus;
+
+/**
+ * struct i3c_i2c_dev - I3C/I2C common information
+ *
+ * @node: node element used to insert the device into the I2C or I3C device
+ * list
+ * @bus: I3C bus this device is connected to
+ * @master: I3C master that instantiated this device. Will be used to send
+ * I2C/I3C frames on the bus
+ * @master_priv: master private data assigned to the device. Can be used to
+ * add master specific information
+ *
+ * This structure is describing common I3C/I2C dev information.
+ */
+struct i3c_i2c_dev {
+ struct list_head node;
+ struct i3c_bus *bus;
+ struct i3c_master_controller *master;
+ void *master_priv;
+};
+
+#define I3C_LVR_I2C_INDEX_MASK GENMASK(7, 5)
+#define I3C_LVR_I2C_INDEX(x) ((x) << 5)
+#define I3C_LVR_I2C_FM_MODE BIT(4)
+
+#define I2C_MAX_ADDR GENMASK(9, 0)
+
+/**
+ * struct i2c_device - I2C device object
+ *
+ * @common: inherit common I3C/I2C description
+ * @info: I2C board info used to instantiate the I2C device. If you are
+ * using DT to describe your hardware, this will be filled for you.
+ * @client: I2C client object created by the I2C framework. This will only
+ * be valid after i3c_master_register() returns.
+ * @lvr: Legacy Virtual Register value as described in the I3C specification
+ *
+ * I2C device object. Note that the real I2C device is represented by
+ * i2c_device->client, but we need extra information to handle the device when
+ * it's connected to an I3C bus, hence the &struct i2c_device wrapper.
+ *
+ * The I2C framework is not impacted by this new representation.
+ */
+struct i2c_device {
+ struct i3c_i2c_dev common;
+ struct i2c_board_info info;
+ struct i2c_client *client;
+ u8 lvr;
+};
+
+/**
+ * struct i3c_device - I3C device object
+ *
+ * @common: inherit common I3C/I2C description
+ * @dev: device object to register the I3C dev to the device model
+ * @info: I3C device information. Will be automatically filled when you create
+ * your device with i3c_master_add_i3c_dev_locked().
+ *
+ * I3C device object. Every I3C devs on the I3C bus are represented, including
+ * I3C masters. For each of them, we have an instance of &struct i3c_device.
+ */
+struct i3c_device {
+ struct i3c_i2c_dev common;
+ struct device dev;
+ struct i3c_device_info info;
+};
+
+/*
+ * The I3C specification says the maximum number of devices connected on the
+ * bus is 11, but this number depends on external parameters like trace length,
+ * capacitive load per Device, and the types of Devices present on the Bus.
+ * I3C master can also have limitations, so this number is just here as a
+ * reference and should be adjusted on a per-controller/per-board basis.
+ */
+#define I3C_BUS_MAX_DEVS 11
+
+#define I3C_BUS_MAX_I3C_SCL_RATE 12900000
+#define I3C_BUS_TYP_I3C_SCL_RATE 12500000
+#define I3C_BUS_I2C_FM_PLUS_SCL_RATE 1000000
+#define I3C_BUS_I2C_FM_SCL_RATE 400000
+#define I3C_BUS_TLOW_OD_MIN_NS 200
+
+/**
+ * enum i3c_bus_mode - I3C bus mode
+ *
+ * @I3C_BUS_MODE_PURE: only I3C devices are connected to the bus. No limitation
+ * expected
+ * @I3C_BUS_MODE_MIXED_FAST: I2C devices with 50ns spike filter are present on
+ * the bus. The only impact in this mode is that the
+ * high SCL pulse has to stay below 50ns to trick I2C
+ * devices when transmitting I3C frames
+ * @I3C_BUS_MODE_MIXED_SLOW: I2C devices without 50ns spike filter are present
+ * on the bus
+ */
+enum i3c_bus_mode {
+ I3C_BUS_MODE_PURE,
+ I3C_BUS_MODE_MIXED_FAST,
+ I3C_BUS_MODE_MIXED_SLOW,
+};
+
+/**
+ * enum i3c_addr_slot_status - I3C address slot status
+ *
+ * @I3C_ADDR_SLOT_FREE: address is free
+ * @I3C_ADDR_SLOT_RSVD: address is reserved
+ * @I3C_ADDR_SLOT_I2C_DEV: address is assigned to an I2C device
+ * @I3C_ADDR_SLOT_I3C_DEV: address is assigned to an I3C device
+ * @I3C_ADDR_SLOT_STATUS_MASK: address slot mask
+ *
+ * On an I3C bus, addresses are assigned dynamically, and we need to know which
+ * addresses are free to use and which ones are already assigned.
+ *
+ * Addresses marked as reserved are those reserved by the I3C protocol
+ * (broadcast address, ...).
+ */
+enum i3c_addr_slot_status {
+ I3C_ADDR_SLOT_FREE,
+ I3C_ADDR_SLOT_RSVD,
+ I3C_ADDR_SLOT_I2C_DEV,
+ I3C_ADDR_SLOT_I3C_DEV,
+ I3C_ADDR_SLOT_STATUS_MASK = 3,
+};
+
+/**
+ * struct i3c_bus - I3C bus object
+ *
+ * @dev: device to be registered to the device-model
+ * @cur_master: I3C master currently driving the bus. Since I3C is multi-master
+ * this can change over the time. Will be used to let a master
+ * know whether it needs to request bus ownership before sending
+ * a frame or not
+ * @addrslots: a bitmap with 2-bits per-slot to encode the address status and
+ * ease the DAA (Dynamic Address Assignment) procedure (see
+ * &enum i3c_addr_slot_status)
+ * @mode: bus mode (see &enum i3c_bus_mode)
+ * @scl_rate: SCL signal rate for I3C and I2C mode
+ * @devs: 2 lists containing all I3C/I2C devices connected to the bus
+ * @lock: read/write lock on the bus. This is needed to protect against
+ * operations that have an impact on the whole bus and the devices
+ * connected to it. For example, when asking slaves to drop their
+ * dynamic address (RSTDAA CCC), we need to make sure no one is trying
+ * to send I3C frames to these devices.
+ * Note that this lock does not protect against concurrency between
+ * devices: several drivers can send different I3C/I2C frames through
+ * the same master in parallel. This is the responsibility of the
+ * master to guarantee that frames are actually sent sequentially and
+ * not interlaced.
+ *
+ * The I3C bus is represented with its own object and not implicitly described
+ * by the I3C master to cope with the multi-master functionality, where one bus
+ * can be shared amongst several masters, each of them requesting bus ownership
+ * when they need to.
+ */
+struct i3c_bus {
+ struct device dev;
+ struct i3c_device *cur_master;
+ int id;
+ unsigned long addrslots[((I2C_MAX_ADDR + 1) * 2) / BITS_PER_LONG];
+ enum i3c_bus_mode mode;
+ struct {
+ unsigned long i3c;
+ unsigned long i2c;
+ } scl_rate;
+ struct {
+ struct list_head i3c;
+ struct list_head i2c;
+ } devs;
+ struct rw_semaphore lock;
+};
+
+static inline struct i3c_device *dev_to_i3cdev(struct device *dev)
+{
+ return container_of(dev, struct i3c_device, dev);
+}
+
+struct i3c_master_controller;
+
+/**
+ * struct i3c_master_controller_ops - I3C master methods
+ *
+ * @bus_init: hook responsible for the I3C bus initialization. This
+ * initialization should follow the steps described in the I3C
+ * specification. This hook is called with the bus lock held in
+ * write mode, which means all _locked() helpers can safely be
+ * called from there.
+ * @bus_cleanup: cleanup everything done in
+ * &i3c_master_controller_ops->bus_init(). This function is
+ * optional and should only be implemented if
+ * &i3c_master_controller_ops->bus_init() attached private data
+ * to I3C/I2C devices. This hook is called with the bus lock
+ * held in write mode, which means all _locked() helpers can
+ * safely be called from there.
+ * @supports_ccc_cmd: should return true if the CCC command is supported, false
+ * otherwise
+ * @send_ccc_cmd: send a CCC command
+ * @send_hdr_cmds: send one or several HDR commands. If there is more than one
+ * command, they should ideally be sent in the same HDR
+ * transaction
+ * @priv_xfers: do one or several private I3C SDR transfers
+ * @i2c_xfers: do one or several I2C transfers
+ *
+ * One of the most important hooks in these ops is
+ * &i3c_master_controller_ops->bus_init(). Here is a non-exhaustive list of
+ * things that should be done in &i3c_master_controller_ops->bus_init():
+ *
+ * 1) call i3c_master_set_info() with all information describing the master
+ * 2) ask all slaves to drop their dynamic address by sending the RSTDAA CCC
+ * with i3c_master_rstdaa_locked()
+ * 3) ask all slaves to disable IBIs using i3c_master_disec_locked()
+ * 4) start a DDA procedure by sending the ENTDAA CCC with
+ * i3c_master_entdaa_locked(), or using the internal DAA logic provided by
+ * your controller
+ * 5) assign a dynamic address to each I3C device discovered during DAA and
+ * for each of them, call i3c_master_add_i3c_dev_locked()
+ * 6) propagate device table to secondary masters by calling
+ * i3c_master_defslvs_locked()
+ *
+ * Note that these steps do not include all controller specific initialization.
+ */
+struct i3c_master_controller_ops {
+ int (*bus_init)(struct i3c_master_controller *master);
+ void (*bus_cleanup)(struct i3c_master_controller *master);
+ bool (*supports_ccc_cmd)(struct i3c_master_controller *master,
+ const struct i3c_ccc_cmd *cmd);
+ int (*send_ccc_cmd)(struct i3c_master_controller *master,
+ struct i3c_ccc_cmd *cmd);
+ int (*send_hdr_cmds)(struct i3c_master_controller *master,
+ const struct i3c_hdr_cmd *cmds,
+ int ncmds);
+ int (*priv_xfers)(struct i3c_master_controller *master,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers);
+ int (*i2c_xfers)(struct i3c_master_controller *master,
+ const struct i2c_msg *xfers, int nxfers);
+};
+
+/**
+ * struct i3c_master_controller - I3C master controller object
+ *
+ * @parent: parent device that instantiated this master
+ * @base: inherit from &struct i3c_device. A master is just a I3C device that
+ * has to be represented on the bus
+ * @i2c: I2C adapter used for backward compatibility. This adapter is
+ * registered to the I2C subsystem to be as transparent as possible to
+ * existing I2C drivers
+ * @ops: master operations. See &struct i3c_master_controller_ops
+ * @secondary: true if the master is a secondary master
+ * @bus: I3C bus object created by this master
+ *
+ * A &struct i3c_master_controller has to be registered to the I3C subsystem
+ * through i3c_master_register(). None of &struct i3c_master_controller fields
+ * should be set manually, just pass appropriate values to
+ * i3c_master_register().
+ */
+struct i3c_master_controller {
+ struct device *parent;
+ struct i3c_device base;
+ struct i2c_adapter i2c;
+ const struct i3c_master_controller_ops *ops;
+ bool secondary;
+ struct i3c_bus *bus;
+};
+
+/**
+ * i3c_bus_for_each_i2cdev() - iterate over all I2C devices present on the bus
+ *
+ * @bus: the I3C bus
+ * @i2cdev: an I2C device updated to point to the current device at each loop
+ * iteration
+ *
+ * Iterate over all I2C devs present on the bus.
+ */
+#define i3c_bus_for_each_i2cdev(bus, i2cdev) \
+ list_for_each_entry(i2cdev, &(bus)->devs.i2c, common.node)
+
+/**
+ * i3c_bus_for_each_i3cdev() - iterate over all I3C devices present on the bus
+ *
+ * @bus: the I3C bus
+ * @i3cdev: an I3C device updated to point to the current device at each loop
+ * iteration
+ *
+ * Iterate over all I3C devs present on the bus.
+ */
+#define i3c_bus_for_each_i3cdev(bus, i3cdev) \
+ list_for_each_entry(i3cdev, &(bus)->devs.i3c, common.node)
+
+int i3c_master_send_hdr_cmds(struct i3c_master_controller *master,
+ const struct i3c_hdr_cmd *cmds,
+ int ncmds);
+int i3c_master_do_priv_xfers(struct i3c_master_controller *master,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers);
+int i3c_master_do_i2c_xfers(struct i3c_master_controller *master,
+ const struct i2c_msg *xfers,
+ int nxfers);
+
+int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
+ const struct i3c_ccc_events *evts);
+int i3c_master_rstdaa_locked(struct i3c_master_controller *master, u8 addr);
+int i3c_master_entdaa_locked(struct i3c_master_controller *master);
+int i3c_master_defslvs_locked(struct i3c_master_controller *master);
+
+int i3c_master_get_free_addr(struct i3c_master_controller *master,
+ u8 start_addr);
+
+struct i3c_device *
+i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master, u8 addr);
+
+int i3c_master_set_info(struct i3c_master_controller *master,
+ const struct i3c_device_info *info);
+
+int i3c_master_register(struct i3c_master_controller *master,
+ struct device *parent,
+ const struct i3c_master_controller_ops *ops,
+ bool secondary);
+int i3c_master_unregister(struct i3c_master_controller *master);
+
+/**
+ * i3c_device_get_master_data() - get master private data attached to an I3C
+ * device
+ *
+ * @dev: the I3C dev to attach private data to
+ *
+ * Return: the private data previously attached with
+ * i3c_device_set_master_data() or NULL if no data has been attached
+ * to the device.
+ */
+static inline void *i3c_device_get_master_data(const struct i3c_device *dev)
+{
+ return dev->common.master_priv;
+}
+
+/**
+ * i3c_device_set_master_data() - attach master private data to an I3C device
+ *
+ * @dev: the I3C dev to attach private data to
+ * @data: private data
+ *
+ * This functions allows a master controller to attach per-device private data
+ * which can then be retrieved with i3c_device_get_master_data().
+ *
+ * Attaching private data to a device is usually done just after calling
+ * i3c_master_add_i3c_dev_locked().
+ */
+static inline void i3c_device_set_master_data(struct i3c_device *dev,
+ void *data)
+{
+ dev->common.master_priv = data;
+}
+
+/**
+ * i2c_device_get_master_data() - get master private data attached to an I2C
+ * device
+ *
+ * @dev: the I2C dev to attach private data to
+ *
+ * Return: the private data previously attached with
+ * i2c_device_set_master_data() or NULL if no data has been attached
+ * to the device.
+ */
+static inline void *i2c_device_get_master_data(const struct i2c_device *dev)
+{
+ return dev->common.master_priv;
+}
+
+/**
+ * i2c_device_set_master_data() - attach master private data to an I2C device
+ *
+ * @dev: the I2C dev to attach private data to
+ * @data: private data
+ *
+ * This functions allows a master controller to attach per-device private data
+ * which can then be retrieved with i2c_device_get_master_data().
+ *
+ * Attaching private data to a device is usually done during
+ * &master_controller_ops->bus_init(), by iterating over all I2C devices
+ * instantiated by the core (using i3c_bus_for_each_i2cdev()).
+ */
+static inline void i2c_device_set_master_data(struct i2c_device *dev,
+ void *data)
+{
+ dev->common.master_priv = data;
+}
+
+/**
+ * i3c_device_get_master() - get master used to communicate with a device
+ *
+ * @dev: I3C dev
+ *
+ * Return: the master controller driving @dev
+ */
+static inline struct i3c_master_controller *
+i3c_device_get_master(struct i3c_device *dev)
+{
+ return dev->common.master;
+}
+
+/**
+ * i3c_master_get_bus() - get the bus attached to a master
+ *
+ * @master: master object
+ *
+ * Return: the I3C bus @master is connected to
+ */
+static inline struct i3c_bus *
+i3c_master_get_bus(struct i3c_master_controller *master)
+{
+ return master->bus;
+}
+
+/**
+ * i3c_device_get_bus() - get the bus attached to a device
+ *
+ * @dev: an I3C device
+ *
+ * Return: the I3C bus @dev is connected to
+ */
+static inline struct i3c_bus *i3c_device_get_bus(struct i3c_device *dev)
+{
+ return i3c_master_get_bus(i3c_device_get_master(dev));
+}
+
+#endif /* I3C_MASTER_H */
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 3f74ef2281e8..df6c3a43b51c 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -438,6 +438,21 @@ struct pci_epf_device_id {
kernel_ulong_t driver_data;
};
+/* i3c */
+
+#define I3C_MATCH_DCR BIT(0)
+#define I3C_MATCH_MANUF BIT(1)
+#define I3C_MATCH_PART BIT(2)
+#define I3C_MATCH_EXTRA_INFO BIT(3)
+
+struct i3c_device_id {
+ __u8 match_flags;
+ __u8 dcr;
+ __u16 manuf_id;
+ __u16 part_id;
+ __u16 extra_info;
+};
+
/* spi */
#define SPI_NAME_SIZE 32
--
2.7.4
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC 3/5] dt-bindings: i3c: Document core bindings
@ 2017-07-31 16:24 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, 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 <boris.brezillon@free-electrons.com>
---
Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index 000000000000..49261dec7b01
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,90 @@
+Generic device tree bindings for I3C busses
+===========================================
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+-------------------
+
+- #address-cells - should be <1>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of I3C bus controller following generic names
+ recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+-------------------
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+ transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+ transfers. When undefined, the core looks at LVR values
+ of I2C devices described in the device tree to determine
+ the maximum I2C frequency.
+
+I2C devices
+===========
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+------------------------
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+ describing device capabilities as described in the I3C
+ specification.
+
+ bit[31:8]: unused
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+ frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not
+ tolerant to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+I3C devices
+===========
+
+I3C are not described in the device tree yet. We could decide to represent them
+at some point to assign a specific dynamic address to a device or to force an
+I3C device to act as an I2C device if it has a static address.
+
+Example:
+
+ i3c-master@0d040000 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d040000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+ i2c-scl-frequency = <100000>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.7.4
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC 3/5] dt-bindings: i3c: Document core bindings
@ 2017-07-31 16:24 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, 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 <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
1 file changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index 000000000000..49261dec7b01
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,90 @@
+Generic device tree bindings for I3C busses
+===========================================
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+-------------------
+
+- #address-cells - should be <1>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of I3C bus controller following generic names
+ recommended practice.
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+
+Optional properties
+-------------------
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
+ transfers. When undefined the core set it to 12.5MHz.
+
+- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
+ transfers. When undefined, the core looks at LVR values
+ of I2C devices described in the device tree to determine
+ the maximum I2C frequency.
+
+I2C devices
+===========
+
+Each I2C device connected to the bus should be described in a subnode with
+the following properties:
+
+All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here.
+
+New required properties:
+------------------------
+- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
+ describing device capabilities as described in the I3C
+ specification.
+
+ bit[31:8]: unused
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+ frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not
+ tolerant to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+I3C devices
+===========
+
+I3C are not described in the device tree yet. We could decide to represent them
+at some point to assign a specific dynamic address to a device or to force an
+I3C device to act as an I2C device if it has a static address.
+
+Example:
+
+ i3c-master@0d040000 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d040000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+ i2c-scl-frequency = <100000>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC 4/5] i3c: master: Add driver for Cadence IP
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
` (2 preceding siblings ...)
2017-07-31 16:24 ` Boris Brezillon
@ 2017-07-31 16:24 ` Boris Brezillon
2017-07-31 16:24 ` [RFC 5/5] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2017-07-31 19:17 ` Wolfram Sang
5 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Boris Brezillon
Add a driver for Cadence I3C master IP.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
drivers/i3c/master/Kconfig | 4 +
drivers/i3c/master/Makefile | 1 +
drivers/i3c/master/i3c-master-cdns.c | 1382 ++++++++++++++++++++++++++++++++++
3 files changed, 1387 insertions(+)
create mode 100644 drivers/i3c/master/i3c-master-cdns.c
diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index e69de29bb2d1..23ed1642828c 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -0,0 +1,4 @@
+config CDNS_I3C_MASTER
+ tristate "Cadence I3C master driver"
+ help
+ Enable this driver if you want to support Cadence I3C master block.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index e69de29bb2d1..4c4304aa9534 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o
diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
new file mode 100644
index 000000000000..74564fe55247
--- /dev/null
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -0,0 +1,1382 @@
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/i3c/master.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define DEV_ID 0x0
+#define DEV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20)
+#define DEV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8)
+#define DEV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4)
+#define DEV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0))
+
+#define CONF_STATUS 0x4
+#define CONF_STATUS_HAS_FIFOS BIT(26)
+#define CONF_STATUS_GPO_NUM(s) (((s) & GENMASK(25, 18)) >> 18)
+#define CONF_STATUS_GPI_NUM(s) (((s) & GENMASK(17, 10)) >> 10)
+#define CONF_STATUS_DEVS_NUM(s) (((s) & GENMASK(6, 3)) >> 3)
+#define DEV_TYPE_MAIN_MASTER 0
+#define DEV_TYPE_SECONDARY_MASTER 1
+#define DEV_TYPE_SLAVE 2
+#define CONF_STATUS_DEV_TYPE(s) ((s) & GENMASK(2, 0))
+
+#define DEVS_CTRL 0x8
+#define DEVS_CTRL_DEV_CLR_ALL GENMASK(31, 16)
+#define DEVS_CTRL_DEV_CLR(dev) BIT(16 + (dev))
+#define DEVS_CTRL_DEV_ACTIVE(dev) BIT(dev)
+
+#define CTRL 0x10
+#define CTRL_DEV_EN BIT(31)
+#define CTRL_HALT_EN BIT(30)
+#define CTRL_HJ_DISEC BIT(8)
+#define CTRL_MST_ACK BIT(7)
+#define CTRL_HJ_ACK BIT(6)
+#define CTRL_HJ_INIT BIT(5)
+#define CTRL_MST_INIT BIT(4)
+#define CTRL_AHDR_OPT BIT(3)
+#define CTRL_PURE_BUS_MODE 0
+#define CTRL_MIXED_FAST_BUS_MODE 2
+#define CTRL_MIXED_SLOW_BUS_MODE 3
+#define CTRL_BUS_MODE_MASK GENMASK(1, 0)
+
+#define PRESCL_CTRL0 0x14
+#define PRESCL_CTRL0_I2C(x) ((x) << 16)
+#define PRESCL_CTRL0_I3C(x) (x)
+#define PRESCL_CTRL0_MAX GENMASK(15, 0)
+
+#define PRESCL_CTRL1 0x18
+#define PRESCL_CTRL1_PP_LOW(x) ((x) << 8)
+#define PRESCL_CTRL1_OD_LOW(x) (x)
+
+#define MST_IER 0x20
+#define MST_IDR 0x24
+#define MST_IMR 0x28
+#define MST_ICR 0x2c
+#define MST_ISR 0x30
+#define MST_INT_RX_THR BIT(24)
+#define MST_INT_TX_THR BIT(23)
+#define MST_INT_IBI_THR BIT(22)
+#define MST_INT_CMD_THR BIT(21)
+#define MST_INT_RX_UNF BIT(20)
+#define MST_INT_TX_OVF BIT(19)
+#define MST_INT_IBI_UNF BIT(18)
+#define MST_INT_CMD_OVF BIT(17)
+#define MST_INT_CMD_EMPTY BIT(16)
+#define MST_INT_MR_DONE BIT(11)
+#define MST_INT_IBI_FAIL BIT(10)
+#define MST_INT_SDR_FAIL BIT(9)
+#define MST_INT_DDR_FAIL BIT(8)
+#define MST_INT_HJ_REQ BIT(7)
+#define MST_INT_MR_REQ BIT(6)
+#define MST_INT_IBI_REQ BIT(5)
+#define MST_INT_BUS_DISCR BIT(4)
+#define MST_INT_INVALID_DA BIT(3)
+#define MST_INT_RD_ABORT BIT(2)
+#define MST_INT_NACK BIT(1)
+#define MST_INT_COMP BIT(0)
+
+#define MST_STATUS0 0x34
+#define MST_STATUS0_IDLE BIT(31)
+#define MST_STATUS0_HALTED BIT(30)
+#define MST_STATUS0_MASTER_MODE BIT(29)
+#define MST_STATUS0_IMM_COMP BIT(28)
+#define MST_STATUS0_DDR_ERR_ID(s) ((s) & GENMASK(27, 25) >> 25)
+#define MST_STATUS0_DAA_COMP BIT(24)
+#define MST_STATUS0_IBI_FIFO_FULL BIT(23)
+#define MST_STATUS0_RX_FIFO_FULL BIT(22)
+#define MST_STATUS0_XFER_BYTES(s) ((s) & GENMASK(21, 10) >> 10)
+#define MST_STATUS0_DEV_ADDR(s) ((s) & GENMASK(9, 0))
+
+#define SIR_STATUS 0x3c
+#define SIR_STATUS_DEV(d) BIT(d)
+
+#define SLV_IER 0x40
+#define SLV_IDR 0x44
+#define SLV_IMR 0x48
+#define SLV_ICR 0x4c
+#define SLV_ISR 0x50
+#define SLV_INT_TM BIT(20)
+#define SLV_INT_ERROR BIT(19)
+#define SLV_INT_EVENT_UP BIT(18)
+#define SLV_INT_HJ_DONE BIT(17)
+#define SLV_INT_MR_DONE BIT(16)
+#define SLV_INT_SDR_FAIL BIT(14)
+#define SLV_INT_DDR_FAIL BIT(13)
+#define SLV_INT_M_RD_ABORT BIT(12)
+#define SLV_INT_DDR_RX_THR BIT(11)
+#define SLV_INT_DDR_TX_THR BIT(10)
+#define SLV_INT_SDR_RX_THR BIT(9)
+#define SLV_INT_SDR_TX_THR BIT(8)
+#define SLV_INT_DDR_RX_UNF BIT(7)
+#define SLV_INT_DDR_TX_OVF BIT(6)
+#define SLV_INT_SDR_RX_UNF BIT(5)
+#define SLV_INT_SDR_TX_OVF BIT(4)
+#define SLV_INT_DDR_RD_COMP BIT(3)
+#define SLV_INT_DDR_WR_COMP BIT(2)
+#define SLV_INT_SDR_RD_COMP BIT(1)
+#define SLV_INT_SDR_WR_COMP BIT(0)
+
+#define SLV_STATUS0 0x54
+#define SLV_STATUS0_REG_ADDR(s) (((s) & GENMASK(23, 16)) >> 16)
+#define SLV_STATUS0_XFRD_BYTES(s) ((s) & GENMASK(15, 0))
+
+#define SLV_STATUS1 0x58
+#define SLV_STATUS1_AS(s) (((s) & GENMASK(21, 20)) >> 20)
+#define SLV_STATUS1_VEN_TM BIT(19)
+#define SLV_STATUS1_HJ_DIS BIT(18)
+#define SLV_STATUS1_MR_DIS BIT(17)
+#define SLV_STATUS1_PROT_ERR BIT(16)
+#define SLV_STATUS1_DDR_RX_FULL BIT(7)
+#define SLV_STATUS1_DDR_TX_FULL BIT(6)
+#define SLV_STATUS1_DDR_RX_EMPTY BIT(5)
+#define SLV_STATUS1_DDR_TX_EMPTY BIT(4)
+#define SLV_STATUS1_SDR_RX_FULL BIT(3)
+#define SLV_STATUS1_SDR_TX_FULL BIT(2)
+#define SLV_STATUS1_SDR_RX_EMPTY BIT(1)
+#define SLV_STATUS1_SDR_TX_EMPTY BIT(0)
+
+#define CMD0_FIFO 0x60
+#define CMD0_FIFO_IS_DDR BIT(31)
+#define CMD0_FIFO_IS_CCC BIT(30)
+#define CMD0_FIFO_BCH BIT(29)
+#define XMIT_BURST_STATIC_SUBADDR 0
+#define XMIT_SINGLE_INC_SUBADDR 1
+#define XMIT_SINGLE_STATIC_SUBADDR 2
+#define XMIT_BURST_WITHOUT_SUBADDR 3
+#define CMD0_FIFO_PRIV_XMIT_MODE(m) ((m) << 27)
+#define CMD0_FIFO_SBCA BIT(26)
+#define CMD0_FIFO_RSBC BIT(25)
+#define CMD0_FIFO_IS_10B BIT(24)
+#define CMD0_FIFO_PL_LEN(l) ((l) << 12)
+#define CMD0_FIFO_PL_LEN_MAX 4095
+#define CMD0_FIFO_DEV_ADDR(a) ((a) << 1)
+#define CMD0_FIFO_RNW BIT(0)
+
+#define CMD1_FIFO 0x64
+#define CMD1_FIFO_CSRADDR(a) (a)
+#define CMD1_FIFO_CCC(id) (id)
+
+#define TX_FIFO 0x68
+
+#define IMD_CMD0 0x70
+#define IMD_CMD0_PL_LEN(l) ((l) << 12)
+#define IMD_CMD0_DEV_ADDR(a) ((a) << 1)
+#define IMD_CMD0_RNW BIT(0)
+
+#define IMD_CMD1 0x74
+#define IMD_CMD1_CCC(id) (id)
+
+#define IMD_DATA 0x78
+#define RX_FIFO 0x80
+#define IBI_DATA_FIFO 0x84
+#define SLV_DDR_TX_FIFO 0x88
+#define SLV_DDR_RX_FIFO 0x8c
+
+#define CMD_IBI_THR_CTRL 0x90
+#define IBI_THR(t) ((t) << 8)
+#define CMD_THR(t) (t)
+
+#define TX_RX_THR_CTRL 0x94
+#define RX_THR(t) ((t) << 16)
+#define TX_THR(t) (t)
+
+#define SLV_DDR_TX_RX_THR_CTRL 0x98
+#define SLV_DDR_RX_THR(t) ((t) << 16)
+#define SLV_DDR_TX_THR(t) (t)
+
+#define FLUSH_CTRL 0x9c
+#define FLUSH_SLV_DDR_RX_FIFO BIT(22)
+#define FLUSH_SLV_DDR_TX_FIFO BIT(21)
+#define FLUSH_IMM_FIFO BIT(20)
+#define FLUSH_IBI_FIFO BIT(19)
+#define FLUSH_RX_FIFO BIT(18)
+#define FLUSH_TX_FIFO BIT(17)
+#define FLUSH_CMD_FIFO BIT(16)
+
+#define DEV_ID_RR0(d) (0xa0 + ((d) * 0x10))
+#define DEV_ID_RR0_LVR_EXT_ADDR BIT(11)
+#define DEV_ID_RR0_HDR_CAP BIT(10)
+#define DEV_ID_RR0_IS_I3C BIT(9)
+#define DEV_ID_RR0_SET_DEV_ADDR(a) (((a) & GENMASK(6, 0)) | \
+ (((a) & GENMASK(9, 7)) << 6))
+#define DEV_ID_RR0_GET_DEV_ADDR(x) ((((x) >> 1) & GENMASK(6, 0)) | \
+ (((x) >> 6) & GENMASK(9, 7)))
+
+#define DEV_ID_RR1(d) (0xa4 + ((d) * 0x10))
+#define DEV_ID_RR1_PID_MSB(pid) (pid)
+
+#define DEV_ID_RR2(d) (0xa8 + ((d) * 0x10))
+#define DEV_ID_RR2_PID_LSB(pid) ((pid) << 16)
+#define DEV_ID_RR2_BCR(bcr) ((bcr) << 8)
+#define DEV_ID_RR2_DCR(dcr) (dcr)
+#define DEV_ID_RR2_LVR(lvr) (lvr)
+
+#define SIR_MAP(x) (0x160 + ((x) * 4))
+#define SIR_MAP_DEV_REG(d) SIR_MAP((d) / 2)
+#define SIR_MAP_DEV_SHIFT(d, fs) ((fs) + (((d) % 2) ? 16 : 0))
+#define SIR_MAP_DEV_MASK(d) (GENMASK(15, 0) << (((d) % 2) ? 16 : 0))
+#define DEV_ROLE_SLAVE 0
+#define DEV_ROLE_MASTER 1
+#define SIR_MAP_DEV_ROLE(d, role) ((role) << SIR_MAP_DEV_SHIFT(d, 14))
+#define SIR_MAP_DEV_SLOW(d) BIT(SIR_MAP_DEV_SHIFT(d, 13))
+#define SIR_MAP_DEV_PL(d, l) ((l) << SIR_MAP_DEV_SHIFT(d, 8))
+#define SIR_MAP_PL_MAX GENMASK(4, 0)
+#define SIR_MAP_DEV_DA(d, a) ((a) << SIR_MAP_DEV_SHIFT(d, 1))
+#define SIR_MAP_DEV_ACK_RESP(d) BIT(SIR_MAP_DEV_SHIFT(d, 0))
+
+#define GPIR_WORD(x) (0x180 + ((x) * 4))
+#define GPI_REG(val, id) \
+ (((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+#define GPOR_WORD(x) (0x200 + ((x) * 4))
+#define GPO_REG(val, id) \
+ (((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+struct cdns_i3c_cmd {
+ struct list_head node;
+ u32 cmd0;
+ u32 cmd1;
+ struct {
+ void *in;
+ const void *out;
+ } data;
+ u32 dataptr;
+ u32 datalen;
+ struct completion *comp;
+};
+
+struct cdns_i3c_master_caps {
+ u32 cmdfifodepth;
+ u32 txfifodepth;
+ u32 rxfifodepth;
+};
+
+struct cdns_i3c_master {
+ struct i3c_master_controller base;
+ struct mutex lock;
+ unsigned long free_dev_slots;
+ void __iomem *regs;
+ struct clk *sysclk;
+ struct clk *pclk;
+ struct completion comp;
+ struct cdns_i3c_master_caps caps;
+};
+
+static inline struct cdns_i3c_master *
+to_cdns_i3c_master(struct i3c_master_controller *master)
+{
+ return container_of(master, struct cdns_i3c_master, base);
+}
+
+static void cdns_i3c_master_wr_to_tx_fifo(struct cdns_i3c_master *master,
+ const u8 *bytes, int nbytes)
+{
+ int i, j;
+
+ for (i = 0; i < nbytes; i += 4) {
+ u32 data = 0;
+
+ for (j = 0; j < 4 && (i + j) < nbytes; j++)
+ data |= (u32)bytes[i + j] << (j * 8);
+
+ writel(data, master->regs + TX_FIFO);
+ }
+}
+
+static void cdns_i3c_master_drain_rx_fifo(struct cdns_i3c_master *master)
+{
+ int i;
+
+ for (i = 0; i < master->caps.rxfifodepth; i++) {
+ readl(master->regs + RX_FIFO);
+ if (readl(master->regs + MST_ISR) & MST_INT_RX_UNF) {
+ writel(MST_INT_RX_UNF, master->regs + MST_ICR);
+ break;
+ }
+ }
+}
+
+static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master *master,
+ u8 *bytes, int nbytes)
+{
+ u32 status0;
+ int i, j;
+
+ status0 = readl(master->regs + MST_STATUS0);
+
+ if (nbytes > MST_STATUS0_XFER_BYTES(status0))
+ nbytes = MST_STATUS0_XFER_BYTES(status0);
+
+ for (i = 0; i < nbytes; i += 4) {
+ u32 data;
+
+ data = readl(master->regs + RX_FIFO);
+
+ for (j = 0; j < 4 && (i + j) < nbytes; j++)
+ bytes[i + j] = data >> (j * 8);
+ }
+}
+
+static bool cdns_i3c_master_supports_ccc_cmd(struct i3c_master_controller *m,
+ const struct i3c_ccc_cmd *cmd)
+{
+ if (cmd->ndests > 1)
+ return false;
+
+ switch (cmd->id) {
+ case I3C_CCC_ENEC(true):
+ case I3C_CCC_ENEC(false):
+ case I3C_CCC_DISEC(true):
+ case I3C_CCC_DISEC(false):
+ case I3C_CCC_ENTAS(0, true):
+ case I3C_CCC_ENTAS(0, false):
+ case I3C_CCC_RSTDAA(true):
+ case I3C_CCC_RSTDAA(false):
+ case I3C_CCC_ENTDAA:
+ case I3C_CCC_SETMWL(true):
+ case I3C_CCC_SETMWL(false):
+ case I3C_CCC_SETMRL(true):
+ case I3C_CCC_SETMRL(false):
+ case I3C_CCC_DEFSLVS:
+ case I3C_CCC_ENTHDR(0):
+ case I3C_CCC_SETDASA:
+ case I3C_CCC_SETNEWDA:
+ case I3C_CCC_GETMWL:
+ case I3C_CCC_GETMRL:
+ case I3C_CCC_GETPID:
+ case I3C_CCC_GETBCR:
+ case I3C_CCC_GETDCR:
+ case I3C_CCC_GETSTATUS:
+ case I3C_CCC_GETACCMST:
+ case I3C_CCC_GETMXDS:
+ case I3C_CCC_GETHDRCAP:
+ return true;
+ default:
+ break;
+ }
+
+ return false;
+}
+
+static void cdns_i3c_master_init_irqs(struct cdns_i3c_master *master,
+ u32 irqs)
+{
+ writel(irqs, master->regs + MST_ICR);
+ writel(0xffffffff, master->regs + MST_ICR);
+ reinit_completion(&master->comp);
+}
+
+static u32 cdns_i3c_master_wait_for_irqs(struct cdns_i3c_master *master,
+ u32 irqs)
+{
+ u32 ret;
+
+ writel(irqs, master->regs + MST_IER);
+ wait_for_completion_timeout(&master->comp, msecs_to_jiffies(1000));
+ writel(irqs, master->regs + MST_IDR);
+
+ ret = readl(master->regs + MST_ISR) & irqs;
+
+ return ret;
+}
+
+static int cdns_i3c_master_send_ccc_cmd(struct i3c_master_controller *m,
+ struct i3c_ccc_cmd *cmd)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ u32 cmd0, isr, irqs;
+
+ mutex_lock(&master->lock);
+ cmd0 = CMD0_FIFO_IS_CCC | CMD0_FIFO_PL_LEN(cmd->dests[0].payload.len);
+ if (cmd->id & I3C_CCC_DIRECT)
+ cmd0 |= CMD0_FIFO_DEV_ADDR(cmd->dests[0].addr);
+
+ if (cmd->rnw)
+ cmd0 |= CMD0_FIFO_RNW;
+
+ if (!cmd->rnw)
+ cdns_i3c_master_wr_to_tx_fifo(master,
+ cmd->dests[0].payload.data,
+ cmd->dests[0].payload.len);
+
+ irqs = MST_INT_COMP | (cmd->id != I3C_CCC_ENTDAA ? MST_INT_NACK : 0);
+ cdns_i3c_master_init_irqs(master, irqs);
+ writel(CMD1_FIFO_CCC(cmd->id), master->regs + CMD1_FIFO);
+ writel(cmd0, master->regs + CMD0_FIFO);
+ isr = cdns_i3c_master_wait_for_irqs(master, irqs);
+
+ if (cmd->rnw) {
+ int nbytes = cmd->dests[0].payload.len;
+ u32 status0 = readl(master->regs + MST_STATUS0);
+
+ if (nbytes > MST_STATUS0_XFER_BYTES(status0))
+ nbytes = MST_STATUS0_XFER_BYTES(status0);
+
+ cdns_i3c_master_rd_from_rx_fifo(master,
+ cmd->dests[0].payload.data,
+ nbytes);
+ cmd->dests[0].payload.len = nbytes;
+ }
+ mutex_unlock(&master->lock);
+
+ /*
+ * MST_INT_NACK is not an error when doing DAA, it just means "no i3c
+ * devices on the bus".
+ */
+ if (isr & MST_INT_NACK)
+ return -EIO;
+ else if (!(isr & MST_INT_COMP))
+ return -ETIMEDOUT;
+
+ return 0;
+}
+
+static int cdns_i3c_master_priv_xfers(struct i3c_master_controller *m,
+ const struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ int tnxfers = 0, tntx = 0, tnrx = 0, j = 0, i, ret = 0;
+
+ for (i = 0; i < nxfers; i++) {
+ if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+ return -ENOTSUPP;
+ }
+
+ if (!nxfers)
+ return 0;
+
+ /*
+ * First make sure that all transactions (block of transfers separated
+ * by a STOP marker) fit in the FIFOs.
+ */
+ for (i = 0; i < nxfers; i++) {
+ tnxfers++;
+
+ if (xfers[i].flags & I3C_PRIV_XFER_READ)
+ tnrx += DIV_ROUND_UP(xfers[i].len, 4);
+ else
+ tntx += DIV_ROUND_UP(xfers[i].len, 4);
+
+ if (!(xfers[i].flags & I3C_PRIV_XFER_STOP))
+ continue;
+
+ if (tnxfers > master->caps.cmdfifodepth ||
+ tnrx > master->caps.rxfifodepth ||
+ tntx > master->caps.txfifodepth)
+ return -ENOTSUPP;
+
+ tnxfers = 0;
+ tntx = 0;
+ tnrx = 0;
+ }
+
+ mutex_lock(&master->lock);
+
+ cdns_i3c_master_init_irqs(master, MST_INT_NACK | MST_INT_COMP);
+
+ /*
+ * FIXME: The IP does not support stalling the output message queue
+ * while we are queuing I3C commands, and we have no way to tell the
+ * I3C master whether we want a Repeated Start (Sr) or a Stop (S)
+ * between two transfers. Instead, the engine decides by itself when Sr
+ * should be used based on the next command in the queue.
+ * The problem is, we are not guaranteed to queue the second message
+ * before the master has finished transmitting the first one, and the
+ * engine might see an empty FIFO when it tries to figure what kind of
+ * transition should be used, thus generating a S when we expected a
+ * Sr.
+ *
+ * To guarantee atomicity on this transfer queuing operation, we
+ * disable the master, then queue things and finally re-enable it, but
+ * this means we have a short period of time during which we can miss
+ * IBI/HJ events.
+ *
+ * This should hopefully be fixed with the next version of this IP.
+ */
+ writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN, master->regs + CTRL);
+
+ for (i = 0; i < nxfers; i++) {
+ u32 cmd0, isr;
+
+ cmd0 = CMD0_FIFO_DEV_ADDR(xfers[i].addr) |
+ CMD0_FIFO_PL_LEN(xfers[i].len) |
+ CMD0_FIFO_PRIV_XMIT_MODE(XMIT_BURST_WITHOUT_SUBADDR);
+
+ if (xfers[i].flags & I3C_PRIV_XFER_READ)
+ cmd0 |= CMD0_FIFO_RNW;
+ else
+ cdns_i3c_master_wr_to_tx_fifo(master,
+ xfers[i].data.out,
+ xfers[i].len);
+
+ if (!(xfers[i].flags & I3C_PRIV_XFER_STOP) || i == nxfers - 1)
+ cmd0 |= CMD0_FIFO_RSBC;
+
+ if (!i || (xfers[i - 1].flags & I3C_PRIV_XFER_STOP))
+ cmd0 |= CMD0_FIFO_BCH;
+
+ writel_relaxed(0, master->regs + CMD1_FIFO);
+ writel_relaxed(cmd0, master->regs + CMD0_FIFO);
+
+ if (!(xfers[i].flags & I3C_PRIV_XFER_STOP) && i < nxfers - 1)
+ continue;
+
+ writel(readl(master->regs + CTRL) | CTRL_DEV_EN,
+ master->regs + CTRL);
+
+ isr = cdns_i3c_master_wait_for_irqs(master,
+ MST_INT_NACK |
+ MST_INT_COMP);
+ if (isr != MST_INT_COMP) {
+ cdns_i3c_master_drain_rx_fifo(master);
+ if (isr & MST_INT_NACK)
+ ret = -EIO;
+ else
+ ret = -ETIMEDOUT;
+
+ break;
+ }
+
+ for (; j <= i; j++) {
+ if (xfers[j].flags & I3C_PRIV_XFER_READ)
+ cdns_i3c_master_rd_from_rx_fifo(master,
+ xfers[j].data.in,
+ xfers[j].len);
+ }
+
+ cdns_i3c_master_init_irqs(master, MST_INT_NACK | MST_INT_COMP);
+ writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN,
+ master->regs + CTRL);
+ }
+
+ writel(readl(master->regs + CTRL) | CTRL_DEV_EN, master->regs + CTRL);
+
+ mutex_unlock(&master->lock);
+
+ return ret;
+}
+
+#define I3C_DDR_FIRST_DATA_WORD_PREAMBLE 0x2
+#define I3C_DDR_DATA_WORD_PREAMBLE 0x3
+
+#define I3C_DDR_PREAMBLE(p) ((p) << 18)
+
+static u32 prepare_ddr_word(u16 payload)
+{
+ u32 ret;
+ u16 pb;
+
+ ret = (u32)payload << 2;
+
+ /* Calculate parity. */
+ pb = (payload >> 15) ^ (payload >> 13) ^ (payload >> 11) ^
+ (payload >> 9) ^ (payload >> 7) ^ (payload >> 5) ^
+ (payload >> 3) ^ (payload >> 1);
+ ret |= (pb & 1) << 1;
+ pb = (payload >> 14) ^ (payload >> 12) ^ (payload >> 10) ^
+ (payload >> 8) ^ (payload >> 6) ^ (payload >> 4) ^
+ (payload >> 2) ^ payload ^ 1;
+ ret |= (pb & 1);
+
+ return ret;
+}
+
+static u32 prepare_ddr_data_word(u16 data, bool first)
+{
+ return prepare_ddr_word(data) | I3C_DDR_PREAMBLE(first ? 2 : 3);
+}
+
+#define I3C_DDR_READ_CMD BIT(15)
+
+static u32 prepare_ddr_cmd_word(u16 cmd)
+{
+ return prepare_ddr_word(cmd) | I3C_DDR_PREAMBLE(1);
+}
+
+static u32 prepare_ddr_crc_word(u8 crc5)
+{
+ return (((u32)crc5 & 0x1f) << 9) | (0xc << 14) |
+ I3C_DDR_PREAMBLE(1);
+}
+
+static u8 update_crc5(u8 crc5, u16 word)
+{
+ u8 crc0;
+ int i;
+
+ /*
+ * crc0 = next_data_bit ^ crc[4]
+ * 1 2 3 4
+ * crc[4:0] = { crc[3:2], crc[1]^crc0, crc[0], crc0 }
+ */
+ for (i = 0; i < 16; ++i) {
+ crc0 = ((word >> (15 - i)) ^ (crc5 >> 4)) & 0x1;
+ crc5 = ((crc5 << 1) & (0x18 | 0x2)) |
+ (((crc5 >> 1) ^ crc0) << 2) | crc0;
+ }
+
+ return crc5 & 0x1F;
+}
+
+static int cdns_i3c_master_send_hdr_cmd(struct i3c_master_controller *m,
+ const struct i3c_hdr_cmd *cmds,
+ int ncmds)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ int ret, i, ntxwords = 1, nrxwords = 0, pl_len = 1, ncmdwords = 2;
+ u16 cmdword, datain;
+ u32 checkword, word;
+ u32 isr;
+ u8 crc5;
+
+ if (ncmds < 1)
+ return 0;
+
+ if (ncmds > 1 || cmds[0].ndatawords > CMD0_FIFO_PL_LEN_MAX)
+ return -ENOTSUPP;
+
+ if (cmds[0].mode != I3C_HDR_DDR)
+ return -ENOTSUPP;
+
+ cmdword = ((u16)cmds[0].code << 8) | (cmds[0].addr << 1);
+ if (cmdword & I3C_DDR_READ_CMD)
+ nrxwords += cmds[0].ndatawords + 1;
+ else
+ ntxwords += cmds[0].ndatawords + 1;
+
+ if (ntxwords > master->caps.txfifodepth ||
+ nrxwords > master->caps.rxfifodepth ||
+ ncmdwords > master->caps.cmdfifodepth)
+ return -ENOTSUPP;
+
+ if (cmdword & I3C_DDR_READ_CMD) {
+ u16 pb;
+
+ pb = (cmdword >> 14) ^ (cmdword >> 12) ^ (cmdword >> 10) ^
+ (cmdword >> 8) ^ (cmdword >> 6) ^ (cmdword >> 4) ^
+ (cmdword >> 2);
+
+ if (pb & 1)
+ cmdword |= BIT(0);
+ }
+
+ mutex_lock(&master->lock);
+
+ writel(prepare_ddr_cmd_word(cmdword),
+ master->regs + TX_FIFO);
+
+ crc5 = update_crc5(0x1f, cmdword);
+
+ if (!(cmdword & I3C_DDR_READ_CMD)) {
+ for (i = 0; i < cmds[0].ndatawords; i++) {
+ crc5 = update_crc5(crc5, cmds[0].data.out[i]);
+ writel(prepare_ddr_data_word(cmds[0].data.out[i], !i),
+ master->regs + TX_FIFO);
+ }
+
+ writel(prepare_ddr_crc_word(crc5), master->regs + TX_FIFO);
+ pl_len += 1 + cmds[0].ndatawords;
+ }
+
+ cdns_i3c_master_init_irqs(master,
+ MST_INT_NACK | MST_INT_COMP |
+ MST_INT_DDR_FAIL);
+
+ /*
+ * FIXME: The IP does not support stalling the output message queue
+ * while we are queuing I3C HDR commands, and we have no way to tell
+ * the I3C master whether we want an HDR Restart or an HDR Exit
+ * between two HDR commands. Instead, the engine decides by itself when
+ * HDR Restart should be used based on the next command in the queue.
+ * The problem is, we are not guaranteed to queue the second message
+ * before the master has finished transmitting the first one, and the
+ * engine might see an empty FIFO when it tries to figure what kind of
+ * transition should be used, thus generating an HDR Exit when we
+ * expected an HDR Restart.
+ *
+ * To guarantee atomicity on this command queuing operation, we disable
+ * the master, then queue things and finally re-enable it, but this
+ * means we have a short period of time during which we can miss IBI/HJ
+ * events.
+ *
+ * This should hopefully be fixed with the next version of this IP.
+ */
+ writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN, master->regs + CTRL);
+
+ /* Queue ENTHDR command */
+ writel(CMD1_FIFO_CCC(I3C_CCC_ENTHDR(0)),
+ master->regs + CMD1_FIFO);
+ writel(CMD0_FIFO_IS_CCC, master->regs + CMD0_FIFO);
+
+ writel(0, master->regs + CMD1_FIFO);
+ writel(CMD0_FIFO_IS_DDR | CMD0_FIFO_PL_LEN(pl_len) |
+ (cmdword & I3C_DDR_READ_CMD ? CMD0_FIFO_RNW : 0) |
+ CMD0_FIFO_DEV_ADDR(cmds[0].addr),
+ master->regs + CMD0_FIFO);
+
+ writel(readl(master->regs + CTRL) | CTRL_DEV_EN, master->regs + CTRL);
+ isr = cdns_i3c_master_wait_for_irqs(master,
+ MST_INT_NACK |
+ MST_INT_COMP |
+ MST_INT_DDR_FAIL);
+ if (isr != MST_INT_COMP) {
+ if (!isr)
+ ret = -ETIMEDOUT;
+ else
+ ret = -EIO;
+
+ goto err_drain_fifo;
+ }
+
+ if (!(cmdword & I3C_DDR_READ_CMD))
+ return 0;
+
+ for (i = 0; i < cmds[0].ndatawords; i++) {
+ word = readl(master->regs + RX_FIFO);
+ datain = (word >> 2) & GENMASK(15, 0);
+ checkword = prepare_ddr_data_word(datain, !i);
+ word &= GENMASK(19, 0);
+ if (checkword != word) {
+ ret = -EIO;
+ goto err_drain_fifo;
+ }
+
+ crc5 = update_crc5(crc5, datain);
+ cmds[0].data.in[i] = datain;
+ }
+
+ word = readl(master->regs + RX_FIFO);
+ word &= GENMASK(19, 7);
+ datain = (word >> 2) & GENMASK(15, 0);
+ checkword = prepare_ddr_crc_word(crc5);
+ if (checkword != word) {
+ ret = -EIO;
+ goto err_drain_fifo;
+ }
+
+ mutex_unlock(&master->lock);
+
+ return 0;
+
+err_drain_fifo:
+ cdns_i3c_master_drain_rx_fifo(master);
+ mutex_unlock(&master->lock);
+
+ return ret;
+}
+
+static int cdns_i3c_master_i2c_xfers(struct i3c_master_controller *m,
+ const struct i2c_msg *xfers, int nxfers)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ int i, ret = 0;
+
+ for (i = 0; i < nxfers; i++) {
+ if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+ return -ENOTSUPP;
+ }
+
+ mutex_lock(&master->lock);
+
+ for (i = 0; i < nxfers; i++) {
+ u32 cmd0, isr;
+
+ cmd0 = CMD0_FIFO_DEV_ADDR(xfers[i].addr) |
+ CMD0_FIFO_PL_LEN(xfers[i].len) |
+ CMD0_FIFO_PRIV_XMIT_MODE(XMIT_BURST_WITHOUT_SUBADDR);
+
+ if (xfers[i].flags & I2C_M_TEN)
+ cmd0 |= CMD0_FIFO_IS_10B;
+
+ if (xfers[i].flags & I2C_M_RD)
+ cmd0 |= CMD0_FIFO_RNW;
+ else
+ cdns_i3c_master_wr_to_tx_fifo(master, xfers[i].buf,
+ xfers[i].len);
+
+ cdns_i3c_master_init_irqs(master, MST_INT_NACK | MST_INT_COMP);
+ writel(0, master->regs + CMD1_FIFO);
+ writel(cmd0, master->regs + CMD0_FIFO);
+ isr = cdns_i3c_master_wait_for_irqs(master,
+ MST_INT_NACK |
+ MST_INT_COMP);
+
+ if (xfers[i].flags & I2C_M_RD) {
+ if (isr == MST_INT_COMP)
+ cdns_i3c_master_rd_from_rx_fifo(master,
+ xfers[i].buf,
+ xfers[i].len);
+ else
+ cdns_i3c_master_drain_rx_fifo(master);
+ }
+
+ if (isr & MST_INT_NACK) {
+ ret = -EIO;
+ break;
+ } else if (!(isr & MST_INT_COMP)) {
+ ret = -ETIMEDOUT;
+ break;
+ }
+ }
+
+ mutex_unlock(&master->lock);
+
+ return ret;
+}
+
+struct cdns_i3c_i2c_dev_data {
+ int id;
+};
+
+static u32 prepare_rr0_dev_address(u32 addr)
+{
+ u32 ret = (addr << 1) & 0xff;
+
+ /* RR0[7:1] = addr[6:0] */
+ ret |= (addr & GENMASK(6, 0)) << 1;
+
+ /* RR0[15:13] = addr[9:7] */
+ ret |= (addr & GENMASK(9, 7)) << 6;
+
+ /* RR0[0] = ~XOR(addr[6:0]) */
+ if (!(hweight8(addr & 0x7f) & 1))
+ ret |= 1;
+
+ return ret;
+}
+
+static int cdns_i3c_master_attach_i3c_dev(struct cdns_i3c_master *master,
+ struct i3c_device *dev)
+{
+ struct cdns_i3c_i2c_dev_data *data;
+ u32 val;
+
+ if (!master->free_dev_slots)
+ return -ENOMEM;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->id = ffs(master->free_dev_slots) - 1;
+ clear_bit(data->id, &master->free_dev_slots);
+ i3c_device_set_master_data(dev, data);
+
+ if (dev->info.dyn_addr)
+ val = prepare_rr0_dev_address(dev->info.dyn_addr) |
+ DEV_ID_RR0_IS_I3C;
+ else
+ val = prepare_rr0_dev_address(dev->info.static_addr);
+
+ if (dev->info.dcr & I3C_BCR_HDR_CAP)
+ val |= DEV_ID_RR0_HDR_CAP;
+
+ writel(val, master->regs + DEV_ID_RR0(data->id));
+ writel(DEV_ID_RR1_PID_MSB(dev->info.pid),
+ master->regs + DEV_ID_RR1(data->id));
+ writel(DEV_ID_RR2_DCR(dev->info.dcr) | DEV_ID_RR2_BCR(dev->info.bcr) |
+ DEV_ID_RR2_PID_LSB(dev->info.pid),
+ master->regs + DEV_ID_RR2(data->id));
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_ACTIVE(data->id), master->regs + DEVS_CTRL);
+
+ return 0;
+}
+
+static void cdns_i3c_master_detach_i3c_dev(struct cdns_i3c_master *master,
+ struct i3c_device *dev)
+{
+ struct cdns_i3c_i2c_dev_data *data = i3c_device_get_master_data(dev);
+
+ if (!data)
+ return;
+
+ set_bit(data->id, &master->free_dev_slots);
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_CLR(data->id), master->regs + DEVS_CTRL);
+
+ i3c_device_set_master_data(dev, NULL);
+ kfree(data);
+}
+
+static int cdns_i3c_master_attach_i2c_dev(struct cdns_i3c_master *master,
+ struct i2c_device *dev)
+{
+ struct cdns_i3c_i2c_dev_data *data;
+
+ if (!master->free_dev_slots)
+ return -ENOMEM;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->id = ffs(master->free_dev_slots) - 1;
+ clear_bit(data->id, &master->free_dev_slots);
+ i2c_device_set_master_data(dev, data);
+
+ writel(prepare_rr0_dev_address(dev->info.addr) |
+ (dev->info.flags & I2C_CLIENT_TEN ? DEV_ID_RR0_LVR_EXT_ADDR : 0),
+ master->regs + DEV_ID_RR0(data->id));
+ writel(dev->lvr, master->regs + DEV_ID_RR2(data->id));
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_ACTIVE(data->id), master->regs + DEVS_CTRL);
+
+ return 0;
+}
+
+static void cdns_i3c_master_detach_i2c_dev(struct cdns_i3c_master *master,
+ struct i2c_device *dev)
+{
+ struct cdns_i3c_i2c_dev_data *data = i2c_device_get_master_data(dev);
+
+ if (!data)
+ return;
+
+ set_bit(data->id, &master->free_dev_slots);
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_CLR(data->id),
+ master->regs + DEVS_CTRL);
+
+ i2c_device_set_master_data(dev, NULL);
+ kfree(data);
+}
+
+static int cdns_i3c_master_disable(struct cdns_i3c_master *master)
+{
+ u32 status;
+
+ writel(0, master->regs + CTRL);
+
+ return readl_poll_timeout(master->regs + MST_STATUS0, status,
+ status & MST_STATUS0_IDLE, 10, 1000000);
+}
+
+static void cdns_i3c_master_bus_cleanup(struct i3c_master_controller *m)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct i2c_device *i2cdev;
+ struct i3c_device *i3cdev;
+
+ cdns_i3c_master_disable(master);
+
+ i3c_bus_for_each_i2cdev(m->bus, i2cdev)
+ cdns_i3c_master_detach_i2c_dev(master, i2cdev);
+
+ i3c_bus_for_each_i3cdev(m->bus, i3cdev)
+ cdns_i3c_master_detach_i3c_dev(master, i3cdev);
+}
+
+static void cdns_i3c_master_dev_rr_to_info(struct cdns_i3c_master *master,
+ unsigned int slot,
+ struct i3c_device_info *info)
+{
+ u32 rr;
+
+ memset(info, 0, sizeof(info));
+ rr = readl(master->regs + DEV_ID_RR0(slot));
+ info->dyn_addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
+ rr = readl(master->regs + DEV_ID_RR2(slot));
+ info->dcr = rr;
+ info->bcr = rr >> 8;
+ info->pid = rr >> 16;
+ info->pid |= (u64)readl(master->regs + DEV_ID_RR1(slot)) << 16;
+}
+
+static int cdns_i3c_master_bus_init(struct i3c_master_controller *m)
+{
+ unsigned long pres_step, sysclk_rate, max_i2cfreq, i3c_scl_lim = 0;
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ u32 ctrl, prescl0, prescl1, pres, low;
+ struct i3c_device_info info = { };
+ struct i3c_ccc_events events;
+ struct i2c_device *i2cdev;
+ struct i3c_device *i3cdev;
+ int ret, slot, ncycles;
+ u8 last_addr = 0;
+ u32 status, devs;
+
+ switch (m->bus->mode) {
+ case I3C_BUS_MODE_PURE:
+ ctrl = CTRL_PURE_BUS_MODE;
+ break;
+
+ case I3C_BUS_MODE_MIXED_FAST:
+ ctrl = CTRL_MIXED_FAST_BUS_MODE;
+ break;
+
+ case I3C_BUS_MODE_MIXED_SLOW:
+ ctrl = CTRL_MIXED_SLOW_BUS_MODE;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ sysclk_rate = clk_get_rate(master->sysclk);
+ if (!sysclk_rate)
+ return -EINVAL;
+
+ pres = DIV_ROUND_UP(sysclk_rate, (m->bus->scl_rate.i3c * 4)) - 1;
+ if (pres > PRESCL_CTRL0_MAX)
+ return -ERANGE;
+
+ m->bus->scl_rate.i3c = sysclk_rate / ((pres + 1) * 4);
+
+ prescl0 = PRESCL_CTRL0_I3C(pres);
+
+ low = ((I3C_BUS_TLOW_OD_MIN_NS * sysclk_rate) / (pres + 1)) - 2;
+ prescl1 = PRESCL_CTRL1_OD_LOW(low);
+
+ max_i2cfreq = m->bus->scl_rate.i2c;
+
+ pres = (sysclk_rate / (max_i2cfreq * 5)) - 1;
+ if (pres > PRESCL_CTRL0_MAX)
+ return -ERANGE;
+
+ m->bus->scl_rate.i2c = sysclk_rate / ((pres + 1) * 5);
+
+ prescl0 |= PRESCL_CTRL0_I2C(pres);
+
+ writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
+
+ i3c_bus_for_each_i2cdev(m->bus, i2cdev) {
+ ret = cdns_i3c_master_attach_i2c_dev(master, i2cdev);
+ if (ret)
+ goto err_detach_devs;
+ }
+
+ writel(prescl0, master->regs + PRESCL_CTRL0);
+
+ /* Calculate OD and PP low. */
+ pres_step = 1000000000 / (m->bus->scl_rate.i3c * 4);
+ ncycles = DIV_ROUND_UP(I3C_BUS_TLOW_OD_MIN_NS, pres_step) - 2;
+ if (ncycles < 0)
+ ncycles = 0;
+ prescl1 = PRESCL_CTRL1_OD_LOW(ncycles);
+ writel(prescl1, master->regs + PRESCL_CTRL1);
+
+ i3c_bus_for_each_i3cdev(m->bus, i3cdev) {
+ ret = cdns_i3c_master_attach_i3c_dev(master, i3cdev);
+ if (ret)
+ goto err_detach_devs;
+ }
+
+ /* Get an address for the master. */
+ ret = i3c_master_get_free_addr(m, 0);
+ if (ret < 0)
+ goto err_detach_devs;
+
+ writel(prepare_rr0_dev_address(ret) | DEV_ID_RR0_IS_I3C,
+ master->regs + DEV_ID_RR0(0));
+
+ cdns_i3c_master_dev_rr_to_info(master, 0, &info);
+ if (info.bcr & I3C_BCR_HDR_CAP)
+ info.hdr_cap = I3C_CCC_HDR_MODE(I3C_HDR_DDR);
+
+ ret = i3c_master_set_info(&master->base, &info);
+ if (ret)
+ goto err_detach_devs;
+
+ /* Prepare RR slots before lauching DAA. */
+ for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
+ slot < BITS_PER_LONG;
+ slot = find_next_bit(&master->free_dev_slots,
+ BITS_PER_LONG, slot + 1)) {
+ ret = i3c_master_get_free_addr(m, last_addr + 1);
+ if (ret < 0)
+ goto err_disable_master;
+
+ last_addr = ret;
+ writel(prepare_rr0_dev_address(last_addr) | DEV_ID_RR0_IS_I3C,
+ master->regs + DEV_ID_RR0(slot));
+ writel(0, master->regs + DEV_ID_RR1(slot));
+ writel(0, master->regs + DEV_ID_RR2(slot));
+ }
+
+ writel(ctrl | CTRL_DEV_EN, master->regs + CTRL);
+
+ /*
+ * Reset all dynamic addresses on the bus, because we don't know what
+ * happened before this point (the bootloader may have assigned dynamic
+ * addresses that we're not aware of).
+ */
+ ret = i3c_master_rstdaa_locked(m, I3C_BROADCAST_ADDR);
+ if (ret)
+ goto err_disable_master;
+
+ /* Disable all slave events (interrupts) before starting DAA. */
+ events.events = I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
+ I3C_CCC_EVENT_HJ;
+ ret = i3c_master_disec_locked(m, I3C_BROADCAST_ADDR, &events);
+ if (ret)
+ goto err_disable_master;
+
+ ret = i3c_master_entdaa_locked(m);
+ if (ret)
+ goto err_disable_master;
+
+ status = readl(master->regs + MST_STATUS0);
+
+ /* No devices discovered, bail out. */
+ if (!(status & MST_STATUS0_DAA_COMP))
+ return 0;
+
+ /* Now add discovered devices to the bus. */
+ devs = readl(master->regs + DEVS_CTRL);
+ for (slot = find_next_bit(&master->free_dev_slots, BITS_PER_LONG, 1);
+ slot < BITS_PER_LONG;
+ slot = find_next_bit(&master->free_dev_slots,
+ BITS_PER_LONG, slot + 1)) {
+ struct cdns_i3c_i2c_dev_data *data;
+ u32 sircfg, rr, max_fscl = 0;
+ u8 addr;
+
+ if (!(devs & DEVS_CTRL_DEV_ACTIVE(slot)))
+ continue;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ goto err_disable_master;
+
+ data->id = slot;
+ rr = readl(master->regs + DEV_ID_RR0(slot));
+ addr = DEV_ID_RR0_GET_DEV_ADDR(rr);
+ i3cdev = i3c_master_add_i3c_dev_locked(m, addr);
+ if (IS_ERR(i3cdev)) {
+ ret = PTR_ERR(i3cdev);
+ goto err_disable_master;
+ }
+
+ i3c_device_get_info(i3cdev, &info);
+ clear_bit(data->id, &master->free_dev_slots);
+ i3c_device_set_master_data(i3cdev, data);
+
+ max_fscl = max(I3C_CCC_MAX_SDR_FSCL(info.max_read_ds),
+ I3C_CCC_MAX_SDR_FSCL(info.max_write_ds));
+ switch (max_fscl) {
+ case I3C_SDR_DR_FSCL_8MHZ:
+ max_fscl = 8000000;
+ break;
+ case I3C_SDR_DR_FSCL_6MHZ:
+ max_fscl = 6000000;
+ break;
+ case I3C_SDR_DR_FSCL_4MHZ:
+ max_fscl = 4000000;
+ break;
+ case I3C_SDR_DR_FSCL_2MHZ:
+ max_fscl = 2000000;
+ break;
+ case I3C_SDR_DR_FSCL_MAX:
+ default:
+ max_fscl = 0;
+ break;
+ }
+
+ if (max_fscl && (max_fscl < i3c_scl_lim || !i3c_scl_lim))
+ i3c_scl_lim = max_fscl;
+
+ if (!(info.bcr & I3C_BCR_IBI_REQ_CAP))
+ continue;
+
+ if ((info.bcr & I3C_BCR_IBI_PAYLOAD) &&
+ (!info.max_ibi_len ||
+ info.max_ibi_len > SIR_MAP_PL_MAX)) {
+ ret = -ENOTSUPP;
+ goto err_disable_master;
+ }
+
+ sircfg = readl(master->regs + SIR_MAP_DEV_REG(slot));
+ sircfg &= ~SIR_MAP_DEV_MASK(slot);
+ sircfg |= SIR_MAP_DEV_ROLE(slot, info.bcr >> 6) |
+ SIR_MAP_DEV_DA(slot, info.dyn_addr) |
+ SIR_MAP_DEV_PL(slot, info.max_ibi_len);
+
+ if (info.bcr & I3C_BCR_MAX_DATA_SPEED_LIM)
+ sircfg |= SIR_MAP_DEV_SLOW(slot);
+
+ /* Do not ack IBI requests until explicitly requested. */
+ writel(sircfg, master->regs + SIR_MAP_DEV_REG(slot));
+ }
+
+ ret = i3c_master_defslvs_locked(m);
+ if (ret)
+ goto err_disable_master;
+
+ /* Configure PP_LOW to meet I3C slave limitations. */
+ if (i3c_scl_lim && i3c_scl_lim < m->bus->scl_rate.i3c) {
+ unsigned long i3c_lim_period;
+
+ i3c_lim_period = DIV_ROUND_UP(1000000000, i3c_scl_lim);
+ ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step) - 4;
+ if (ncycles < 0)
+ ncycles = 0;
+ prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles);
+
+ /* Disable I3C master before updating PRESCL_CTRL1. */
+ writel(ctrl, master->regs + CTRL);
+ ret = readl_poll_timeout(master->regs + MST_STATUS0, status,
+ status & MST_STATUS0_IDLE, 1,
+ 1000000);
+ if (ret)
+ goto err_disable_master;
+
+ writel(prescl1, master->regs + PRESCL_CTRL1);
+ writel(ctrl | CTRL_DEV_EN, master->regs + CTRL);
+ }
+
+ return 0;
+
+err_disable_master:
+ cdns_i3c_master_disable(master);
+
+err_detach_devs:
+ cdns_i3c_master_bus_cleanup(m);
+
+ return ret;
+}
+
+static const struct i3c_master_controller_ops cdns_i3c_master_ops = {
+ .bus_init = cdns_i3c_master_bus_init,
+ .bus_cleanup = cdns_i3c_master_bus_cleanup,
+ .supports_ccc_cmd = cdns_i3c_master_supports_ccc_cmd,
+ .send_ccc_cmd = cdns_i3c_master_send_ccc_cmd,
+ .send_hdr_cmds = cdns_i3c_master_send_hdr_cmd,
+ .priv_xfers = cdns_i3c_master_priv_xfers,
+ .i2c_xfers = cdns_i3c_master_i2c_xfers,
+};
+
+static irqreturn_t cdns_i3c_master_interrupt(int irq, void *data)
+{
+ struct cdns_i3c_master *master = data;
+ u32 status;
+
+ status = readl(master->regs + MST_ISR) & readl(master->regs + MST_IMR);
+ if (!status)
+ return IRQ_NONE;
+
+ writel(status, master->regs + MST_IDR);
+ complete(&master->comp);
+
+ return IRQ_HANDLED;
+}
+
+static int cdns_i3c_master_probe(struct platform_device *pdev)
+{
+ struct cdns_i3c_master *master;
+ struct resource *res;
+ int ret, irq;
+ u32 val;
+
+ master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
+ if (!master)
+ return -ENOMEM;
+
+ master->caps.cmdfifodepth = 8;
+ master->caps.rxfifodepth = 16;
+ master->caps.txfifodepth = 16;
+
+ init_completion(&master->comp);
+ mutex_init(&master->lock);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ master->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(master->regs))
+ return PTR_ERR(master->regs);
+
+ master->pclk = devm_clk_get(&pdev->dev, "pclk");
+ if (IS_ERR(master->pclk))
+ return PTR_ERR(master->pclk);
+
+ master->sysclk = devm_clk_get(&pdev->dev, "sysclk");
+ if (IS_ERR(master->pclk))
+ return PTR_ERR(master->pclk);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = clk_prepare_enable(master->pclk);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(master->sysclk);
+ if (ret)
+ goto err_disable_pclk;
+
+ writel(0xffffffff, master->regs + MST_IDR);
+ writel(0xffffffff, master->regs + SLV_IDR);
+ ret = devm_request_irq(&pdev->dev, irq, cdns_i3c_master_interrupt, 0,
+ dev_name(&pdev->dev), master);
+ if (ret)
+ goto err_disable_sysclk;
+
+ platform_set_drvdata(pdev, master);
+
+ val = readl(master->regs + CONF_STATUS);
+
+ /* Device ID0 is reserved to describe this master. */
+ master->free_dev_slots = GENMASK(CONF_STATUS_DEVS_NUM(val), 1);
+
+ ret = i3c_master_register(&master->base, &pdev->dev,
+ &cdns_i3c_master_ops, false);
+ if (ret)
+ goto err_disable_sysclk;
+
+err_disable_sysclk:
+ clk_disable_unprepare(master->sysclk);
+
+err_disable_pclk:
+ clk_disable_unprepare(master->pclk);
+
+ return ret;
+}
+
+static int cdns_i3c_master_remove(struct platform_device *pdev)
+{
+ struct cdns_i3c_master *master = platform_get_drvdata(pdev);
+ int ret;
+
+ ret = i3c_master_unregister(&master->base);
+ if (ret)
+ return ret;
+
+ clk_disable_unprepare(master->sysclk);
+ clk_disable_unprepare(master->pclk);
+
+ return 0;
+}
+
+static const struct of_device_id cdns_i3c_master_of_ids[] = {
+ { .compatible = "cdns,i3c-master" },
+};
+
+static struct platform_driver cdns_i3c_master = {
+ .probe = cdns_i3c_master_probe,
+ .remove = cdns_i3c_master_remove,
+ .driver = {
+ .name = "cdns-i3c-master",
+ .of_match_table = cdns_i3c_master_of_ids,
+ },
+};
+module_platform_driver(cdns_i3c_master);
--
2.7.4
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [RFC 5/5] dt-bindings: i3c: Document Cadence I3C master bindings
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
` (3 preceding siblings ...)
2017-07-31 16:24 ` [RFC 4/5] i3c: master: Add driver for Cadence IP Boris Brezillon
@ 2017-07-31 16:24 ` Boris Brezillon
2017-07-31 19:17 ` Wolfram Sang
5 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 16:24 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann
Cc: Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Boris Brezillon
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
.../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 000000000000..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@0d040000 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d040000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-scl-frequency = <100000>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52>;
+ i3c-lvr = <0x10>;
+ };
+ };
+
--
2.7.4
^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-07-31 19:17 ` Wolfram Sang
2017-07-31 20:16 ` Arnd Bergmann
` (2 subsequent siblings)
3 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 19:17 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
> +This document is just a brief introduction to the I3C protocol and the concepts
> +it brings on the table. If you need more information, please refer to the MIPI
> +I3C specification.
I wish I could.
> +
> +Introduction
> +============
> +
> +The I3C (I-Cube-C) is a MIPI standardized protocol designed to overcome I2C
"Eye-three-See", according to:
http://eecatalog.com/sensors/2017/07/05/after-35-years-of-i2c-i3c-improves-capability-and-performance/
> +Backward compatibility with I2C devices
> +=======================================
> +
> +The I3C protocol has been designed to be backward compatible with I2C devices.
> +This backward compatibility allows one to connect a mix of I2C and I3C devices
> +on the same bus, though, in order to be really efficient, I2C devices should
> +be equipped with 50 ns spike filters.
I just found a slide which says I3C does not support clock stretching.
That should be mentioned here, too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 19:17 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 19:17 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
> +This document is just a brief introduction to the I3C protocol and the concepts
> +it brings on the table. If you need more information, please refer to the MIPI
> +I3C specification.
I wish I could.
> +
> +Introduction
> +============
> +
> +The I3C (I-Cube-C) is a MIPI standardized protocol designed to overcome I2C
"Eye-three-See", according to:
http://eecatalog.com/sensors/2017/07/05/after-35-years-of-i2c-i3c-improves-capability-and-performance/
> +Backward compatibility with I2C devices
> +=======================================
> +
> +The I3C protocol has been designed to be backward compatible with I2C devices.
> +This backward compatibility allows one to connect a mix of I2C and I3C devices
> +on the same bus, though, in order to be really efficient, I2C devices should
> +be equipped with 50 ns spike filters.
I just found a slide which says I3C does not support clock stretching.
That should be mentioned here, too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
@ 2017-07-31 19:17 ` Wolfram Sang
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
` (4 subsequent siblings)
5 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 19:17 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]
Hi Boris,
> This patch series is a proposal for a new I3C [1] subsystem.
Nice. Good luck with that!
Some hi-level comments from me related to I2C. I can't say a lot more
because the specs are not public :(
> - the bus element is a separate object and is not implicitly described
> by the master (as done in I2C). The reason is that I want to be able
> to handle multiple master connected to the same bus and visible to
> Linux.
> In this situation, we should only have one instance of the device and
> not one per master, and sharing the bus object would be part of the
> solution to gracefully handle this case.
> I'm not sure if we will ever need to deal with multiple masters
> controlling the same bus and exposed under Linux, but separating the
> bus and master concept is pretty easy, hence the decision to do it
> now, just in case we need it some day.
From my experience, it is a good thing to have this separation.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
I agree this is the least invasive and also the most compatible
approach. The other solution would probably be to have some kind of
emulation layer?
> I'd also like to get feedback on the doc. Should I detail a bit more
> the protocol or the framework API? Is this the kind of things you
> expect in a subsystem doc?
Since the spec is not public, details about the protocol will be
especially useful, I'd say.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
@ 2017-07-31 19:17 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 19:17 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]
Hi Boris,
> This patch series is a proposal for a new I3C [1] subsystem.
Nice. Good luck with that!
Some hi-level comments from me related to I2C. I can't say a lot more
because the specs are not public :(
> - the bus element is a separate object and is not implicitly described
> by the master (as done in I2C). The reason is that I want to be able
> to handle multiple master connected to the same bus and visible to
> Linux.
> In this situation, we should only have one instance of the device and
> not one per master, and sharing the bus object would be part of the
> solution to gracefully handle this case.
> I'm not sure if we will ever need to deal with multiple masters
> controlling the same bus and exposed under Linux, but separating the
> bus and master concept is pretty easy, hence the decision to do it
> now, just in case we need it some day.
From my experience, it is a good thing to have this separation.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
I agree this is the least invasive and also the most compatible
approach. The other solution would probably be to have some kind of
emulation layer?
> I'd also like to get feedback on the doc. Should I detail a bit more
> the protocol or the framework API? Is this the kind of things you
> expect in a subsystem doc?
Since the spec is not public, details about the protocol will be
especially useful, I'd say.
Regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-07-31 20:16 ` Arnd Bergmann
2017-07-31 20:16 ` Arnd Bergmann
` (2 subsequent siblings)
3 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-07-31 20:16 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Add core infrastructure to support I3C in Linux and document it.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
Can you describe the reasons for making i3c a separate subsystem then,
rather than extending the i2c subsystem to handle both i2c devices as
before and also i3c devices and hosts?
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 20:16 ` Arnd Bergmann
0 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-07-31 20:16 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Add core infrastructure to support I3C in Linux and document it.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
Can you describe the reasons for making i3c a separate subsystem then,
rather than extending the i2c subsystem to handle both i2c devices as
before and also i3c devices and hosts?
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
2017-07-31 19:17 ` Wolfram Sang
@ 2017-07-31 20:40 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 20:40 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
Hi Wolfram,
Le Mon, 31 Jul 2017 21:17:45 +0200,
Wolfram Sang <wsa@the-dreams.de> a écrit :
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public :(
Unfortunately they're not :(.
>
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure if we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > now, just in case we need it some day.
>
> From my experience, it is a good thing to have this separation.
Good to hear that you agree with this approach.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> I agree this is the least invasive and also the most compatible
> approach. The other solution would probably be to have some kind of
> emulation layer?
Could you detail a bit more what you mean by "emulation layer"?
>
> > I'd also like to get feedback on the doc. Should I detail a bit more
> > the protocol or the framework API? Is this the kind of things you
> > expect in a subsystem doc?
>
> Since the spec is not public, details about the protocol will be
> especially useful, I'd say.
Okay, I'll see what I can do.
Thanks,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
@ 2017-07-31 20:40 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 20:40 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
Hi Wolfram,
Le Mon, 31 Jul 2017 21:17:45 +0200,
Wolfram Sang <wsa@the-dreams.de> a écrit :
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public :(
Unfortunately they're not :(.
>
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure if we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > now, just in case we need it some day.
>
> From my experience, it is a good thing to have this separation.
Good to hear that you agree with this approach.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> I agree this is the least invasive and also the most compatible
> approach. The other solution would probably be to have some kind of
> emulation layer?
Could you detail a bit more what you mean by "emulation layer"?
>
> > I'd also like to get feedback on the doc. Should I detail a bit more
> > the protocol or the framework API? Is this the kind of things you
> > expect in a subsystem doc?
>
> Since the spec is not public, details about the protocol will be
> especially useful, I'd say.
Okay, I'll see what I can do.
Thanks,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 19:17 ` Wolfram Sang
@ 2017-07-31 20:46 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 20:46 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
Le Mon, 31 Jul 2017 21:17:21 +0200,
Wolfram Sang <wsa@the-dreams.de> a écrit :
> > +This document is just a brief introduction to the I3C protocol and the concepts
> > +it brings on the table. If you need more information, please refer to the MIPI
> > +I3C specification.
>
> I wish I could.
>
> > +
> > +Introduction
> > +============
> > +
> > +The I3C (I-Cube-C) is a MIPI standardized protocol designed to overcome I2C
>
> "Eye-three-See", according to:
> http://eecatalog.com/sensors/2017/07/05/after-35-years-of-i2c-i3c-improves-capability-and-performance/
I remember hearing eye-cube-see during the discussion we had with
Cadence engineers but I might wrong. I'll double check (or maybe I'll
just drop any mention of the pronunciation).
>
> > +Backward compatibility with I2C devices
> > +=======================================
> > +
> > +The I3C protocol has been designed to be backward compatible with I2C devices.
> > +This backward compatibility allows one to connect a mix of I2C and I3C devices
> > +on the same bus, though, in order to be really efficient, I2C devices should
> > +be equipped with 50 ns spike filters.
>
> I just found a slide which says I3C does not support clock stretching.
> That should be mentioned here, too.
>
You're right, clock stretching is not allowed, and if devices without a
50ns spike filter are connected to the bus, it lowers the maximum
speed for all devices, which renders I3C kind of useless.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 20:46 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 20:46 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
Le Mon, 31 Jul 2017 21:17:21 +0200,
Wolfram Sang <wsa@the-dreams.de> a écrit :
> > +This document is just a brief introduction to the I3C protocol and the concepts
> > +it brings on the table. If you need more information, please refer to the MIPI
> > +I3C specification.
>
> I wish I could.
>
> > +
> > +Introduction
> > +============
> > +
> > +The I3C (I-Cube-C) is a MIPI standardized protocol designed to overcome I2C
>
> "Eye-three-See", according to:
> http://eecatalog.com/sensors/2017/07/05/after-35-years-of-i2c-i3c-improves-capability-and-performance/
I remember hearing eye-cube-see during the discussion we had with
Cadence engineers but I might wrong. I'll double check (or maybe I'll
just drop any mention of the pronunciation).
>
> > +Backward compatibility with I2C devices
> > +=======================================
> > +
> > +The I3C protocol has been designed to be backward compatible with I2C devices.
> > +This backward compatibility allows one to connect a mix of I2C and I3C devices
> > +on the same bus, though, in order to be really efficient, I2C devices should
> > +be equipped with 50 ns spike filters.
>
> I just found a slide which says I3C does not support clock stretching.
> That should be mentioned here, too.
>
You're right, clock stretching is not allowed, and if devices without a
50ns spike filter are connected to the bus, it lowers the maximum
speed for all devices, which renders I3C kind of useless.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
2017-07-31 20:40 ` Boris Brezillon
@ 2017-07-31 20:47 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 20:47 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
> > I agree this is the least invasive and also the most compatible
> > approach. The other solution would probably be to have some kind of
> > emulation layer?
>
> Could you detail a bit more what you mean by "emulation layer"?
Not really. That was more a extremly high level approach of what
theoretically could be possible. When I try to think about details, it
gets pretty invasive.
> > Since the spec is not public, details about the protocol will be
> > especially useful, I'd say.
>
> Okay, I'll see what I can do.
Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
@ 2017-07-31 20:47 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 20:47 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
> > I agree this is the least invasive and also the most compatible
> > approach. The other solution would probably be to have some kind of
> > emulation layer?
>
> Could you detail a bit more what you mean by "emulation layer"?
Not really. That was more a extremly high level approach of what
theoretically could be possible. When I try to think about details, it
gets pretty invasive.
> > Since the spec is not public, details about the protocol will be
> > especially useful, I'd say.
>
> Okay, I'll see what I can do.
Thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 21:15 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 21:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
Hi Arnd,
Le Mon, 31 Jul 2017 22:16:42 +0200,
Arnd Bergmann <arnd@arndb.de> a écrit :
> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > Add core infrastructure to support I3C in Linux and document it.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> Can you describe the reasons for making i3c a separate subsystem then,
> rather than extending the i2c subsystem to handle both i2c devices as
> before and also i3c devices and hosts?
Actually, that's the first option I considered, but I3C and I2C are
really different. I'm not talking about the physical layer here, but
the way the bus has to be handled by the software layer. Actually, I
thing the I3C bus is philosophically closer to auto-discoverable busses
like USB than I2C or SPI.
Indeed, all I3C devices can be discovered and do not need to be
described at the board level (using DT, board files, ACPI or whatever).
Also, some I3C devices are hotpluggable, and most importantly, all I3C
devices describe themselves during the discovery procedure (called DAA
in the I3C world).
There is some kind of "device class" concept. In the I3C world it's
called DCR (Device Characteristic Register), but it plays the same role:
it's a set of generic interfaces devices have to comply with when they
declare themselves as being compatible with a DCR ID (like
accelerometer, gyroscope, or whatever). See this table of normalized
DCR for more information [1].
Devices also expose a 48-bit Provisional ID which is made of
sub-fields. Two of them are particularly interesting: the manufacturer
ID and the part ID, which are comparable to the vendor and product ID in
the USB world.
These three information (DCR, ManufacturerID and PartID) can be used to
match drivers instead of the compatible string or driver-name used for
I2C devices
So, as you can imagine, dealing with an I3C bus is really different
from dealing with an I2C bus, and I found the "expose an i2c_adapter
object for each i3c_master" way simpler (and less invasive) than
extending the I2C framework to support I3C devices.
Of course, I can move all the code in drivers/i2c/, but that won't
change the fact that I3C and I2C busses are completely different
with little to share between them.
To me, the I2C backward compatibility is just a nice feature that was
added to help people smoothly transition from mixed I3C busses with
both I2C and I3C devices connected to it (I2C devices being here
when no (affordable) equivalent exist in the I3C world) to pure I3C
busses with only I3C devices connected to it.
This being said, I'd be happy if you prove me wrong and propose a
solution that allows us to extend the I2C framework to support I3C
without to much pain ;-).
Thanks,
Boris
[1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 21:15 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-07-31 21:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Ku
Hi Arnd,
Le Mon, 31 Jul 2017 22:16:42 +0200,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> a écrit :
> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Add core infrastructure to support I3C in Linux and document it.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> Can you describe the reasons for making i3c a separate subsystem then,
> rather than extending the i2c subsystem to handle both i2c devices as
> before and also i3c devices and hosts?
Actually, that's the first option I considered, but I3C and I2C are
really different. I'm not talking about the physical layer here, but
the way the bus has to be handled by the software layer. Actually, I
thing the I3C bus is philosophically closer to auto-discoverable busses
like USB than I2C or SPI.
Indeed, all I3C devices can be discovered and do not need to be
described at the board level (using DT, board files, ACPI or whatever).
Also, some I3C devices are hotpluggable, and most importantly, all I3C
devices describe themselves during the discovery procedure (called DAA
in the I3C world).
There is some kind of "device class" concept. In the I3C world it's
called DCR (Device Characteristic Register), but it plays the same role:
it's a set of generic interfaces devices have to comply with when they
declare themselves as being compatible with a DCR ID (like
accelerometer, gyroscope, or whatever). See this table of normalized
DCR for more information [1].
Devices also expose a 48-bit Provisional ID which is made of
sub-fields. Two of them are particularly interesting: the manufacturer
ID and the part ID, which are comparable to the vendor and product ID in
the USB world.
These three information (DCR, ManufacturerID and PartID) can be used to
match drivers instead of the compatible string or driver-name used for
I2C devices
So, as you can imagine, dealing with an I3C bus is really different
from dealing with an I2C bus, and I found the "expose an i2c_adapter
object for each i3c_master" way simpler (and less invasive) than
extending the I2C framework to support I3C devices.
Of course, I can move all the code in drivers/i2c/, but that won't
change the fact that I3C and I2C busses are completely different
with little to share between them.
To me, the I2C backward compatibility is just a nice feature that was
added to help people smoothly transition from mixed I3C busses with
both I2C and I3C devices connected to it (I2C devices being here
when no (affordable) equivalent exist in the I3C world) to pure I3C
busses with only I3C devices connected to it.
This being said, I'd be happy if you prove me wrong and propose a
solution that allows us to extend the I2C framework to support I3C
without to much pain ;-).
Thanks,
Boris
[1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 21:15 ` Boris Brezillon
@ 2017-07-31 21:32 ` Peter Rosin
-1 siblings, 0 replies; 91+ messages in thread
From: Peter Rosin @ 2017-07-31 21:32 UTC (permalink / raw)
To: Boris Brezillon, Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On 2017-07-31 23:15, Boris Brezillon wrote:
> [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
Stupid non-programmers...
This part
65 41 01000001 Accelerometer
66 42 01000010 Gyroscope
67 43 01000011 Magnetometer
68 44 01000100 Accel/Gyro Combo
69 45 01000101 Accel/Mag Combo
70 46 01000110 Accel/Gyro/Mag Combo
should *obviously* have been something like
65 41 01000001 Accelerometer
66 42 01000010 Gyroscope
67 43 01000011 Accel/Gyro Combo
68 44 01000100 Magnetometer
69 45 01000101 Accel/Mag Combo
71 47 01000111 Accel/Gyro/Mag Combo
Cheers,
peda
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 21:32 ` Peter Rosin
0 siblings, 0 replies; 91+ messages in thread
From: Peter Rosin @ 2017-07-31 21:32 UTC (permalink / raw)
To: Boris Brezillon, Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On 2017-07-31 23:15, Boris Brezillon wrote:
> [1]https://www.mipi.org/MIPI_I3C_device_characteristics_register
Stupid non-programmers...
This part
65 41 01000001 Accelerometer
66 42 01000010 Gyroscope
67 43 01000011 Magnetometer
68 44 01000100 Accel/Gyro Combo
69 45 01000101 Accel/Mag Combo
70 46 01000110 Accel/Gyro/Mag Combo
should *obviously* have been something like
65 41 01000001 Accelerometer
66 42 01000010 Gyroscope
67 43 01000011 Accel/Gyro Combo
68 44 01000100 Magnetometer
69 45 01000101 Accel/Mag Combo
71 47 01000111 Accel/Gyro/Mag Combo
Cheers,
peda
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 21:15 ` Boris Brezillon
@ 2017-07-31 21:42 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 21:42 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB than I2C or SPI.
Acked-by: Wolfram Sang <wsa@the-dreams.de>
> Of course, I can move all the code in drivers/i2c/, but that won't
> change the fact that I3C and I2C busses are completely different
> with little to share between them.
That wouldn't make sense.
> To me, the I2C backward compatibility is just a nice feature that was
> added to help people smoothly transition from mixed I3C busses with
> both I2C and I3C devices connected to it (I2C devices being here
> when no (affordable) equivalent exist in the I3C world) to pure I3C
> busses with only I3C devices connected to it.
Yeah, and it is still to be seen how good this really works. Devices
which do clock stretching are out of the question. Probably everything
which needs an interrupt as well?
> This being said, I'd be happy if you prove me wrong and propose a
> solution that allows us to extend the I2C framework to support I3C
> without to much pain ;-).
From all I know, I don't see that coming.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-07-31 21:42 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-07-31 21:42 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB than I2C or SPI.
Acked-by: Wolfram Sang <wsa@the-dreams.de>
> Of course, I can move all the code in drivers/i2c/, but that won't
> change the fact that I3C and I2C busses are completely different
> with little to share between them.
That wouldn't make sense.
> To me, the I2C backward compatibility is just a nice feature that was
> added to help people smoothly transition from mixed I3C busses with
> both I2C and I3C devices connected to it (I2C devices being here
> when no (affordable) equivalent exist in the I3C world) to pure I3C
> busses with only I3C devices connected to it.
Yeah, and it is still to be seen how good this really works. Devices
which do clock stretching are out of the question. Probably everything
which needs an interrupt as well?
> This being said, I'd be happy if you prove me wrong and propose a
> solution that allows us to extend the I2C framework to support I3C
> without to much pain ;-).
From all I know, I don't see that coming.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-08-01 1:40 ` Greg Kroah-Hartman
2017-07-31 20:16 ` Arnd Bergmann
` (2 subsequent siblings)
3 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-01 1:40 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> Add core infrastructure to support I3C in Linux and document it.
>
> This infrastructure is not complete yet and will be extended over
> time.
>
> There are a few design choices that are worth mentioning because they
> impact the way I3C device drivers can interact with their devices:
>
> - all functions used to send I3C/I2C frames must be called in
> non-atomic context. Mainly done this way to ease implementation, but
> this is still open to discussion. Please let me know if you think it's
> worth considering an asynchronous model here
> - the bus element is a separate object and is not implicitly described
> by the master (as done in I2C). The reason is that I want to be able
> to handle multiple master connected to the same bus and visible to
> Linux.
> In this situation, we should only have one instance of the device and
> not one per master, and sharing the bus object would be part of the
> solution to gracefully handle this case.
> I'm not sure we will ever need to deal with multiple masters
> controlling the same bus and exposed under Linux, but separating the
> bus and master concept is pretty easy, hence the decision to do it
> like that.
> The other benefit of separating the bus and master concepts is that
> master devices appear under the bus directory in sysfs.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
> - the whole API is exposed through a single header file (i3c.h), but I'm
> seriously considering the option of splitting the I3C driver/user API
> and the I3C master one, mainly to hide I3C core internals and restrict
> what I3C users can do to a limited set of functionalities (send
> I3C/I2C frames to a specific device and that's all).
>
> Missing features in this preliminary version:
> - no support for IBI (In Band Interrupts). This is something I'm working
> on, and I'm still unsure how to represent it: an irqchip or a
> completely independent representation that would be I3C specific.
> Right now, I'm more inclined to go for the irqchip approach, since
> this is something people are used to deal with already.
> - no Hot Join support, which is similar to hotplug
> - no support for multi-master and the associated concepts (mastership
> handover, support for secondary masters, ...)
> - I2C devices can only be described using DT because this is the only
> use case I have. However, the framework can easily be extended with
> ACPI and board info support
> - I3C slave framework. This has been completely omitted, but shouldn't
> have a huge impact on the I3C framework because I3C slaves don't see
> the whole bus, it's only about handling master requests and generating
> IBIs. Some of the struct, constant and enum definitions could be
> shared, but most of the I3C slave framework logic will be different
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/i3c/conf.py | 10 +
> Documentation/i3c/device-driver-api.rst | 7 +
> Documentation/i3c/index.rst | 9 +
> Documentation/i3c/master-driver-api.rst | 8 +
> Documentation/i3c/protocol.rst | 199 +++++
> Documentation/index.rst | 1 +
> drivers/Kconfig | 2 +
> drivers/Makefile | 2 +-
> drivers/i3c/Kconfig | 24 +
> drivers/i3c/Makefile | 3 +
> drivers/i3c/core.c | 532 ++++++++++++++
> drivers/i3c/device.c | 138 ++++
> drivers/i3c/internals.h | 45 ++
> drivers/i3c/master.c | 1225 +++++++++++++++++++++++++++++++
> drivers/i3c/master/Kconfig | 0
> drivers/i3c/master/Makefile | 0
> include/linux/i3c/ccc.h | 389 ++++++++++
> include/linux/i3c/device.h | 212 ++++++
> include/linux/i3c/master.h | 453 ++++++++++++
> include/linux/mod_devicetable.h | 15 +
> 20 files changed, 3273 insertions(+), 1 deletion(-)
Any chance you can break the documentation out from this patch to make
it smaller and a bit simpler to review?
Here's a few random review comments, I have only glanced at this, not
done any real reading of this at all...
> +menu "I3C support"
> +
> +config I3C
> + tristate "I3C support"
> + ---help---
> + I3C (pronounce: I-cube-C) is a serial protocol standardized by the
> + MIPI alliance.
> +
> + It's supposed to be backward compatible with I2C while providing
> + support for high speed transfers and native interrupt support
> + without the need for extra pins.
> +
> + The I3C protocol also standardizes the slave device types and is
> + mainly design to communicate with sensors.
> +
> + If you want I3C support, you should say Y here and also to the
> + specific driver for your bus adapter(s) below.
> +
> + This I3C support can also be built as a module. If so, the module
> + will be called i3c.
> +
> +source "drivers/i3c/master/Kconfig"
Don't source unless i3c is enabled, right?
> +
> +endmenu
> diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
> new file mode 100644
> index 000000000000..0605a275f47b
> --- /dev/null
> +++ b/drivers/i3c/Makefile
> @@ -0,0 +1,3 @@
> +i3c-y := core.o device.o master.o
> +obj-$(CONFIG_I3C) += i3c.o
> +obj-$(CONFIG_I3C) += master/
> diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> new file mode 100644
> index 000000000000..c000fb458547
> --- /dev/null
> +++ b/drivers/i3c/core.c
> @@ -0,0 +1,532 @@
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
I have to ask, do you really mean "or any later version"?
> +static DEFINE_IDR(i3c_bus_idr);
You never clean this up when the module goes away :(
> +static DEFINE_MUTEX(i3c_core_lock);
> +
> +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> +{
> + if (exclusive)
> + down_write(&bus->lock);
> + else
> + down_read(&bus->lock);
> +}
The "exclusive" flag is odd, and messy, and hard to understand, don't
you agree? And have you measured the difference in using a rw lock over
a normal mutex and found it to be faster? If not, just use a normal
mutex, it's simpler and almost always better in the end.
> +
> +void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive)
> +{
> + if (exclusive)
> + up_write(&bus->lock);
> + else
> + up_read(&bus->lock);
> +}
> +
> +static ssize_t bcr_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(bcr);
> +
> +static ssize_t dcr_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(dcr);
> +
> +static ssize_t pid_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(pid);
No Documentation/ABI entries for all of these sysfs files?
> +
> +static ssize_t address_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(address);
> +
> +static const char * const hdrcap_strings[] = {
> + "hdr-ddr", "hdr-tsp", "hdr-tsl",
> +};
> +
> +static ssize_t hdrcap_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + unsigned long caps = i3cdev->info.hdr_cap;
> + ssize_t offset = 0, ret;
> + int mode;
> +
> + i3c_bus_lock(bus, false);
> + for_each_set_bit(mode, &caps, 8) {
> + if (mode >= ARRAY_SIZE(hdrcap_strings))
> + break;
> +
> + if (!hdrcap_strings[mode])
> + continue;
> +
> + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
Multiple lines in a single sysfs file? No.
> + if (ret < 0)
> + goto out;
> +
> + offset += ret;
> + }
> + ret = offset;
> +
> +out:
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(hdrcap);
> +
> +static struct attribute *i3c_device_attrs[] = {
> + &dev_attr_bcr.attr,
> + &dev_attr_dcr.attr,
> + &dev_attr_pid.attr,
> + &dev_attr_address.attr,
> + &dev_attr_hdrcap.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group i3c_device_group = {
> + .attrs = i3c_device_attrs,
> +};
> +
> +static const struct attribute_group *i3c_device_groups[] = {
> + &i3c_device_group,
> + NULL,
> +};
ATTRIBUTE_GROUPS()?
> +
> +static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> + u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> +
> + if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
> + return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
> + i3cdev->info.dcr, manuf);
> +
> + return add_uevent_var(env,
> + "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
> + i3cdev->info.dcr, manuf, part, ext);
> +}
> +
> +const struct device_type i3c_device_type = {
> + .groups = i3c_device_groups,
> + .uevent = i3c_device_uevent,
> +};
No release type? Oh that's bad bad bad and implies you have never
removed a device from your system as the kernel would have complained
loudly at you.
> +
> +static const struct attribute_group *i3c_master_groups[] = {
> + &i3c_device_group,
> + NULL,
> +};
ATTRIBUTE_GROUPS()?
> +
> +const struct device_type i3c_master_type = {
> + .groups = i3c_master_groups,
> +};
> +
> +static const char * const i3c_bus_mode_strings[] = {
> + [I3C_BUS_MODE_PURE] = "pure",
> + [I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
> + [I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
> +};
> +
> +static ssize_t mode_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + if (i3cbus->mode < 0 ||
> + i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
> + !i3c_bus_mode_strings[i3cbus->mode])
> + ret = sprintf(buf, "unknown\n");
> + else
> + ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(mode);
> +
> +static ssize_t current_master_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(current_master);
> +
> +static ssize_t i3c_scl_frequency_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i3c_scl_frequency);
> +
> +static ssize_t i2c_scl_frequency_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i2c_scl_frequency);
> +
> +static struct attribute *i3c_busdev_attrs[] = {
> + &dev_attr_mode.attr,
> + &dev_attr_current_master.attr,
> + &dev_attr_i3c_scl_frequency.attr,
> + &dev_attr_i2c_scl_frequency.attr,
> + NULL,
> +};
> +ATTRIBUTE_GROUPS(i3c_busdev);
Yeah, you used it here!
that's all the time I have right now...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 1:40 ` Greg Kroah-Hartman
0 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-01 1:40 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> Add core infrastructure to support I3C in Linux and document it.
>
> This infrastructure is not complete yet and will be extended over
> time.
>
> There are a few design choices that are worth mentioning because they
> impact the way I3C device drivers can interact with their devices:
>
> - all functions used to send I3C/I2C frames must be called in
> non-atomic context. Mainly done this way to ease implementation, but
> this is still open to discussion. Please let me know if you think it's
> worth considering an asynchronous model here
> - the bus element is a separate object and is not implicitly described
> by the master (as done in I2C). The reason is that I want to be able
> to handle multiple master connected to the same bus and visible to
> Linux.
> In this situation, we should only have one instance of the device and
> not one per master, and sharing the bus object would be part of the
> solution to gracefully handle this case.
> I'm not sure we will ever need to deal with multiple masters
> controlling the same bus and exposed under Linux, but separating the
> bus and master concept is pretty easy, hence the decision to do it
> like that.
> The other benefit of separating the bus and master concepts is that
> master devices appear under the bus directory in sysfs.
> - I2C backward compatibility has been designed to be transparent to I2C
> drivers and the I2C subsystem. The I3C master just registers an I2C
> adapter which creates a new I2C bus. I'd say that, from a
> representation PoV it's not ideal because what should appear as a
> single I3C bus exposing I3C and I2C devices here appears as 2
> different busses connected to each other through the parenting (the
> I3C master is the parent of the I2C and I3C busses).
> On the other hand, I don't see a better solution if we want something
> that is not invasive.
> - the whole API is exposed through a single header file (i3c.h), but I'm
> seriously considering the option of splitting the I3C driver/user API
> and the I3C master one, mainly to hide I3C core internals and restrict
> what I3C users can do to a limited set of functionalities (send
> I3C/I2C frames to a specific device and that's all).
>
> Missing features in this preliminary version:
> - no support for IBI (In Band Interrupts). This is something I'm working
> on, and I'm still unsure how to represent it: an irqchip or a
> completely independent representation that would be I3C specific.
> Right now, I'm more inclined to go for the irqchip approach, since
> this is something people are used to deal with already.
> - no Hot Join support, which is similar to hotplug
> - no support for multi-master and the associated concepts (mastership
> handover, support for secondary masters, ...)
> - I2C devices can only be described using DT because this is the only
> use case I have. However, the framework can easily be extended with
> ACPI and board info support
> - I3C slave framework. This has been completely omitted, but shouldn't
> have a huge impact on the I3C framework because I3C slaves don't see
> the whole bus, it's only about handling master requests and generating
> IBIs. Some of the struct, constant and enum definitions could be
> shared, but most of the I3C slave framework logic will be different
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/i3c/conf.py | 10 +
> Documentation/i3c/device-driver-api.rst | 7 +
> Documentation/i3c/index.rst | 9 +
> Documentation/i3c/master-driver-api.rst | 8 +
> Documentation/i3c/protocol.rst | 199 +++++
> Documentation/index.rst | 1 +
> drivers/Kconfig | 2 +
> drivers/Makefile | 2 +-
> drivers/i3c/Kconfig | 24 +
> drivers/i3c/Makefile | 3 +
> drivers/i3c/core.c | 532 ++++++++++++++
> drivers/i3c/device.c | 138 ++++
> drivers/i3c/internals.h | 45 ++
> drivers/i3c/master.c | 1225 +++++++++++++++++++++++++++++++
> drivers/i3c/master/Kconfig | 0
> drivers/i3c/master/Makefile | 0
> include/linux/i3c/ccc.h | 389 ++++++++++
> include/linux/i3c/device.h | 212 ++++++
> include/linux/i3c/master.h | 453 ++++++++++++
> include/linux/mod_devicetable.h | 15 +
> 20 files changed, 3273 insertions(+), 1 deletion(-)
Any chance you can break the documentation out from this patch to make
it smaller and a bit simpler to review?
Here's a few random review comments, I have only glanced at this, not
done any real reading of this at all...
> +menu "I3C support"
> +
> +config I3C
> + tristate "I3C support"
> + ---help---
> + I3C (pronounce: I-cube-C) is a serial protocol standardized by the
> + MIPI alliance.
> +
> + It's supposed to be backward compatible with I2C while providing
> + support for high speed transfers and native interrupt support
> + without the need for extra pins.
> +
> + The I3C protocol also standardizes the slave device types and is
> + mainly design to communicate with sensors.
> +
> + If you want I3C support, you should say Y here and also to the
> + specific driver for your bus adapter(s) below.
> +
> + This I3C support can also be built as a module. If so, the module
> + will be called i3c.
> +
> +source "drivers/i3c/master/Kconfig"
Don't source unless i3c is enabled, right?
> +
> +endmenu
> diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
> new file mode 100644
> index 000000000000..0605a275f47b
> --- /dev/null
> +++ b/drivers/i3c/Makefile
> @@ -0,0 +1,3 @@
> +i3c-y := core.o device.o master.o
> +obj-$(CONFIG_I3C) += i3c.o
> +obj-$(CONFIG_I3C) += master/
> diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> new file mode 100644
> index 000000000000..c000fb458547
> --- /dev/null
> +++ b/drivers/i3c/core.c
> @@ -0,0 +1,532 @@
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the Free
> + * Software Foundation; either version 2 of the License, or (at your option)
> + * any later version.
I have to ask, do you really mean "or any later version"?
> +static DEFINE_IDR(i3c_bus_idr);
You never clean this up when the module goes away :(
> +static DEFINE_MUTEX(i3c_core_lock);
> +
> +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> +{
> + if (exclusive)
> + down_write(&bus->lock);
> + else
> + down_read(&bus->lock);
> +}
The "exclusive" flag is odd, and messy, and hard to understand, don't
you agree? And have you measured the difference in using a rw lock over
a normal mutex and found it to be faster? If not, just use a normal
mutex, it's simpler and almost always better in the end.
> +
> +void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive)
> +{
> + if (exclusive)
> + up_write(&bus->lock);
> + else
> + up_read(&bus->lock);
> +}
> +
> +static ssize_t bcr_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(bcr);
> +
> +static ssize_t dcr_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(dcr);
> +
> +static ssize_t pid_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(pid);
No Documentation/ABI entries for all of these sysfs files?
> +
> +static ssize_t address_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + ssize_t ret;
> +
> + i3c_bus_lock(bus, false);
> + ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(address);
> +
> +static const char * const hdrcap_strings[] = {
> + "hdr-ddr", "hdr-tsp", "hdr-tsl",
> +};
> +
> +static ssize_t hdrcap_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> + unsigned long caps = i3cdev->info.hdr_cap;
> + ssize_t offset = 0, ret;
> + int mode;
> +
> + i3c_bus_lock(bus, false);
> + for_each_set_bit(mode, &caps, 8) {
> + if (mode >= ARRAY_SIZE(hdrcap_strings))
> + break;
> +
> + if (!hdrcap_strings[mode])
> + continue;
> +
> + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
Multiple lines in a single sysfs file? No.
> + if (ret < 0)
> + goto out;
> +
> + offset += ret;
> + }
> + ret = offset;
> +
> +out:
> + i3c_bus_unlock(bus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(hdrcap);
> +
> +static struct attribute *i3c_device_attrs[] = {
> + &dev_attr_bcr.attr,
> + &dev_attr_dcr.attr,
> + &dev_attr_pid.attr,
> + &dev_attr_address.attr,
> + &dev_attr_hdrcap.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group i3c_device_group = {
> + .attrs = i3c_device_attrs,
> +};
> +
> +static const struct attribute_group *i3c_device_groups[] = {
> + &i3c_device_group,
> + NULL,
> +};
ATTRIBUTE_GROUPS()?
> +
> +static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> + u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> +
> + if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
> + return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
> + i3cdev->info.dcr, manuf);
> +
> + return add_uevent_var(env,
> + "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
> + i3cdev->info.dcr, manuf, part, ext);
> +}
> +
> +const struct device_type i3c_device_type = {
> + .groups = i3c_device_groups,
> + .uevent = i3c_device_uevent,
> +};
No release type? Oh that's bad bad bad and implies you have never
removed a device from your system as the kernel would have complained
loudly at you.
> +
> +static const struct attribute_group *i3c_master_groups[] = {
> + &i3c_device_group,
> + NULL,
> +};
ATTRIBUTE_GROUPS()?
> +
> +const struct device_type i3c_master_type = {
> + .groups = i3c_master_groups,
> +};
> +
> +static const char * const i3c_bus_mode_strings[] = {
> + [I3C_BUS_MODE_PURE] = "pure",
> + [I3C_BUS_MODE_MIXED_FAST] = "mixed-fast",
> + [I3C_BUS_MODE_MIXED_SLOW] = "mixed-slow",
> +};
> +
> +static ssize_t mode_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + if (i3cbus->mode < 0 ||
> + i3cbus->mode > ARRAY_SIZE(i3c_bus_mode_strings) ||
> + !i3c_bus_mode_strings[i3cbus->mode])
> + ret = sprintf(buf, "unknown\n");
> + else
> + ret = sprintf(buf, "%s\n", i3c_bus_mode_strings[i3cbus->mode]);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(mode);
> +
> +static ssize_t current_master_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%s\n", dev_name(&i3cbus->cur_master->dev));
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(current_master);
> +
> +static ssize_t i3c_scl_frequency_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i3c_scl_frequency);
> +
> +static ssize_t i2c_scl_frequency_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_bus *i3cbus = container_of(dev, struct i3c_bus, dev);
> + ssize_t ret;
> +
> + i3c_bus_lock(i3cbus, false);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> + i3c_bus_unlock(i3cbus, false);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(i2c_scl_frequency);
> +
> +static struct attribute *i3c_busdev_attrs[] = {
> + &dev_attr_mode.attr,
> + &dev_attr_current_master.attr,
> + &dev_attr_i3c_scl_frequency.attr,
> + &dev_attr_i2c_scl_frequency.attr,
> + NULL,
> +};
> +ATTRIBUTE_GROUPS(i3c_busdev);
Yeah, you used it here!
that's all the time I have right now...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 10:48 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 10:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
Hello Greg,
On Mon, 31 Jul 2017 18:40:21 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> > Add core infrastructure to support I3C in Linux and document it.
> >
> > This infrastructure is not complete yet and will be extended over
> > time.
> >
> > There are a few design choices that are worth mentioning because they
> > impact the way I3C device drivers can interact with their devices:
> >
> > - all functions used to send I3C/I2C frames must be called in
> > non-atomic context. Mainly done this way to ease implementation, but
> > this is still open to discussion. Please let me know if you think it's
> > worth considering an asynchronous model here
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > like that.
> > The other benefit of separating the bus and master concepts is that
> > master devices appear under the bus directory in sysfs.
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
> > - the whole API is exposed through a single header file (i3c.h), but I'm
> > seriously considering the option of splitting the I3C driver/user API
> > and the I3C master one, mainly to hide I3C core internals and restrict
> > what I3C users can do to a limited set of functionalities (send
> > I3C/I2C frames to a specific device and that's all).
> >
> > Missing features in this preliminary version:
> > - no support for IBI (In Band Interrupts). This is something I'm working
> > on, and I'm still unsure how to represent it: an irqchip or a
> > completely independent representation that would be I3C specific.
> > Right now, I'm more inclined to go for the irqchip approach, since
> > this is something people are used to deal with already.
> > - no Hot Join support, which is similar to hotplug
> > - no support for multi-master and the associated concepts (mastership
> > handover, support for secondary masters, ...)
> > - I2C devices can only be described using DT because this is the only
> > use case I have. However, the framework can easily be extended with
> > ACPI and board info support
> > - I3C slave framework. This has been completely omitted, but shouldn't
> > have a huge impact on the I3C framework because I3C slaves don't see
> > the whole bus, it's only about handling master requests and generating
> > IBIs. Some of the struct, constant and enum definitions could be
> > shared, but most of the I3C slave framework logic will be different
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > Documentation/i3c/conf.py | 10 +
> > Documentation/i3c/device-driver-api.rst | 7 +
> > Documentation/i3c/index.rst | 9 +
> > Documentation/i3c/master-driver-api.rst | 8 +
> > Documentation/i3c/protocol.rst | 199 +++++
> > Documentation/index.rst | 1 +
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 2 +-
> > drivers/i3c/Kconfig | 24 +
> > drivers/i3c/Makefile | 3 +
> > drivers/i3c/core.c | 532 ++++++++++++++
> > drivers/i3c/device.c | 138 ++++
> > drivers/i3c/internals.h | 45 ++
> > drivers/i3c/master.c | 1225 +++++++++++++++++++++++++++++++
> > drivers/i3c/master/Kconfig | 0
> > drivers/i3c/master/Makefile | 0
> > include/linux/i3c/ccc.h | 389 ++++++++++
> > include/linux/i3c/device.h | 212 ++++++
> > include/linux/i3c/master.h | 453 ++++++++++++
> > include/linux/mod_devicetable.h | 15 +
> > 20 files changed, 3273 insertions(+), 1 deletion(-)
>
> Any chance you can break the documentation out from this patch to make
> it smaller and a bit simpler to review?
Sure. I'll put the doc and code in 2 different commits.
>
> Here's a few random review comments, I have only glanced at this, not
> done any real reading of this at all...
>
> > +menu "I3C support"
> > +
> > +config I3C
> > + tristate "I3C support"
> > + ---help---
> > + I3C (pronounce: I-cube-C) is a serial protocol standardized by the
> > + MIPI alliance.
> > +
> > + It's supposed to be backward compatible with I2C while providing
> > + support for high speed transfers and native interrupt support
> > + without the need for extra pins.
> > +
> > + The I3C protocol also standardizes the slave device types and is
> > + mainly design to communicate with sensors.
> > +
> > + If you want I3C support, you should say Y here and also to the
> > + specific driver for your bus adapter(s) below.
> > +
> > + This I3C support can also be built as a module. If so, the module
> > + will be called i3c.
> > +
> > +source "drivers/i3c/master/Kconfig"
>
> Don't source unless i3c is enabled, right?
Right, I'll also switch to menuconfig instead of menu+config.
>
> > +
> > +endmenu
> > diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
> > new file mode 100644
> > index 000000000000..0605a275f47b
> > --- /dev/null
> > +++ b/drivers/i3c/Makefile
> > @@ -0,0 +1,3 @@
> > +i3c-y := core.o device.o master.o
> > +obj-$(CONFIG_I3C) += i3c.o
> > +obj-$(CONFIG_I3C) += master/
> > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> > new file mode 100644
> > index 000000000000..c000fb458547
> > --- /dev/null
> > +++ b/drivers/i3c/core.c
> > @@ -0,0 +1,532 @@
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon@free-electrons.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License as published by the Free
> > + * Software Foundation; either version 2 of the License, or (at your option)
> > + * any later version.
>
> I have to ask, do you really mean "or any later version"?
I'll ask Cadence.
>
> > +static DEFINE_IDR(i3c_bus_idr);
>
> You never clean this up when the module goes away :(
I'll call idr_destroy() in i3c_exit().
>
> > +static DEFINE_MUTEX(i3c_core_lock);
> > +
> > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > +{
> > + if (exclusive)
> > + down_write(&bus->lock);
> > + else
> > + down_read(&bus->lock);
> > +}
>
> The "exclusive" flag is odd, and messy, and hard to understand, don't
> you agree?
I could create 2 functions, one for the exclusive lock and the other
one for the shared lock.
> And have you measured the difference in using a rw lock over
> a normal mutex and found it to be faster? If not, just use a normal
> mutex, it's simpler and almost always better in the end.
I did not measure the difference, but using a standard lock means
serializing all I3C accesses going through a given master in the core.
Note that this lock is not here to guarantee that calls to
master->ops->xxx() are serialized (this part is left to the master
driver), but to ensure that when a bus management operation is in
progress (like changing the address of a device on the bus), no one can
send I3C frames. If we don't do that, one could queue an I3C transfer,
and by the time this transfer reach the bus, the I3C device this
message was targeting may have a different address.
Unless you see a good reason to not use a R/W lock, I'd like to keep it
this way because master IPs are likely to implement advanced queuing
mechanism (allows one to queue new transfers even if the master is
already busy processing other requests), and serializing things at the
framework level will just prevent us from using this kind of
optimization.
>
> > +
> > +void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive)
> > +{
> > + if (exclusive)
> > + up_write(&bus->lock);
> > + else
> > + up_read(&bus->lock);
> > +}
> > +
> > +static ssize_t bcr_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(bcr);
> > +
> > +static ssize_t dcr_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(dcr);
> > +
> > +static ssize_t pid_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(pid);
>
> No Documentation/ABI entries for all of these sysfs files?
Yep, I mentioned the lack of sysfs doc in my cover letter. Will address
that in v2.
>
> > +
> > +static ssize_t address_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(address);
> > +
> > +static const char * const hdrcap_strings[] = {
> > + "hdr-ddr", "hdr-tsp", "hdr-tsl",
> > +};
> > +
> > +static ssize_t hdrcap_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + unsigned long caps = i3cdev->info.hdr_cap;
> > + ssize_t offset = 0, ret;
> > + int mode;
> > +
> > + i3c_bus_lock(bus, false);
> > + for_each_set_bit(mode, &caps, 8) {
> > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > + break;
> > +
> > + if (!hdrcap_strings[mode])
> > + continue;
> > +
> > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
>
> Multiple lines in a single sysfs file? No.
Okay. Would that be okay with a different separator (like a comma)?
>
> > + if (ret < 0)
> > + goto out;
> > +
> > + offset += ret;
> > + }
> > + ret = offset;
> > +
> > +out:
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(hdrcap);
> > +
> > +static struct attribute *i3c_device_attrs[] = {
> > + &dev_attr_bcr.attr,
> > + &dev_attr_dcr.attr,
> > + &dev_attr_pid.attr,
> > + &dev_attr_address.attr,
> > + &dev_attr_hdrcap.attr,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group i3c_device_group = {
> > + .attrs = i3c_device_attrs,
> > +};
> > +
> > +static const struct attribute_group *i3c_device_groups[] = {
> > + &i3c_device_group,
> > + NULL,
> > +};
>
> ATTRIBUTE_GROUPS()?
My initial plan was to have a common set of attributes that apply to
both devices and masters, and then add specific attributes in each of
them when they only apply to a specific device type.
Something like:
static const struct attribute_group i3c_common_group = {
.attrs = i3c_common_attrs,
};
static const struct attribute_group i3c_device_group = {
.attrs = i3c_device_attrs,
};
static const struct attribute_group *i3c_device_groups[] = {
&i3c_common_group,
&i3c_device_group,
NULL,
};
static const struct attribute_group i3c_master_group = {
.attrs = i3c_master_attrs,
};
static const struct attribute_group *i3c_master_groups[] = {
&i3c_common_group,
&i3c_master_group,
NULL,
};
It turned out I didn't have device or master specific attributes in this
version, so this differentiation is useless right now. I'll drop that
in my v2.
Just out of curiosity, what's the preferred solution when you need to
do something like that? Should we just use ATTRIBUTE_GROUPS() and
duplicate the entries that apply to both device types?
>
>
> > +
> > +static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > + u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > +
> > + if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
> > + return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
> > + i3cdev->info.dcr, manuf);
> > +
> > + return add_uevent_var(env,
> > + "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
> > + i3cdev->info.dcr, manuf, part, ext);
> > +}
> > +
> > +const struct device_type i3c_device_type = {
> > + .groups = i3c_device_groups,
> > + .uevent = i3c_device_uevent,
> > +};
>
> No release type? Oh that's bad bad bad and implies you have never
> removed a device from your system as the kernel would have complained
> loudly at you.
You got me, never tried to remove a device :-). Note that these
->release() hooks will just be dummy ones, because right now, device
resources are freed at bus destruction time.
Also, I see that dev->release() is called instead of
dev->type->release() if it's not NULL [1]. what's the preferred solution
here? Set dev->release or type->release()?
Thanks for your review,
Boris
[1]http://elixir.free-electrons.com/linux/v4.13-rc3/source/drivers/base/core.c#L809
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 10:48 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 10:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Hello Greg,
On Mon, 31 Jul 2017 18:40:21 -0700
Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Mon, Jul 31, 2017 at 06:24:47PM +0200, Boris Brezillon wrote:
> > Add core infrastructure to support I3C in Linux and document it.
> >
> > This infrastructure is not complete yet and will be extended over
> > time.
> >
> > There are a few design choices that are worth mentioning because they
> > impact the way I3C device drivers can interact with their devices:
> >
> > - all functions used to send I3C/I2C frames must be called in
> > non-atomic context. Mainly done this way to ease implementation, but
> > this is still open to discussion. Please let me know if you think it's
> > worth considering an asynchronous model here
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > like that.
> > The other benefit of separating the bus and master concepts is that
> > master devices appear under the bus directory in sysfs.
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
> > - the whole API is exposed through a single header file (i3c.h), but I'm
> > seriously considering the option of splitting the I3C driver/user API
> > and the I3C master one, mainly to hide I3C core internals and restrict
> > what I3C users can do to a limited set of functionalities (send
> > I3C/I2C frames to a specific device and that's all).
> >
> > Missing features in this preliminary version:
> > - no support for IBI (In Band Interrupts). This is something I'm working
> > on, and I'm still unsure how to represent it: an irqchip or a
> > completely independent representation that would be I3C specific.
> > Right now, I'm more inclined to go for the irqchip approach, since
> > this is something people are used to deal with already.
> > - no Hot Join support, which is similar to hotplug
> > - no support for multi-master and the associated concepts (mastership
> > handover, support for secondary masters, ...)
> > - I2C devices can only be described using DT because this is the only
> > use case I have. However, the framework can easily be extended with
> > ACPI and board info support
> > - I3C slave framework. This has been completely omitted, but shouldn't
> > have a huge impact on the I3C framework because I3C slaves don't see
> > the whole bus, it's only about handling master requests and generating
> > IBIs. Some of the struct, constant and enum definitions could be
> > shared, but most of the I3C slave framework logic will be different
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Documentation/i3c/conf.py | 10 +
> > Documentation/i3c/device-driver-api.rst | 7 +
> > Documentation/i3c/index.rst | 9 +
> > Documentation/i3c/master-driver-api.rst | 8 +
> > Documentation/i3c/protocol.rst | 199 +++++
> > Documentation/index.rst | 1 +
> > drivers/Kconfig | 2 +
> > drivers/Makefile | 2 +-
> > drivers/i3c/Kconfig | 24 +
> > drivers/i3c/Makefile | 3 +
> > drivers/i3c/core.c | 532 ++++++++++++++
> > drivers/i3c/device.c | 138 ++++
> > drivers/i3c/internals.h | 45 ++
> > drivers/i3c/master.c | 1225 +++++++++++++++++++++++++++++++
> > drivers/i3c/master/Kconfig | 0
> > drivers/i3c/master/Makefile | 0
> > include/linux/i3c/ccc.h | 389 ++++++++++
> > include/linux/i3c/device.h | 212 ++++++
> > include/linux/i3c/master.h | 453 ++++++++++++
> > include/linux/mod_devicetable.h | 15 +
> > 20 files changed, 3273 insertions(+), 1 deletion(-)
>
> Any chance you can break the documentation out from this patch to make
> it smaller and a bit simpler to review?
Sure. I'll put the doc and code in 2 different commits.
>
> Here's a few random review comments, I have only glanced at this, not
> done any real reading of this at all...
>
> > +menu "I3C support"
> > +
> > +config I3C
> > + tristate "I3C support"
> > + ---help---
> > + I3C (pronounce: I-cube-C) is a serial protocol standardized by the
> > + MIPI alliance.
> > +
> > + It's supposed to be backward compatible with I2C while providing
> > + support for high speed transfers and native interrupt support
> > + without the need for extra pins.
> > +
> > + The I3C protocol also standardizes the slave device types and is
> > + mainly design to communicate with sensors.
> > +
> > + If you want I3C support, you should say Y here and also to the
> > + specific driver for your bus adapter(s) below.
> > +
> > + This I3C support can also be built as a module. If so, the module
> > + will be called i3c.
> > +
> > +source "drivers/i3c/master/Kconfig"
>
> Don't source unless i3c is enabled, right?
Right, I'll also switch to menuconfig instead of menu+config.
>
> > +
> > +endmenu
> > diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
> > new file mode 100644
> > index 000000000000..0605a275f47b
> > --- /dev/null
> > +++ b/drivers/i3c/Makefile
> > @@ -0,0 +1,3 @@
> > +i3c-y := core.o device.o master.o
> > +obj-$(CONFIG_I3C) += i3c.o
> > +obj-$(CONFIG_I3C) += master/
> > diff --git a/drivers/i3c/core.c b/drivers/i3c/core.c
> > new file mode 100644
> > index 000000000000..c000fb458547
> > --- /dev/null
> > +++ b/drivers/i3c/core.c
> > @@ -0,0 +1,532 @@
> > +/*
> > + * Copyright (C) 2017 Cadence Design Systems Inc.
> > + *
> > + * Author: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License as published by the Free
> > + * Software Foundation; either version 2 of the License, or (at your option)
> > + * any later version.
>
> I have to ask, do you really mean "or any later version"?
I'll ask Cadence.
>
> > +static DEFINE_IDR(i3c_bus_idr);
>
> You never clean this up when the module goes away :(
I'll call idr_destroy() in i3c_exit().
>
> > +static DEFINE_MUTEX(i3c_core_lock);
> > +
> > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > +{
> > + if (exclusive)
> > + down_write(&bus->lock);
> > + else
> > + down_read(&bus->lock);
> > +}
>
> The "exclusive" flag is odd, and messy, and hard to understand, don't
> you agree?
I could create 2 functions, one for the exclusive lock and the other
one for the shared lock.
> And have you measured the difference in using a rw lock over
> a normal mutex and found it to be faster? If not, just use a normal
> mutex, it's simpler and almost always better in the end.
I did not measure the difference, but using a standard lock means
serializing all I3C accesses going through a given master in the core.
Note that this lock is not here to guarantee that calls to
master->ops->xxx() are serialized (this part is left to the master
driver), but to ensure that when a bus management operation is in
progress (like changing the address of a device on the bus), no one can
send I3C frames. If we don't do that, one could queue an I3C transfer,
and by the time this transfer reach the bus, the I3C device this
message was targeting may have a different address.
Unless you see a good reason to not use a R/W lock, I'd like to keep it
this way because master IPs are likely to implement advanced queuing
mechanism (allows one to queue new transfers even if the master is
already busy processing other requests), and serializing things at the
framework level will just prevent us from using this kind of
optimization.
>
> > +
> > +void i3c_bus_unlock(struct i3c_bus *bus, bool exclusive)
> > +{
> > + if (exclusive)
> > + up_write(&bus->lock);
> > + else
> > + up_read(&bus->lock);
> > +}
> > +
> > +static ssize_t bcr_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%x\n", i3cdev->info.bcr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(bcr);
> > +
> > +static ssize_t dcr_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%x\n", i3cdev->info.dcr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(dcr);
> > +
> > +static ssize_t pid_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%llx\n", i3cdev->info.pid);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(pid);
>
> No Documentation/ABI entries for all of these sysfs files?
Yep, I mentioned the lack of sysfs doc in my cover letter. Will address
that in v2.
>
> > +
> > +static ssize_t address_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + ssize_t ret;
> > +
> > + i3c_bus_lock(bus, false);
> > + ret = sprintf(buf, "%02x\n", i3cdev->info.dyn_addr);
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(address);
> > +
> > +static const char * const hdrcap_strings[] = {
> > + "hdr-ddr", "hdr-tsp", "hdr-tsl",
> > +};
> > +
> > +static ssize_t hdrcap_show(struct device *dev,
> > + struct device_attribute *da,
> > + char *buf)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > + unsigned long caps = i3cdev->info.hdr_cap;
> > + ssize_t offset = 0, ret;
> > + int mode;
> > +
> > + i3c_bus_lock(bus, false);
> > + for_each_set_bit(mode, &caps, 8) {
> > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > + break;
> > +
> > + if (!hdrcap_strings[mode])
> > + continue;
> > +
> > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
>
> Multiple lines in a single sysfs file? No.
Okay. Would that be okay with a different separator (like a comma)?
>
> > + if (ret < 0)
> > + goto out;
> > +
> > + offset += ret;
> > + }
> > + ret = offset;
> > +
> > +out:
> > + i3c_bus_unlock(bus, false);
> > +
> > + return ret;
> > +}
> > +static DEVICE_ATTR_RO(hdrcap);
> > +
> > +static struct attribute *i3c_device_attrs[] = {
> > + &dev_attr_bcr.attr,
> > + &dev_attr_dcr.attr,
> > + &dev_attr_pid.attr,
> > + &dev_attr_address.attr,
> > + &dev_attr_hdrcap.attr,
> > + NULL,
> > +};
> > +
> > +static const struct attribute_group i3c_device_group = {
> > + .attrs = i3c_device_attrs,
> > +};
> > +
> > +static const struct attribute_group *i3c_device_groups[] = {
> > + &i3c_device_group,
> > + NULL,
> > +};
>
> ATTRIBUTE_GROUPS()?
My initial plan was to have a common set of attributes that apply to
both devices and masters, and then add specific attributes in each of
them when they only apply to a specific device type.
Something like:
static const struct attribute_group i3c_common_group = {
.attrs = i3c_common_attrs,
};
static const struct attribute_group i3c_device_group = {
.attrs = i3c_device_attrs,
};
static const struct attribute_group *i3c_device_groups[] = {
&i3c_common_group,
&i3c_device_group,
NULL,
};
static const struct attribute_group i3c_master_group = {
.attrs = i3c_master_attrs,
};
static const struct attribute_group *i3c_master_groups[] = {
&i3c_common_group,
&i3c_master_group,
NULL,
};
It turned out I didn't have device or master specific attributes in this
version, so this differentiation is useless right now. I'll drop that
in my v2.
Just out of curiosity, what's the preferred solution when you need to
do something like that? Should we just use ATTRIBUTE_GROUPS() and
duplicate the entries that apply to both device types?
>
>
> > +
> > +static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > +{
> > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > + u16 manuf = I3C_PID_MANUF_ID(i3cdev->info.pid);
> > + u16 part = I3C_PID_PART_ID(i3cdev->info.pid);
> > + u16 ext = I3C_PID_EXTRA_INFO(i3cdev->info.pid);
> > +
> > + if (I3C_PID_RND_LOWER_32BITS(i3cdev->info.pid))
> > + return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
> > + i3cdev->info.dcr, manuf);
> > +
> > + return add_uevent_var(env,
> > + "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
> > + i3cdev->info.dcr, manuf, part, ext);
> > +}
> > +
> > +const struct device_type i3c_device_type = {
> > + .groups = i3c_device_groups,
> > + .uevent = i3c_device_uevent,
> > +};
>
> No release type? Oh that's bad bad bad and implies you have never
> removed a device from your system as the kernel would have complained
> loudly at you.
You got me, never tried to remove a device :-). Note that these
->release() hooks will just be dummy ones, because right now, device
resources are freed at bus destruction time.
Also, I see that dev->release() is called instead of
dev->type->release() if it's not NULL [1]. what's the preferred solution
here? Set dev->release or type->release()?
Thanks for your review,
Boris
[1]http://elixir.free-electrons.com/linux/v4.13-rc3/source/drivers/base/core.c#L809
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 21:15 ` Boris Brezillon
@ 2017-08-01 12:00 ` Arnd Bergmann
-1 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 12:00 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> Hi Arnd,
>
> Le Mon, 31 Jul 2017 22:16:42 +0200,
> Arnd Bergmann <arnd@arndb.de> a écrit :
>
>> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>> > Add core infrastructure to support I3C in Linux and document it.
>>
>> > - I2C backward compatibility has been designed to be transparent to I2C
>> > drivers and the I2C subsystem. The I3C master just registers an I2C
>> > adapter which creates a new I2C bus. I'd say that, from a
>> > representation PoV it's not ideal because what should appear as a
>> > single I3C bus exposing I3C and I2C devices here appears as 2
>> > different busses connected to each other through the parenting (the
>> > I3C master is the parent of the I2C and I3C busses).
>> > On the other hand, I don't see a better solution if we want something
>> > that is not invasive.
>>
>> Can you describe the reasons for making i3c a separate subsystem then,
>> rather than extending the i2c subsystem to handle both i2c devices as
>> before and also i3c devices and hosts?
>
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB than I2C or SPI.
>
> Indeed, all I3C devices can be discovered and do not need to be
> described at the board level (using DT, board files, ACPI or whatever).
> Also, some I3C devices are hotpluggable, and most importantly, all I3C
> devices describe themselves during the discovery procedure (called DAA
> in the I3C world).
Side note: please make sure you define a way to describe them
in DT anyway. We ended up needing additional DT properties
as well as power sequencing for most discoverable buses (pci,
usb, mmc, ...), I'm sure this one won't be an exception even though
the standard says you don't need it and most devices will work
without it.
> There is some kind of "device class" concept. In the I3C world it's
> called DCR (Device Characteristic Register), but it plays the same role:
> it's a set of generic interfaces devices have to comply with when they
> declare themselves as being compatible with a DCR ID (like
> accelerometer, gyroscope, or whatever). See this table of normalized
> DCR for more information [1].
>
> Devices also expose a 48-bit Provisional ID which is made of
> sub-fields. Two of them are particularly interesting: the manufacturer
> ID and the part ID, which are comparable to the vendor and product ID in
> the USB world.
>
> These three information (DCR, ManufacturerID and PartID) can be used to
> match drivers instead of the compatible string or driver-name used for
> I2C devices
The matching would be fairly easy to accomodate: the i2c bus already
handles two distinct ways: of_device_id tables and matching by
name, so we could easily add another method here.
> So, as you can imagine, dealing with an I3C bus is really different
> from dealing with an I2C bus, and I found the "expose an i2c_adapter
> object for each i3c_master" way simpler (and less invasive) than
> extending the I2C framework to support I3C devices.
>
> Of course, I can move all the code in drivers/i2c/, but that won't
> change the fact that I3C and I2C busses are completely different
> with little to share between them.
>
> To me, the I2C backward compatibility is just a nice feature that was
> added to help people smoothly transition from mixed I3C busses with
> both I2C and I3C devices connected to it (I2C devices being here
> when no (affordable) equivalent exist in the I3C world) to pure I3C
> busses with only I3C devices connected to it.
>
> This being said, I'd be happy if you prove me wrong and propose a
> solution that allows us to extend the I2C framework to support I3C
> without to much pain ;-).
I think the question is not whether it can be done or not, but whether
it is a good idea. Obviously we can create some frankenstein bus
design that combines arbitrary different device types by just containing
the superset of the required information, and sprinking the code
with if()/else() to call one or the other function.
If there is very little shared code between the i2c and i3c
implementations, then the added complexity of having a combined
subsystem is clearly a strong argument against it.
On the other hand, there is value in representing the physical
bus hierarchy in the software model, and if i2c and i3c devices can
be attached to the same host bus, a good abstraction should
show them under the same parent. This is true for both the
kernel representation (in sysfs and the data structures) as well
as the device tree binding (assuming we will need to represent
i3c devices at all). The two don't have to use the same model,
but it's easier if they do.
Another argument for a combined bus would be devices that
can be attached to either i2c and i3c, depending on the host
capabilities. We have discussed whether i2c and spi should be
merged into a single bus_type in the past, as a lot of devices
can be attached to either of them. If it's common enough for i3c
devices to support an i2c fallback mode, having a common
bus_type might noticeably simplify device drivers by only requiring
a single i2c_driver structure. Simplifying many drivers a little
bit can in turn offset the added complexity in the subsystem.
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 12:00 ` Arnd Bergmann
0 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 12:00 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Ku
On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Arnd,
>
> Le Mon, 31 Jul 2017 22:16:42 +0200,
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> a écrit :
>
>> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
>> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > Add core infrastructure to support I3C in Linux and document it.
>>
>> > - I2C backward compatibility has been designed to be transparent to I2C
>> > drivers and the I2C subsystem. The I3C master just registers an I2C
>> > adapter which creates a new I2C bus. I'd say that, from a
>> > representation PoV it's not ideal because what should appear as a
>> > single I3C bus exposing I3C and I2C devices here appears as 2
>> > different busses connected to each other through the parenting (the
>> > I3C master is the parent of the I2C and I3C busses).
>> > On the other hand, I don't see a better solution if we want something
>> > that is not invasive.
>>
>> Can you describe the reasons for making i3c a separate subsystem then,
>> rather than extending the i2c subsystem to handle both i2c devices as
>> before and also i3c devices and hosts?
>
> Actually, that's the first option I considered, but I3C and I2C are
> really different. I'm not talking about the physical layer here, but
> the way the bus has to be handled by the software layer. Actually, I
> thing the I3C bus is philosophically closer to auto-discoverable busses
> like USB than I2C or SPI.
>
> Indeed, all I3C devices can be discovered and do not need to be
> described at the board level (using DT, board files, ACPI or whatever).
> Also, some I3C devices are hotpluggable, and most importantly, all I3C
> devices describe themselves during the discovery procedure (called DAA
> in the I3C world).
Side note: please make sure you define a way to describe them
in DT anyway. We ended up needing additional DT properties
as well as power sequencing for most discoverable buses (pci,
usb, mmc, ...), I'm sure this one won't be an exception even though
the standard says you don't need it and most devices will work
without it.
> There is some kind of "device class" concept. In the I3C world it's
> called DCR (Device Characteristic Register), but it plays the same role:
> it's a set of generic interfaces devices have to comply with when they
> declare themselves as being compatible with a DCR ID (like
> accelerometer, gyroscope, or whatever). See this table of normalized
> DCR for more information [1].
>
> Devices also expose a 48-bit Provisional ID which is made of
> sub-fields. Two of them are particularly interesting: the manufacturer
> ID and the part ID, which are comparable to the vendor and product ID in
> the USB world.
>
> These three information (DCR, ManufacturerID and PartID) can be used to
> match drivers instead of the compatible string or driver-name used for
> I2C devices
The matching would be fairly easy to accomodate: the i2c bus already
handles two distinct ways: of_device_id tables and matching by
name, so we could easily add another method here.
> So, as you can imagine, dealing with an I3C bus is really different
> from dealing with an I2C bus, and I found the "expose an i2c_adapter
> object for each i3c_master" way simpler (and less invasive) than
> extending the I2C framework to support I3C devices.
>
> Of course, I can move all the code in drivers/i2c/, but that won't
> change the fact that I3C and I2C busses are completely different
> with little to share between them.
>
> To me, the I2C backward compatibility is just a nice feature that was
> added to help people smoothly transition from mixed I3C busses with
> both I2C and I3C devices connected to it (I2C devices being here
> when no (affordable) equivalent exist in the I3C world) to pure I3C
> busses with only I3C devices connected to it.
>
> This being said, I'd be happy if you prove me wrong and propose a
> solution that allows us to extend the I2C framework to support I3C
> without to much pain ;-).
I think the question is not whether it can be done or not, but whether
it is a good idea. Obviously we can create some frankenstein bus
design that combines arbitrary different device types by just containing
the superset of the required information, and sprinking the code
with if()/else() to call one or the other function.
If there is very little shared code between the i2c and i3c
implementations, then the added complexity of having a combined
subsystem is clearly a strong argument against it.
On the other hand, there is value in representing the physical
bus hierarchy in the software model, and if i2c and i3c devices can
be attached to the same host bus, a good abstraction should
show them under the same parent. This is true for both the
kernel representation (in sysfs and the data structures) as well
as the device tree binding (assuming we will need to represent
i3c devices at all). The two don't have to use the same model,
but it's easier if they do.
Another argument for a combined bus would be devices that
can be attached to either i2c and i3c, depending on the host
capabilities. We have discussed whether i2c and spi should be
merged into a single bus_type in the past, as a lot of devices
can be attached to either of them. If it's common enough for i3c
devices to support an i2c fallback mode, having a common
bus_type might noticeably simplify device drivers by only requiring
a single i2c_driver structure. Simplifying many drivers a little
bit can in turn offset the added complexity in the subsystem.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 12:00 ` Arnd Bergmann
@ 2017-08-01 12:29 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 12:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 14:00:05 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > Hi Arnd,
> >
> > Le Mon, 31 Jul 2017 22:16:42 +0200,
> > Arnd Bergmann <arnd@arndb.de> a écrit :
> >
> >> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:
> >> > Add core infrastructure to support I3C in Linux and document it.
> >>
> >> > - I2C backward compatibility has been designed to be transparent to I2C
> >> > drivers and the I2C subsystem. The I3C master just registers an I2C
> >> > adapter which creates a new I2C bus. I'd say that, from a
> >> > representation PoV it's not ideal because what should appear as a
> >> > single I3C bus exposing I3C and I2C devices here appears as 2
> >> > different busses connected to each other through the parenting (the
> >> > I3C master is the parent of the I2C and I3C busses).
> >> > On the other hand, I don't see a better solution if we want something
> >> > that is not invasive.
> >>
> >> Can you describe the reasons for making i3c a separate subsystem then,
> >> rather than extending the i2c subsystem to handle both i2c devices as
> >> before and also i3c devices and hosts?
> >
> > Actually, that's the first option I considered, but I3C and I2C are
> > really different. I'm not talking about the physical layer here, but
> > the way the bus has to be handled by the software layer. Actually, I
> > thing the I3C bus is philosophically closer to auto-discoverable busses
> > like USB than I2C or SPI.
> >
> > Indeed, all I3C devices can be discovered and do not need to be
> > described at the board level (using DT, board files, ACPI or whatever).
> > Also, some I3C devices are hotpluggable, and most importantly, all I3C
> > devices describe themselves during the discovery procedure (called DAA
> > in the I3C world).
>
> Side note: please make sure you define a way to describe them
> in DT anyway. We ended up needing additional DT properties
> as well as power sequencing for most discoverable buses (pci,
> usb, mmc, ...), I'm sure this one won't be an exception even though
> the standard says you don't need it and most devices will work
> without it.
>
> > There is some kind of "device class" concept. In the I3C world it's
> > called DCR (Device Characteristic Register), but it plays the same role:
> > it's a set of generic interfaces devices have to comply with when they
> > declare themselves as being compatible with a DCR ID (like
> > accelerometer, gyroscope, or whatever). See this table of normalized
> > DCR for more information [1].
> >
> > Devices also expose a 48-bit Provisional ID which is made of
> > sub-fields. Two of them are particularly interesting: the manufacturer
> > ID and the part ID, which are comparable to the vendor and product ID in
> > the USB world.
> >
> > These three information (DCR, ManufacturerID and PartID) can be used to
> > match drivers instead of the compatible string or driver-name used for
> > I2C devices
>
> The matching would be fairly easy to accomodate: the i2c bus already
> handles two distinct ways: of_device_id tables and matching by
> name, so we could easily add another method here.
Should be doable. All we need to do is define device PIDs (Provisional
IDs) in the DT so that they can be attached to the real device when it's
discovered on the bus. Also note that some I3C devices come with a
static/I2C/legacy address which can be used when this device is
connected on an I2C bus. Such devices can be accessed in I2C mode using
this static address before they get assigned a dynamic one by the I3C
master. So, that would be another solution to describe I3C devs in the
DT, but this won't work for all devs.
>
> > So, as you can imagine, dealing with an I3C bus is really different
> > from dealing with an I2C bus, and I found the "expose an i2c_adapter
> > object for each i3c_master" way simpler (and less invasive) than
> > extending the I2C framework to support I3C devices.
> >
> > Of course, I can move all the code in drivers/i2c/, but that won't
> > change the fact that I3C and I2C busses are completely different
> > with little to share between them.
> >
> > To me, the I2C backward compatibility is just a nice feature that was
> > added to help people smoothly transition from mixed I3C busses with
> > both I2C and I3C devices connected to it (I2C devices being here
> > when no (affordable) equivalent exist in the I3C world) to pure I3C
> > busses with only I3C devices connected to it.
> >
> > This being said, I'd be happy if you prove me wrong and propose a
> > solution that allows us to extend the I2C framework to support I3C
> > without to much pain ;-).
>
> I think the question is not whether it can be done or not, but whether
> it is a good idea. Obviously we can create some frankenstein bus
> design that combines arbitrary different device types by just containing
> the superset of the required information, and sprinking the code
> with if()/else() to call one or the other function.
>
> If there is very little shared code between the i2c and i3c
> implementations, then the added complexity of having a combined
> subsystem is clearly a strong argument against it.
AFAICT, there is little to share.
>
> On the other hand, there is value in representing the physical
> bus hierarchy in the software model, and if i2c and i3c devices can
> be attached to the same host bus, a good abstraction should
> show them under the same parent.
I agree here, hence my comment in the cover letter.
> This is true for both the
> kernel representation (in sysfs and the data structures) as well
> as the device tree binding (assuming we will need to represent
> i3c devices at all).
DT representation is already adopting a single bus representation: I2C
devices are directly described under the I3C master/bus node and so
will I3C devs if we ever need to represent them in the DT.
> The two don't have to use the same model,
> but it's easier if they do.
Agreed.
>
> Another argument for a combined bus would be devices that
> can be attached to either i2c and i3c, depending on the host
> capabilities.
Hm, that's already the case, isn't it? And you'll anyway need to
develop specific code for both cases in the I2C/I3C device driver
because I2C and I3C transfers are different. So I don't see how it
would help to have a single bus here.
> We have discussed whether i2c and spi should be
> merged into a single bus_type in the past, as a lot of devices
> can be attached to either of them.
Oh, really? What's the rational behind that? I mean, I2C and SPI are
quite different, and even if some devices provide both interfaces, I
don't see why we should merge them. But you probably had good reasons
to do so.
> If it's common enough for i3c
> devices to support an i2c fallback mode,
If the device has a static address, it's likely to be compatible with
I2C. Don't know how usual this is though.
> having a common
> bus_type might noticeably simplify device drivers by only requiring
> a single i2c_driver structure.
Well, it's not only about having 2 different driver objects. As I said,
I3C and I2C frames are different and the driver will have to handle the
device differently depending on whether it's addressed in I2C or I3C
mode.
> Simplifying many drivers a little
> bit can in turn offset the added complexity in the subsystem.
Hm, maybe you'll save a few lines (and a few hundred of bytes) by not
having to declare/register 2 different drivers, but IMHO that's not the
part that would be the most difficult when it comes to supporting both
I2C and I3C modes in the same driver.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 12:29 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 12:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Tue, 1 Aug 2017 14:00:05 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jul 31, 2017 at 11:15 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > Hi Arnd,
> >
> > Le Mon, 31 Jul 2017 22:16:42 +0200,
> > Arnd Bergmann <arnd@arndb.de> a écrit :
> >
> >> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:
> >> > Add core infrastructure to support I3C in Linux and document it.
> >>
> >> > - I2C backward compatibility has been designed to be transparent to I2C
> >> > drivers and the I2C subsystem. The I3C master just registers an I2C
> >> > adapter which creates a new I2C bus. I'd say that, from a
> >> > representation PoV it's not ideal because what should appear as a
> >> > single I3C bus exposing I3C and I2C devices here appears as 2
> >> > different busses connected to each other through the parenting (the
> >> > I3C master is the parent of the I2C and I3C busses).
> >> > On the other hand, I don't see a better solution if we want something
> >> > that is not invasive.
> >>
> >> Can you describe the reasons for making i3c a separate subsystem then,
> >> rather than extending the i2c subsystem to handle both i2c devices as
> >> before and also i3c devices and hosts?
> >
> > Actually, that's the first option I considered, but I3C and I2C are
> > really different. I'm not talking about the physical layer here, but
> > the way the bus has to be handled by the software layer. Actually, I
> > thing the I3C bus is philosophically closer to auto-discoverable busses
> > like USB than I2C or SPI.
> >
> > Indeed, all I3C devices can be discovered and do not need to be
> > described at the board level (using DT, board files, ACPI or whatever).
> > Also, some I3C devices are hotpluggable, and most importantly, all I3C
> > devices describe themselves during the discovery procedure (called DAA
> > in the I3C world).
>
> Side note: please make sure you define a way to describe them
> in DT anyway. We ended up needing additional DT properties
> as well as power sequencing for most discoverable buses (pci,
> usb, mmc, ...), I'm sure this one won't be an exception even though
> the standard says you don't need it and most devices will work
> without it.
>
> > There is some kind of "device class" concept. In the I3C world it's
> > called DCR (Device Characteristic Register), but it plays the same role:
> > it's a set of generic interfaces devices have to comply with when they
> > declare themselves as being compatible with a DCR ID (like
> > accelerometer, gyroscope, or whatever). See this table of normalized
> > DCR for more information [1].
> >
> > Devices also expose a 48-bit Provisional ID which is made of
> > sub-fields. Two of them are particularly interesting: the manufacturer
> > ID and the part ID, which are comparable to the vendor and product ID in
> > the USB world.
> >
> > These three information (DCR, ManufacturerID and PartID) can be used to
> > match drivers instead of the compatible string or driver-name used for
> > I2C devices
>
> The matching would be fairly easy to accomodate: the i2c bus already
> handles two distinct ways: of_device_id tables and matching by
> name, so we could easily add another method here.
Should be doable. All we need to do is define device PIDs (Provisional
IDs) in the DT so that they can be attached to the real device when it's
discovered on the bus. Also note that some I3C devices come with a
static/I2C/legacy address which can be used when this device is
connected on an I2C bus. Such devices can be accessed in I2C mode using
this static address before they get assigned a dynamic one by the I3C
master. So, that would be another solution to describe I3C devs in the
DT, but this won't work for all devs.
>
> > So, as you can imagine, dealing with an I3C bus is really different
> > from dealing with an I2C bus, and I found the "expose an i2c_adapter
> > object for each i3c_master" way simpler (and less invasive) than
> > extending the I2C framework to support I3C devices.
> >
> > Of course, I can move all the code in drivers/i2c/, but that won't
> > change the fact that I3C and I2C busses are completely different
> > with little to share between them.
> >
> > To me, the I2C backward compatibility is just a nice feature that was
> > added to help people smoothly transition from mixed I3C busses with
> > both I2C and I3C devices connected to it (I2C devices being here
> > when no (affordable) equivalent exist in the I3C world) to pure I3C
> > busses with only I3C devices connected to it.
> >
> > This being said, I'd be happy if you prove me wrong and propose a
> > solution that allows us to extend the I2C framework to support I3C
> > without to much pain ;-).
>
> I think the question is not whether it can be done or not, but whether
> it is a good idea. Obviously we can create some frankenstein bus
> design that combines arbitrary different device types by just containing
> the superset of the required information, and sprinking the code
> with if()/else() to call one or the other function.
>
> If there is very little shared code between the i2c and i3c
> implementations, then the added complexity of having a combined
> subsystem is clearly a strong argument against it.
AFAICT, there is little to share.
>
> On the other hand, there is value in representing the physical
> bus hierarchy in the software model, and if i2c and i3c devices can
> be attached to the same host bus, a good abstraction should
> show them under the same parent.
I agree here, hence my comment in the cover letter.
> This is true for both the
> kernel representation (in sysfs and the data structures) as well
> as the device tree binding (assuming we will need to represent
> i3c devices at all).
DT representation is already adopting a single bus representation: I2C
devices are directly described under the I3C master/bus node and so
will I3C devs if we ever need to represent them in the DT.
> The two don't have to use the same model,
> but it's easier if they do.
Agreed.
>
> Another argument for a combined bus would be devices that
> can be attached to either i2c and i3c, depending on the host
> capabilities.
Hm, that's already the case, isn't it? And you'll anyway need to
develop specific code for both cases in the I2C/I3C device driver
because I2C and I3C transfers are different. So I don't see how it
would help to have a single bus here.
> We have discussed whether i2c and spi should be
> merged into a single bus_type in the past, as a lot of devices
> can be attached to either of them.
Oh, really? What's the rational behind that? I mean, I2C and SPI are
quite different, and even if some devices provide both interfaces, I
don't see why we should merge them. But you probably had good reasons
to do so.
> If it's common enough for i3c
> devices to support an i2c fallback mode,
If the device has a static address, it's likely to be compatible with
I2C. Don't know how usual this is though.
> having a common
> bus_type might noticeably simplify device drivers by only requiring
> a single i2c_driver structure.
Well, it's not only about having 2 different driver objects. As I said,
I3C and I2C frames are different and the driver will have to handle the
device differently depending on whether it's addressed in I2C or I3C
mode.
> Simplifying many drivers a little
> bit can in turn offset the added complexity in the subsystem.
Hm, maybe you'll save a few lines (and a few hundred of bytes) by not
having to declare/register 2 different drivers, but IMHO that's not the
part that would be the most difficult when it comes to supporting both
I2C and I3C modes in the same driver.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 12:29 ` Boris Brezillon
@ 2017-08-01 13:11 ` Arnd Bergmann
-1 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 13:11 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 14:00:05 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>> Another argument for a combined bus would be devices that
>> can be attached to either i2c and i3c, depending on the host
>> capabilities.
>
> Hm, that's already the case, isn't it? And you'll anyway need to
> develop specific code for both cases in the I2C/I3C device driver
> because I2C and I3C transfers are different. So I don't see how it
> would help to have a single bus here.
>
>> We have discussed whether i2c and spi should be
>> merged into a single bus_type in the past, as a lot of devices
>> can be attached to either of them.
>
> Oh, really? What's the rational behind that? I mean, I2C and SPI are
> quite different, and even if some devices provide both interfaces, I
> don't see why we should merge them. But you probably had good reasons
> to do so.
Well, we never changed it, so at least the work required to merge
the two was considered too much to justify any advantages.
The main problem with having one driver that can operate on
different bus types (i2c plus either spi or i3c) is the handling for
the various combinations in configurations (e.g. I2C=m, SPI=y).
The easy case is having a module_init function that registers two
device drivers, but that requires having a Kconfig dependency
on both subsystems, and you can't use the module_i2c_driver()
helper.
The second way is to have a number of #ifdef and complex
Kconfig dependencies for the driver to only register the
device_driver objects for the buses that are enabled. This
is also doable, but everyone gets the logic wrong the first time.
What we end up doing to work around this for other drivers is
to have the base driver in one library module, and separate
modules for the bus-specific portions, which can then
use module_i2c_driver again. There are many instances
for combined i2c/spi drivers in the kernel, and it works fine,
but it adds a fair bit of overhead compared to having one
driver that would e.g. use regmap to abstract the differences
in the probe() function and otherwise keeps everything in
one place.
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 13:11 ` Arnd Bergmann
0 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 13:11 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 14:00:05 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>> Another argument for a combined bus would be devices that
>> can be attached to either i2c and i3c, depending on the host
>> capabilities.
>
> Hm, that's already the case, isn't it? And you'll anyway need to
> develop specific code for both cases in the I2C/I3C device driver
> because I2C and I3C transfers are different. So I don't see how it
> would help to have a single bus here.
>
>> We have discussed whether i2c and spi should be
>> merged into a single bus_type in the past, as a lot of devices
>> can be attached to either of them.
>
> Oh, really? What's the rational behind that? I mean, I2C and SPI are
> quite different, and even if some devices provide both interfaces, I
> don't see why we should merge them. But you probably had good reasons
> to do so.
Well, we never changed it, so at least the work required to merge
the two was considered too much to justify any advantages.
The main problem with having one driver that can operate on
different bus types (i2c plus either spi or i3c) is the handling for
the various combinations in configurations (e.g. I2C=m, SPI=y).
The easy case is having a module_init function that registers two
device drivers, but that requires having a Kconfig dependency
on both subsystems, and you can't use the module_i2c_driver()
helper.
The second way is to have a number of #ifdef and complex
Kconfig dependencies for the driver to only register the
device_driver objects for the buses that are enabled. This
is also doable, but everyone gets the logic wrong the first time.
What we end up doing to work around this for other drivers is
to have the base driver in one library module, and separate
modules for the bus-specific portions, which can then
use module_i2c_driver again. There are many instances
for combined i2c/spi drivers in the kernel, and it works fine,
but it adds a fair bit of overhead compared to having one
driver that would e.g. use regmap to abstract the differences
in the probe() function and otherwise keeps everything in
one place.
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 13:11 ` Arnd Bergmann
@ 2017-08-01 13:34 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 13:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 15:11:44 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Tue, 1 Aug 2017 14:00:05 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
>
> >> Another argument for a combined bus would be devices that
> >> can be attached to either i2c and i3c, depending on the host
> >> capabilities.
> >
> > Hm, that's already the case, isn't it? And you'll anyway need to
> > develop specific code for both cases in the I2C/I3C device driver
> > because I2C and I3C transfers are different. So I don't see how it
> > would help to have a single bus here.
> >
> >> We have discussed whether i2c and spi should be
> >> merged into a single bus_type in the past, as a lot of devices
> >> can be attached to either of them.
> >
> > Oh, really? What's the rational behind that? I mean, I2C and SPI are
> > quite different, and even if some devices provide both interfaces, I
> > don't see why we should merge them. But you probably had good reasons
> > to do so.
>
> Well, we never changed it, so at least the work required to merge
> the two was considered too much to justify any advantages.
>
> The main problem with having one driver that can operate on
> different bus types (i2c plus either spi or i3c) is the handling for
> the various combinations in configurations (e.g. I2C=m, SPI=y).
>
> The easy case is having a module_init function that registers two
> device drivers, but that requires having a Kconfig dependency
> on both subsystems, and you can't use the module_i2c_driver()
> helper.
>
> The second way is to have a number of #ifdef and complex
> Kconfig dependencies for the driver to only register the
> device_driver objects for the buses that are enabled. This
> is also doable, but everyone gets the logic wrong the first time.
Hm, I understand now why you'd prefer to have a single bus. Can't we
solve this problem with a module_i3c_i2c_driver() macro that would hide
all this complexity from I2C/I3C drivers?
>
> What we end up doing to work around this for other drivers is
> to have the base driver in one library module, and separate
> modules for the bus-specific portions, which can then
> use module_i2c_driver again. There are many instances
> for combined i2c/spi drivers in the kernel, and it works fine,
> but it adds a fair bit of overhead compared to having one
> driver that would e.g. use regmap to abstract the differences
> in the probe() function and otherwise keeps everything in
> one place.
>
> Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 13:34 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 13:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Tue, 1 Aug 2017 15:11:44 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Tue, 1 Aug 2017 14:00:05 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
>
> >> Another argument for a combined bus would be devices that
> >> can be attached to either i2c and i3c, depending on the host
> >> capabilities.
> >
> > Hm, that's already the case, isn't it? And you'll anyway need to
> > develop specific code for both cases in the I2C/I3C device driver
> > because I2C and I3C transfers are different. So I don't see how it
> > would help to have a single bus here.
> >
> >> We have discussed whether i2c and spi should be
> >> merged into a single bus_type in the past, as a lot of devices
> >> can be attached to either of them.
> >
> > Oh, really? What's the rational behind that? I mean, I2C and SPI are
> > quite different, and even if some devices provide both interfaces, I
> > don't see why we should merge them. But you probably had good reasons
> > to do so.
>
> Well, we never changed it, so at least the work required to merge
> the two was considered too much to justify any advantages.
>
> The main problem with having one driver that can operate on
> different bus types (i2c plus either spi or i3c) is the handling for
> the various combinations in configurations (e.g. I2C=m, SPI=y).
>
> The easy case is having a module_init function that registers two
> device drivers, but that requires having a Kconfig dependency
> on both subsystems, and you can't use the module_i2c_driver()
> helper.
>
> The second way is to have a number of #ifdef and complex
> Kconfig dependencies for the driver to only register the
> device_driver objects for the buses that are enabled. This
> is also doable, but everyone gets the logic wrong the first time.
Hm, I understand now why you'd prefer to have a single bus. Can't we
solve this problem with a module_i3c_i2c_driver() macro that would hide
all this complexity from I2C/I3C drivers?
>
> What we end up doing to work around this for other drivers is
> to have the base driver in one library module, and separate
> modules for the bus-specific portions, which can then
> use module_i2c_driver again. There are many instances
> for combined i2c/spi drivers in the kernel, and it works fine,
> but it adds a fair bit of overhead compared to having one
> driver that would e.g. use regmap to abstract the differences
> in the probe() function and otherwise keeps everything in
> one place.
>
> Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 13:34 ` Boris Brezillon
@ 2017-08-01 13:58 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 13:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 15:34:14 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 15:11:44 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> > <boris.brezillon@free-electrons.com> wrote:
> > > On Tue, 1 Aug 2017 14:00:05 +0200
> > > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > >> Another argument for a combined bus would be devices that
> > >> can be attached to either i2c and i3c, depending on the host
> > >> capabilities.
> > >
> > > Hm, that's already the case, isn't it? And you'll anyway need to
> > > develop specific code for both cases in the I2C/I3C device driver
> > > because I2C and I3C transfers are different. So I don't see how it
> > > would help to have a single bus here.
> > >
> > >> We have discussed whether i2c and spi should be
> > >> merged into a single bus_type in the past, as a lot of devices
> > >> can be attached to either of them.
> > >
> > > Oh, really? What's the rational behind that? I mean, I2C and SPI are
> > > quite different, and even if some devices provide both interfaces, I
> > > don't see why we should merge them. But you probably had good reasons
> > > to do so.
> >
> > Well, we never changed it, so at least the work required to merge
> > the two was considered too much to justify any advantages.
> >
> > The main problem with having one driver that can operate on
> > different bus types (i2c plus either spi or i3c) is the handling for
> > the various combinations in configurations (e.g. I2C=m, SPI=y).
> >
> > The easy case is having a module_init function that registers two
> > device drivers, but that requires having a Kconfig dependency
> > on both subsystems, and you can't use the module_i2c_driver()
> > helper.
> >
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer to have a single bus. Can't we
> solve this problem with a module_i3c_i2c_driver() macro that would hide
> all this complexity from I2C/I3C drivers?
I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
entry. Indeed, I'm unconditionally calling functions provided by the
I2C framework which have no dummy wrapper when I2C support is disabled.
I could of course conditionally compile some portion of the I3C
framework so that it still builds when I2C is disabled but I'm not sure
it's worth the trouble.
This "depends on I2C" should also solve the I2C+I3C driver issue, since
I2C is necessarily enabled when I3C is.
Am I missing something?
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 13:58 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 13:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Ku
On Tue, 1 Aug 2017 15:34:14 +0200
Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, 1 Aug 2017 15:11:44 +0200
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>
> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> > <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > > On Tue, 1 Aug 2017 14:00:05 +0200
> > > Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> >
> > >> Another argument for a combined bus would be devices that
> > >> can be attached to either i2c and i3c, depending on the host
> > >> capabilities.
> > >
> > > Hm, that's already the case, isn't it? And you'll anyway need to
> > > develop specific code for both cases in the I2C/I3C device driver
> > > because I2C and I3C transfers are different. So I don't see how it
> > > would help to have a single bus here.
> > >
> > >> We have discussed whether i2c and spi should be
> > >> merged into a single bus_type in the past, as a lot of devices
> > >> can be attached to either of them.
> > >
> > > Oh, really? What's the rational behind that? I mean, I2C and SPI are
> > > quite different, and even if some devices provide both interfaces, I
> > > don't see why we should merge them. But you probably had good reasons
> > > to do so.
> >
> > Well, we never changed it, so at least the work required to merge
> > the two was considered too much to justify any advantages.
> >
> > The main problem with having one driver that can operate on
> > different bus types (i2c plus either spi or i3c) is the handling for
> > the various combinations in configurations (e.g. I2C=m, SPI=y).
> >
> > The easy case is having a module_init function that registers two
> > device drivers, but that requires having a Kconfig dependency
> > on both subsystems, and you can't use the module_i2c_driver()
> > helper.
> >
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer to have a single bus. Can't we
> solve this problem with a module_i3c_i2c_driver() macro that would hide
> all this complexity from I2C/I3C drivers?
I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
entry. Indeed, I'm unconditionally calling functions provided by the
I2C framework which have no dummy wrapper when I2C support is disabled.
I could of course conditionally compile some portion of the I3C
framework so that it still builds when I2C is disabled but I'm not sure
it's worth the trouble.
This "depends on I2C" should also solve the I2C+I3C driver issue, since
I2C is necessarily enabled when I3C is.
Am I missing something?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 13:34 ` Boris Brezillon
@ 2017-08-01 14:12 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 14:12 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer to have a single bus. Can't we
> solve this problem with a module_i3c_i2c_driver() macro that would hide
> all this complexity from I2C/I3C drivers?
Do you know of devices speaking both i3c and i2c as of today?
I think I3C/I2C is a bit different than I2C/SPI. For the latter, it
might happen that you have only this or that bus on the board, so it
makes sense to support both. But if you have I3C, you can simply attach
the I2C device onto it. I guess you would only implement I3C in the
device if you explicitly need its feature set. And then, a I2C fallback
doesn't make much sense? Or am I missing something?
OK, now I know that those I3C+I2C devices will exist, even if only for
Murphy's law. However, my assumptions would be that those devices are
not common and so we could live with the core plus bus_drivers
seperation we have for SPI/I2C already (although I would love a common
regmap-based I2C/SPI abstraction).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 14:12 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 14:12 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
> > The second way is to have a number of #ifdef and complex
> > Kconfig dependencies for the driver to only register the
> > device_driver objects for the buses that are enabled. This
> > is also doable, but everyone gets the logic wrong the first time.
>
> Hm, I understand now why you'd prefer to have a single bus. Can't we
> solve this problem with a module_i3c_i2c_driver() macro that would hide
> all this complexity from I2C/I3C drivers?
Do you know of devices speaking both i3c and i2c as of today?
I think I3C/I2C is a bit different than I2C/SPI. For the latter, it
might happen that you have only this or that bus on the board, so it
makes sense to support both. But if you have I3C, you can simply attach
the I2C device onto it. I guess you would only implement I3C in the
device if you explicitly need its feature set. And then, a I2C fallback
doesn't make much sense? Or am I missing something?
OK, now I know that those I3C+I2C devices will exist, even if only for
Murphy's law. However, my assumptions would be that those devices are
not common and so we could live with the core plus bus_drivers
seperation we have for SPI/I2C already (although I would love a common
regmap-based I2C/SPI abstraction).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 13:58 ` Boris Brezillon
@ 2017-08-01 14:22 ` Arnd Bergmann
-1 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 14:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 15:34:14 +0200
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>> On Tue, 1 Aug 2017 15:11:44 +0200
>> Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> > <boris.brezillon@free-electrons.com> wrote:
> I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
> entry. Indeed, I'm unconditionally calling functions provided by the
> I2C framework which have no dummy wrapper when I2C support is disabled.
> I could of course conditionally compile some portion of the I3C
> framework so that it still builds when I2C is disabled but I'm not sure
> it's worth the trouble.
>
> This "depends on I2C" should also solve the I2C+I3C driver issue, since
> I2C is necessarily enabled when I3C is.
>
> Am I missing something?
That should solve another part of the problem, as a combined driver then
just needs 'depends on I3C'.
On top of that, the i3c_driver structure could also contain callback
pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
When the i2c_probe() callback exists, the i3c layer could construct
a 'struct i2c_driver' with those callbacks and register that under the
cover. This would mean that combined drivers no longer need to
register two driver objects.
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 14:22 ` Arnd Bergmann
0 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 14:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 15:34:14 +0200
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>> On Tue, 1 Aug 2017 15:11:44 +0200
>> Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> > <boris.brezillon@free-electrons.com> wrote:
> I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
> entry. Indeed, I'm unconditionally calling functions provided by the
> I2C framework which have no dummy wrapper when I2C support is disabled.
> I could of course conditionally compile some portion of the I3C
> framework so that it still builds when I2C is disabled but I'm not sure
> it's worth the trouble.
>
> This "depends on I2C" should also solve the I2C+I3C driver issue, since
> I2C is necessarily enabled when I3C is.
>
> Am I missing something?
That should solve another part of the problem, as a combined driver then
just needs 'depends on I3C'.
On top of that, the i3c_driver structure could also contain callback
pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
When the i2c_probe() callback exists, the i3c layer could construct
a 'struct i2c_driver' with those callbacks and register that under the
cover. This would mean that combined drivers no longer need to
register two driver objects.
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 14:12 ` Wolfram Sang
@ 2017-08-01 14:48 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 14:48 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 16:12:18 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> > > The second way is to have a number of #ifdef and complex
> > > Kconfig dependencies for the driver to only register the
> > > device_driver objects for the buses that are enabled. This
> > > is also doable, but everyone gets the logic wrong the first time.
> >
> > Hm, I understand now why you'd prefer to have a single bus. Can't we
> > solve this problem with a module_i3c_i2c_driver() macro that would hide
> > all this complexity from I2C/I3C drivers?
>
> Do you know of devices speaking both i3c and i2c as of today?
I do not know of any real devices as of today (all my tests have been
done with a dummy/fake I3C slaves emulated with a slave IP), but the
spec clearly describe what legacy/static addresses are for and one of
their use case is to connect an I3C device on an I2C bus and let it act
as an I2C device.
>
> I think I3C/I2C is a bit different than I2C/SPI. For the latter, it
> might happen that you have only this or that bus on the board, so it
> makes sense to support both. But if you have I3C, you can simply attach
> the I2C device onto it. I guess you would only implement I3C in the
> device if you explicitly need its feature set. And then, a I2C fallback
> doesn't make much sense? Or am I missing something?
Unless you want your device (likely a sensor) to be compatible with both
I3C and I2C so that you can target even more people.
>
> OK, now I know that those I3C+I2C devices will exist, even if only for
> Murphy's law. However, my assumptions would be that those devices are
> not common and so we could live with the core plus bus_drivers
> seperation we have for SPI/I2C already (although I would love a common
> regmap-based I2C/SPI abstraction).
>
I'm perfectly fine with the I3C / I2C framework separation. The only
minor problem I had with that was the inaccuracy of the
sysfs/device-model representation: we don't have one i2c and one i3c
bus, we just have one i3c bus with a mix of i2c and i3c devices.
Apart from that, I'm happy with the current approach.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 14:48 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 14:48 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar
On Tue, 1 Aug 2017 16:12:18 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> > > The second way is to have a number of #ifdef and complex
> > > Kconfig dependencies for the driver to only register the
> > > device_driver objects for the buses that are enabled. This
> > > is also doable, but everyone gets the logic wrong the first time.
> >
> > Hm, I understand now why you'd prefer to have a single bus. Can't we
> > solve this problem with a module_i3c_i2c_driver() macro that would hide
> > all this complexity from I2C/I3C drivers?
>
> Do you know of devices speaking both i3c and i2c as of today?
I do not know of any real devices as of today (all my tests have been
done with a dummy/fake I3C slaves emulated with a slave IP), but the
spec clearly describe what legacy/static addresses are for and one of
their use case is to connect an I3C device on an I2C bus and let it act
as an I2C device.
>
> I think I3C/I2C is a bit different than I2C/SPI. For the latter, it
> might happen that you have only this or that bus on the board, so it
> makes sense to support both. But if you have I3C, you can simply attach
> the I2C device onto it. I guess you would only implement I3C in the
> device if you explicitly need its feature set. And then, a I2C fallback
> doesn't make much sense? Or am I missing something?
Unless you want your device (likely a sensor) to be compatible with both
I3C and I2C so that you can target even more people.
>
> OK, now I know that those I3C+I2C devices will exist, even if only for
> Murphy's law. However, my assumptions would be that those devices are
> not common and so we could live with the core plus bus_drivers
> seperation we have for SPI/I2C already (although I would love a common
> regmap-based I2C/SPI abstraction).
>
I'm perfectly fine with the I3C / I2C framework separation. The only
minor problem I had with that was the inaccuracy of the
sysfs/device-model representation: we don't have one i2c and one i3c
bus, we just have one i3c bus with a mix of i2c and i3c devices.
Apart from that, I'm happy with the current approach.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 14:48 ` Boris Brezillon
@ 2017-08-01 15:01 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 15:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
> I do not know of any real devices as of today (all my tests have been
> done with a dummy/fake I3C slaves emulated with a slave IP),
I see.
> spec clearly describe what legacy/static addresses are for and one of
> their use case is to connect an I3C device on an I2C bus and let it act
> as an I2C device.
OK. That makes it more likely.
> Unless you want your device (likely a sensor) to be compatible with both
> I3C and I2C so that you can target even more people.
Right. My question was if this is a realistic or more academic scenario.
> I'm perfectly fine with the I3C / I2C framework separation. The only
> minor problem I had with that was the inaccuracy of the
> sysfs/device-model representation: we don't have one i2c and one i3c
> bus, we just have one i3c bus with a mix of i2c and i3c devices.
I understand that. What if I2C had the same seperation between the "bus"
and the "master"?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 15:01 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 15:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
> I do not know of any real devices as of today (all my tests have been
> done with a dummy/fake I3C slaves emulated with a slave IP),
I see.
> spec clearly describe what legacy/static addresses are for and one of
> their use case is to connect an I3C device on an I2C bus and let it act
> as an I2C device.
OK. That makes it more likely.
> Unless you want your device (likely a sensor) to be compatible with both
> I3C and I2C so that you can target even more people.
Right. My question was if this is a realistic or more academic scenario.
> I'm perfectly fine with the I3C / I2C framework separation. The only
> minor problem I had with that was the inaccuracy of the
> sysfs/device-model representation: we don't have one i2c and one i3c
> bus, we just have one i3c bus with a mix of i2c and i3c devices.
I understand that. What if I2C had the same seperation between the "bus"
and the "master"?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 14:22 ` Arnd Bergmann
@ 2017-08-01 15:14 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 15:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 16:22:21 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Tue, 1 Aug 2017 15:34:14 +0200
> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> >> On Tue, 1 Aug 2017 15:11:44 +0200
> >> Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> >> > <boris.brezillon@free-electrons.com> wrote:
> > I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
> > entry. Indeed, I'm unconditionally calling functions provided by the
> > I2C framework which have no dummy wrapper when I2C support is disabled.
> > I could of course conditionally compile some portion of the I3C
> > framework so that it still builds when I2C is disabled but I'm not sure
> > it's worth the trouble.
> >
> > This "depends on I2C" should also solve the I2C+I3C driver issue, since
> > I2C is necessarily enabled when I3C is.
> >
> > Am I missing something?
>
> That should solve another part of the problem, as a combined driver then
> just needs 'depends on I3C'.
>
> On top of that, the i3c_driver structure could also contain callback
> pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
> When the i2c_probe() callback exists, the i3c layer could construct
> a 'struct i2c_driver' with those callbacks and register that under the
> cover. This would mean that combined drivers no longer need to
> register two driver objects.
That should work. Actually, i2c_driver contains a few more hooks, like
->alert(), ->command() and ->detect(). Of course we could assume that
I3C/I2C drivers do not need them, but I'm wondering if it's not easier
to just add an i2c_driver pointer inside the i3c_driver struct and let
the driver populate it if it needs to supports both protocols.
Something like:
struct i3c_driver {
...
struct i2c_driver *i2c_compat;
...
};
and then in I3C/I2C drivers:
static struct i2c_driver my_i2c_driver = {
...
};
static struct i3c_driver my_i3c_driver = {
...
.i2c_compat = &my_i2c_driver,
...
};
module_i3c_driver(my_i3c_driver);
Of course, you'll have a few fields of ->i2c_compat that would be
filled by the core (like the driver name which can be extracted from
my_i3c_driver->driver.name).
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 15:14 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 15:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Ku
On Tue, 1 Aug 2017 16:22:21 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Tue, 1 Aug 2017 15:34:14 +0200
> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> >> On Tue, 1 Aug 2017 15:11:44 +0200
> >> Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
> >> > <boris.brezillon@free-electrons.com> wrote:
> > I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
> > entry. Indeed, I'm unconditionally calling functions provided by the
> > I2C framework which have no dummy wrapper when I2C support is disabled.
> > I could of course conditionally compile some portion of the I3C
> > framework so that it still builds when I2C is disabled but I'm not sure
> > it's worth the trouble.
> >
> > This "depends on I2C" should also solve the I2C+I3C driver issue, since
> > I2C is necessarily enabled when I3C is.
> >
> > Am I missing something?
>
> That should solve another part of the problem, as a combined driver then
> just needs 'depends on I3C'.
>
> On top of that, the i3c_driver structure could also contain callback
> pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
> When the i2c_probe() callback exists, the i3c layer could construct
> a 'struct i2c_driver' with those callbacks and register that under the
> cover. This would mean that combined drivers no longer need to
> register two driver objects.
That should work. Actually, i2c_driver contains a few more hooks, like
->alert(), ->command() and ->detect(). Of course we could assume that
I3C/I2C drivers do not need them, but I'm wondering if it's not easier
to just add an i2c_driver pointer inside the i3c_driver struct and let
the driver populate it if it needs to supports both protocols.
Something like:
struct i3c_driver {
...
struct i2c_driver *i2c_compat;
...
};
and then in I3C/I2C drivers:
static struct i2c_driver my_i2c_driver = {
...
};
static struct i3c_driver my_i3c_driver = {
...
.i2c_compat = &my_i2c_driver,
...
};
module_i3c_driver(my_i3c_driver);
Of course, you'll have a few fields of ->i2c_compat that would be
filled by the core (like the driver name which can be extracted from
my_i3c_driver->driver.name).
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 15:01 ` Wolfram Sang
@ 2017-08-01 15:20 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 15:20 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 17:01:08 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> > I do not know of any real devices as of today (all my tests have been
> > done with a dummy/fake I3C slaves emulated with a slave IP),
>
> I see.
>
> > spec clearly describe what legacy/static addresses are for and one of
> > their use case is to connect an I3C device on an I2C bus and let it act
> > as an I2C device.
>
> OK. That makes it more likely.
>
> > Unless you want your device (likely a sensor) to be compatible with both
> > I3C and I2C so that you can target even more people.
>
> Right. My question was if this is a realistic or more academic scenario.
>
> > I'm perfectly fine with the I3C / I2C framework separation. The only
> > minor problem I had with that was the inaccuracy of the
> > sysfs/device-model representation: we don't have one i2c and one i3c
> > bus, we just have one i3c bus with a mix of i2c and i3c devices.
>
> I understand that. What if I2C had the same seperation between the "bus"
> and the "master"?
>
Yep, it might work if we can register an i2c_adapter and pass it an
existing bus object. We'd still need a common base for i2c and i3c
busses, unless we consider the bus as an opaque "struct device *"
object.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 15:20 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 15:20 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar
On Tue, 1 Aug 2017 17:01:08 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> > I do not know of any real devices as of today (all my tests have been
> > done with a dummy/fake I3C slaves emulated with a slave IP),
>
> I see.
>
> > spec clearly describe what legacy/static addresses are for and one of
> > their use case is to connect an I3C device on an I2C bus and let it act
> > as an I2C device.
>
> OK. That makes it more likely.
>
> > Unless you want your device (likely a sensor) to be compatible with both
> > I3C and I2C so that you can target even more people.
>
> Right. My question was if this is a realistic or more academic scenario.
>
> > I'm perfectly fine with the I3C / I2C framework separation. The only
> > minor problem I had with that was the inaccuracy of the
> > sysfs/device-model representation: we don't have one i2c and one i3c
> > bus, we just have one i3c bus with a mix of i2c and i3c devices.
>
> I understand that. What if I2C had the same seperation between the "bus"
> and the "master"?
>
Yep, it might work if we can register an i2c_adapter and pass it an
existing bus object. We'd still need a common base for i2c and i3c
busses, unless we consider the bus as an opaque "struct device *"
object.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 21:42 ` Wolfram Sang
@ 2017-08-01 16:47 ` Andrew F. Davis
-1 siblings, 0 replies; 91+ messages in thread
From: Andrew F. Davis @ 2017-08-01 16:47 UTC (permalink / raw)
To: Wolfram Sang, Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On 07/31/2017 04:42 PM, Wolfram Sang wrote:
>
>> Actually, that's the first option I considered, but I3C and I2C are
>> really different. I'm not talking about the physical layer here, but
>> the way the bus has to be handled by the software layer. Actually, I
>> thing the I3C bus is philosophically closer to auto-discoverable busses
>> like USB than I2C or SPI.
>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
>
>> Of course, I can move all the code in drivers/i2c/, but that won't
>> change the fact that I3C and I2C busses are completely different
>> with little to share between them.
>
> That wouldn't make sense.
>
>> To me, the I2C backward compatibility is just a nice feature that was
>> added to help people smoothly transition from mixed I3C busses with
>> both I2C and I3C devices connected to it (I2C devices being here
>> when no (affordable) equivalent exist in the I3C world) to pure I3C
>> busses with only I3C devices connected to it.
>
> Yeah, and it is still to be seen how good this really works. Devices
> which do clock stretching are out of the question. Probably everything
> which needs an interrupt as well?
>
I'm surprised they didn't allow for slave clock stretching when
communicating with a legacy i2c device, it will prohibit use of a rather
large class of devices. :(
As for interrupts you are always free to wire up an out-of-band
interrupt like before. :)
>> This being said, I'd be happy if you prove me wrong and propose a
>> solution that allows us to extend the I2C framework to support I3C
>> without to much pain ;-).
>
> From all I know, I don't see that coming.
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 16:47 ` Andrew F. Davis
0 siblings, 0 replies; 91+ messages in thread
From: Andrew F. Davis @ 2017-08-01 16:47 UTC (permalink / raw)
To: Wolfram Sang, Boris Brezillon
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
On 07/31/2017 04:42 PM, Wolfram Sang wrote:
>
>> Actually, that's the first option I considered, but I3C and I2C are
>> really different. I'm not talking about the physical layer here, but
>> the way the bus has to be handled by the software layer. Actually, I
>> thing the I3C bus is philosophically closer to auto-discoverable busses
>> like USB than I2C or SPI.
>
> Acked-by: Wolfram Sang <wsa@the-dreams.de>
>
>> Of course, I can move all the code in drivers/i2c/, but that won't
>> change the fact that I3C and I2C busses are completely different
>> with little to share between them.
>
> That wouldn't make sense.
>
>> To me, the I2C backward compatibility is just a nice feature that was
>> added to help people smoothly transition from mixed I3C busses with
>> both I2C and I3C devices connected to it (I2C devices being here
>> when no (affordable) equivalent exist in the I3C world) to pure I3C
>> busses with only I3C devices connected to it.
>
> Yeah, and it is still to be seen how good this really works. Devices
> which do clock stretching are out of the question. Probably everything
> which needs an interrupt as well?
>
I'm surprised they didn't allow for slave clock stretching when
communicating with a legacy i2c device, it will prohibit use of a rather
large class of devices. :(
As for interrupts you are always free to wire up an out-of-band
interrupt like before. :)
>> This being said, I'd be happy if you prove me wrong and propose a
>> solution that allows us to extend the I2C framework to support I3C
>> without to much pain ;-).
>
> From all I know, I don't see that coming.
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 16:47 ` Andrew F. Davis
@ 2017-08-01 17:27 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 17:27 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Boris Brezillon, Arnd Bergmann, linux-i2c, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
> I'm surprised they didn't allow for slave clock stretching when
> communicating with a legacy i2c device, it will prohibit use of a rather
> large class of devices. :(
Yes, but I3C is push/pull IIRC.
> As for interrupts you are always free to wire up an out-of-band
> interrupt like before. :)
Yes, my wording was a bit too strong. It is possible, sure. Yet, I
understood that one of the features of I3C is to have in-band interrupt
support. We will see if the demand for backward compatibility or "saving
pins" is higher.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 17:27 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-01 17:27 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Boris Brezillon, Arnd Bergmann, linux-i2c, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
> I'm surprised they didn't allow for slave clock stretching when
> communicating with a legacy i2c device, it will prohibit use of a rather
> large class of devices. :(
Yes, but I3C is push/pull IIRC.
> As for interrupts you are always free to wire up an out-of-band
> interrupt like before. :)
Yes, my wording was a bit too strong. It is possible, sure. Yet, I
understood that one of the features of I3C is to have in-band interrupt
support. We will see if the demand for backward compatibility or "saving
pins" is higher.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 10:48 ` Boris Brezillon
@ 2017-08-01 17:51 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-01 17:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > +static DEFINE_MUTEX(i3c_core_lock);
> > > +
> > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > +{
> > > + if (exclusive)
> > > + down_write(&bus->lock);
> > > + else
> > > + down_read(&bus->lock);
> > > +}
> >
> > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > you agree?
>
> I could create 2 functions, one for the exclusive lock and the other
> one for the shared lock.
Or you could just use a simple mutex until you determine you really
would do better with a rw lock :)
> > And have you measured the difference in using a rw lock over
> > a normal mutex and found it to be faster? If not, just use a normal
> > mutex, it's simpler and almost always better in the end.
>
> I did not measure the difference, but using a standard lock means
> serializing all I3C accesses going through a given master in the core.
Which you are doing with a rw lock anyway, right?
> Note that this lock is not here to guarantee that calls to
> master->ops->xxx() are serialized (this part is left to the master
> driver), but to ensure that when a bus management operation is in
> progress (like changing the address of a device on the bus), no one can
> send I3C frames. If we don't do that, one could queue an I3C transfer,
> and by the time this transfer reach the bus, the I3C device this
> message was targeting may have a different address.
That sounds really odd. locks should protect data, not bus access,
right?
> Unless you see a good reason to not use a R/W lock, I'd like to keep it
> this way because master IPs are likely to implement advanced queuing
> mechanism (allows one to queue new transfers even if the master is
> already busy processing other requests), and serializing things at the
> framework level will just prevent us from using this kind of
> optimization.
Unless you can prove otherwise, using a rw lock is almost always worse
than just a mutex. And you shouldn't have a lock for bus transactions,
that's just going to be a total mess. You could have a lock for a
single device access, but that still seems really strange, is the i3c
spec that bad?
> > > +static ssize_t hdrcap_show(struct device *dev,
> > > + struct device_attribute *da,
> > > + char *buf)
> > > +{
> > > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > > + unsigned long caps = i3cdev->info.hdr_cap;
> > > + ssize_t offset = 0, ret;
> > > + int mode;
> > > +
> > > + i3c_bus_lock(bus, false);
> > > + for_each_set_bit(mode, &caps, 8) {
> > > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > > + break;
> > > +
> > > + if (!hdrcap_strings[mode])
> > > + continue;
> > > +
> > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> >
> > Multiple lines in a single sysfs file? No.
>
> Okay. Would that be okay with a different separator (like a comma)?
No, sysfs files are "one value per file", given you don't have any
documentation saying what this file is supposed to be showing, I can't
really judge the proper way for you to present it to userspace :)
> > > +static const struct attribute_group *i3c_device_groups[] = {
> > > + &i3c_device_group,
> > > + NULL,
> > > +};
> >
> > ATTRIBUTE_GROUPS()?
>
> My initial plan was to have a common set of attributes that apply to
> both devices and masters, and then add specific attributes in each of
> them when they only apply to a specific device type.
That's fine, but you do know that attributes can be enabled/disabled at
device creation time with the return value of the callback is_visable(),
right? Why not just use that here, simplifying a lot of logic?
> Just out of curiosity, what's the preferred solution when you need to
> do something like that? Should we just use ATTRIBUTE_GROUPS() and
> duplicate the entries that apply to both device types?
is_visable()?
> > No release type? Oh that's bad bad bad and implies you have never
> > removed a device from your system as the kernel would have complained
> > loudly at you.
>
> You got me, never tried to remove a device :-). Note that these
> ->release() hooks will just be dummy ones, because right now, device
> resources are freed at bus destruction time.
You better not have a "dummy" release hook, do that and as per the
kernel documentation, I get to make fun of you in public for doing that
:(
> Also, I see that dev->release() is called instead of
> dev->type->release() if it's not NULL [1]. what's the preferred solution
> here? Set dev->release or type->release()?
It depends on how your bus is managed, who controls the creation of the
resources, free it in the same place you create it.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 17:51 ` Greg Kroah-Hartman
0 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-01 17:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > +static DEFINE_MUTEX(i3c_core_lock);
> > > +
> > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > +{
> > > + if (exclusive)
> > > + down_write(&bus->lock);
> > > + else
> > > + down_read(&bus->lock);
> > > +}
> >
> > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > you agree?
>
> I could create 2 functions, one for the exclusive lock and the other
> one for the shared lock.
Or you could just use a simple mutex until you determine you really
would do better with a rw lock :)
> > And have you measured the difference in using a rw lock over
> > a normal mutex and found it to be faster? If not, just use a normal
> > mutex, it's simpler and almost always better in the end.
>
> I did not measure the difference, but using a standard lock means
> serializing all I3C accesses going through a given master in the core.
Which you are doing with a rw lock anyway, right?
> Note that this lock is not here to guarantee that calls to
> master->ops->xxx() are serialized (this part is left to the master
> driver), but to ensure that when a bus management operation is in
> progress (like changing the address of a device on the bus), no one can
> send I3C frames. If we don't do that, one could queue an I3C transfer,
> and by the time this transfer reach the bus, the I3C device this
> message was targeting may have a different address.
That sounds really odd. locks should protect data, not bus access,
right?
> Unless you see a good reason to not use a R/W lock, I'd like to keep it
> this way because master IPs are likely to implement advanced queuing
> mechanism (allows one to queue new transfers even if the master is
> already busy processing other requests), and serializing things at the
> framework level will just prevent us from using this kind of
> optimization.
Unless you can prove otherwise, using a rw lock is almost always worse
than just a mutex. And you shouldn't have a lock for bus transactions,
that's just going to be a total mess. You could have a lock for a
single device access, but that still seems really strange, is the i3c
spec that bad?
> > > +static ssize_t hdrcap_show(struct device *dev,
> > > + struct device_attribute *da,
> > > + char *buf)
> > > +{
> > > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > > + unsigned long caps = i3cdev->info.hdr_cap;
> > > + ssize_t offset = 0, ret;
> > > + int mode;
> > > +
> > > + i3c_bus_lock(bus, false);
> > > + for_each_set_bit(mode, &caps, 8) {
> > > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > > + break;
> > > +
> > > + if (!hdrcap_strings[mode])
> > > + continue;
> > > +
> > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> >
> > Multiple lines in a single sysfs file? No.
>
> Okay. Would that be okay with a different separator (like a comma)?
No, sysfs files are "one value per file", given you don't have any
documentation saying what this file is supposed to be showing, I can't
really judge the proper way for you to present it to userspace :)
> > > +static const struct attribute_group *i3c_device_groups[] = {
> > > + &i3c_device_group,
> > > + NULL,
> > > +};
> >
> > ATTRIBUTE_GROUPS()?
>
> My initial plan was to have a common set of attributes that apply to
> both devices and masters, and then add specific attributes in each of
> them when they only apply to a specific device type.
That's fine, but you do know that attributes can be enabled/disabled at
device creation time with the return value of the callback is_visable(),
right? Why not just use that here, simplifying a lot of logic?
> Just out of curiosity, what's the preferred solution when you need to
> do something like that? Should we just use ATTRIBUTE_GROUPS() and
> duplicate the entries that apply to both device types?
is_visable()?
> > No release type? Oh that's bad bad bad and implies you have never
> > removed a device from your system as the kernel would have complained
> > loudly at you.
>
> You got me, never tried to remove a device :-). Note that these
> ->release() hooks will just be dummy ones, because right now, device
> resources are freed at bus destruction time.
You better not have a "dummy" release hook, do that and as per the
kernel documentation, I get to make fun of you in public for doing that
:(
> Also, I see that dev->release() is called instead of
> dev->type->release() if it's not NULL [1]. what's the preferred solution
> here? Set dev->release or type->release()?
It depends on how your bus is managed, who controls the creation of the
resources, free it in the same place you create it.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 15:14 ` Boris Brezillon
@ 2017-08-01 20:16 ` Arnd Bergmann
-1 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 20:16 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, Aug 1, 2017 at 5:14 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>> > On Tue, 1 Aug 2017 15:34:14 +0200
>> > Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>> >> On Tue, 1 Aug 2017 15:11:44 +0200
>> >> Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> >> > <boris.brezillon@free-electrons.com> wrote:
>> > I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
>> > entry. Indeed, I'm unconditionally calling functions provided by the
>> > I2C framework which have no dummy wrapper when I2C support is disabled.
>> > I could of course conditionally compile some portion of the I3C
>> > framework so that it still builds when I2C is disabled but I'm not sure
>> > it's worth the trouble.
>> >
>> > This "depends on I2C" should also solve the I2C+I3C driver issue, since
>> > I2C is necessarily enabled when I3C is.
>> >
>> > Am I missing something?
>>
>> That should solve another part of the problem, as a combined driver then
>> just needs 'depends on I3C'.
>>
>> On top of that, the i3c_driver structure could also contain callback
>> pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
>> When the i2c_probe() callback exists, the i3c layer could construct
>> a 'struct i2c_driver' with those callbacks and register that under the
>> cover. This would mean that combined drivers no longer need to
>> register two driver objects.
>
> That should work. Actually, i2c_driver contains a few more hooks, like
> ->alert(), ->command() and ->detect(). Of course we could assume that
> I3C/I2C drivers do not need them,
I was thinking we can add them as they are needed.
> but I'm wondering if it's not easier
> to just add an i2c_driver pointer inside the i3c_driver struct and let
> the driver populate it if it needs to supports both protocols.
>
> Something like:
>
> struct i3c_driver {
> ...
> struct i2c_driver *i2c_compat;
> ...
> };
>
>
> and then in I3C/I2C drivers:
>
> static struct i2c_driver my_i2c_driver = {
> ...
> };
>
> static struct i3c_driver my_i3c_driver = {
> ...
> .i2c_compat = &my_i2c_driver,
> ...
> };
> module_i3c_driver(my_i3c_driver);
>
>
>
> Of course, you'll have a few fields of ->i2c_compat that would be
> filled by the core (like the driver name which can be extracted from
> my_i3c_driver->driver.name).
Right, that would work too, but it's almost the same as the version
you proposed earlier that would use
module_i2c_i3c_driver(my_i2c_driver, my_i3c_driver);
It's probably a little cleaner this way in the subsystem implementation
compared to my suggestion of adding the i2c callback pointers in
struct i3c_driver, while that would make the drivers look a little nicer
(and save a few lines per driver).
Arnd
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 20:16 ` Arnd Bergmann
0 siblings, 0 replies; 91+ messages in thread
From: Arnd Bergmann @ 2017-08-01 20:16 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Ku
On Tue, Aug 1, 2017 at 5:14 PM, Boris Brezillon
<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, 1 Aug 2017 16:22:21 +0200 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> On Tue, Aug 1, 2017 at 3:58 PM, Boris Brezillon
>> <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > On Tue, 1 Aug 2017 15:34:14 +0200
>> > Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> >> On Tue, 1 Aug 2017 15:11:44 +0200
>> >> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> >> > On Tue, Aug 1, 2017 at 2:29 PM, Boris Brezillon
>> >> > <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > I just realized I forgot to add a "depends on I2C" in the I3C Kconfig
>> > entry. Indeed, I'm unconditionally calling functions provided by the
>> > I2C framework which have no dummy wrapper when I2C support is disabled.
>> > I could of course conditionally compile some portion of the I3C
>> > framework so that it still builds when I2C is disabled but I'm not sure
>> > it's worth the trouble.
>> >
>> > This "depends on I2C" should also solve the I2C+I3C driver issue, since
>> > I2C is necessarily enabled when I3C is.
>> >
>> > Am I missing something?
>>
>> That should solve another part of the problem, as a combined driver then
>> just needs 'depends on I3C'.
>>
>> On top of that, the i3c_driver structure could also contain callback
>> pointers for the i2c subsystem, e.g. i2c_probe(), i2c_remove() etc.
>> When the i2c_probe() callback exists, the i3c layer could construct
>> a 'struct i2c_driver' with those callbacks and register that under the
>> cover. This would mean that combined drivers no longer need to
>> register two driver objects.
>
> That should work. Actually, i2c_driver contains a few more hooks, like
> ->alert(), ->command() and ->detect(). Of course we could assume that
> I3C/I2C drivers do not need them,
I was thinking we can add them as they are needed.
> but I'm wondering if it's not easier
> to just add an i2c_driver pointer inside the i3c_driver struct and let
> the driver populate it if it needs to supports both protocols.
>
> Something like:
>
> struct i3c_driver {
> ...
> struct i2c_driver *i2c_compat;
> ...
> };
>
>
> and then in I3C/I2C drivers:
>
> static struct i2c_driver my_i2c_driver = {
> ...
> };
>
> static struct i3c_driver my_i3c_driver = {
> ...
> .i2c_compat = &my_i2c_driver,
> ...
> };
> module_i3c_driver(my_i3c_driver);
>
>
>
> Of course, you'll have a few fields of ->i2c_compat that would be
> filled by the core (like the driver name which can be extracted from
> my_i3c_driver->driver.name).
Right, that would work too, but it's almost the same as the version
you proposed earlier that would use
module_i2c_i3c_driver(my_i2c_driver, my_i3c_driver);
It's probably a little cleaner this way in the subsystem implementation
compared to my suggestion of adding the i2c callback pointers in
struct i3c_driver, while that would make the drivers look a little nicer
(and save a few lines per driver).
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 17:51 ` Greg Kroah-Hartman
@ 2017-08-01 21:30 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 21:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
Hi Greg,
Le Tue, 1 Aug 2017 10:51:33 -0700,
Greg Kroah-Hartman <gregkh@linuxfoundation.org> a écrit :
> On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > +
> > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > > +{
> > > > + if (exclusive)
> > > > + down_write(&bus->lock);
> > > > + else
> > > > + down_read(&bus->lock);
> > > > +}
> > >
> > > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > > you agree?
> >
> > I could create 2 functions, one for the exclusive lock and the other
> > one for the shared lock.
>
> Or you could just use a simple mutex until you determine you really
> would do better with a rw lock :)
>
> > > And have you measured the difference in using a rw lock over
> > > a normal mutex and found it to be faster? If not, just use a normal
> > > mutex, it's simpler and almost always better in the end.
> >
> > I did not measure the difference, but using a standard lock means
> > serializing all I3C accesses going through a given master in the core.
>
> Which you are doing with a rw lock anyway, right?
Absolutely not. If you look more closely at the code you'll see that
most of the time the lock is taken in read/non-exclusive mode. The only
situations where it's taken in exclusive mode is when the operation (and
associated command) has an impact on the bus and/or its devices.
For instance, resetting addresses of all I3C devices on the bus (using
RSTDAA) means you won't be able to send I3C messages to these devices
after that. If you don't take an exclusive lock to protect this
operation, that means you might end up with drivers queuing messages
with a device address that is about to be invalid. Also, we might soon
provide the possibility to change I3C dynamic address at runtime, which
is important since the dynamic address also encodes the priority of the
device when it's generating in-band interrupts (the lower the address
the higher the priority). We need this 'change dynamic address'
operation to be atomic for the same reason: to prevent drivers from
sending messages to an invalid address.
>
> > Note that this lock is not here to guarantee that calls to
> > master->ops->xxx() are serialized (this part is left to the master
> > driver), but to ensure that when a bus management operation is in
> > progress (like changing the address of a device on the bus), no one can
> > send I3C frames. If we don't do that, one could queue an I3C transfer,
> > and by the time this transfer reach the bus, the I3C device this
> > message was targeting may have a different address.
>
> That sounds really odd. locks should protect data, not bus access,
> right?
Well, it's protecting data: the dynamic address is a piece of
information attached to the device.
>
> > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > this way because master IPs are likely to implement advanced queuing
> > mechanism (allows one to queue new transfers even if the master is
> > already busy processing other requests), and serializing things at the
> > framework level will just prevent us from using this kind of
> > optimization.
>
> Unless you can prove otherwise, using a rw lock is almost always worse
> than just a mutex.
Is it still true when it's taken in non-exclusive mode most of the
time, and the time you spend in the critical section is non-negligible?
I won't pretend I know better than you do what is preferable, it's just
that the RW lock seemed appropriate to me for the situation I tried to
described here.
> And you shouldn't have a lock for bus transactions,
> that's just going to be a total mess.
It's not a lock for bus transactions, it's lock to protect from any
operation that can have an impact on the bus or its devices (see the
'change device address' example above).
> You could have a lock for a
> single device access, but that still seems really strange, is the i3c
> spec that bad?
Having a lock per device would complicate even more the situation
because some operations like the broadcasted RSTDAA have an impact on
all devices on the bus.
>
> > > > +static ssize_t hdrcap_show(struct device *dev,
> > > > + struct device_attribute *da,
> > > > + char *buf)
> > > > +{
> > > > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > > > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > > > + unsigned long caps = i3cdev->info.hdr_cap;
> > > > + ssize_t offset = 0, ret;
> > > > + int mode;
> > > > +
> > > > + i3c_bus_lock(bus, false);
> > > > + for_each_set_bit(mode, &caps, 8) {
> > > > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > > > + break;
> > > > +
> > > > + if (!hdrcap_strings[mode])
> > > > + continue;
> > > > +
> > > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> > >
> > > Multiple lines in a single sysfs file? No.
> >
> > Okay. Would that be okay with a different separator (like a comma)?
>
> No, sysfs files are "one value per file", given you don't have any
> documentation saying what this file is supposed to be showing, I can't
> really judge the proper way for you to present it to userspace :)
Okay. Let's put that aside until I send a v2 with a sysfs doc.
Still, note that the "one value per file" rule does not apply to all
sysfs files. I have 2 examples in mind (maybe they are bad examples,
but they exist):
- /sys/class/leds/<led>/trigger returns a list of supported triggers
each of them is separated by a space
- /sys/class/graphics/<fbx>/modes lists the supported video modes, one
per line
>
> > > > +static const struct attribute_group *i3c_device_groups[] = {
> > > > + &i3c_device_group,
> > > > + NULL,
> > > > +};
> > >
> > > ATTRIBUTE_GROUPS()?
> >
> > My initial plan was to have a common set of attributes that apply to
> > both devices and masters, and then add specific attributes in each of
> > them when they only apply to a specific device type.
>
> That's fine, but you do know that attributes can be enabled/disabled at
> device creation time with the return value of the callback is_visable(),
> right? Why not just use that here, simplifying a lot of logic?
I didn't know that, thanks for the hint.
>
> > Just out of curiosity, what's the preferred solution when you need to
> > do something like that? Should we just use ATTRIBUTE_GROUPS() and
> > duplicate the entries that apply to both device types?
>
> is_visable()?
>
> > > No release type? Oh that's bad bad bad and implies you have never
> > > removed a device from your system as the kernel would have complained
> > > loudly at you.
> >
> > You got me, never tried to remove a device :-). Note that these
> > ->release() hooks will just be dummy ones, because right now, device
> > resources are freed at bus destruction time.
>
> You better not have a "dummy" release hook, do that and as per the
> kernel documentation, I get to make fun of you in public for doing that
> :(
I'm not afraid of admitting I don't know everything, even the
simplest things that you consider as basics for a kernel developer. You
can make fun of me publicly if you want but that's not helping :-P.
BTW, the very reason I Cc-ed you in the first place is to have feedback
on this implementation, and please note that this is an RFC, so of
course, not everything is perfect. I'm here to learn from your reviews,
but that doesn't prevent me from asking more details about the
reasoning behind your suggestions. That's part of the learning process,
right?
The reason I proposed this dummy ->release() hook is because the
lifetime of the i2c/i3c dev allocated by the I3C framework goes beyond
the underlying struct device object embedded in it. Indeed, when the
i3c_device object is allocated, the I3C master can attach private data
to it (this is done inside master->ops->bus_init()), and these data
are expected to be freed in master->ops->bus_cleanup() which is done
after all devices attached to the I3C bus have been unregistered (so
the ->release() callback of each I3C dev has already been called before
we enter ->bus_cleanup()).
Now, maybe I took a wrong approach here, but I just wanted to explain
why releasing the I3C dev inside dev->release() or
dev->type->release() is not possible with the current implementation.
>
> > Also, I see that dev->release() is called instead of
> > dev->type->release() if it's not NULL [1]. what's the preferred solution
> > here? Set dev->release or type->release()?
>
> It depends on how your bus is managed, who controls the creation of the
> resources, free it in the same place you create it.
I3C devices are allocated by the master inside its ->bus_init() hook,
and I currently free all devices in i3c_bus_cleanup(), which is kind of
symmetric.
I understand that you're not happy with this solution, so I'll try to
come up with a different approach where dev->release() calls a master
hook to release private master data and only then frees the i3c_device
object.
I hope you're not taking my answers as a sign of arrogance, because
this is definitely not what it is. I just want to make sure you
understand why I made some (bad?) choices when designing this framework.
I really appreciate your reviews and will of course take all of your
comments into account before sending a v2.
Thanks for your time.
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 21:30 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 21:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
Hi Greg,
Le Tue, 1 Aug 2017 10:51:33 -0700,
Greg Kroah-Hartman <gregkh@linuxfoundation.org> a écrit :
> On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > +
> > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > > +{
> > > > + if (exclusive)
> > > > + down_write(&bus->lock);
> > > > + else
> > > > + down_read(&bus->lock);
> > > > +}
> > >
> > > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > > you agree?
> >
> > I could create 2 functions, one for the exclusive lock and the other
> > one for the shared lock.
>
> Or you could just use a simple mutex until you determine you really
> would do better with a rw lock :)
>
> > > And have you measured the difference in using a rw lock over
> > > a normal mutex and found it to be faster? If not, just use a normal
> > > mutex, it's simpler and almost always better in the end.
> >
> > I did not measure the difference, but using a standard lock means
> > serializing all I3C accesses going through a given master in the core.
>
> Which you are doing with a rw lock anyway, right?
Absolutely not. If you look more closely at the code you'll see that
most of the time the lock is taken in read/non-exclusive mode. The only
situations where it's taken in exclusive mode is when the operation (and
associated command) has an impact on the bus and/or its devices.
For instance, resetting addresses of all I3C devices on the bus (using
RSTDAA) means you won't be able to send I3C messages to these devices
after that. If you don't take an exclusive lock to protect this
operation, that means you might end up with drivers queuing messages
with a device address that is about to be invalid. Also, we might soon
provide the possibility to change I3C dynamic address at runtime, which
is important since the dynamic address also encodes the priority of the
device when it's generating in-band interrupts (the lower the address
the higher the priority). We need this 'change dynamic address'
operation to be atomic for the same reason: to prevent drivers from
sending messages to an invalid address.
>
> > Note that this lock is not here to guarantee that calls to
> > master->ops->xxx() are serialized (this part is left to the master
> > driver), but to ensure that when a bus management operation is in
> > progress (like changing the address of a device on the bus), no one can
> > send I3C frames. If we don't do that, one could queue an I3C transfer,
> > and by the time this transfer reach the bus, the I3C device this
> > message was targeting may have a different address.
>
> That sounds really odd. locks should protect data, not bus access,
> right?
Well, it's protecting data: the dynamic address is a piece of
information attached to the device.
>
> > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > this way because master IPs are likely to implement advanced queuing
> > mechanism (allows one to queue new transfers even if the master is
> > already busy processing other requests), and serializing things at the
> > framework level will just prevent us from using this kind of
> > optimization.
>
> Unless you can prove otherwise, using a rw lock is almost always worse
> than just a mutex.
Is it still true when it's taken in non-exclusive mode most of the
time, and the time you spend in the critical section is non-negligible?
I won't pretend I know better than you do what is preferable, it's just
that the RW lock seemed appropriate to me for the situation I tried to
described here.
> And you shouldn't have a lock for bus transactions,
> that's just going to be a total mess.
It's not a lock for bus transactions, it's lock to protect from any
operation that can have an impact on the bus or its devices (see the
'change device address' example above).
> You could have a lock for a
> single device access, but that still seems really strange, is the i3c
> spec that bad?
Having a lock per device would complicate even more the situation
because some operations like the broadcasted RSTDAA have an impact on
all devices on the bus.
>
> > > > +static ssize_t hdrcap_show(struct device *dev,
> > > > + struct device_attribute *da,
> > > > + char *buf)
> > > > +{
> > > > + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> > > > + struct i3c_bus *bus = i3c_device_get_bus(i3cdev);
> > > > + unsigned long caps = i3cdev->info.hdr_cap;
> > > > + ssize_t offset = 0, ret;
> > > > + int mode;
> > > > +
> > > > + i3c_bus_lock(bus, false);
> > > > + for_each_set_bit(mode, &caps, 8) {
> > > > + if (mode >= ARRAY_SIZE(hdrcap_strings))
> > > > + break;
> > > > +
> > > > + if (!hdrcap_strings[mode])
> > > > + continue;
> > > > +
> > > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> > >
> > > Multiple lines in a single sysfs file? No.
> >
> > Okay. Would that be okay with a different separator (like a comma)?
>
> No, sysfs files are "one value per file", given you don't have any
> documentation saying what this file is supposed to be showing, I can't
> really judge the proper way for you to present it to userspace :)
Okay. Let's put that aside until I send a v2 with a sysfs doc.
Still, note that the "one value per file" rule does not apply to all
sysfs files. I have 2 examples in mind (maybe they are bad examples,
but they exist):
- /sys/class/leds/<led>/trigger returns a list of supported triggers
each of them is separated by a space
- /sys/class/graphics/<fbx>/modes lists the supported video modes, one
per line
>
> > > > +static const struct attribute_group *i3c_device_groups[] = {
> > > > + &i3c_device_group,
> > > > + NULL,
> > > > +};
> > >
> > > ATTRIBUTE_GROUPS()?
> >
> > My initial plan was to have a common set of attributes that apply to
> > both devices and masters, and then add specific attributes in each of
> > them when they only apply to a specific device type.
>
> That's fine, but you do know that attributes can be enabled/disabled at
> device creation time with the return value of the callback is_visable(),
> right? Why not just use that here, simplifying a lot of logic?
I didn't know that, thanks for the hint.
>
> > Just out of curiosity, what's the preferred solution when you need to
> > do something like that? Should we just use ATTRIBUTE_GROUPS() and
> > duplicate the entries that apply to both device types?
>
> is_visable()?
>
> > > No release type? Oh that's bad bad bad and implies you have never
> > > removed a device from your system as the kernel would have complained
> > > loudly at you.
> >
> > You got me, never tried to remove a device :-). Note that these
> > ->release() hooks will just be dummy ones, because right now, device
> > resources are freed at bus destruction time.
>
> You better not have a "dummy" release hook, do that and as per the
> kernel documentation, I get to make fun of you in public for doing that
> :(
I'm not afraid of admitting I don't know everything, even the
simplest things that you consider as basics for a kernel developer. You
can make fun of me publicly if you want but that's not helping :-P.
BTW, the very reason I Cc-ed you in the first place is to have feedback
on this implementation, and please note that this is an RFC, so of
course, not everything is perfect. I'm here to learn from your reviews,
but that doesn't prevent me from asking more details about the
reasoning behind your suggestions. That's part of the learning process,
right?
The reason I proposed this dummy ->release() hook is because the
lifetime of the i2c/i3c dev allocated by the I3C framework goes beyond
the underlying struct device object embedded in it. Indeed, when the
i3c_device object is allocated, the I3C master can attach private data
to it (this is done inside master->ops->bus_init()), and these data
are expected to be freed in master->ops->bus_cleanup() which is done
after all devices attached to the I3C bus have been unregistered (so
the ->release() callback of each I3C dev has already been called before
we enter ->bus_cleanup()).
Now, maybe I took a wrong approach here, but I just wanted to explain
why releasing the I3C dev inside dev->release() or
dev->type->release() is not possible with the current implementation.
>
> > Also, I see that dev->release() is called instead of
> > dev->type->release() if it's not NULL [1]. what's the preferred solution
> > here? Set dev->release or type->release()?
>
> It depends on how your bus is managed, who controls the creation of the
> resources, free it in the same place you create it.
I3C devices are allocated by the master inside its ->bus_init() hook,
and I currently free all devices in i3c_bus_cleanup(), which is kind of
symmetric.
I understand that you're not happy with this solution, so I'll try to
come up with a different approach where dev->release() calls a master
hook to release private master data and only then frees the i3c_device
object.
I hope you're not taking my answers as a sign of arrogance, because
this is definitely not what it is. I just want to make sure you
understand why I made some (bad?) choices when designing this framework.
I really appreciate your reviews and will of course take all of your
comments into account before sending a v2.
Thanks for your time.
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 17:27 ` Wolfram Sang
@ 2017-08-01 21:47 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 21:47 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andrew F. Davis, Arnd Bergmann, linux-i2c, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
Le Tue, 1 Aug 2017 19:27:03 +0200,
Wolfram Sang <wsa@the-dreams.de> a écrit :
> > I'm surprised they didn't allow for slave clock stretching when
> > communicating with a legacy i2c device, it will prohibit use of a rather
> > large class of devices. :(
>
> Yes, but I3C is push/pull IIRC.
It is.
>
> > As for interrupts you are always free to wire up an out-of-band
> > interrupt like before. :)
>
> Yes, my wording was a bit too strong. It is possible, sure. Yet, I
> understood that one of the features of I3C is to have in-band interrupt
> support. We will see if the demand for backward compatibility or "saving
> pins" is higher.
>
Indeed, you can use in-band interrupts if your device is able to
generate them, but that doesn't prevent I3C device designers from using
an external pin to signal interrupts if they prefer.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-01 21:47 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-01 21:47 UTC (permalink / raw)
To: Wolfram Sang
Cc: Andrew F. Davis, Arnd Bergmann, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
Jonathan Corbet, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
Le Tue, 1 Aug 2017 19:27:03 +0200,
Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> a écrit :
> > I'm surprised they didn't allow for slave clock stretching when
> > communicating with a legacy i2c device, it will prohibit use of a rather
> > large class of devices. :(
>
> Yes, but I3C is push/pull IIRC.
It is.
>
> > As for interrupts you are always free to wire up an out-of-band
> > interrupt like before. :)
>
> Yes, my wording was a bit too strong. It is possible, sure. Yet, I
> understood that one of the features of I3C is to have in-band interrupt
> support. We will see if the demand for backward compatibility or "saving
> pins" is higher.
>
Indeed, you can use in-band interrupts if your device is able to
generate them, but that doesn't prevent I3C device designers from using
an external pin to signal interrupts if they prefer.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 21:30 ` Boris Brezillon
@ 2017-08-02 0:54 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-02 0:54 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> > > > No release type? Oh that's bad bad bad and implies you have never
> > > > removed a device from your system as the kernel would have complained
> > > > loudly at you.
> > >
> > > You got me, never tried to remove a device :-). Note that these
> > > ->release() hooks will just be dummy ones, because right now, device
> > > resources are freed at bus destruction time.
> >
> > You better not have a "dummy" release hook, do that and as per the
> > kernel documentation, I get to make fun of you in public for doing that
> > :(
>
> I'm not afraid of admitting I don't know everything, even the
> simplest things that you consider as basics for a kernel developer. You
> can make fun of me publicly if you want but that's not helping :-P.
No, I am referring to the Documentation/kobject.txt file, where it says:
One important point cannot be overstated: every kobject must
have a release() method, and the kobject must persist (in a
consistent state) until that method is called. If these
constraints are not met, the code is flawed. Note that the
kernel will warn you if you forget to provide a release()
method. Do not try to get rid of this warning by providing an
"empty" release function; you will be mocked mercilessly by the
kobject maintainer if you attempt this.
Sometimes I wonder why I even write documentation...
The point is, you have to release the memory the device structure "owns"
in the release callback, if not, then the model is not correct. That's
all, please fix up your code to do so and I will be glad to review it
again. I'm not trying to be rude here at all, but please, at the least,
read the documentation we have already first...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-02 0:54 ` Greg Kroah-Hartman
0 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-02 0:54 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> > > > No release type? Oh that's bad bad bad and implies you have never
> > > > removed a device from your system as the kernel would have complained
> > > > loudly at you.
> > >
> > > You got me, never tried to remove a device :-). Note that these
> > > ->release() hooks will just be dummy ones, because right now, device
> > > resources are freed at bus destruction time.
> >
> > You better not have a "dummy" release hook, do that and as per the
> > kernel documentation, I get to make fun of you in public for doing that
> > :(
>
> I'm not afraid of admitting I don't know everything, even the
> simplest things that you consider as basics for a kernel developer. You
> can make fun of me publicly if you want but that's not helping :-P.
No, I am referring to the Documentation/kobject.txt file, where it says:
One important point cannot be overstated: every kobject must
have a release() method, and the kobject must persist (in a
consistent state) until that method is called. If these
constraints are not met, the code is flawed. Note that the
kernel will warn you if you forget to provide a release()
method. Do not try to get rid of this warning by providing an
"empty" release function; you will be mocked mercilessly by the
kobject maintainer if you attempt this.
Sometimes I wonder why I even write documentation...
The point is, you have to release the memory the device structure "owns"
in the release callback, if not, then the model is not correct. That's
all, please fix up your code to do so and I will be glad to review it
again. I'm not trying to be rude here at all, but please, at the least,
read the documentation we have already first...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 21:30 ` Boris Brezillon
@ 2017-08-02 2:13 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-02 2:13 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> Hi Greg,
>
> Le Tue, 1 Aug 2017 10:51:33 -0700,
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> a écrit :
>
> > On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > > +
> > > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > > > +{
> > > > > + if (exclusive)
> > > > > + down_write(&bus->lock);
> > > > > + else
> > > > > + down_read(&bus->lock);
> > > > > +}
> > > >
> > > > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > > > you agree?
> > >
> > > I could create 2 functions, one for the exclusive lock and the other
> > > one for the shared lock.
> >
> > Or you could just use a simple mutex until you determine you really
> > would do better with a rw lock :)
> >
> > > > And have you measured the difference in using a rw lock over
> > > > a normal mutex and found it to be faster? If not, just use a normal
> > > > mutex, it's simpler and almost always better in the end.
> > >
> > > I did not measure the difference, but using a standard lock means
> > > serializing all I3C accesses going through a given master in the core.
> >
> > Which you are doing with a rw lock anyway, right?
>
> Absolutely not. If you look more closely at the code you'll see that
> most of the time the lock is taken in read/non-exclusive mode. The only
> situations where it's taken in exclusive mode is when the operation (and
> associated command) has an impact on the bus and/or its devices.
Then you really need to document the heck out of this, as it was not
obvious at all :)
> > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > this way because master IPs are likely to implement advanced queuing
> > > mechanism (allows one to queue new transfers even if the master is
> > > already busy processing other requests), and serializing things at the
> > > framework level will just prevent us from using this kind of
> > > optimization.
> >
> > Unless you can prove otherwise, using a rw lock is almost always worse
> > than just a mutex.
>
> Is it still true when it's taken in non-exclusive mode most of the
> time, and the time you spend in the critical section is non-negligible?
>
> I won't pretend I know better than you do what is preferable, it's just
> that the RW lock seemed appropriate to me for the situation I tried to
> described here.
Again, measure it. If you can't measure it, then don't use it. Use a
simple lock instead. Seriously, don't make it more complex until you
really have to. It sounds like you didn't measure it at all, which
isn't good, please do so.
> > And you shouldn't have a lock for bus transactions,
> > that's just going to be a total mess.
>
> It's not a lock for bus transactions, it's lock to protect from any
> operation that can have an impact on the bus or its devices (see the
> 'change device address' example above).
Again, document it really well please.
> > > > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> > > >
> > > > Multiple lines in a single sysfs file? No.
> > >
> > > Okay. Would that be okay with a different separator (like a comma)?
> >
> > No, sysfs files are "one value per file", given you don't have any
> > documentation saying what this file is supposed to be showing, I can't
> > really judge the proper way for you to present it to userspace :)
>
> Okay. Let's put that aside until I send a v2 with a sysfs doc.
>
> Still, note that the "one value per file" rule does not apply to all
> sysfs files. I have 2 examples in mind (maybe they are bad examples,
> but they exist):
>
> - /sys/class/leds/<led>/trigger returns a list of supported triggers
> each of them is separated by a space
> - /sys/class/graphics/<fbx>/modes lists the supported video modes, one
> per line
I'm not saying there are not bad files, but I didn't review them :)
A list of supported triggers all on one line and one you pick from it
(the power file is also the same way), is different from multiple lines.
The graphics stuff should be fixed up.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-02 2:13 ` Greg Kroah-Hartman
0 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-08-02 2:13 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
On Tue, Aug 01, 2017 at 11:30:01PM +0200, Boris Brezillon wrote:
> Hi Greg,
>
> Le Tue, 1 Aug 2017 10:51:33 -0700,
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> a écrit :
>
> > On Tue, Aug 01, 2017 at 12:48:01PM +0200, Boris Brezillon wrote:
> > > > > +static DEFINE_MUTEX(i3c_core_lock);
> > > > > +
> > > > > +void i3c_bus_lock(struct i3c_bus *bus, bool exclusive)
> > > > > +{
> > > > > + if (exclusive)
> > > > > + down_write(&bus->lock);
> > > > > + else
> > > > > + down_read(&bus->lock);
> > > > > +}
> > > >
> > > > The "exclusive" flag is odd, and messy, and hard to understand, don't
> > > > you agree?
> > >
> > > I could create 2 functions, one for the exclusive lock and the other
> > > one for the shared lock.
> >
> > Or you could just use a simple mutex until you determine you really
> > would do better with a rw lock :)
> >
> > > > And have you measured the difference in using a rw lock over
> > > > a normal mutex and found it to be faster? If not, just use a normal
> > > > mutex, it's simpler and almost always better in the end.
> > >
> > > I did not measure the difference, but using a standard lock means
> > > serializing all I3C accesses going through a given master in the core.
> >
> > Which you are doing with a rw lock anyway, right?
>
> Absolutely not. If you look more closely at the code you'll see that
> most of the time the lock is taken in read/non-exclusive mode. The only
> situations where it's taken in exclusive mode is when the operation (and
> associated command) has an impact on the bus and/or its devices.
Then you really need to document the heck out of this, as it was not
obvious at all :)
> > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > this way because master IPs are likely to implement advanced queuing
> > > mechanism (allows one to queue new transfers even if the master is
> > > already busy processing other requests), and serializing things at the
> > > framework level will just prevent us from using this kind of
> > > optimization.
> >
> > Unless you can prove otherwise, using a rw lock is almost always worse
> > than just a mutex.
>
> Is it still true when it's taken in non-exclusive mode most of the
> time, and the time you spend in the critical section is non-negligible?
>
> I won't pretend I know better than you do what is preferable, it's just
> that the RW lock seemed appropriate to me for the situation I tried to
> described here.
Again, measure it. If you can't measure it, then don't use it. Use a
simple lock instead. Seriously, don't make it more complex until you
really have to. It sounds like you didn't measure it at all, which
isn't good, please do so.
> > And you shouldn't have a lock for bus transactions,
> > that's just going to be a total mess.
>
> It's not a lock for bus transactions, it's lock to protect from any
> operation that can have an impact on the bus or its devices (see the
> 'change device address' example above).
Again, document it really well please.
> > > > > + ret = sprintf(buf + offset, "%s\n", hdrcap_strings[mode]);
> > > >
> > > > Multiple lines in a single sysfs file? No.
> > >
> > > Okay. Would that be okay with a different separator (like a comma)?
> >
> > No, sysfs files are "one value per file", given you don't have any
> > documentation saying what this file is supposed to be showing, I can't
> > really judge the proper way for you to present it to userspace :)
>
> Okay. Let's put that aside until I send a v2 with a sysfs doc.
>
> Still, note that the "one value per file" rule does not apply to all
> sysfs files. I have 2 examples in mind (maybe they are bad examples,
> but they exist):
>
> - /sys/class/leds/<led>/trigger returns a list of supported triggers
> each of them is separated by a space
> - /sys/class/graphics/<fbx>/modes lists the supported video modes, one
> per line
I'm not saying there are not bad files, but I didn't review them :)
A list of supported triggers all on one line and one you pick from it
(the power file is also the same way), is different from multiple lines.
The graphics stuff should be fixed up.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 21:47 ` Boris Brezillon
@ 2017-08-02 10:21 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-02 10:21 UTC (permalink / raw)
To: Boris Brezillon
Cc: Andrew F. Davis, Arnd Bergmann, linux-i2c, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
> > Yes, my wording was a bit too strong. It is possible, sure. Yet, I
> > understood that one of the features of I3C is to have in-band interrupt
> > support. We will see if the demand for backward compatibility or "saving
> > pins" is higher.
> >
>
> Indeed, you can use in-band interrupts if your device is able to
> generate them, but that doesn't prevent I3C device designers from using
> an external pin to signal interrupts if they prefer.
Exactly. Thus, "We will see if the demand for backward compatibility or "saving
pins" is higher" :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-02 10:21 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-08-02 10:21 UTC (permalink / raw)
To: Boris Brezillon
Cc: Andrew F. Davis, Arnd Bergmann, linux-i2c, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
> > Yes, my wording was a bit too strong. It is possible, sure. Yet, I
> > understood that one of the features of I3C is to have in-band interrupt
> > support. We will see if the demand for backward compatibility or "saving
> > pins" is higher.
> >
>
> Indeed, you can use in-band interrupts if your device is able to
> generate them, but that doesn't prevent I3C device designers from using
> an external pin to signal interrupts if they prefer.
Exactly. Thus, "We will see if the demand for backward compatibility or "saving
pins" is higher" :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 15:20 ` Boris Brezillon
@ 2017-08-03 8:03 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-03 8:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, 1 Aug 2017 17:20:41 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Tue, 1 Aug 2017 17:01:08 +0200
> Wolfram Sang <wsa@the-dreams.de> wrote:
>
> > > I do not know of any real devices as of today (all my tests have been
> > > done with a dummy/fake I3C slaves emulated with a slave IP),
> >
> > I see.
> >
> > > spec clearly describe what legacy/static addresses are for and one of
> > > their use case is to connect an I3C device on an I2C bus and let it act
> > > as an I2C device.
> >
> > OK. That makes it more likely.
> >
> > > Unless you want your device (likely a sensor) to be compatible with both
> > > I3C and I2C so that you can target even more people.
> >
> > Right. My question was if this is a realistic or more academic scenario.
> >
> > > I'm perfectly fine with the I3C / I2C framework separation. The only
> > > minor problem I had with that was the inaccuracy of the
> > > sysfs/device-model representation: we don't have one i2c and one i3c
> > > bus, we just have one i3c bus with a mix of i2c and i3c devices.
> >
> > I understand that. What if I2C had the same seperation between the "bus"
> > and the "master"?
> >
>
> Yep, it might work if we can register an i2c_adapter and pass it an
> existing bus object. We'd still need a common base for i2c and i3c
> busses, unless we consider the bus as an opaque "struct device *"
> object.
I tried to envision how this could be implemented but realized
separating the bus and master concepts in I2C wouldn't solve all
problems.
Each device is attached a bus_type which defines how to match devices
and drivers, uevent format, ... But it also defines where the device
appears in sysfs (/sys/bus/<bus-name>/devices).
First question: where should an I2C device connected on an I3C bus
appear? /sys/bus/i3c/devices/ or /sys/bus/i2c/devices/? I'd say both
(with one of them being a symlink to the other) but I'm not sure.
Also, if we go for a 'single bus per master' representation but still
want i3c and i2c to be differentiated, that means when one adds an
i2c_driver we'll have to duplicate this driver object and register one
instance to the i2c framework and the other one to the i3c framework,
because device <-> driver matching is done per bus_type.
One solution would be to go for Arnd suggestion to extend i2c_bus_type
with I3C support, but then i3c related kojects would be exposed
under /sys/bus/i2c/ which can be disturbing for people who are used to
look at /sys/bus/<bus-name> to find devices connected on a specific bus
type.
Honestly, I don't know what's the best solution here. Every solution has
its pros and cons:
1/ The "one i2c bus and one i3c bus per i3c master" I proposed in this
RFC is non-invasive but the resulting sysfs/device-model
representation is not accurate.
2/ Separating the I3C and I2C framework with a thin layer between them
to propagate i2c drivers registration to the i3c framework and make
sure i2c devices are exposed in both worlds is much more complicated
to implement but should provide an accurate bus <-> device
representation.
3/ Extending i2c_bus_type (and more generally the I2C framework) to
support I3C devices/busses is invasive and we still have a
non-accurate representation (i2c busses are mixed with i3c busses
and all exposed under /sys/bus/i2c/). One advantage with this
solution compared to #2 is that we don't need to duplicate
i2c_driver objects in order to register them to both i2c and i3c bus
types.
Any advice is welcome.
Thanks,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-03 8:03 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-03 8:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar
On Tue, 1 Aug 2017 17:20:41 +0200
Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Tue, 1 Aug 2017 17:01:08 +0200
> Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>
> > > I do not know of any real devices as of today (all my tests have been
> > > done with a dummy/fake I3C slaves emulated with a slave IP),
> >
> > I see.
> >
> > > spec clearly describe what legacy/static addresses are for and one of
> > > their use case is to connect an I3C device on an I2C bus and let it act
> > > as an I2C device.
> >
> > OK. That makes it more likely.
> >
> > > Unless you want your device (likely a sensor) to be compatible with both
> > > I3C and I2C so that you can target even more people.
> >
> > Right. My question was if this is a realistic or more academic scenario.
> >
> > > I'm perfectly fine with the I3C / I2C framework separation. The only
> > > minor problem I had with that was the inaccuracy of the
> > > sysfs/device-model representation: we don't have one i2c and one i3c
> > > bus, we just have one i3c bus with a mix of i2c and i3c devices.
> >
> > I understand that. What if I2C had the same seperation between the "bus"
> > and the "master"?
> >
>
> Yep, it might work if we can register an i2c_adapter and pass it an
> existing bus object. We'd still need a common base for i2c and i3c
> busses, unless we consider the bus as an opaque "struct device *"
> object.
I tried to envision how this could be implemented but realized
separating the bus and master concepts in I2C wouldn't solve all
problems.
Each device is attached a bus_type which defines how to match devices
and drivers, uevent format, ... But it also defines where the device
appears in sysfs (/sys/bus/<bus-name>/devices).
First question: where should an I2C device connected on an I3C bus
appear? /sys/bus/i3c/devices/ or /sys/bus/i2c/devices/? I'd say both
(with one of them being a symlink to the other) but I'm not sure.
Also, if we go for a 'single bus per master' representation but still
want i3c and i2c to be differentiated, that means when one adds an
i2c_driver we'll have to duplicate this driver object and register one
instance to the i2c framework and the other one to the i3c framework,
because device <-> driver matching is done per bus_type.
One solution would be to go for Arnd suggestion to extend i2c_bus_type
with I3C support, but then i3c related kojects would be exposed
under /sys/bus/i2c/ which can be disturbing for people who are used to
look at /sys/bus/<bus-name> to find devices connected on a specific bus
type.
Honestly, I don't know what's the best solution here. Every solution has
its pros and cons:
1/ The "one i2c bus and one i3c bus per i3c master" I proposed in this
RFC is non-invasive but the resulting sysfs/device-model
representation is not accurate.
2/ Separating the I3C and I2C framework with a thin layer between them
to propagate i2c drivers registration to the i3c framework and make
sure i2c devices are exposed in both worlds is much more complicated
to implement but should provide an accurate bus <-> device
representation.
3/ Extending i2c_bus_type (and more generally the I2C framework) to
support I3C devices/busses is invasive and we still have a
non-accurate representation (i2c busses are mixed with i3c busses
and all exposed under /sys/bus/i2c/). One advantage with this
solution compared to #2 is that we don't need to duplicate
i2c_driver objects in order to register them to both i2c and i3c bus
types.
Any advice is welcome.
Thanks,
Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 3/5] dt-bindings: i3c: Document core bindings
2017-07-31 16:24 ` Boris Brezillon
@ 2017-08-09 23:43 ` Rob Herring
-1 siblings, 0 replies; 91+ messages in thread
From: Rob Herring @ 2017-08-09 23:43 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Mon, Jul 31, 2017 at 06:24:48PM +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> new file mode 100644
> index 000000000000..49261dec7b01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,90 @@
> +Generic device tree bindings for I3C busses
> +===========================================
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +-------------------
> +
> +- #address-cells - should be <1>. Read more about addresses below.
> +- #size-cells - should be <0>.
> +- compatible - name of I3C bus controller following generic names
> + recommended practice.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +-------------------
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> + transfers. When undefined the core set it to 12.5MHz.
> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> + transfers. When undefined, the core looks at LVR values
> + of I2C devices described in the device tree to determine
> + the maximum I2C frequency.
> +
> +I2C devices
> +===========
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:
> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.
> +
> +New required properties:
> +------------------------
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
What does lvr mean?
> + describing device capabilities as described in the I3C
> + specification.
> +
> + bit[31:8]: unused
> + bit[7:5]: I2C device index. Possible values
index? Seems more like flags
> + * 0: I2C device has a 50 ns spike filter
> + * 1: I2C device does not have a 50 ns spike filter but supports high
> + frequency on SCL
> + * 2: I2C device does not have a 50 ns spike filter and is not
> + tolerant to high frequencies
> + * 3-7: reserved
> +
> + bit[4]: tell whether the device operates in FM or FM+ mode
> + * 0: FM+ mode
> + * 1: FM mode
> +
> + bit[3:0]: device type
> + * 0-15: reserved
That's useful...
> +
> +I3C devices
> +===========
> +
> +I3C are not described in the device tree yet. We could decide to represent them
> +at some point to assign a specific dynamic address to a device or to force an
> +I3C device to act as an I2C device if it has a static address.
I think we need to define this sooner rather than later if there's not a
standard connector. That's the only thing that would enforce any sort of
standard. Of course, that didn't help with SDIO.
> +
> +Example:
> +
> + i3c-master@0d040000 {
The node name should go into the DT spec. I tend to think "i3c" would be
sufficient and aligned with i2c.
> + compatible = "cdns,i3c-master";
> + clocks = <&coreclock>, <&i3csysclock>;
> + clock-names = "pclk", "sysclk";
> + interrupts = <3 0>;
> + reg = <0x0d040000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> + i2c-scl-frequency = <100000>;
> +
> + nunchuk: nunchuk@52 {
> + compatible = "nintendo,nunchuk";
> + reg = <0x52>;
> + i3c-lvr = <0x10>;
> + };
> + };
> +
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 3/5] dt-bindings: i3c: Document core bindings
@ 2017-08-09 23:43 ` Rob Herring
0 siblings, 0 replies; 91+ messages in thread
From: Rob Herring @ 2017-08-09 23:43 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar
On Mon, Jul 31, 2017 at 06:24:48PM +0200, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> new file mode 100644
> index 000000000000..49261dec7b01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,90 @@
> +Generic device tree bindings for I3C busses
> +===========================================
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +-------------------
> +
> +- #address-cells - should be <1>. Read more about addresses below.
> +- #size-cells - should be <0>.
> +- compatible - name of I3C bus controller following generic names
> + recommended practice.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +-------------------
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> + transfers. When undefined the core set it to 12.5MHz.
> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> + transfers. When undefined, the core looks at LVR values
> + of I2C devices described in the device tree to determine
> + the maximum I2C frequency.
> +
> +I2C devices
> +===========
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:
> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.
> +
> +New required properties:
> +------------------------
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
What does lvr mean?
> + describing device capabilities as described in the I3C
> + specification.
> +
> + bit[31:8]: unused
> + bit[7:5]: I2C device index. Possible values
index? Seems more like flags
> + * 0: I2C device has a 50 ns spike filter
> + * 1: I2C device does not have a 50 ns spike filter but supports high
> + frequency on SCL
> + * 2: I2C device does not have a 50 ns spike filter and is not
> + tolerant to high frequencies
> + * 3-7: reserved
> +
> + bit[4]: tell whether the device operates in FM or FM+ mode
> + * 0: FM+ mode
> + * 1: FM mode
> +
> + bit[3:0]: device type
> + * 0-15: reserved
That's useful...
> +
> +I3C devices
> +===========
> +
> +I3C are not described in the device tree yet. We could decide to represent them
> +at some point to assign a specific dynamic address to a device or to force an
> +I3C device to act as an I2C device if it has a static address.
I think we need to define this sooner rather than later if there's not a
standard connector. That's the only thing that would enforce any sort of
standard. Of course, that didn't help with SDIO.
> +
> +Example:
> +
> + i3c-master@0d040000 {
The node name should go into the DT spec. I tend to think "i3c" would be
sufficient and aligned with i2c.
> + compatible = "cdns,i3c-master";
> + clocks = <&coreclock>, <&i3csysclock>;
> + clock-names = "pclk", "sysclk";
> + interrupts = <3 0>;
> + reg = <0x0d040000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> + i2c-scl-frequency = <100000>;
> +
> + nunchuk: nunchuk@52 {
> + compatible = "nintendo,nunchuk";
> + reg = <0x52>;
> + i3c-lvr = <0x10>;
> + };
> + };
> +
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 3/5] dt-bindings: i3c: Document core bindings
2017-08-09 23:43 ` Rob Herring
@ 2017-08-10 8:49 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-10 8:49 UTC (permalink / raw)
To: Rob Herring
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, devicetree, linux-kernel
Hi Rob,
Le Wed, 9 Aug 2017 18:43:02 -0500,
Rob Herring <robh@kernel.org> a écrit :
> On Mon, Jul 31, 2017 at 06:24:48PM +0200, Boris Brezillon wrote:
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
> > 1 file changed, 90 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
> >
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> > new file mode 100644
> > index 000000000000..49261dec7b01
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,90 @@
> > +Generic device tree bindings for I3C busses
> > +===========================================
> > +
> > +This document describes generic bindings that should be used to describe I3C
> > +busses in a device tree.
> > +
> > +Required properties
> > +-------------------
> > +
> > +- #address-cells - should be <1>. Read more about addresses below.
> > +- #size-cells - should be <0>.
> > +- compatible - name of I3C bus controller following generic names
> > + recommended practice.
> > +
> > +For other required properties e.g. to describe register sets,
> > +clocks, etc. check the binding documentation of the specific driver.
> > +
> > +Optional properties
> > +-------------------
> > +
> > +These properties may not be supported by all I3C master drivers. Each I3C
> > +master bindings should specify which of them are supported.
> > +
> > +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> > + transfers. When undefined the core set it to 12.5MHz.
> > +
> > +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> > + transfers. When undefined, the core looks at LVR values
> > + of I2C devices described in the device tree to determine
> > + the maximum I2C frequency.
> > +
> > +I2C devices
> > +===========
> > +
> > +Each I2C device connected to the bus should be described in a subnode with
> > +the following properties:
> > +
> > +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> > +valid here.
> > +
> > +New required properties:
> > +------------------------
> > +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
>
> What does lvr mean?
Legacy Virtual Register. It's the name used in the I3C specification
and a short description is given in the I3C doc (patch 2 of this RFC):
"
Backward compatibility with I2C devices
=======================================
The I3C protocol has been designed to be backward compatible with I2C
devices. This backward compatibility allows one to connect a mix of I2C
and I3C device on the same bus, though, in order to be really
efficient, I2C devices should be equipped with 50 ns spike filters.
I2C devices can't be discovered like I3C ones and have to be statically
declared. In order to let the master know what these devices are
capable of (both in terms of bus related limitations and
functionalities), the software has to provide some information, which
is done through the LVR (Legacy I2C Virtual Register).
"
>
> > + describing device capabilities as described in the I3C
> > + specification.
> > +
> > + bit[31:8]: unused
> > + bit[7:5]: I2C device index. Possible values
>
> index?
Yes, I also find this name inappropriate, but that's directly
extracted from the specification.
> Seems more like flags
These are not described as independent flags in the spec. It's an enum
with only 3 values on 7 currently defined. I guess MIPI reserves other
values for future use (v2 of the spec?).
>
> > + * 0: I2C device has a 50 ns spike filter
> > + * 1: I2C device does not have a 50 ns spike filter but supports high
> > + frequency on SCL
> > + * 2: I2C device does not have a 50 ns spike filter and is not
> > + tolerant to high frequencies
> > + * 3-7: reserved
> > +
> > + bit[4]: tell whether the device operates in FM or FM+ mode
> > + * 0: FM+ mode
> > + * 1: FM mode
> > +
> > + bit[3:0]: device type
> > + * 0-15: reserved
>
> That's useful...
Unfortunately, v1 of the spec does not define any of these device
types. Probably something that will be extended in future versions.
>
> > +
> > +I3C devices
> > +===========
> > +
> > +I3C are not described in the device tree yet. We could decide to represent them
> > +at some point to assign a specific dynamic address to a device or to force an
> > +I3C device to act as an I2C device if it has a static address.
>
> I think we need to define this sooner rather than later if there's not a
> standard connector. That's the only thing that would enforce any sort of
> standard. Of course, that didn't help with SDIO.
I'm perfectly fine with that. I'll try to come up with a proposal in
v2 of this patchset.
>
> > +
> > +Example:
> > +
> > + i3c-master@0d040000 {
>
> The node name should go into the DT spec. I tend to think "i3c" would be
> sufficient and aligned with i2c.
Well, I3C slave IPs are around the corner (actually I used one to test
this framework), and I thought clarifying things from the beginning
would be beneficial. But if you think i3c implicitly means i3c-master,
I can change that.
>
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + nunchuk: nunchuk@52 {
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52>;
> > + i3c-lvr = <0x10>;
> > + };
> > + };
> > +
> > --
> > 2.7.4
> >
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 3/5] dt-bindings: i3c: Document core bindings
@ 2017-08-10 8:49 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-10 8:49 UTC (permalink / raw)
To: Rob Herring
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar
Hi Rob,
Le Wed, 9 Aug 2017 18:43:02 -0500,
Rob Herring <robh@kernel.org> a écrit :
> On Mon, Jul 31, 2017 at 06:24:48PM +0200, Boris Brezillon wrote:
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/i3c/i3c.txt | 90 +++++++++++++++++++++++++++
> > 1 file changed, 90 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
> >
> > diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> > new file mode 100644
> > index 000000000000..49261dec7b01
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,90 @@
> > +Generic device tree bindings for I3C busses
> > +===========================================
> > +
> > +This document describes generic bindings that should be used to describe I3C
> > +busses in a device tree.
> > +
> > +Required properties
> > +-------------------
> > +
> > +- #address-cells - should be <1>. Read more about addresses below.
> > +- #size-cells - should be <0>.
> > +- compatible - name of I3C bus controller following generic names
> > + recommended practice.
> > +
> > +For other required properties e.g. to describe register sets,
> > +clocks, etc. check the binding documentation of the specific driver.
> > +
> > +Optional properties
> > +-------------------
> > +
> > +These properties may not be supported by all I3C master drivers. Each I3C
> > +master bindings should specify which of them are supported.
> > +
> > +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> > + transfers. When undefined the core set it to 12.5MHz.
> > +
> > +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> > + transfers. When undefined, the core looks at LVR values
> > + of I2C devices described in the device tree to determine
> > + the maximum I2C frequency.
> > +
> > +I2C devices
> > +===========
> > +
> > +Each I2C device connected to the bus should be described in a subnode with
> > +the following properties:
> > +
> > +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> > +valid here.
> > +
> > +New required properties:
> > +------------------------
> > +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
>
> What does lvr mean?
Legacy Virtual Register. It's the name used in the I3C specification
and a short description is given in the I3C doc (patch 2 of this RFC):
"
Backward compatibility with I2C devices
=======================================
The I3C protocol has been designed to be backward compatible with I2C
devices. This backward compatibility allows one to connect a mix of I2C
and I3C device on the same bus, though, in order to be really
efficient, I2C devices should be equipped with 50 ns spike filters.
I2C devices can't be discovered like I3C ones and have to be statically
declared. In order to let the master know what these devices are
capable of (both in terms of bus related limitations and
functionalities), the software has to provide some information, which
is done through the LVR (Legacy I2C Virtual Register).
"
>
> > + describing device capabilities as described in the I3C
> > + specification.
> > +
> > + bit[31:8]: unused
> > + bit[7:5]: I2C device index. Possible values
>
> index?
Yes, I also find this name inappropriate, but that's directly
extracted from the specification.
> Seems more like flags
These are not described as independent flags in the spec. It's an enum
with only 3 values on 7 currently defined. I guess MIPI reserves other
values for future use (v2 of the spec?).
>
> > + * 0: I2C device has a 50 ns spike filter
> > + * 1: I2C device does not have a 50 ns spike filter but supports high
> > + frequency on SCL
> > + * 2: I2C device does not have a 50 ns spike filter and is not
> > + tolerant to high frequencies
> > + * 3-7: reserved
> > +
> > + bit[4]: tell whether the device operates in FM or FM+ mode
> > + * 0: FM+ mode
> > + * 1: FM mode
> > +
> > + bit[3:0]: device type
> > + * 0-15: reserved
>
> That's useful...
Unfortunately, v1 of the spec does not define any of these device
types. Probably something that will be extended in future versions.
>
> > +
> > +I3C devices
> > +===========
> > +
> > +I3C are not described in the device tree yet. We could decide to represent them
> > +at some point to assign a specific dynamic address to a device or to force an
> > +I3C device to act as an I2C device if it has a static address.
>
> I think we need to define this sooner rather than later if there's not a
> standard connector. That's the only thing that would enforce any sort of
> standard. Of course, that didn't help with SDIO.
I'm perfectly fine with that. I'll try to come up with a proposal in
v2 of this patchset.
>
> > +
> > +Example:
> > +
> > + i3c-master@0d040000 {
>
> The node name should go into the DT spec. I tend to think "i3c" would be
> sufficient and aligned with i2c.
Well, I3C slave IPs are around the corner (actually I used one to test
this framework), and I thought clarifying things from the beginning
would be beneficial. But if you think i3c implicitly means i3c-master,
I can change that.
>
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + nunchuk: nunchuk@52 {
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52>;
> > + i3c-lvr = <0x10>;
> > + };
> > + };
> > +
> > --
> > 2.7.4
> >
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-01 15:01 ` Wolfram Sang
@ 2017-08-16 21:03 ` Geert Uytterhoeven
-1 siblings, 0 replies; 91+ messages in thread
From: Geert Uytterhoeven @ 2017-08-16 21:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Boris Brezillon, Arnd Bergmann, Linux I2C, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> I'm perfectly fine with the I3C / I2C framework separation. The only
>> minor problem I had with that was the inaccuracy of the
>> sysfs/device-model representation: we don't have one i2c and one i3c
>> bus, we just have one i3c bus with a mix of i2c and i3c devices.
>
> I understand that. What if I2C had the same seperation between the "bus"
> and the "master"?
There can be multiple masters on an i2c bus. But not on an i3c bus, due
to SCL being push/pull.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-16 21:03 ` Geert Uytterhoeven
0 siblings, 0 replies; 91+ messages in thread
From: Geert Uytterhoeven @ 2017-08-16 21:03 UTC (permalink / raw)
To: Wolfram Sang
Cc: Boris Brezillon, Arnd Bergmann, Linux I2C, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll
On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>> I'm perfectly fine with the I3C / I2C framework separation. The only
>> minor problem I had with that was the inaccuracy of the
>> sysfs/device-model representation: we don't have one i2c and one i3c
>> bus, we just have one i3c bus with a mix of i2c and i3c devices.
>
> I understand that. What if I2C had the same seperation between the "bus"
> and the "master"?
There can be multiple masters on an i2c bus. But not on an i3c bus, due
to SCL being push/pull.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-16 21:03 ` Geert Uytterhoeven
@ 2017-08-17 7:48 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-17 7:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfram Sang, Arnd Bergmann, Linux I2C, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, Linux Kernel Mailing List
Le Wed, 16 Aug 2017 23:03:55 +0200,
Geert Uytterhoeven <geert@linux-m68k.org> a écrit :
> On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> I'm perfectly fine with the I3C / I2C framework separation. The only
> >> minor problem I had with that was the inaccuracy of the
> >> sysfs/device-model representation: we don't have one i2c and one i3c
> >> bus, we just have one i3c bus with a mix of i2c and i3c devices.
> >
> > I understand that. What if I2C had the same seperation between the "bus"
> > and the "master"?
>
> There can be multiple masters on an i2c bus. But not on an i3c bus, due
> to SCL being push/pull.
I guess you mean there can't be a mix of I2C and I3C masters on the same
bus. Then yes, you're right, you can only connect I2C slaves on an I3C
bus, but I don't think Wolfram suggested this approach to support this
case.
Note that there can be multiple I3C masters on an I3C bus. When a
'secondary master' wants to become the current master it must ask the
permission to the 'current master' which can decide to ack or nack the
request.
As soon as the previous 'current master' accepted to release the bus it
should act as a slave and if it needs to reclaim the bus, it should ask
the new 'current master'.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-17 7:48 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-17 7:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Wolfram Sang, Arnd Bergmann, Linux I2C, Jonathan Corbet,
linux-doc, Greg Kroah-Hartman, Przemyslaw Sroka, Arkadiusz Golec,
Alan Douglas, Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak,
Jan Kotas, Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark
Le Wed, 16 Aug 2017 23:03:55 +0200,
Geert Uytterhoeven <geert@linux-m68k.org> a écrit :
> On Tue, Aug 1, 2017 at 5:01 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> >> I'm perfectly fine with the I3C / I2C framework separation. The only
> >> minor problem I had with that was the inaccuracy of the
> >> sysfs/device-model representation: we don't have one i2c and one i3c
> >> bus, we just have one i3c bus with a mix of i2c and i3c devices.
> >
> > I understand that. What if I2C had the same seperation between the "bus"
> > and the "master"?
>
> There can be multiple masters on an i2c bus. But not on an i3c bus, due
> to SCL being push/pull.
I guess you mean there can't be a mix of I2C and I3C masters on the same
bus. Then yes, you're right, you can only connect I2C slaves on an I3C
bus, but I don't think Wolfram suggested this approach to support this
case.
Note that there can be multiple I3C masters on an I3C bus. When a
'secondary master' wants to become the current master it must ask the
permission to the 'current master' which can decide to ack or nack the
request.
As soon as the previous 'current master' accepted to release the bus it
should act as a slave and if it needs to reclaim the bus, it should ask
the new 'current master'.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
@ 2017-08-17 9:03 ` Linus Walleij
2017-07-31 20:16 ` Arnd Bergmann
` (2 subsequent siblings)
3 siblings, 0 replies; 91+ messages in thread
From: Linus Walleij @ 2017-08-17 9:03 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> This infrastructure is not complete yet and will be extended over
> time.
I noticed the lack of pm_* from the core.
This will be noticed very quickly since the means the problem seen
in e.g. commit 04f59143b571 and the wakeup IRQ business will make it
impossible to do power-efficient drivers until that is resolved.
It'd be nice to have it to PM right from the start, and the I2C core has
all the right infrastructure in place, so when this stabilize I'd say
atleast it'd be *nice* if the PM business was added in the same
kernel release that introduce this core infrastructure, even if it will
be a separate patch.
I.e. I consider that more of necessary bread and butter and less of
nice to have topping on the cake.
What I have seen that leaf vendors doing (i3c) device drivers do
otherwise is complain "it is broken" and then they start to hack
around it instead of helping out with the core. (I think you're
well aware of that phenomenon.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-17 9:03 ` Linus Walleij
0 siblings, 0 replies; 91+ messages in thread
From: Linus Walleij @ 2017-08-17 9:03 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> This infrastructure is not complete yet and will be extended over
> time.
I noticed the lack of pm_* from the core.
This will be noticed very quickly since the means the problem seen
in e.g. commit 04f59143b571 and the wakeup IRQ business will make it
impossible to do power-efficient drivers until that is resolved.
It'd be nice to have it to PM right from the start, and the I2C core has
all the right infrastructure in place, so when this stabilize I'd say
atleast it'd be *nice* if the PM business was added in the same
kernel release that introduce this core infrastructure, even if it will
be a separate patch.
I.e. I consider that more of necessary bread and butter and less of
nice to have topping on the cake.
What I have seen that leaf vendors doing (i3c) device drivers do
otherwise is complain "it is broken" and then they start to hack
around it instead of helping out with the core. (I think you're
well aware of that phenomenon.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-08-17 9:03 ` Linus Walleij
@ 2017-08-17 9:28 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-17 9:28 UTC (permalink / raw)
To: Linus Walleij
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel
Le Thu, 17 Aug 2017 11:03:10 +0200,
Linus Walleij <linus.walleij@linaro.org> a écrit :
> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
>
> > This infrastructure is not complete yet and will be extended over
> > time.
>
> I noticed the lack of pm_* from the core.
>
> This will be noticed very quickly since the means the problem seen
> in e.g. commit 04f59143b571 and the wakeup IRQ business will make it
> impossible to do power-efficient drivers until that is resolved.
>
> It'd be nice to have it to PM right from the start, and the I2C core has
> all the right infrastructure in place, so when this stabilize I'd say
> atleast it'd be *nice* if the PM business was added in the same
> kernel release that introduce this core infrastructure, even if it will
> be a separate patch.
>
> I.e. I consider that more of necessary bread and butter and less of
> nice to have topping on the cake.
>
> What I have seen that leaf vendors doing (i3c) device drivers do
> otherwise is complain "it is broken" and then they start to hack
> around it instead of helping out with the core. (I think you're
> well aware of that phenomenon.)
Noted. I'll try to provide core infrastructure for PM in my v2, but it's
kind of hard to design something when you don't have real devices. I
guess I can mimic I2C for now and make it evolve based on users needs.
Regards,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-08-17 9:28 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-08-17 9:28 UTC (permalink / raw)
To: Linus Walleij
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll
Le Thu, 17 Aug 2017 11:03:10 +0200,
Linus Walleij <linus.walleij@linaro.org> a écrit :
> On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
>
> > This infrastructure is not complete yet and will be extended over
> > time.
>
> I noticed the lack of pm_* from the core.
>
> This will be noticed very quickly since the means the problem seen
> in e.g. commit 04f59143b571 and the wakeup IRQ business will make it
> impossible to do power-efficient drivers until that is resolved.
>
> It'd be nice to have it to PM right from the start, and the I2C core has
> all the right infrastructure in place, so when this stabilize I'd say
> atleast it'd be *nice* if the PM business was added in the same
> kernel release that introduce this core infrastructure, even if it will
> be a separate patch.
>
> I.e. I consider that more of necessary bread and butter and less of
> nice to have topping on the cake.
>
> What I have seen that leaf vendors doing (i3c) device drivers do
> otherwise is complain "it is broken" and then they start to hack
> around it instead of helping out with the core. (I think you're
> well aware of that phenomenon.)
Noted. I'll try to provide core infrastructure for PM in my v2, but it's
kind of hard to design something when you don't have real devices. I
guess I can mimic I2C for now and make it evolve based on users needs.
Regards,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
2017-07-31 19:17 ` Wolfram Sang
@ 2017-12-12 19:58 ` Boris Brezillon
-1 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-12-12 19:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Mon, 31 Jul 2017 21:17:45 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public :(
>
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure if we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > now, just in case we need it some day.
>
> From my experience, it is a good thing to have this separation.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> I agree this is the least invasive and also the most compatible
> approach. The other solution would probably be to have some kind of
> emulation layer?
>
> > I'd also like to get feedback on the doc. Should I detail a bit more
> > the protocol or the framework API? Is this the kind of things you
> > expect in a subsystem doc?
>
> Since the spec is not public, details about the protocol will be
> especially useful, I'd say.
MIPI has opened the I3C spec [1], it can be downloaded here [2].
v2 of this series will come soon (sorry for the delay).
Regards,
Boris
[1]https://www.businesswire.com/news//home/20171212005059/en/MIPI-Alliance-Opens-Access-MIPI-I3C-Sensor
[2]http://resources.mipi.org/mipi-i3c-v1-download
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
@ 2017-12-12 19:58 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-12-12 19:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
On Mon, 31 Jul 2017 21:17:45 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> Hi Boris,
>
> > This patch series is a proposal for a new I3C [1] subsystem.
>
> Nice. Good luck with that!
>
> Some hi-level comments from me related to I2C. I can't say a lot more
> because the specs are not public :(
>
> > - the bus element is a separate object and is not implicitly described
> > by the master (as done in I2C). The reason is that I want to be able
> > to handle multiple master connected to the same bus and visible to
> > Linux.
> > In this situation, we should only have one instance of the device and
> > not one per master, and sharing the bus object would be part of the
> > solution to gracefully handle this case.
> > I'm not sure if we will ever need to deal with multiple masters
> > controlling the same bus and exposed under Linux, but separating the
> > bus and master concept is pretty easy, hence the decision to do it
> > now, just in case we need it some day.
>
> From my experience, it is a good thing to have this separation.
>
> > - I2C backward compatibility has been designed to be transparent to I2C
> > drivers and the I2C subsystem. The I3C master just registers an I2C
> > adapter which creates a new I2C bus. I'd say that, from a
> > representation PoV it's not ideal because what should appear as a
> > single I3C bus exposing I3C and I2C devices here appears as 2
> > different busses connected to each other through the parenting (the
> > I3C master is the parent of the I2C and I3C busses).
> > On the other hand, I don't see a better solution if we want something
> > that is not invasive.
>
> I agree this is the least invasive and also the most compatible
> approach. The other solution would probably be to have some kind of
> emulation layer?
>
> > I'd also like to get feedback on the doc. Should I detail a bit more
> > the protocol or the framework API? Is this the kind of things you
> > expect in a subsystem doc?
>
> Since the spec is not public, details about the protocol will be
> especially useful, I'd say.
MIPI has opened the I3C spec [1], it can be downloaded here [2].
v2 of this series will come soon (sorry for the delay).
Regards,
Boris
[1]https://www.businesswire.com/news//home/20171212005059/en/MIPI-Alliance-Opens-Access-MIPI-I3C-Sensor
[2]http://resources.mipi.org/mipi-i3c-v1-download
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
2017-12-12 19:58 ` Boris Brezillon
@ 2017-12-12 22:01 ` Wolfram Sang
-1 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-12-12 22:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 133 bytes --]
> MIPI has opened the I3C spec [1], it can be downloaded here [2].
Wow, that's good news. And so fast. Congrats and thanks a lot!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 0/5] Add I3C subsystem
@ 2017-12-12 22:01 ` Wolfram Sang
0 siblings, 0 replies; 91+ messages in thread
From: Wolfram Sang @ 2017-12-12 22:01 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-i2c, Jonathan Corbet, linux-doc, Greg Kroah-Hartman,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell
[-- Attachment #1: Type: text/plain, Size: 133 bytes --]
> MIPI has opened the I3C spec [1], it can be downloaded here [2].
Wow, that's good news. And so fast. Congrats and thanks a lot!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-12-13 16:20 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-12-13 16:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
Hi Greg,
On Tue, 1 Aug 2017 19:13:27 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > > this way because master IPs are likely to implement advanced queuing
> > > > mechanism (allows one to queue new transfers even if the master is
> > > > already busy processing other requests), and serializing things at the
> > > > framework level will just prevent us from using this kind of
> > > > optimization.
> > >
> > > Unless you can prove otherwise, using a rw lock is almost always worse
> > > than just a mutex.
> >
> > Is it still true when it's taken in non-exclusive mode most of the
> > time, and the time you spend in the critical section is non-negligible?
> >
> > I won't pretend I know better than you do what is preferable, it's just
> > that the RW lock seemed appropriate to me for the situation I tried to
> > described here.
>
> Again, measure it. If you can't measure it, then don't use it. Use a
> simple lock instead. Seriously, don't make it more complex until you
> really have to. It sounds like you didn't measure it at all, which
> isn't good, please do so.
>
I'm resurrecting this thread because I finally had the time to implement
message queuing in Cadence I3C master driver. So I did a test with 2
I3C devices on the bus, and their drivers sending as much SDR messages
as they can in 10s. Here are the results:
| mutex | rwsem |
---------------------------------------
dev1 | 19087 | 29532 |
dev2 | 19341 | 29118 |
=======================================
total | 38428 | 58650 |
msg/sec | ~3843 | ~5865 |
The results I'm obtaining here are not so surprising since all normal
transfers are taking the lock in read mode, so there's no contention.
I didn't measure the impact on performances when there's one
maintenance operation taking the lock in write mode and several normal
transfers waiting for this lock, but really, maintenance operations are
infrequent, and that's not where performance matters in our use case.
I also did the same test with only one device doing transfers on the
bus, and this time the mutex wins, but there's not a huge difference.
| mutex | rwsem |
---------------------------------------
total | 67116 | 66561 |
msg/sec | ~6712 | ~6656 |
Let me know if you want more information on the test procedure.
Regards,
Boris
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-12-13 16:20 ` Boris Brezillon
0 siblings, 0 replies; 91+ messages in thread
From: Boris Brezillon @ 2017-12-13 16:20 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Hi Greg,
On Tue, 1 Aug 2017 19:13:27 -0700
Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > > this way because master IPs are likely to implement advanced queuing
> > > > mechanism (allows one to queue new transfers even if the master is
> > > > already busy processing other requests), and serializing things at the
> > > > framework level will just prevent us from using this kind of
> > > > optimization.
> > >
> > > Unless you can prove otherwise, using a rw lock is almost always worse
> > > than just a mutex.
> >
> > Is it still true when it's taken in non-exclusive mode most of the
> > time, and the time you spend in the critical section is non-negligible?
> >
> > I won't pretend I know better than you do what is preferable, it's just
> > that the RW lock seemed appropriate to me for the situation I tried to
> > described here.
>
> Again, measure it. If you can't measure it, then don't use it. Use a
> simple lock instead. Seriously, don't make it more complex until you
> really have to. It sounds like you didn't measure it at all, which
> isn't good, please do so.
>
I'm resurrecting this thread because I finally had the time to implement
message queuing in Cadence I3C master driver. So I did a test with 2
I3C devices on the bus, and their drivers sending as much SDR messages
as they can in 10s. Here are the results:
| mutex | rwsem |
---------------------------------------
dev1 | 19087 | 29532 |
dev2 | 19341 | 29118 |
=======================================
total | 38428 | 58650 |
msg/sec | ~3843 | ~5865 |
The results I'm obtaining here are not so surprising since all normal
transfers are taking the lock in read mode, so there's no contention.
I didn't measure the impact on performances when there's one
maintenance operation taking the lock in write mode and several normal
transfers waiting for this lock, but really, maintenance operations are
infrequent, and that's not where performance matters in our use case.
I also did the same test with only one device doing transfers on the
bus, and this time the mutex wins, but there's not a huge difference.
| mutex | rwsem |
---------------------------------------
total | 67116 | 66561 |
msg/sec | ~6712 | ~6656 |
Let me know if you want more information on the test procedure.
Regards,
Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
2017-12-13 16:20 ` Boris Brezillon
@ 2017-12-13 16:51 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-13 16:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Arnd Bergmann, Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas,
Bartosz Folta, Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas,
Cyprian Wronka, Alexandre Belloni, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel
On Wed, Dec 13, 2017 at 05:20:43PM +0100, Boris Brezillon wrote:
> Hi Greg,
>
> On Tue, 1 Aug 2017 19:13:27 -0700
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > > > this way because master IPs are likely to implement advanced queuing
> > > > > mechanism (allows one to queue new transfers even if the master is
> > > > > already busy processing other requests), and serializing things at the
> > > > > framework level will just prevent us from using this kind of
> > > > > optimization.
> > > >
> > > > Unless you can prove otherwise, using a rw lock is almost always worse
> > > > than just a mutex.
> > >
> > > Is it still true when it's taken in non-exclusive mode most of the
> > > time, and the time you spend in the critical section is non-negligible?
> > >
> > > I won't pretend I know better than you do what is preferable, it's just
> > > that the RW lock seemed appropriate to me for the situation I tried to
> > > described here.
> >
> > Again, measure it. If you can't measure it, then don't use it. Use a
> > simple lock instead. Seriously, don't make it more complex until you
> > really have to. It sounds like you didn't measure it at all, which
> > isn't good, please do so.
> >
>
> I'm resurrecting this thread because I finally had the time to implement
> message queuing in Cadence I3C master driver. So I did a test with 2
> I3C devices on the bus, and their drivers sending as much SDR messages
> as they can in 10s. Here are the results:
>
> | mutex | rwsem |
> ---------------------------------------
> dev1 | 19087 | 29532 |
> dev2 | 19341 | 29118 |
> =======================================
> total | 38428 | 58650 |
> msg/sec | ~3843 | ~5865 |
>
>
> The results I'm obtaining here are not so surprising since all normal
> transfers are taking the lock in read mode, so there's no contention.
> I didn't measure the impact on performances when there's one
> maintenance operation taking the lock in write mode and several normal
> transfers waiting for this lock, but really, maintenance operations are
> infrequent, and that's not where performance matters in our use case.
>
> I also did the same test with only one device doing transfers on the
> bus, and this time the mutex wins, but there's not a huge difference.
>
> | mutex | rwsem |
> ---------------------------------------
> total | 67116 | 66561 |
> msg/sec | ~6712 | ~6656 |
>
> Let me know if you want more information on the test procedure.
Nice, thanks for testing, so it is a real win here, good!
greg k-h
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [RFC 2/5] i3c: Add core I3C infrastructure
@ 2017-12-13 16:51 ` Greg Kroah-Hartman
0 siblings, 0 replies; 91+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-13 16:51 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Jan Kotas, Cyprian Wronka,
Alexandre Belloni, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
On Wed, Dec 13, 2017 at 05:20:43PM +0100, Boris Brezillon wrote:
> Hi Greg,
>
> On Tue, 1 Aug 2017 19:13:27 -0700
> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>
> > > > > Unless you see a good reason to not use a R/W lock, I'd like to keep it
> > > > > this way because master IPs are likely to implement advanced queuing
> > > > > mechanism (allows one to queue new transfers even if the master is
> > > > > already busy processing other requests), and serializing things at the
> > > > > framework level will just prevent us from using this kind of
> > > > > optimization.
> > > >
> > > > Unless you can prove otherwise, using a rw lock is almost always worse
> > > > than just a mutex.
> > >
> > > Is it still true when it's taken in non-exclusive mode most of the
> > > time, and the time you spend in the critical section is non-negligible?
> > >
> > > I won't pretend I know better than you do what is preferable, it's just
> > > that the RW lock seemed appropriate to me for the situation I tried to
> > > described here.
> >
> > Again, measure it. If you can't measure it, then don't use it. Use a
> > simple lock instead. Seriously, don't make it more complex until you
> > really have to. It sounds like you didn't measure it at all, which
> > isn't good, please do so.
> >
>
> I'm resurrecting this thread because I finally had the time to implement
> message queuing in Cadence I3C master driver. So I did a test with 2
> I3C devices on the bus, and their drivers sending as much SDR messages
> as they can in 10s. Here are the results:
>
> | mutex | rwsem |
> ---------------------------------------
> dev1 | 19087 | 29532 |
> dev2 | 19341 | 29118 |
> =======================================
> total | 38428 | 58650 |
> msg/sec | ~3843 | ~5865 |
>
>
> The results I'm obtaining here are not so surprising since all normal
> transfers are taking the lock in read mode, so there's no contention.
> I didn't measure the impact on performances when there's one
> maintenance operation taking the lock in write mode and several normal
> transfers waiting for this lock, but really, maintenance operations are
> infrequent, and that's not where performance matters in our use case.
>
> I also did the same test with only one device doing transfers on the
> bus, and this time the mutex wins, but there's not a huge difference.
>
> | mutex | rwsem |
> ---------------------------------------
> total | 67116 | 66561 |
> msg/sec | ~6712 | ~6656 |
>
> Let me know if you want more information on the test procedure.
Nice, thanks for testing, so it is a real win here, good!
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2017-12-13 16:51 UTC | newest]
Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-31 16:24 [RFC 0/5] Add I3C subsystem Boris Brezillon
2017-07-31 16:24 ` [RFC 1/5] i2c: Export of_i2c_get_board_info() Boris Brezillon
2017-07-31 16:24 ` [RFC 2/5] i3c: Add core I3C infrastructure Boris Brezillon
2017-07-31 19:17 ` Wolfram Sang
2017-07-31 19:17 ` Wolfram Sang
2017-07-31 20:46 ` Boris Brezillon
2017-07-31 20:46 ` Boris Brezillon
2017-07-31 20:16 ` Arnd Bergmann
2017-07-31 20:16 ` Arnd Bergmann
2017-07-31 21:15 ` Boris Brezillon
2017-07-31 21:15 ` Boris Brezillon
2017-07-31 21:32 ` Peter Rosin
2017-07-31 21:32 ` Peter Rosin
2017-07-31 21:42 ` Wolfram Sang
2017-07-31 21:42 ` Wolfram Sang
2017-08-01 16:47 ` Andrew F. Davis
2017-08-01 16:47 ` Andrew F. Davis
2017-08-01 17:27 ` Wolfram Sang
2017-08-01 17:27 ` Wolfram Sang
2017-08-01 21:47 ` Boris Brezillon
2017-08-01 21:47 ` Boris Brezillon
2017-08-02 10:21 ` Wolfram Sang
2017-08-02 10:21 ` Wolfram Sang
2017-08-01 12:00 ` Arnd Bergmann
2017-08-01 12:00 ` Arnd Bergmann
2017-08-01 12:29 ` Boris Brezillon
2017-08-01 12:29 ` Boris Brezillon
2017-08-01 13:11 ` Arnd Bergmann
2017-08-01 13:11 ` Arnd Bergmann
2017-08-01 13:34 ` Boris Brezillon
2017-08-01 13:34 ` Boris Brezillon
2017-08-01 13:58 ` Boris Brezillon
2017-08-01 13:58 ` Boris Brezillon
2017-08-01 14:22 ` Arnd Bergmann
2017-08-01 14:22 ` Arnd Bergmann
2017-08-01 15:14 ` Boris Brezillon
2017-08-01 15:14 ` Boris Brezillon
2017-08-01 20:16 ` Arnd Bergmann
2017-08-01 20:16 ` Arnd Bergmann
2017-08-01 14:12 ` Wolfram Sang
2017-08-01 14:12 ` Wolfram Sang
2017-08-01 14:48 ` Boris Brezillon
2017-08-01 14:48 ` Boris Brezillon
2017-08-01 15:01 ` Wolfram Sang
2017-08-01 15:01 ` Wolfram Sang
2017-08-01 15:20 ` Boris Brezillon
2017-08-01 15:20 ` Boris Brezillon
2017-08-03 8:03 ` Boris Brezillon
2017-08-03 8:03 ` Boris Brezillon
2017-08-16 21:03 ` Geert Uytterhoeven
2017-08-16 21:03 ` Geert Uytterhoeven
2017-08-17 7:48 ` Boris Brezillon
2017-08-17 7:48 ` Boris Brezillon
2017-08-01 1:40 ` Greg Kroah-Hartman
2017-08-01 1:40 ` Greg Kroah-Hartman
2017-08-01 10:48 ` Boris Brezillon
2017-08-01 10:48 ` Boris Brezillon
2017-08-01 17:51 ` Greg Kroah-Hartman
2017-08-01 17:51 ` Greg Kroah-Hartman
2017-08-01 21:30 ` Boris Brezillon
2017-08-01 21:30 ` Boris Brezillon
2017-08-02 0:54 ` Greg Kroah-Hartman
2017-08-02 0:54 ` Greg Kroah-Hartman
2017-08-02 2:13 ` Greg Kroah-Hartman
2017-08-02 2:13 ` Greg Kroah-Hartman
2017-12-13 16:20 ` Boris Brezillon
2017-12-13 16:20 ` Boris Brezillon
2017-12-13 16:51 ` Greg Kroah-Hartman
2017-12-13 16:51 ` Greg Kroah-Hartman
2017-08-17 9:03 ` Linus Walleij
2017-08-17 9:03 ` Linus Walleij
2017-08-17 9:28 ` Boris Brezillon
2017-08-17 9:28 ` Boris Brezillon
2017-07-31 16:24 ` [RFC 3/5] dt-bindings: i3c: Document core bindings Boris Brezillon
2017-07-31 16:24 ` Boris Brezillon
2017-08-09 23:43 ` Rob Herring
2017-08-09 23:43 ` Rob Herring
2017-08-10 8:49 ` Boris Brezillon
2017-08-10 8:49 ` Boris Brezillon
2017-07-31 16:24 ` [RFC 4/5] i3c: master: Add driver for Cadence IP Boris Brezillon
2017-07-31 16:24 ` [RFC 5/5] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2017-07-31 19:17 ` [RFC 0/5] Add I3C subsystem Wolfram Sang
2017-07-31 19:17 ` Wolfram Sang
2017-07-31 20:40 ` Boris Brezillon
2017-07-31 20:40 ` Boris Brezillon
2017-07-31 20:47 ` Wolfram Sang
2017-07-31 20:47 ` Wolfram Sang
2017-12-12 19:58 ` Boris Brezillon
2017-12-12 19:58 ` Boris Brezillon
2017-12-12 22:01 ` Wolfram Sang
2017-12-12 22:01 ` Wolfram Sang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.